Wheel odometry is the estimation of a wheeled robot’s position, heading and velocity from the measured rotation of its wheels, usually counted by wheel or motor encoders and integrated over time with a kinematic model of the drive. In robot navigation, it is the most common source of short-term relative motion: it is fast, cheap and smooth, but its error grows without bound because every small mistake is added to all later estimates.
Wheel odometry is a specific form of dead reckoning. Navigation stacks therefore treat it as a local motion estimate that must be corrected by localization against a map, by satellite positioning or by other sensors.
How wheel odometry computes motion
Wheel odometry converts encoder ticks into wheel travel and then combines the travel of all wheels into a body motion. For a wheel of radius r and an encoder with N counts per revolution, each count corresponds to a distance of 2πr divided by N.
For the widespread differential drive, the robot’s forward travel in one update is the average of the left and right wheel distances, and the change in heading is their difference divided by the track width, the distance between the wheel contact points. The new pose is then obtained by integrating these increments, typically at 50 to 200 Hz in mobile robots.
The key parameters of this calculation are listed below with typical values.
| Parameter | Typical range | What it affects |
|---|---|---|
| Encoder resolution | Hundreds to tens of thousands of counts per wheel revolution | Smallest measurable motion |
| Wheel radius | About 3 to 20 cm on indoor robots | Scale of every distance estimate |
| Track width | About 0.2 to 1 m | Accuracy of heading changes |
| Update rate | About 20 to 200 Hz | Integration error during fast turns |
| Gear ratio | From direct drive to over 50:1 | Effective counts per wheel revolution |
Quadrature encoders are typically read with four-times decoding, which counts every edge of both channels and quadruples the nominal resolution. Motor-side encoders give high resolution, but gearbox backlash means they do not see small wheel movements during direction changes.
Sources of odometry error
Odometry errors fall into systematic errors, which repeat in the same direction and can be calibrated, and non-systematic errors, which depend on the terrain and cannot be predicted. Heading errors are the most damaging, because a small angular error turns into a lateral position error that grows with distance traveled.
| Error source | Type | Effect | Mitigation |
|---|---|---|---|
| Unequal wheel diameters | Systematic | Robot curves when it should drive straight | Calibrate each wheel radius |
| Uncertain track width | Systematic | Rotations are over or under estimated | Calibrate with in-place turns |
| Wheel slip | Non-systematic | Wheels turn without moving the robot | Fuse with IMU, limit acceleration |
| Uneven or soft floor | Non-systematic | Path length differs from wheel travel | External localization corrections |
| Tire deformation and load | Mostly systematic | Effective radius changes with payload | Recalibrate for typical loads |
| Encoder quantization | Random | Jitter in velocity at low speed | Higher resolution or filtering |
The UMBmark procedure, in which a robot drives a square path clockwise and counterclockwise, is a classic method for separating the effect of wheel diameter mismatch from track width error. After calibration, systematic errors on hard indoor floors can become small, so slip and floor irregularities dominate the remaining drift.
Wheel odometry with different drive types
The kinematic model and the expected accuracy depend strongly on the drive configuration. Skid-steer and mecanum platforms rely on wheel slip to turn or move sideways, which makes their odometry inherently less reliable than that of a differential drive with free casters.
| Drive type | Kinematic model | Odometry quality |
|---|---|---|
| Differential drive | Two driven wheels on one axis | Good on hard floors after calibration |
| Ackermann steering | Bicycle model with steering angle | Good; needs accurate steering angle |
| Skid-steer | Differential model with slip during turns | Poor heading during rotation |
| Mecanum wheels | Holonomic model with roller geometry | Moderate; slip on rollers adds error |
| Omni wheels | Holonomic model with three or four wheels | Moderate; sensitive to floor contact |
Some robots add passive measurement wheels, unpowered wheels with their own encoders, because they carry little load and slip much less than driven wheels. This technique is common on cleaning robots and competition robots that need precise relative motion.
Wheel odometry in a navigation stack
In a navigation stack, wheel odometry provides a continuous, smooth local frame that planners and controllers can rely on between localization updates. In ROS conventions, it publishes the transform from the odom frame to the robot base frame, while a localization system such as AMCL publishes the correction from the map frame to the odom frame.
Wheel odometry compares with other motion sources as follows.
| Method | Strength | Weakness |
|---|---|---|
| Wheel odometry | High rate, low cost, smooth | Unbounded drift, fails with slip |
| Inertial measurement unit | Good short-term rotation rates | Position drifts quickly from double integration |
| Visual odometry | Works without wheel contact | Fails in low texture or poor light |
| Lidar scan matching | Accurate in structured spaces | Struggles in long featureless corridors |
| GNSS or RTK GPS | Absolute position outdoors | Unavailable indoors, multipath errors |
A common design fuses wheel odometry with an IMU in an extended Kalman filter: the gyroscope supplies heading changes, which are usually more reliable than wheel-based rotation, and the wheels supply forward velocity. Reporting realistic covariance values in the odometry message is essential, because the filter weights each source according to them.
Common mistakes
Most odometry problems come from configuration rather than hardware. The following mistakes are typical in new robot integrations:
- Nominal instead of measured wheel radius, which creates a constant scale error.
- Wrong encoder sign or swapped wheels, so the robot appears to turn the wrong way.
- Zero or tiny covariance values, which make fusion filters trust odometry blindly.
- Publishing the odometry transform twice, from both the driver and a fusion node.
- Expecting long-term accuracy without any absolute correction from a map or satellites.
In plain words
Wheel odometry is how a robot keeps track of where it has driven by counting wheel turns. If the robot knows how big its wheels are, it can work out how far it moved. If one wheel turned more than the other, it knows it turned.
It is like walking with your eyes closed and counting steps. The estimate is good for a short distance, but small mistakes add up. That is why robots regularly check their position against a map or other sensors.
A real-world example
A warehouse robot with a differential drive moves carts along aisles about 40 meters long. Its wheel encoders provide odometry at 100 Hz, and a lidar-based localization system corrects the position against a map about ten times per second.
During commissioning, engineers find that the robot drifts to one side on long straight runs. They run a square calibration test, measure a small difference between the two wheel radii, and correct the track width after a series of in-place rotations. An IMU is added to the fusion filter to stabilize heading during turns.
After calibration, the odometry stays consistent enough between lidar updates that the robot docks at charging stations reliably, and localization corrections become small and smooth instead of sudden jumps.