Visual odometry

Visual odometry – definition

Visual odometry, abbreviated as VO, is the process of estimating a robot’s motion from a sequence of camera images. In mobile robotics, the output is the relative change of pose over time, usually expressed as translation and rotation between consecutive frames. In ROS and ROS 2 systems, this estimate is typically published as odometry and integrated with other sensors such as IMU, wheel encoders, LiDAR, or GNSS.

For a UGV, visual odometry is not a map by itself. It is a local motion estimator. It answers the question: how did the robot move between image timestamps? This distinction matters. VO can operate without a globally consistent map, while SLAM adds loop closure and map optimization. In practice, VO is often one layer in a larger localization stack used on platforms such as Leo Rover or Raph Rover.

From a robotics perspective, visual odometry is useful when wheel odometry becomes unreliable due to slip, uneven terrain, loose soil, or changing contact conditions. That is common in field robotics. A camera can observe external features in the environment and estimate motion from them, which complements proprioceptive sensors.

How visual odometry works in mobile robotics

The core idea is to track visual information across frames and infer the camera motion that best explains the observed image changes. The method depends on the sensor setup and algorithm family.

In UGV applications, the most common variants are:

Monocular VO – one camera. Scale is not directly observable without additional assumptions or sensors.
Stereo VO – two synchronized cameras with known baseline. Metric scale is observable from triangulation.
RGB-D VO – a color camera with per-pixel depth. Metric scale is available from the depth sensor.
Visual-inertial odometry – camera plus IMU. The IMU improves short-term motion estimation and robustness during rapid motion or low-texture periods.

Most pipelines follow these stages:

Acquire time-synchronized images, and optionally IMU data.
Detect or sample visual features, or use direct image intensity methods.
Match features or align images between frames.
Estimate relative motion with geometric constraints, for example epipolar geometry or reprojection error minimization.
Reject outliers, often with RANSAC.
Refine the pose estimate with bundle adjustment, nonlinear optimization, or a filtering method.

For ground robots, visual odometry is usually fused with wheel odometry and IMU rather than used as a single source of truth. This is because the camera estimate can degrade under motion blur, poor lighting, repeated textures, or dust.

Visual odometry in ROS 2

In ROS 2, VO is integrated through standard message types, frame conventions, calibration data, and timestamp handling. The most relevant interfaces are defined by ROS messages and REP documents. Coordinate frame conventions are described in REP 103 and mobile platform frame semantics in REP 105. Camera calibration is carried in sensor_msgs/msg/CameraInfo.

A typical ROS 2 visual odometry pipeline publishes or consumes the following topics:

Topic	ROS 2 message type	Typical rate	Purpose
/camera/image_raw	sensor_msgs/msg/Image	15-60 Hz	Input image stream
/camera/camera_info	sensor_msgs/msg/CameraInfo	same as image	Intrinsics and distortion model
/imu/data	sensor_msgs/msg/Imu	100-400 Hz	Inertial aiding
/visual_odom	nav_msgs/msg/Odometry	15-60 Hz	Estimated pose and twist
/tf	tf2 transform stream	10-100 Hz	Frame transform, often odom -> base_link

Common ROS 2 implementations include VSLAM or VO modules from packages such as RTAB-Map, ORB-SLAM integrations, or vendor stacks for Intel RealSense T265-class devices. Availability differs by ROS distribution and package maintenance status, so integration should be verified for the target ROS 2 distribution before deployment.

ros2 topic echo /visual_odom
ros2 topic hz /camera/image_raw
ros2 run tf2_ros tf2_echo odom base_link

Key parameters and metrics

Visual odometry quality depends on sensor quality, calibration accuracy, scene texture, and compute budget. In research and field integration, the most useful metrics are drift, update rate, latency, and failure recovery behavior.

Translational drift – often reported as percentage of traveled distance.
Rotational drift – often reported in degrees per meter or degrees per 100 m.
Frame rate – the effective estimation rate, for example 15-30 Hz on embedded platforms.
End-to-end latency – time from image capture to published odometry.
Feature track count – number of stable correspondences used for motion estimation.
Inlier ratio – fraction of matched features retained after outlier rejection.
Calibration quality – reprojection error after intrinsic and extrinsic calibration.

A simple kinematic interpretation is:

T(k) = T(k-1) * ΔT(k)

where T(k) is the robot pose at frame k, and ΔT(k) is the relative transform estimated from the current visual measurement. In practice, this transform is represented in SE(3), then fused with other estimates in an EKF, UKF, factor graph, or optimization-based localization stack.

Supported hardware and sensor integration

For UGV platforms, VO hardware must be selected with attention to field of view, low-light behavior, synchronization, and mounting stability. A rolling shutter camera can work, but global shutter cameras usually reduce motion distortion. Depth cameras simplify scale estimation indoors, while stereo is often more robust outdoors under natural light.

Typical hardware used with ROS 2 UGVs includes:

Stereo cameras with hardware synchronization and known baseline.
RGB-D cameras such as Intel RealSense depth devices for indoor or short-range operation.
Industrial USB or MIPI cameras paired with an external IMU.
GNSS or RTK receiver for global reference in outdoor deployments.

On Leo Rover, visual odometry is usually an added subsystem, not a default capability. The platform uses a Raspberry Pi as the built-in compute unit and supports ROS and ROS 2. That is sufficient for basic camera streaming and lightweight VO, but heavier stereo or visual-inertial pipelines may require an external computer or optimized acceleration. Wheel odometry from the differential drive base can be fused with VO to improve short-term stability. Because Leo Rover is not autonomous out of the box, full navigation still requires integration of localization, costmaps, planners, and obstacle sensing.

On Raph Rover, the larger payload budget makes it easier to carry more capable compute and sensor suites, such as stereo rigs, higher-grade IMUs, or LiDAR plus camera combinations. This is relevant for rough terrain, construction, or agricultural testbeds where pure wheel odometry is often insufficient.

Use cases with Leo Rover and Raph Rover

Visual odometry is most useful on platforms that operate in environments where wheel slip or uneven terrain causes encoder drift. It also supports rapid prototyping in research because it can be added without redesigning the drivetrain.

Typical use cases include:

Indoor navigation on Leo Rover with RGB-D or stereo odometry fused with IMU.
Outdoor row-following or path estimation where GNSS is intermittent and wheel slip occurs.
Inspection missions where LiDAR provides geometry and VO improves local pose continuity.
Dataset collection and algorithm benchmarking for visual-inertial and multi-sensor fusion.

In a practical ROS 2 setup, VO may feed robot_localization together with wheel and IMU data. The fused output then becomes the odometric source for Nav2 or for a higher-level SLAM system.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    odom0: /wheel/odom
    odom0_config: [false, false, false,
                   false, false, false,
                   true,  true,  false,
                   false, false, true,
                   false, false, false]
    odom1: /visual_odom
    odom1_config: [true,  true,  false,
                   false, false, true,
                   true,  true,  false,
                   false, false, true,
                   false, false, false]
    imu0: /imu/data

Limitations and trade-offs

Visual odometry is sensitive to environmental conditions. Textureless corridors, direct sunlight, reflections, dust, fog, rain, and repeated patterns can all reduce reliability. Monocular VO has scale ambiguity unless combined with IMU, wheel constraints, known landmarks, or another ranging sensor.

There are also system-level trade-offs:

Higher image resolution improves feature quality but increases compute load and latency.
Wider field of view helps tracking during turns but may add distortion.
Stereo gives metric scale but requires accurate extrinsic calibration.
Visual-inertial fusion improves robustness but depends on tight time synchronization.

For field robots, VO should be treated as one estimator in a redundant sensing architecture, not as the only localization source.

Normative references and standards

The ROS frame and sensor conventions relevant to visual odometry are documented in REP 103 – Standard Units of Measure and Coordinate Conventions, and REP 105 – Coordinate Frames for Mobile Platforms. ROS 2 camera pipelines use sensor_msgs/msg/Image and sensor_msgs/msg/CameraInfo as the standard transport and calibration interface. Odometry is usually represented with nav_msgs/msg/Odometry and frame transforms in TF2.

For algorithmic background, the term visual odometry is established in the robotics and computer vision literature, including IEEE publications on stereo VO, monocular VO, and visual-inertial navigation. For hardware-specific integration, the relevant references are the manufacturer specifications for camera frame rate, synchronization support, shutter type, depth range, and IMU rate.