NXT Programming lesson 9

Lesson 9 description

Date: 11. November 2010

Duration of activity: 12 - 17

Group members participating: Nikki & Knud

---

GOALS for lesson 9:

Our goal is to make the robot able to get back to its starting point, after some random movement.

Plan for achieving the goals:

We plan to achieve the “return to start” goal, by implementing navigation using the tacho counter on the motors combined with the wheel diameter and track width [Bagnall07]. We want to translate all movement into a x,y position with reference to the starting point 0,0, and thereby using a coordinate system as a map. This method of positioning is also called Dead Reckoning [Ridgesoft05]. We will try to implement the method proposed in [Ridgesoft05]. By having a x,y position of the robots current position, we should be able to get back to 0,0 (the starting point).

Dead reckoning positioning has some inherent disadvantages. If there is an insignificant error in the positioning measurement, it will accumulate over time/movement to a significant error, also called drifting. It is virtually impossible to avoid small errors in the measurements. The errors are introduced by small imprecision in the tacho-counter of the motors (as Bagnall notes in chapter 12 [Bagnall07]), wheel-slipping, etc. It is impossible to correct an accumulated error by only using self-centric measurements, we would need an external reference, like a GPS position, infrared receiver on the robot and transmitters placed strategically in the room it is navigating, etc.

An alternative to navigating by coordinates, is using a memory map of recognized landmarks [Mataric97]. We will not investigate this further, as we are constrained by time.

Results:

To test the accuracy of using the tacho for navigation, we used the TachoPilot class (http://lejos.sourceforge.net/nxt/pc/api/lejos/robotics/navigation/TachoPilot.html) in two simple programs, one that make the robot drive forward 1 meter,and one that makes it move in a square. We attached a marker to the robot, so we could measure the distance and turning angles.

With the first program, we measured the marked line to 97 cm where it should have been 100 cm, we assess this mainly to be because of the error in the tacho measurements of the motors.

With the program that was supposed to make the car draw a square we encountered that while the car was driving on whiteboard at first, it didn't make 90degree turns, but rather 20degrees turns. This was caused by excessive wheel slipping and wrong measure of the track width. The mounted marker lifted the wheels a little and as a result of that tracking of the wheel became worse on an already slippery surface. The incorrect track width measurement was due to confusion of how to measure the track width. The track width should be measured from the center width of the wheel, while our first measurements was from the inside and the outside of the wheels. After correcting the track width and adjusting the marker so less lifting occurred, it moved in a acceptable square.

The picture below shows the result of drawing a square, after the above errors were corrected

We found that dead reckoning positioning is already implemented in the lejos SimpleNavigator class (http://www.mathcs.org/robotics/nxt-java/lejos-api/lejos/robotics/navigation/SimpleNavigator.html)
Instead of writing our own implementation, we used the SimpleNavigator and ran some tests.

To test the accuracy of the dead reckoning positioning we placed a coin at the starting position of the robot and did the following:

• Move forward for 2 seconds
• Turn 90 degrees
• Move forward for 2 seconds
• Return to start position (0,0) and starting angle
• Repeat 3 times

The following video show the robot complete the movement and how the small position errors accumulate, by comparing the end position of the robot to the reference starting position, the coin.

Conclusion:

The accuracy of dead reckoning by using the tacho count is very dependent on measuring the correct track width and wheel diameter. Furthermore it is also dependent on no wheel-slipping on the surface. It is virtually impossible to avoid accumulating errors, because of these factors and imprecision in the motor tacho counter.

We tried to minimize errors by using smaller wheels and a longer axle. In theory this should make it more precise, as an error in the tacho count has less impact as more rotations are required. This proved not to hold, probably because of the axle bending under the weight of the robot. A better robot design would make the axle more stable and should make it more accurate.

Source code:
http://www.liscom.dk/lego/Lab9Navigation/Navigation.java 
http://www.liscom.dk/lego/Lab9Navigation/Localizer.java 

References:

Bagnall07:
Brian Bagnall 2007, Maximum Lego NXT: Building Robots with Java Brains, Variant Press, ISBN-10 0973864915

Ridgesoft05:
Ridgesoft 2005, Enabling Your Robot to Keep Track of its Position
(http://www.ridgesoft.com/articles/trackingposition/TrackingPosition.pdf)

Mataric97:
Maja J Mataric Jun 1992 304-312, Integration of Representation Into Goal-Driven Behavior-Based Robots, in IEEE Transactions on Robotics and Automation (http://www-robotics.usc.edu/~maja/publications/ieeetra92.pdf)