Odometry

Odometry – definition

Odometry is the process of estimating a mobile robot’s change in pose over time from onboard motion measurements. In ground robots, pose usually means position and orientation in a 2D plane, expressed as x, y, and yaw theta. For UGV platforms, odometry is most often computed from wheel encoder data, inertial measurements, visual motion estimates, or a fusion of these sources. The result is not a global position fix. It is a locally consistent estimate of how far the robot has moved relative to a starting frame.

In ROS and ROS 2, odometry is typically published as nav_msgs/Odometry in ROS 1 and nav_msgs/msg/Odometry in ROS 2. This message contains pose, twist, and covariance, and is usually associated with the odom frame in the standard mobile robot TF tree. The frame conventions used in ROS are defined in REP 103 for units and coordinate conventions, and REP 105 for coordinate frames such as base_link, odom, and map. In practical terms, odometry provides the short-term motion estimate required by localization, SLAM, and closed-loop navigation stacks.

For differential-drive UGVs, odometry usually starts with wheel rotations measured on the left and right side of the drivetrain. Those increments are converted into linear and angular displacement using wheel radius and track width. On larger payload-oriented platforms, the same principle applies, but error sources become more visible because higher mass, wheel slip, terrain deformation, and sensor mounting vibrations can degrade dead-reckoning quality.

How odometry works on mobile UGV platforms

Odometry is a dead-reckoning method. It integrates incremental motion over time. This makes it simple and fast, but also subject to drift. Every small measurement error accumulates, so the estimate is reliable over short distances and degrades over longer runs.

For a differential-drive robot, the standard kinematic model is based on left and right wheel travel:

d_left  = r * delta_phi_left
d_right = r * delta_phi_right

d_center = (d_right + d_left) / 2
d_theta  = (d_right - d_left) / b

Where:

r – wheel radius
delta_phi_left, delta_phi_right – wheel angle increments
b – wheel separation or track width

The planar pose update is then approximated as:

x_(k+1) = x_k + d_center * cos(theta_k + d_theta / 2)
y_(k+1) = y_k + d_center * sin(theta_k + d_theta / 2)
theta_(k+1) = theta_k + d_theta

This model is standard for two-sided differential drive. It is also the basis of many ROS 2 controller implementations and odometry publishers used with wheeled UGVs.

Odometry in ROS 2

In ROS 2, odometry is not just a number stream. It is part of a frame-consistent state estimation pipeline. A typical robot publishes wheel encoder-derived odometry, the transform between odom and base_link, and optionally fused estimates from IMU, GNSS, or visual sources.

The most relevant ROS interfaces are:

nav_msgs/msg/Odometry – pose, twist, covariance
geometry_msgs/msg/Twist – commanded or estimated velocity
sensor_msgs/msg/Imu – angular velocity, linear acceleration, orientation
tf2 transforms – especially odom -> base_link

According to REP 105, the odom frame should be continuous and drift over time, while the map frame should be globally corrected but may jump when localization updates occur. This distinction matters. Local planners consume smooth odometry, while global localization or SLAM corrects drift in the map frame.

A common ROS 2 setup uses robot_localization to fuse wheel odometry and IMU data. Example configuration:

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    publish_tf: true
    map_frame: map
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom

    odom0: /wheel/odometry
    odom0_config: [true, true, false,
                   false, false, true,
                   true, false, 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]

Typical publication rates are 20-100 Hz for wheel odometry and IMU, depending on controller and compute budget. The exact value depends on encoder resolution, motor controller update frequency, and ROS 2 executor load.

Key parameters and metrics

Odometry quality depends on both kinematics and implementation details. Small configuration mistakes can produce large pose errors even when the hardware is functioning correctly.

Parameter	Why it matters	Typical source
Wheel radius	Converts encoder angle to linear distance	Mechanical specification or calibration
Wheel separation	Determines angular motion estimate	Chassis geometry
Encoder resolution	Affects distance quantization and low-speed accuracy	Motor or encoder datasheet
Update rate	Influences smoothness and controller response	Driver and ROS node configuration
Covariance	Defines estimator trust in pose and twist	Empirical tuning or sensor model
Slip sensitivity	Main source of drift on loose terrain	Field testing

For technical validation, engineers usually monitor:

linear drift per meter traveled
heading drift per minute or per turn
repeatability over closed-loop trajectories
consistency between /odom, IMU yaw, and LiDAR or visual localization

Use on Leo Rover and Raph Rover

On Leo Rover, odometry is the base layer for any autonomous stack, but it is not sufficient for full autonomy on its own. The platform supports ROS 2, and differential-drive odometry integrates naturally with Nav2, SLAM Toolbox, or robot_localization. In indoor or lab conditions, wheel odometry combined with an IMU is often enough for short-range waypoint following and mapping. On grass, gravel, ramps, or uneven ground, wheel slip increases and fused state estimation becomes necessary.

On larger UGV platforms, the same ROS concepts apply, but the larger chassis and payload-oriented use cases often justify additional sensors such as higher-grade IMU, RTK GNSS, or 3D LiDAR. This is especially important in outdoor inspection, construction, or agricultural scenarios where the traveled distance is longer and dead-reckoning drift becomes operationally relevant.

A useful ROS 2 diagnostic command is:

ros2 topic echo /odom
ros2 run tf2_ros tf2_echo odom base_link
ros2 topic hz /odom

Limitations and trade-offs

Odometry is required in almost every mobile robot stack, but it has known limitations. It estimates motion, not absolute truth. Errors grow over time because integration has no natural correction mechanism.

The most common failure modes are:

wheel slip on loose, wet, or compliant terrain
incorrect wheel radius or wheelbase parameters
encoder quantization at very low speed
time synchronization errors between sensors
IMU bias when odometry is fused without proper calibration

For that reason, odometry is usually combined with exteroceptive localization. LiDAR scan matching, visual odometry, SLAM, GNSS/RTK, or fiducial markers can provide drift correction. In ROS 2 systems, this often means keeping wheel odometry in odom and allowing a localization node to estimate map -> odom.

Normative references and standards

The ROS interpretation of odometry should follow official message and frame definitions. The most relevant references are ROS message documentation for nav_msgs/Odometry and nav_msgs/msg/Odometry, REP 103 for standard units and coordinate conventions, and REP 105 for mobile platform coordinate frames. For fused estimation in ROS 2, the robot_localization package documentation is the practical implementation reference. For the underlying motion model, differential-drive odometry is standard material in mobile robotics literature and widely aligned with established terminology for robot position estimation and dead reckoning.