Thursday, November 18, 2010

Lab Exercise 9

Date:
11/11 2010

Duration of activity:
3 hours

Group members participating:
Frederik, Christian & Lasse

Goals:
The main goal is to keep track of the position and direction (pose) of a Lego car by using the tacho counters. 

Plan:
1. Experiment with the SimpleNavigator class (instead of TachoNavigator which is deprecated)
2. Experiment with navigation while avoiding obstacles

Results:

1. Navigation

The first experiment was to make the car move to different positions and then return to the start position and thereby observe the accuracy. To get a better idea of the accuracy we mounted a whiteboard marker on the car and thereby made the car trace its own path on a whiteboard placed horizontally on the floor. The car with the marker mounted is seen below:



We made a route with 4 waypoints ending at the start point and saw an inaccuracy of approximately 10 cm as seen in the video below. As Brian Bagnall [1] also states the main source of error is the tacho rotation but wheel spin is also a source of error as we also experienced in the Lego race lab exercise. 




To avoid the wheel spin we experimented with a paper surface instead of the whiteboard. The idea behind using paper as surface was that we assumed 1) that the tyres would have better traction than on a slippery whiteboard, and 2) that the paper would easier slip on the surface of the whiteboard than under the tyres of the vehicle. We actually didn't notice a huge difference but when we tried to use the Reverse property in the TachoPillot constructor we got an even worse behaviour. We also noticed that the starting angle of the rear wheel has an impact of the result. So we concluded that performances on the two different surfaces were roughly the same.


2. Navigation with obstacle avoidance
We mounted the ultrasonic sensor on the Lego car to be able to detect obstacles in front of the car. The SimpleNavigator was investigated by means of its behaviour when a goTo()-action is aborted, because this will be the case when avoiding obstacles. We wanted to make the car continue when aborted in a goTo() action. We did this by creating a Thread to simulate the avoidance behaviour and thereby blocking the navigation thread. The navigator thread uses a flag to determine if the goTo()-action was finished or aborted, if aborted the command should be repeated. This principle was used for a set of positions where an obstacle was placed in the way of the path - this scenario can been on the video below:



The code is found in the class BlighbotExtended [2] and the avoidance is done in the method avoider():



The handling of the positions is done in the main thread where the flag as mentioned before is used to check for interruption: 





Conclusion:
When using the tacho counter we observed and measured that the distance travelled by using tacho count was very accurate but the rotation was not. To improve the rotation accuracy additional control of the motors is needed because the inaccuracy occurs because the motors "may not stop smoothly at the target angle if called when the motor is already moving" [3]. The implementation should be less fluent like our implementation for the Lego race[4] where the car stopped before each rotation.

As seen on the second video the vehicle is able to avoid an obstacle dynamically appearing in front of it. The chosen method for this avoidance is to let the vehicle stray a given distance to one side, when an obstacle is detected, and when finished this avoidance, recalculate the direction needed to obtain the original goal. This simple method has a problem if the next goal is too close the obstacle, because the obstacle could be in the path needed to reach the goal. A solution to this could be to Add More Sensors. Alternatively a more complex algorithm for letting the vehicle work itself around the obstacle could be used, but this method might also require More Sensors.

References:
[1] Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.