Dead reckoning

Dead reckoning – definition

Dead reckoning is a method for estimating a robot’s current pose from a previously known pose by integrating motion over time. In mobile robotics, pose usually means position and orientation in 2D or 3D. For a ground robot, dead reckoning is most often computed from wheel encoder data, inertial measurements, or both. It does not require external references such as landmarks, GNSS, or a prior map.

For UGV platforms, dead reckoning is the shortest path from raw motion sensing to an odometry estimate. In ROS and ROS 2, this estimate is typically published as nav_msgs/msg/Odometry and represented in the TF tree between frames such as odom and base_link, following REP 105 frame conventions. The key property of dead reckoning is that errors accumulate. Small bias in wheel radius, wheel slip, encoder quantization, IMU bias, or timestamp mismatch causes drift that grows with traveled distance and time.

On differential-drive platforms such as Leo Rover, dead reckoning usually starts from wheel odometry. On larger UGVs such as Raph Rover, the same principle applies, but payload, terrain variation, and higher speed often make fusion with IMU and GNSS more important. Dead reckoning is therefore not a full localization method. It is a local motion estimate that must usually be corrected by SLAM, visual odometry, LiDAR localization, or GNSS/RTK when long-term accuracy matters.

How dead reckoning works on a differential-drive UGV

On a differential-drive robot, dead reckoning is derived from the angular displacement of the left and right wheels. Encoders provide wheel rotation, and the robot kinematics convert it into linear and angular motion. This approach is standard for small and medium UGVs that do not have steering linkages.

For a robot with wheel radius r, wheel separation b, and wheel angular increments Δφ_L and Δφ_R, the incremental travel is:

s_L = r * Δφ_L
s_R = r * Δφ_R

Δs = (s_R + s_L) / 2
Δθ = (s_R - s_L) / b

x_(k+1) = x_k + Δs * cos(θ_k + Δθ/2)
y_(k+1) = y_k + Δs * sin(θ_k + Δθ/2)
θ_(k+1) = θ_k + Δθ

In practice, the estimate depends on calibration. The most sensitive parameters are effective wheel radius and wheel track width. A few millimeters of mismatch can produce noticeable heading drift over long runs. On loose soil, gravel, wet grass, ramps, or thresholds, dead reckoning degrades further because the no-slip assumption is violated.

Dead reckoning in ROS 2

In ROS 2, dead reckoning is usually implemented by a motor driver node, a controller, or a sensor fusion node. The output is then consumed by higher-level stacks such as localization, SLAM, and navigation. ROS 2 systems commonly use TF2, nav_msgs/msg/Odometry, sensor_msgs/msg/Imu, and optionally sensor_msgs/msg/JointState for wheel states.

According to REP 105, the odom frame should be continuous and locally smooth, while map may jump when global localization updates occur. Dead reckoning usually defines the odom -> base_link transform. If a SLAM or localization node is used, it often computes map -> odom.

nav_msgs/msg/Odometry – estimated position, orientation, linear velocity, angular velocity, covariance
sensor_msgs/msg/Imu – angular velocity, linear acceleration, orientation if provided by the IMU filter
tf2 – runtime transform tree used by Nav2 and perception nodes
robot_localization – common ROS package for EKF/UKF fusion of wheel odometry, IMU, and GNSS

A typical ROS 2 workflow is to compute raw wheel odometry, then fuse it with IMU data to improve heading stability and short-term velocity estimation. This does not remove drift. It mainly reduces sensitivity to transient wheel slip and noisy angular velocity estimates.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    base_link_frame: base_link
    odom_frame: odom
    world_frame: odom
    odom0: /wheel/odometry
    odom0_config: [false, false, false,
                   false, false, true,
                   true, true, false,
                   false, false, true,
                   false, false, false]
    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, true,
                  false, false, false,
                  false, false, true,
                  true, false, false]

Key parameters and metrics

Dead reckoning quality should be evaluated with measurable parameters. In research and field robotics, the important question is not whether odometry exists, but how quickly it diverges under real operating conditions.

Parameter	Typical ROS 2 representation	Why it matters
Odometry update rate	`/odom` at 10-100 Hz	Higher rates improve controller smoothness and state estimation
Encoder resolution	Driver-specific, often counts per revolution	Limits distance quantization and low-speed accuracy
IMU rate	`/imu/data` at 50-400 Hz	Improves heading and motion filtering
Covariance	Included in `nav_msgs/msg/Odometry`	Used by fusion nodes to weight the source correctly
Drift rate	Measured experimentally, for example % of distance traveled	Defines practical autonomy limits without external correction
Time synchronization	ROS time stamps	Bad timing produces integration error and TF inconsistency

There is no universal drift number for all UGVs because terrain, payload, wheel material, and controller tuning change the result. For that reason, dead reckoning should be validated on the target surface and at the target speed, not only on a lab floor.

Use on Leo Rover and Raph Rover

For Leo Rover, dead reckoning is the natural first-stage odometry source because the platform is a four-wheel skid-steer UGV with onboard compute based on Raspberry Pi and ROS support. In a lab, wheel odometry may be sufficient for teleoperation, waypoint experiments in short corridors, and controller testing. For autonomous navigation, Leo Rover still requires an integrated localization stack. Dead reckoning alone is not enough for repeatable map-based navigation over longer trajectories.

On Leo Rover, common upgrade paths are:

wheel odometry only – simplest setup, highest drift on uneven terrain
wheel odometry + IMU – better short-term orientation estimate
wheel odometry + IMU + LiDAR SLAM – suitable for indoor and GNSS-denied research
wheel odometry + IMU + GPS/RTK – useful for outdoor navigation and row-following experiments

Raph Rover operates in cases where payload, sensor stack, and field conditions are more demanding. In such systems, dead reckoning remains necessary because it provides continuous local motion even when GNSS is intermittent or perception updates are delayed. However, larger mass and more aggressive terrain interactions can increase wheel slip, so fusion quality and covariance tuning become more important than on a small indoor robot.

Limitations and trade-offs

Dead reckoning is simple, fast, and available at high rate. These are its main strengths. It is also deterministic and easy to inspect in logs. For that reason, it remains a core component in most ROS-based UGV systems.

The main limitation is unbounded drift. Typical failure modes include:

wheel slip during acceleration, braking, or turning in place
systematic calibration error in wheel radius or track width
IMU bias and poor mounting alignment
timestamp jitter between motor driver, IMU, and fusion node
terrain deformation such as sand, mud, grass, or rubble

Because of these limitations, dead reckoning should be treated as local odometry, not as a global truth source. In ROS 2 navigation stacks, it supports motion control and short-term state propagation, while absolute corrections should come from SLAM, landmark localization, visual odometry, or GNSS.

Normative references and standards

The ROS frame semantics most relevant to dead reckoning are defined in REP 105, which describes coordinate frames for mobile platforms, including base_link, odom, and map. Message definitions are maintained in standard ROS interface packages such as nav_msgs and sensor_msgs. In applied robotics literature, dead reckoning is also discussed in the context of inertial navigation and mobile robot odometry by IEEE and textbook references on probabilistic robotics and field robotics.

When implementing dead reckoning on a UGV, the minimum technical checks are:

consistent TF tree according to REP 105
correct wheel geometry in robot model and controller configuration
realistic covariance values in nav_msgs/msg/Odometry
synchronized timestamps across encoder, IMU, and fusion outputs
validation against ground truth or an external reference