Pose estimation

Pose estimation – definition

Pose estimation is the process of determining the position and orientation of a robot, sensor, or detected object relative to a defined reference frame. In mobile robotics, a pose is usually represented as a six-degree-of-freedom rigid-body transform in three-dimensional space:

T ∈ SE(3) = [ R  t ]
             [ 0  1 ]

In this representation, R is a 3 × 3 rotation matrix and t is a translation vector. ROS systems commonly express the same information through position coordinates x, y, z and an orientation quaternion x, y, z, w. The standard ROS message type is geometry_msgs/Pose, while geometry_msgs/PoseStamped adds a timestamp and frame identifier.

For an unmanned ground vehicle (UGV), pose estimation determines where the platform is located and which direction it is facing. This information is required by navigation, mapping, path tracking, obstacle avoidance, sensor fusion, and visual perception pipelines. On wheeled platforms such as Leo Rover and Raph Rover, pose estimation commonly combines wheel odometry with inertial, LiDAR, camera, GNSS, or RTK-GNSS measurements.

Pose estimation in the ROS 2 coordinate-frame system

ROS 2 uses the tf2 library to publish, buffer, and query coordinate-frame transforms. REP 105 defines the conventional frame hierarchy for mobile robots. It distinguishes global frames from locally continuous odometry frames and from robot-fixed frames.

A typical UGV transform tree contains the following frames:

map – a global frame used for localization and mapping. It can change discontinuously after relocalization or loop closure.
odom – a locally continuous frame generated from wheel odometry, IMU integration, or visual odometry. Its drift may grow over time.
base_link – the robot body frame. REP 105 defines it as rigidly attached to the mobile base.
base_footprint – an optional ground-projected frame often used by planar navigation systems.
laser, camera_link, imu_link, or gps_link – sensor frames typically connected to base_link by static transforms when the sensors are rigidly mounted.

The common relationship is map → odom → base_link. A localization system, such as AMCL or a SLAM package, publishes the correction between map and odom. Wheel odometry or state estimation publishes odom to base_link. This separation preserves local motion continuity while allowing global pose corrections.

ros2 run tf2_ros tf2_echo odom base_link
ros2 topic echo /odom
ros2 topic echo /tf
ros2 topic echo /tf_static

Source: REP 105: Coordinate Frames for Mobile Platforms; ROS 2 tf2 documentation.

Pose representations and ROS 2 message types

The selected message type depends on whether the application needs only geometry, a frame and timestamp, velocity, or uncertainty. A pose without covariance is insufficient for many fusion and navigation tasks because it does not indicate measurement confidence.

ROS 2 message	Purpose	Typical UGV use
`geometry_msgs/Pose`	Position and quaternion orientation	Internal geometric representation
`geometry_msgs/PoseStamped`	Pose with `std_msgs/Header`	Timestamped localization output
`geometry_msgs/PoseWithCovarianceStamped`	Pose plus 6 × 6 covariance matrix	GNSS-derived, AMCL, fiducial-marker, or visual localization input
`nav_msgs/Odometry`	Pose, twist, covariance, parent and child frames	Wheel odometry and fused state estimation

The covariance matrix represents uncertainty in position and orientation. In ROS message definitions, pose covariance is stored as 36 values representing a row-major 6 × 6 matrix for x, y, z, rotation about X, rotation about Y, rotation about Z. Source: geometry_msgs documentation and nav_msgs documentation.

How pose estimation works on a mobile UGV

No single sensor provides reliable pose estimates in every environment. Differential-drive wheel encoders provide frequent relative motion estimates but accumulate error through wheel slip, uneven terrain, incorrect wheel parameters, and skid steering effects. An IMU measures angular velocity and acceleration, but integration also drifts. LiDAR, cameras, and GNSS provide external constraints under different operating conditions.

A practical estimation stack can combine the following measurement sources:

Wheel odometry for short-term planar motion estimation.
IMU angular velocity and acceleration for orientation and motion dynamics.
2D or 3D LiDAR scan matching for localization against a map or SLAM-generated map.
RGB-D or stereo visual odometry for feature-based or direct motion estimation.
GNSS or RTK-GNSS for outdoor global position measurements.
AprilTag or ArUco detections for local pose measurements relative to known markers.

The robot_localization package is commonly used in ROS 2 to fuse odometry, IMU, and GNSS-derived measurements through Extended Kalman Filter (EKF) or Unscented Kalman Filter (UKF) nodes. Its output is typically published as nav_msgs/Odometry and as a transform from odom to base_link.

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    publish_tf: true
    odom_frame: odom
    base_link_frame: base_link
    world_frame: odom
    odom0: /wheel/odometry
    odom0_config: [false, false, false,
                   false, false, false,
                   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]

The value frequency: 30.0 in this example is a configuration choice, not a platform specification. It must be selected according to sensor rates, compute capacity, transport latency, and control-loop requirements.

Pose estimation on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform for which ROS 2 Humble-based software is available. Its base motion can provide an odometry input for a local pose estimate, but wheel odometry alone does not provide globally accurate localization. A navigation deployment therefore requires sensor integration, frame calibration, and a configured localization or SLAM stack.

For indoor experiments with Leo Rover, a common architecture uses wheel odometry and an IMU for local state estimation, then adds a 2D LiDAR or depth camera for map-based localization or SLAM. The resulting global pose can support Nav2, provided that the required transforms, costmaps, robot footprint, and sensor topics are correctly configured.

Raph Rover is intended for payload-demanding deployments. Its larger payload capacity can support multi-sensor configurations, such as LiDAR, RTK-GNSS receiver, IMU, and onboard compute. The estimation principle remains the same: every sensor requires a measured or calibrated transform to base_link, synchronized timestamps, and uncertainty values appropriate to the measurement source.

Common failure modes

Pose estimation errors often originate from integration rather than from the estimator itself. Frame naming, timestamp alignment, covariance configuration, and sensor mounting geometry must be verified before tuning filtering parameters.

Incorrect static transforms produce apparently plausible but spatially offset sensor data.
Wheel slip causes odometry drift, particularly on loose ground, ramps, grass, or gravel.
Unsynchronized sensor timestamps degrade fusion quality during rotation or acceleration.
Invalid quaternion values can cause unstable orientation handling. Quaternions should be normalized.
Overconfident covariance values cause a filter to trust inaccurate measurements excessively.
A missing map → odom transform prevents a standard global navigation setup from resolving robot pose in the map frame.

References and conventions

ROS frame conventions and message semantics are documented through ROS Enhancement Proposals and ROS interface packages. These references are relevant when implementing interoperable ROS 2 UGV systems.