Preamble
During the 2022 RoboCup Season, I tried to implement a fully vision-based approach with 2 of my RoboCup Junior Rescue Line teams. Such an approach allowed us to perform object detection from a much greater range, giving the robot more opportunities to pose itself in an optimal way to grasp and manipulate objects such as the Rescue Kit.
However, deviating from the set path in a dynamic manner meant that the robot would have to return to its initial pose to move on with other tasks. The most convenient way to do this would be to utilise the Encoders on each motor to perform Odometry. Odometry is the use of motion sensors to determine the robot’s change in position relative to some known position (MIT CSAIL), and is a strategy that worked well enough given the generous tolerances afforded by the use of a camera.
Later in the year, as my teams were preparing for the World Robot Olympiad (WRO), I pondered about the usefulness of Odometry for EV3 robots competing in WRO. Precise odometry could see uses from determining the heading of the robot without the use of the Gyro sensor to dynamic movement between specific landmarks in the absence of features.
With my severely overbuilt teaching robot, I spent a couple minutes cobbling together this program in EV3-G to better understand the possibilities with EV3 Odometry.
The basic Idea
The basic Kinematic and Dynamic analysis of a Differential Drive Vehicle is of paramount importance for success at a competition like WRO where speed and precision is requisite. To that end, I make sure to recapitulate these concepts with my students before the start of each season. This set of notes from Caltech provides a decent summary for the uninitiated.
In this program, the initial reference frame (0 angular displacement, 0 translational displacement) is captured when the middle button of the EV3 is pressed. Following which, we capture the angular displacement of the left and right motor encoder at each loop, determining the new pose of the robot. We continue to accumulate these pose updates until the middle button is pressed again. As a differential drive is non-holonomic, we turn to face the origin, move until we are at the origin, and turn again to revert to the original heading. These 3 actions are done with simple proportional control.
Analysis of Errors
After going through a short but winding path, the robot is about 5cm off the initial position, with significant angular error. Some sources of error may include:
- Encoder Resolution
In this build, the wheels used had a diameter of 62.4mm. With an angular resolution of 1 degree, we smallest increment we can measure is 0.54mm. While this may not seem like much, the error is cumulative, and compounds with every loop. - Axle Track Variability
The other major source of error comes from the variation in Axle Track as the robot drives. These wheels measure 20mm across. Even if they were to be perfectly rigid, the Axle Track could vary by as much as 40mm on a robot that measures less than 250mm across. Unfortunately, perfect rigidity is also not a realistic assumption. The tyres exhibit some camber and deformation as the robot is moved. Taken together, this results in the measured heading of the robot quickly diverging from the true heading of the robot when the robot is turning. Note that Axle Track is not a variable in the Kinematic equation of a robot that is only translating forwards and backwards. In this case, the model of the robot can be simplified to a one-wheeled robot as there is no difference between left and right wheel velocities. - Others
Other less significant sources of error may include the Time Discreteness of Pose Updates (wheels are assumed to have constant angular velocity through the time step), Floating Point Precision, Wheel Diameter Estimation (official dimensions used without accounting for tolerance, wear, changes due to angular velocity etc.), Rolling Without Slipping, Motor Backlash etc.
Finally, it is worth noting that the robot seemed to have achieved a more precise heading after the first turn, and veered off during the straight phase. This may suggest that moving while performing Odometry computations may have been too computationally demanding, especially when considering that the EV3 does not have a dedicated Floating Point Unit (FPU). Unfortunately, the few minutes I had for this experiment were up so I was not able to perform further tests.
Usefulness
Some sources of error mentioned above can be reduced with material or design choices. For instance, using a smaller and narrower tyre (e.g. Tyre Technic Wedge Belt with a diameter of 27mm and a contact width under 4mm), increasing Axle Track, and increasing rigidity.
However, where changing these may be suboptimal, using pure odometry may still be helpful in understanding rough positions in the absence of other dedicated sensors, and in movements that are shorter and less winding.
Odometry may be most useful in cases where other sensors can be used for fusion. Traditionally, these come from an Inertial Measurement Unit (IMU), which may contain sensors such as Accelerometers, Gyros and Magnetometers in various axes. In the LEGO EV3 context, and especially in WRO, loop closure can be done via features detected by Colour Sensors and Ultrasonic Sensors.
If localisation is of utmost importance, consider using the Robot Inventor or the less cost effective SPIKE Prime system to make full use of the in-built IMU. Python programmers can also leverage on the work that Pybricks has done!
Footnote
I have taken the robot apart a long time ago and have neither the Building Instructions nor the Code. While I will not be able to provide these, I will try my best to answer questions.
