Java – a better way to design this algorithm?
I'm working on a more complex version (the vehicle moves in X and Y directions)
I did this example to get a better way to achieve this
>I have a car moving in the X direction (24.5872 km) > I simulate this by using the actuator to increment the x value every 100ms (to keep its x position more accurate and real-time) > after every second, I send a message to another process and the xmin and xmax values of the line I just covered > the other process will respond to a JMS message (usually immediately) telling me to stop, If there is a "hole" in the previous x area (message callback msg to a linkedblockingqueue)
The problem I encountered was the "usually immediate" part If I don't get enough response, I think it will abandon my algorithm all the time What is a better way to deal with this situation?
Here are some basic codes I want to do:
public class Mover implements MessageHandler {
private static final long CAR_UPDATE_RATE_IN_MS = 100;
private static double currX = 0;
private static double CONSTANT_SPEED_IN_MPS = 24.5872; // 55 mph
private static double increment = CONSTANT_SPEED_IN_MPS / (1000 / CAR_UPDATE_RATE_IN_MS);
static LinkedBlockingQueue<BaseMessage> messageQueue = new LinkedBlockingQueue<BaseMessage>(); // ms
private static int incrementor = 0;
public static void main(String[] args) {
startMoverExecutor();
}
private static void startMoverExecutor() {
scheduledexecutorservice mover = Executors.newSingleThreadScheduledExecutor();
mover.scheduleAtFixedRate((new Runnable() {
@Override
public void run() {
currX = incrementor * increment;
if (incrementor % (1000 / CAR_UPDATE_RATE_IN_MS) == 0) {
System.out.println(currX);
sendMessage(currX - CONSTANT_SPEED_IN_MPS,currX);
// do something
try {
messageQueue.poll(1000,TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
incrementor++;
}
}),CAR_UPDATE_RATE_IN_MS,TimeUnit.MILLISECONDS);
}
@Override
public void handleMessage(BaseMessage msg) {
messageQueue.add(msg);
}
protected static void sendMessage(double firstX,double secondX) {
// sendMessage here
}
}
Solution
I am proposing changes to the above algorithm as shown above
JMS calls other processes
1A. Start by sending the current vehicle position
1B. Another process will respond to a JMS message containing a list of all "row hole locations" in the visible area of your vehicle location Keep the "visible pot hole position" in this list on the client for use in the following steps
1C. We define the visual area as the adjacent area of the vehicle. Even if JMS is used to call other processes (1 second delay, network delay), the movement of the vehicle should not pass through this area
1D. After every second, repeat steps 1a and 1b and replace the list of pot hole positions of the client relative to the current position of your vehicle
.
On board sports observer
2A. Implement observer mode that can receive vehicle action notification
2B. Each time an event occurs, the observer will check whether the position of the vehicle matches an entry in the list of visible holes obtained in step 1b
2C. If a match is found, bingo! You must stop
.
Vehicle movement
3A. Register a step-2a observer to observe the movement of the vehicle
3B. Wait until you reach the first visible pit list from step 1b
3C. Increase the x value every 100 milliseconds to start moving the vehicle The observer in step 2A shall be informed of each movement
.
The following figure shows:
o - Instance of each pot hole somewhere on map X - Moving vehical . - Path followed by vehical Circle - Visible area of the vehical driver
+---------------------------------------------+ | | | o o | | o | | | | | | _.-''''`-._ | | o,' `. o | |,' o `. | | .' . `. | | | . . | | | | . | o | | | X | | | o \ o / | | \ / | | `.,' | | `-._ _.-' | | `'''' | | | | o | | o | | | | | | o o | +---------------------------------------------+