This is the second of a series of posts on leJOS navigation. The first dealt with pilots, which move mobile robots around.
This post deals with pose providers which implement localization, i.e. they tell you where your robot is.
The robot’s pose is its position and heading in space. In two-dimensional navigation, this is typically represented by an x and a y co-ordinate to define its position, and a heading angle.
The Pose class defines the pose.
The heading is given in degrees, and standard mathematical conventions are used, so heading zero is parallel to the x axis, and +90 parallel to the y axis. On the screen or on paper this is typically represented with a horizontal x axis with positive values to the right, and a vertical y axis with positive values going up. When the robot heading changes by a positive value, it turns anti-clockwise. As with distance moved by pilots, the x and y values can be in any units, but the units must be used consistently everywhere.
A pose provider is a class that determines the robot’s pose. All pose provider classes implement the PoseProvider interface.
There are several different ways of determining a robot’s pose. The most common is by odometry and dead reckoning using the tachometers built into the Mindstorms motors. This is what the OdometryPoseProvider class does.
The constructor for OdometryPoseProvider takes a MoveProvider (e.g. a pilot) as a parameter. When the pilot completes a move, the OdometryPoseProvider calculates the new Pose, and you can request the intermediate pose while a move is in progress. In both cases, you obtain the current pose by calling the getPose method. There is also a setPose method to set the initial pose of a robot.
OdometryPoseProvider also implements the SampleProvider interface, so you can also obtain the pose as if it were a sample coming from a sensor.
You can add a pose provider to any application that you have that uses a pilot, and it will keep track of the robot’s pose. This is true for any application that uses a pilot, whatever pilot methods it is using. It makes it very easy to add localization to any navigation application.
Working out the pose of a robot using just odometry and dead reckoning is not very accurate. After the first few moves you will typically get a good estimate of the pose, but as more moves are done the error accumulates and eventually the estimated pose drifts a long way from reality.
If getting an accurate pose for the robot and maintaining it over many moves is important for your application, you will need to use another pose provider to supplement or replace the odometry pose provider.
CompassPoseProvider uses a combination of odometry and the compass heading from any compass sensor to give a pose where the heading is more accurate and does not deteriorate over time.
BeaconPoseProvider uses triangulation to calculate the pose of a robot from beacons. It requires an implementation of the BeaconLocator interface. This usually requires a custom sensor, and leJOS does not currently include any classes that implement this interface.
MCLPoseProvider uses Monte Carlo Localization to calculate the robot’s pose using a map and a range finding sensor such as the EV3 Ultrasonic sensor. It will be the subject of another blog post.