Finding your place in the world

Starting up:
Participants: Johan & Jakob
Date: 11/11-2010
Duration: 6 Hours
Goal: Experiment with different approaches regarding calculating the position of the robot


Out-of-the-box
In the current version of Lejos ( 0.85 beta ) the package nxt.robotics, provides among other things SimpleNavigator and TachoPilot. SimpleNavigator allows the programmer to control the robot in terms of a cartesian coordinates, if given a pilot class. The pilot class gives the navigator a more abstract control over the robot. The two tables below gives the distance from the starting point to the end point of a four-step route with the robot starting in (0,0) and trying to stop in (0,0). 

Wheel diameter(mm):	Error(cm):
81.6	50
81.6	65
81.6	80
81.6	75
49.6	15
49.6	22
49.6	13
49.6	7
49.6	7

As is seen from the above, the smaller wheel size actually did quite well with regards to returning to the robots point of origin, while the big wheels caused the robot to be so bad at returning to its starting position, that an external observer would not have been able to determine that returning to the beginning was the intended behaviour of the robot. We attribute this to the fact that even a tiny error in the motor usage can trigger a large discrepancy of the course when actuated with larger wheels attached.
Regarding the difference in the robots ability to determine distance versus its aptness with regard to do precise turns, this can also be attributed to the same issue. Especially with the large wheels, this is accentuated, but even with the smaller wheels attached, a slight error in angle, will over distance grow to a large error regarding distance from the outset. This only becomes truer with regard to turning as the changes in motorrotation to turn is quite more minute that the more rough movement necessary just to go straight.
We had the added problem of being unable to get the robot to drive in straight lines as it curves a bit to the right when trying to go straight, we attribute this to poor construction and more significantly differences in motors. We tried with a few different motors, and where able to get a bit better results, but it is still a possible course that can be taken to improve further upon the robots general performance.


From A to B ( via Z?)
The challenge now is to propose a solution that takes care of obstacles while navigating the world as a simple cartesian coordinate system. Concretely that means that you must be able to use goTo(x,y) and even though there exists an obstacle between your current position and (x,y) end up at (x,y). In earlier weeks we have built wall-followers, line followers and more generic avoidance bots. We have devised a very basic strategy building on the fact that as long as we only use goTo(x,y) calls rather than interact directly with the motors the state is consistent with the robots actual position, if not absolutely then at least as good as we generally can maintain the state. Thusly we can for each goTo(x,y), when detecting an object ( via touch, ultrasonic or more arcane means ), go off on some non-parellel vector from our current direction, and then when satisfied call goTo(x,y) again. We have tried to illustrate this approach on this picture:

This approach should work, given that we at all times can obtain the vector between our current position and the desirable end position.


Better sensing

In [2] they use "states" to differentiate between turning and moving straight forwards. When moving straight the average of the encoders are used to determine the distance traversed by the robot. This gives a certain error margin which grows as the bot travels further if the wheels or motors are not correctly calibrated or have defects. When turning the method utilizes trigonometric calculations to calculate a new heading based on the number of counts on each wheel, this method (assuming the wheels do not slip) is quite accurate.

The kinematics approach uses both counters constantly and does not differentiate between moving and turning. By calculating a new position for each step it is able to make smooth turns and because it does not assume that moving straight forward equals the average count of each wheel, it is better able to keep track of its position. It also, of course, assumes that the wheels do not slip on the surface, as all the calculations are based around the number of counts on each wheel.

Because the kinematics approach does not use as many assumptions, it is more accurate when determining the position of the robot.

Based on the observations from testing the lejos navigation system we believe that the system is very similar to the algorithm in [2], since the robot sometimes diverged due to crooked tires and it made no attempt to compensate for this on the return trip. We believe that using the kinematics solution would have given the robot a more accurate position of itself, thereby enabling it to compensate for the error on the return trip.

References

• [1],
  Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains,
  Chapter 12, Localization, p.297 - p.298.
  
  
  
• [2],
  Java Robotics Tutorials,
  Enabling Your Robot to Keep Track of its Position. You could
  also look into
  Programming Your Robot to Navigate to see how an alternative to
  the leJos classes could be implemented.
• [3],
  Maja J Mataric,
  Integration of Representation Into Goal-Driven
  Behavior-Based Robots, in IEEE Transactions
  on Robotics and Automation, 8(3), Jun 1992, 304-312.
  
• [4],
  leJOS Tutorial: Controlling Wheeled Vehicles
  
  
• [5],
  Thomas Hellstrom,
  Foreward Kinematics for the Khepera Robot