Glossary

Fictionlab > Glossary > robot_localization

robot_localization

robot_localization – definition

robot_localization is a ROS package for estimating the state of a mobile robot by fusing measurements from multiple sensors. It is commonly used on wheeled UGVs to combine wheel odometry, IMU data, GNSS fixes, and pose measurements into a consistent estimate of position, orientation, linear velocity, and angular velocity.

For mobile robotics, the package provides Extended Kalman Filter (EKF) and Unscented Kalman Filter (UKF) nodes. Both estimate a 15-state vector defined by the package documentation: Cartesian position, roll-pitch-yaw orientation, linear velocity, angular velocity, and linear acceleration. The estimate is published as standard ROS messages, primarily nav_msgs/msg/Odometry and the corresponding TF transform.

On a differential-drive UGV such as Leo Rover, robot_localization is usually the state-estimation layer between low-level wheel encoders and higher-level components such as Nav2, SLAM, autonomous waypoint execution, or telemetry software. It does not create a map and does not plan paths. Its task is to estimate where the platform is and how it is moving.

How robot_localization works in ROS 2

The package subscribes to one or more sensor topics and applies recursive probabilistic filtering. Each incoming measurement is evaluated together with its covariance matrix. Measurements with lower reported uncertainty have greater influence on the estimated state than measurements with higher uncertainty.

The two main filtering nodes have similar ROS interfaces but use different estimation methods:

  • ekf_node uses an Extended Kalman Filter. It linearizes the motion and measurement models around the current estimate.
  • ukf_node uses an Unscented Kalman Filter. It propagates sigma points through nonlinear functions instead of relying on first-order linearization.
  • navsat_transform_node converts GNSS coordinates into a local Cartesian frame and can combine GNSS data with an IMU heading and filtered odometry.

The EKF is the usual starting point for Leo Rover and Raph Rover deployments because its computational requirements are moderate and its configuration is well suited to wheeled outdoor platforms. A UKF can be useful when measurement models are strongly nonlinear, but it requires the same careful treatment of timestamps, coordinate frames, and covariance values.

The package follows the coordinate-frame conventions described in REP-105. A typical UGV configuration uses map, odom, and base_link:

  • base_link is fixed to the rover body.
  • odom is a locally continuous frame, normally driven by wheel odometry and IMU integration.
  • map is a globally corrected frame, often updated by GNSS, visual localization, or SLAM.

This separation is important. Wheel odometry is generally smooth over short distances but accumulates drift. GNSS or SLAM can correct global drift, but their updates may be discontinuous. REP-105 recommends publishing the map -> odom correction separately so that local motion control continues to receive a continuous odom -> base_link transform.

Inputs, messages, and coordinate conventions

Most deployments use standard ROS 2 message types. Sensor drivers should publish valid timestamps and frame identifiers. The filter cannot compensate for inconsistent time sources or incorrect static transforms.

Sensor source Typical ROS 2 message Relevant measurements
Wheel encoders or motor controller nav_msgs/msg/Odometry Linear velocity, angular velocity, optional local pose
IMU sensor_msgs/msg/Imu Orientation, angular velocity, linear acceleration
GNSS receiver sensor_msgs/msg/NavSatFix Latitude, longitude, altitude, position covariance
Visual or LiDAR localization geometry_msgs/msg/PoseWithCovarianceStamped Globally referenced pose correction

ROS mobile-robot frames use the right-handed convention defined by REP-103: x forward, y left, and z upward for body-fixed frames. IMU drivers that use a different convention must provide correctly transformed data before fusion. Incorrect axis mapping is a common cause of inverted yaw, unstable heading, or position drift.

Example EKF configuration for a differential-drive UGV

The following simplified ROS 2 YAML example fuses wheel odometry and IMU angular velocity. The configuration enables planar operation through two_d_mode. This is appropriate when the rover operates on mostly level ground and z-axis motion, roll, and pitch are not required by the navigation stack.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    sensor_timeout: 0.2
    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: [false, false, false,
                   false, false, false,
                   true,  false, false,
                   false, false, true,
                   false, false, false]

    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, false,
                  false, false, false,
                  false, false, true,
                  false, false, false]

The frequency parameter defines the filter output rate, while sensor_timeout specifies the maximum interval without a measurement before the node produces a prediction-only update. Their exact values must be selected according to sensor update rates, CPU load, and the control-loop requirements of the UGV. The parameter definitions are documented in the official robot_localization documentation.

Use with Leo Rover and Raph Rover

Leo Rover supports ROS 2 natively on a Raspberry Pi-based compute unit and uses a four-wheel differential-drive layout. A practical baseline is to fuse wheel odometry with an IMU. This can improve rotational-rate estimation during turns and produces an odom -> base_link transform suitable for local navigation.

For outdoor operation, a GNSS receiver can be added through navsat_transform_node. RTK-capable GNSS hardware can provide more accurate global position measurements than standard GNSS, but the resulting localization quality still depends on antenna placement, correction availability, timestamp synchronization, and reported covariance.

Raph Rover can carry larger sensor payloads and compute hardware. A typical configuration may combine wheel odometry, an IMU, GNSS/RTK, and LiDAR or visual localization. The filter should fuse independent measurements where possible. Feeding two topics derived from the same encoder source can make the estimator overconfident unless covariance is adjusted appropriately.

Key limitations and validation steps

robot_localization estimates state from supplied measurements. It cannot correct systematic sensor errors that are absent from the measurement model, such as wheel slip on loose terrain, incorrect wheel radius calibration, IMU bias, or GNSS multipath near buildings.

Before using the estimate for autonomous navigation, validate the following points:

  • All sensor messages use correct ROS timestamps.
  • Static transforms between sensors and base_link are present in the TF tree.
  • Covariance matrices are populated and reflect realistic uncertainty.
  • Only physically meaningful state variables are enabled in each *_config vector.
  • The odom, map, and base_link frame roles follow REP-105.

Normative references and documentation

The primary references for implementation are the official ROS package documentation and ROS Enhancement Proposals. ROS 1 and ROS 2 releases expose similar filtering concepts, but launch syntax, parameter files, package versions, and message APIs must match the selected ROS distribution.

See also