Programming the robot car

The robot car have only a few functions, which is:
- Communicate with the PC through bluetooth.
- Drive as ordered from the PC.
- Measure the light levels with the 3 light sensors.
- Measure the direction with the compass.
- Stop at the border.

Behavior-based implementation
All the function except the stop at the border is a sequence of things which have to be executed in the right order. But the stop at the border have to run parallel with this sequence because it have to stop the car if it reaches the border.
For this reason it will be appropriate to use behavior-based architecture with a thread for the sequence and one for the stop at the border.

Before the threads are started there will be calibration of the compass and connection to the PC.

The sequence have to receive orders from the pc, complete the order(turn and drive), measure the light levels at the destination and send these values back together with the compass value.
The stop at border have to stop the car if it detect the black color i the direction it is driving. This have to change the order so the car won't drive any further when it returns to the sequence thread.

The implementation was based on Maja J. Mataric's article [3] and the work we made in lab lesson 10. Because the car have different functions this time we rewrote the car class and the behavior class. The new car class was based on the CompassPilot class, which had the functions we needed to navigate on the map.
Based on this we implemented the two threads and started them in a main program. But when we executed the program we got an exception. After some work to avoid the exception we decided to give up the behavior-base architecture.

One thread implementation with stop at the border
The failure of the behavior-base implementation lead to a simpler implementation with only one thread which structure was build on the structure of the sequence thread mentioned above.
In addition the immediateReturn opportunity of the rotateTo og travel functions, and while the car was traveling we made the program execute a while loop were it was looking for the black color, and stop the car if the color was detected.

This program was executeable and we made some tests with it. In these tests the car didn't always stop rotating or driving forward. By removing the immediateReturn option the car was driving more stable, even though we had some trouble with the magnetic field was changing very quickly on the map at some positions in the lab(more about that in the description of the tests).

Removing the immediateReturn also removed the possibility to detect the black border.

One thread implementation without stop at the border
The code for the robot car have yet another time been simplified with the removal of the detection of the border. But now we have a working robot car with exception of the boarder detection. The consequence of this is that we can't drive blind around on the map, but have to look at the cars position on the map before we gives a order to make sure the car isn't driving out of the map.

The previous implementations had a calculation of a direction according to a local north which was initialize in the beginning. But this was removed because it might be the source to some errors we experienced. The removal of this made the code even more simple, but as consequence the map have to be adjusted to the real north according to the compass.

The implementation of the robot car included 3 classes listed and linked to here:
- MCLcar.java
- carBT.java
- myOrders.java

MCLcar.java is preforming initialization and the sequence described above.
carBT.java is the functions that makes the bluetooth connection possible.
myOrders.java is use to pass the orders received form the pc through bluetooth to the MCLcar.java.