Wheel Odometry Calculator (Differential Drive)

What wheel odometry actually does

Every mobile robot needs to know where it is. The cheapest answer is a pair of encoders on the drive wheels: count rotations, multiply by circumference, and you have distance. For a differential-drive base (two independently driven wheels, like a Roomba, a warehouse AMR, or a basic RC tank), the difference between left and right wheel distances also tells you how much the robot turned. That gives a full 2D pose update (x, y, and heading θ) from nothing but two integer counts.

It does not need GPS, vision, or a map. It works indoors, in a basement, in pitch dark. That is why every robotics stack from ROS to Arduino RC frameworks has odometry as the bottom layer.

The math

Step 1, distance per wheel:

d_L = (Δticks_L / ticks_per_rev) × π × wheel_diameter d_R = (Δticks_R / ticks_per_rev) × π × wheel_diameter

Step 2, robot center distance and heading change:

d_center = (d_R + d_L) / 2 Δθ = (d_R − d_L) / wheel_base

Step 3, update the pose (midpoint integration, the standard form):

x_new = x_old + d_center × cos(θ_old + Δθ/2) y_new = y_old + d_center × sin(θ_old + Δθ/2) θ_new = θ_old + Δθ

Why midpoint integration

You could use cos(θ_old) instead of cos(θ_old + Δθ/2), but that introduces a systematic curve-following error: when the robot turns while moving, the trajectory is an arc, not a straight line. Using the midpoint heading is the closed-form solution for constant-curvature arcs and works well as long as Δθ per update is small (say, under a few degrees). ROS, ardupilot, and most embedded robotics frameworks use this exact form.

What kills odometry accuracy

1. Wheel slip. A wheel spinning on dust, tile, or polished concrete clocks ticks without moving the robot. Carpet rovers and outdoor robots see this constantly.
2. Wheel radius calibration. A 1 percent error in wheel diameter compounds with every revolution. After 100 meters of driving, that is 1 meter off.
3. Wheel base calibration. If your measured wheel base is wrong by 5 mm, heading drift becomes the dominant error within tens of meters.
4. Differential wheel wear. Tires wear unevenly; a robot used heavily on right turns ends up with a smaller right tire and a built-in left bias.
5. Encoder resolution. A 100-tick-per-revolution encoder on a 100 mm wheel resolves about 3 mm per tick. Below that, you cannot distinguish movement from quantization.

Why you fuse it with other sensors

Odometry alone drifts. Long-term, every robot uses a Kalman or particle filter to fuse odometry with one of:

Roomba uses a downward optical flow sensor + wheel odometry + gyro. Tesla Autopilot fuses wheel speeds + IMU + cameras + radar. The pattern is universal: odometry alone is never the answer past a few meters.

Worked example

A robot has 360-tick encoders on 100 mm wheels and a 250 mm wheel base. Between two odometry updates the left encoder reads +200 ticks, the right reads +220 ticks. Starting pose: (0, 0, 0°).

d_L = 200/360 × π × 100 = 174.5 mm d_R = 220/360 × π × 100 = 192.0 mm d_center = (192.0 + 174.5)/2 = 183.2 mm Δθ = (192.0 − 174.5)/250 = 0.070 rad ≈ 4.0° θ_new = 0 + 4.0° = 4.0° x_new = 0 + 183.2 × cos(2.0°) = 183.1 mm y_new = 0 + 183.2 × sin(2.0°) = 6.4 mm

The robot moved ~18 cm and turned 4 degrees right (or left, depending on your sign convention). After 100 such updates without correction, expect cumulative error in the range of 1-5 meters depending on surface and calibration.

Sign conventions

Counterclockwise = positive θ is the standard mathematical convention and what ROS uses. Right wheel going faster than left turns the robot counterclockwise (left turn from the robot’s view). If your calculator reports the wrong sign, swap which wheel you treat as left vs right, easier than retrofitting the math.