Wheel odometry#
What wheels measure well, what they don’t, and how to split the work with the IMU.
The basic idea#
To know where it is, a robot keeps answering two questions:
How far did I move forward? This is the forward speed,
vx.How much did I turn? This is the turn rate,
vyaw.
Two sensors can answer both questions: the wheel encoders and the IMU (more exactly, the gyro inside it). But each one is good at one question and bad at the other.
Why wheels are bad at turning#
Wheel odometry works out turning with a simple rule: if the right wheel turned this much more than the left, the robot turned this much. That rule is only true if the wheels never slip.
Now take a skid-steer robot: four wheels, no steering, turning like a tank. To turn, its wheels have to slide sideways across the ground. There is no other way for it to turn. So:
The wheels say “we turned 90°”, but the robot may have turned only 60°.
The gap changes with the ground: one value on asphalt, another on grass, something else again in mud.
If you take the heading from the wheels, the robot keeps thinking it faces the wrong way. And a small heading error grows into a large sideways error as the robot keeps driving.
Not every robot slips like this. Differential and car-like robots barely slip, while mecanum and tracked robots slip even more. See Wheel odometry by drive type for all seven drive types compared.
Why the gyro is good at turning#
The gyro doesn’t look at the wheels at all. It measures how fast the robot’s body rotates, directly. Slippery ground or sliding wheels make no difference: if the robot really turned 60°, the gyro says 60°.
Why the IMU is bad at moving forward#
An IMU can’t measure forward speed. It only measures acceleration. To get speed you have to integrate that acceleration over time, and even a tiny error in it keeps adding up. Within a few seconds the speed estimate is useless.
There is a second problem: at constant speed the acceleration is zero. To the IMU, driving at a steady speed looks almost the same as standing still.
Wheels, on the other hand, measure forward distance well. Driving straight, the wheels slip very little.
The answer: split the work#
Forward speed ( |
Turn rate ( |
|
|---|---|---|
Wheels |
✅ Good |
❌ Bad, because of slip |
IMU (gyro) |
❌ Bad, errors build up fast |
✅ Good |
Ask each question to the sensor that is good at it:
vxfrom the wheelsvyawfrom the gyro
In a robot_localization config this looks like:
odom0: /wheel/odom
odom0_config: [false, false, false, # x, y, z
false, false, false, # roll, pitch, yaw
true, true, false, # vx, vy, vz (vy = 0, no sideways motion)
false, false, false, # vroll, vpitch, vyaw <- not from wheels
false, false, false] # ax, ay, az
imu0: /imu/data
imu0_config: [false, false, false, # x, y, z
false, false, false, # roll, pitch, yaw
false, false, false, # vx, vy, vz
false, false, true, # vroll, vpitch, vyaw <- from the IMU
false, false, false] # ax, ay, az
Note
An everyday comparison. Picture someone walking with their eyes closed. By counting steps they know quite well how far they walked: that’s the wheels. But guessing how much they turned from their steps is hard. Their inner ear feels turning very well: that’s the gyro. Using both, they get lost much less.
One catch: gyro bias#
A gyro has a small bias that slowly drifts over time. Over seconds and minutes it is still far better than the wheels for turning. The chart below shows the difference on a 10-minute drive with a 90° turn every 40 seconds.
Heading error over a 10-minute drive
Simulated example, not a recording. Real logs from the robot are coming.
The wheel error jumps at every turn, because every turn slips, and it never goes back down. The gyro error only creeps up slowly. But after hours of driving the gyro drifts too. That is where outside references like GPS with RTK and LiDAR come in. See LiDAR odometry with ICP.
A few emails a month. Unsubscribe anytime.