Odometry and why its errors add up

TL;DR:

• Odometry computes position by adding up small motions from wheel encoders, so every small error stays in the answer.

• A heading error is the worst kind, because it points every later step in the wrong direction.

• Correct odometry by calibrating wheel size and track width, and by fusing it with a gyroscope, landmarks or a map.

Tell a robot to drive straight for 10 m, and it comes to a stop 1.6 m to the side of where it should be. The wheels never slipped, the motors worked, and the code had no bug. One wheel was a half-millimeter smaller than the other. That is odometry: a very simple idea with surprisingly large consequences.

What odometry is

Odometry estimates how far a robot has moved from how far its wheels turned. An encoder on each wheel counts ticks as the wheel rotates. Multiply the ticks by the distance per tick to get how far each wheel rolled, then combine the left and right distances to get the robot's forward movement and turn (see differential drive). Add this up over time, and you have the robot's pose, a method called dead reckoning.

For a differential-drive robot with left and right wheel distances dL and dR in one time step and track width W:

d = (dL + dR) / 2 and Δθ = (dR − dL) / W

The pose is then updated by moving d forward along the current heading and adding Δθ to the heading.

Worked example: a small wheel error on every meter driven

A robot has wheels of radius 0.050 m, encoders with 1000 ticks per revolution, and a track width W = 0.30 m. The program assumes both wheels have radius 0.050 m.

1. Distance per revolution: 2π × 0.050 = 0.3142 m. So one tick is 0.3142 / 1000 = 0.314 mm.

2. Ticks for 10 m: 10 / 0.3142 = 31.83 revolutions, or about 31,830 ticks.

Now suppose the left wheel is actually a little smaller, radius 0.0495 m (half a millimeter less), because of a worn tire or a different inflation. The robot is commanded to drive "straight", and both encoders count the same 31.83 revolutions.

1. Real distance, right wheel: 31.83 × 2π × 0.050 = 10.00 m.

2. Real distance, left wheel: 31.83 × 2π × 0.0495 = 9.90 m.

3. Difference: 10.00 − 9.90 = 0.10 m.

4. Heading change: Δθ = 0.10 / 0.30 = 0.333 rad = 19.1°.

The odometry believes the robot has gone straight, but it has turned 19° to the left over the 10 m, because the right wheel went farther. The sideways error is about 10 × 0.333 / 2 = 1.7 m using the small-angle approximation, or more precisely 1.64 m using the circular arc (the radius of the arc is 0.15 × (10.00 + 9.90) / 0.10 = 29.85 m, and 29.85 × (1 − cos 0.333) = 1.64 m). About 1.6 m of sideways error from 0.5 mm of wheel error.

Here the robot's own odometry would not know. It thinks the robot is on the straight line. That is the danger: odometry does not report its own error.

Both encoders counted the same number of revolutions, so the odometry reports straight travel. The wheels, though, covered different distances because their sizes differ, and that mismatch is invisible to the encoders.

Why errors add up

• Random errors (slip on dust, a bump, encoder resolution) add in quadrature, so after N independent steps they grow like √N.

• Systematic errors (wheel size, track width, a motor that always pulls to one side) add linearly, so they grow in proportion to the distance, as above.

• Heading errors are multiplied by the distance traveled after them. A heading error of 1° after 10 m gives a sideways error of 10 × sin 1° = 0.17 m.

Since the position is a sum of all past steps, no mistake ever disappears. It only gets joined by new ones.

Reducing the error

1. Calibrate. Measure the real wheel diameters and the effective track width. A common test: drive a known distance (say 5 m) and compare, then spin on the spot for ten full turns and compare the heading.

2. Use a gyroscope for heading. A gyro in an IMU measures rotation directly and does not depend on wheel slip, though it drifts slowly.

3. Fuse with other sensors. Combine odometry with landmarks or scan matching, as in localization and the Kalman filter.

4. Avoid slip. Accelerate gently, use grippy wheels, and avoid bumpy floors.

5. Use loop closure over long trips (see loop closure).

Where it goes wrong

• Wheel slip on carpet, dust or wet floors, which makes the encoders report motion that did not happen.

• Wheel size changes with load, tire wear and temperature.

• Skidding in turns for skid-steer robots.

• Encoder glitches such as missed counts at high speed.

• Time step too coarse, so the arc approximation is rough.

Safety: Never trust odometry alone near drops, stairs or people. Use cliff and obstacle sensors independently of the position estimate, and keep an emergency stop in reach. Test at low speed with the wheels off the ground first when you check the encoder directions.

How real robots use it

Almost every wheeled robot computes odometry because it is cheap, fast and works anywhere. It is used for short-term motion between corrections from better but slower sources. On its own it is only good for short distances. The error pictures in this article are the reason that systems like SLAM exist.

Try it yourself

Mark a start line and drive your robot 3 m forward ten times, using only encoder counts to stop. Measure the final distance and sideways offset each time with a tape measure. Compute the average and the spread. Then change one tire (or wrap tape around one wheel to make it slightly larger) and repeat. The change in the average sideways error shows how sensitive the robot is to wheel size.

Frequently asked questions

Why is odometry still used if it drifts?

It is fast, cheap and accurate over short distances. Other sensors correct its drift over longer ones.

Which error matters most?

Heading error, because it turns every later step in the wrong direction, so its effect grows with the distance driven afterward.