"Dead reckoning is useful because it admits how fast it is becoming unsure."
A Loop Closure That Came Back With Receipts
Odometry and dead reckoning is the state-estimation half of embodied autonomy. The robot has partial, noisy, time-stamped evidence; it must turn that evidence into a pose, a map, and an uncertainty statement that a planner can actually trust.
Problem First
Odometry is tempting because it is always available. Wheel ticks, IMU integration, and visual motion increments keep producing estimates even when no map feature is visible. The danger is that small bias accumulates without an external correction.
For a differential-drive base, wheel angular increments become a forward displacement and heading change. The covariance must grow with each integration step because uncertainty compounds. Dead reckoning is useful as a short-horizon prediction, not as a long-term truth source.
An odometry result is incomplete without integration timestep, frame convention, calibration values, covariance model, and reset behavior. A smooth trajectory can still be wrong if it hides accumulating drift.
Formal Model
For odometry, the posterior is a chained motion belief conditioned on wheel, leg, visual, or inertial increments. Its value is determined by how quickly uncertainty grows and by whether that growth is visible to the planner.
$$ x_{t+1}=x_t+\Delta s\cos(\theta_t+\Delta\theta/2),\quad y_{t+1}=y_t+\Delta s\sin(\theta_t+\Delta\theta/2),\quad \theta_{t+1}=\theta_t+\Delta\theta $$
The important evidence terms are wheel radius, slip, encoder quantization, IMU bias, integration timestep, and frame transform. Each term needs a residual or drift estimate because dead reckoning fails gradually before it fails obviously.
- Calibrate wheel radius, baseline, IMU bias, and timestamp synchronization.
- Integrate small increments in the correct body or odom frame.
- Propagate covariance with motion noise after every step.
- Bound drift by fusing map, visual, GNSS, beacon, or loop-closure evidence.
Worked Diagnostic
Code Fragment 1 is the odometry unit test: integrate a known motion increment, inspect pose drift, then compare the hand result with the library or ROS node before trusting long routes.
# Integrate a differential-drive odometry increment.
# A small wheel mismatch creates a heading change that will compound.
import math
r = 0.05
baseline = 0.32
d_left = 1.00
d_right = 1.06
delta_s = r * (d_right + d_left) / 2.0
delta_theta = r * (d_right - d_left) / baseline
print(f"forward={delta_s:.3f} m")
print(f"heading_change={math.degrees(delta_theta):.2f} deg")Expected output interpretation. The forward increment is only about 5 cm, but it already carries a nonzero yaw error. That is the important readout: if the robot repeats this biased update for hundreds of steps, the translational error will grow mostly because the heading estimate keeps rotating the future motion in the wrong direction.
Tool Workflow
ROS 2 odometry messages, robot_localization, OpenVINS, and visual odometry modules absorb message formats, timestamp handling, and sensor fusion plumbing. Keep the two-line kinematic calculation as a unit test for frame direction and sign conventions.
Keep the dead-reckoning calculation small enough to audit by hand, then use robot_localization, Nav2 odometry sources, or a factor graph for deployment. The invariant is that motion increments and covariance grow in the expected frame.
Replay the same drive with biased wheel radius, injected slip, delayed IMU packets, and a wrong base-link transform as separate cases. The failure label should tell whether drift came from kinematics, timing, calibration, or terrain.
A warehouse odometry log should include encoder ticks, commanded velocity, IMU yaw rate, integrated pose, covariance growth, floor condition, and any scan-match correction. That record shows whether the robot drifted before perception had a chance to recover it.
Visual-inertial odometry remains active because low-cost cameras and IMUs are sensitive to rolling shutter, vibration, bias drift, and degraded lighting. Recent work combines learned features with classical filtering, but hardware timing and calibration still decide field performance.
Dead reckoning is useful because it admits how fast it is becoming unsure.
Can you state the state variables, observation residual, uncertainty representation, replay artifact, and most likely field failure for odometry and dead reckoning? If one field is vague, the estimator is not ready for embodied use.
Odometry and dead reckoning is production-ready only when geometry, uncertainty, timing, and action consequences are tested together.
Use one nominal square path and one path with a biased wheel radius or slip segment. Report final pose error, heading drift, covariance growth, and whether the planner would still accept the route.
What's Next?
Continue to Section 29.3: Localization with particle filters, where this state-estimation contract becomes the input to the next embodied capability.
Section References
Durrant-Whyte, H. and Bailey, T. "Simultaneous Localization and Mapping." IEEE Robotics and Automation Magazine, 2006. https://ieeexplore.ieee.org/document/1638022
Classic SLAM tutorial that frames the estimation problem and the role of uncertainty.
GTSAM Project. "Factor Graphs and GTSAM." Official documentation. https://gtsam.org/
Primary tool reference for factor graphs, smoothing, pose graphs, and robotics estimation examples.
ROS 2 Navigation Project. "Nav2 documentation." Official documentation. https://navigation.ros.org/
Primary documentation for integrating localization, maps, planners, controllers, behavior trees, and recoveries.