marvin:lab9

**Date:** November 14th 2008

**Duration of activity:** 8-13

**Participants:** Kasper, Bent and Johnny

Make a robot that drives from one point to another, using *(x,y)* coordinates, while avoiding obstacles.

- Build a car fit for navigation.
- Find out how to use the tacho counter.
- Write and test navigation program.
- Calibrate the navigator, using the wheel size and track width.
- Find out how to use the compass.
- Find out how to use the two navigator classes, and decide on which one to use.

The car was build using the instructions from ^{1)} since this design is very suitable for this purpose as it has a relative long distance between the centres of the left and right wheel - thus resulting in higher resolution from the tacho-counters on 360 degrees. We decided to use very flat wheels with a higher diameter than suggested in the design in order to eliminate bouncing from the wheels. The higher diameter will reduce the number of tacho-readings and hence the precision. We argue that the change in tacho readings due to the small difference in diameter is negligible.

The use of the tacho counter is an integrated part of the navigator class. The function TachoNavigator() uses the tacho readings together with the measures of the wheel diameter and distance between the centres of the wheel to navigate in a cartesian coordinate system. Another function goTo() enables the car to move to any point in the coordinate system. This function automatically rotates the robot in the direction specified by the coordinates. The command goTo(100,100) will turn the car in a 45 degree angle and travel the distance dictated by the laws of Pythagoras. These functions form an easy basis for the navigation program.

CompassNavigator^{2)}
TachoNavigator^{3)}

As a starting point we measured the wheel diameter and the distance between the centre of the two wheels. These distances are measured in cm and the values are parameters of the function TachoNavigator(). To calibrate the first parameter, wheelDiameter, we tested Marvin to travel 2.00m on a straight line. If he goes beyond this distance, the program uses too many rotations, which indicates the wheelDiameter is set too small compared to reality. After some tests the wheeldiamter was set to 6.9cm. Thereafter we can calibrate the distance between the centre of each wheel by choosing Marvin to make N rotations around its own axis. We decided to make 4 rotations and experimenting with the parameter, trackWidth, while keeping wheelDiameter constant. The calibrated value was set to 17.68cm.

If both calibrations were precise the robot should be able to navigate precisely around in a cartesian coordinate system. The testrun is shown on the figure below together with a video of the performance. There seems to be a weakness in the rotations, but the distance is very accurate. One way to improve the precision during rotations could be to add a compass.

We do not know much about the compass as to how it measures and whether the readings from 0 to 360 degrees are truly linear. But we assume the compass has a higher precision than the tachometer readings and we also assume the output readings from the compass to be a linear function of the sensor input.

There were magnetic disturbances at the test area, which of course made the compass inaccurate.

The precision of the compass was tested by placing a marker on the robot. In this way we can simply measure the deviation by letting the robot turn on a whiteboard and measuring the angle. A little noise was added to these measurements as the slippery surface of the whiteboard caused the wheels to spin a little. The acceleration was too high for this surface and one could have reduced the motor power.

Due to problems with the compass which comprised both magnetic disturbances and a misinterpretation of the compass directions in the given coordinate system we did not reach a satisfactory implementation of the combined navigation system. The best performance was achieved without the compass, but we do not conclude on the precision of the compass, as it may still improve the overall precision when properly implemented in a suitable environment. Neither did we experiment with avoiding obstacles when travelling from point A to B. This may be achieved through a behaviour based program using the goto() function as it provides an easy way to store the alternations on the initial path and thereby finding the correct final destination anyhow.

The final code: navigatingcar.tar.gz

Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.285 - p.302.

marvin/lab9.txt · Last modified: 2009/01/12 09:04 by deva