Wheel Odometry

Wheel odometry estimates where a robot is by adding up how far each wheel has turned. Every update, the robot reads its encoders, works out how far it moved and how much it turned since last time, and adds that small step to its pose.

Update rate Run updates automatically

One odometry update

From the encoder tick counts $\Delta n_L, \Delta n_R$ since the last update, with $N$ ticks per wheel turn, wheel radius $r$, and wheel spacing $b$:

$$\Delta s_{L,R} = \frac{2\pi r}{N}\,\Delta n_{L,R} \qquad \Delta s = \frac{\Delta s_R + \Delta s_L}{2} \qquad \Delta\theta = \frac{\Delta s_R - \Delta s_L}{b}$$

Then move along the average heading during the step:

$$x \mathrel{+}= \Delta s\cos\!\left(\theta + \tfrac{\Delta\theta}{2}\right) \qquad y \mathrel{+}= \Delta s\sin\!\left(\theta + \tfrac{\Delta\theta}{2}\right) \qquad \theta \mathrel{+}= \Delta\theta$$

What to notice

Each update adds one short segment, and the path is just the chain of those segments. Slow the update rate and the steps get longer, so curves turn into polygons and the estimate cuts corners. Using the midpoint heading $\theta + \Delta\theta/2$ instead of the old heading reduces that error. Any error in a step stays in the pose forever, which is why odometry drifts.