LiDAR-inertial odometry (LIO)

LiDAR-inertial odometry (LIO) – definition

LiDAR-inertial odometry (LIO) is a state-estimation method that combines LiDAR point clouds with measurements from an inertial measurement unit (IMU) to estimate a mobile robot’s motion over time. Its primary output is the robot pose, velocity, and often IMU bias estimates. In a UGV, LIO estimates the robot state in a local odometry frame as the vehicle moves.

LiDAR provides geometric constraints from surfaces, edges, and point-cloud registration. The IMU provides high-rate angular velocity and linear acceleration measurements. Fusing both sources improves pose estimation during rapid rotation, short LiDAR feature loss, and motion distortion within a LiDAR scan.

LIO is odometry, not necessarily full localisation or SLAM. It produces a locally consistent trajectory, but drift can accumulate over distance. A global map, loop-closure subsystem, GNSS/RTK measurements, landmarks, or external localisation may be required when a robot must maintain a globally bounded position estimate.

For ROS-based UGVs, LIO commonly publishes a pose in the odom frame and the transform odom → base_link. When a global localisation or mapping system is used, it may additionally provide map → odom, forming the transform chain map → odom → base_link. This convention follows REP 105, which defines coordinate frames for mobile platforms.

How LIO estimates UGV motion

An LIO pipeline first aligns timestamps, compensates for motion during the LiDAR acquisition period, and predicts the robot state from IMU data. It then matches the deskewed point cloud against local geometric features or a local map. The LiDAR residual corrects the inertial prediction.

A simplified robot state can be expressed as follows:

x = [p, v, q, ba, bg]

Where p is position, v is velocity, q is orientation, ba is accelerometer bias, and bg is gyroscope bias. The estimator predicts this state from IMU integration and minimises LiDAR registration error.

Common LiDAR residuals measure the distance between a point and a local plane or line feature. The optimisation may use an extended Kalman filter, an iterated Kalman filter, factor graph optimisation, or nonlinear least squares. LIO-SAM uses a factor-graph formulation, while FAST-LIO2 uses an iterated error-state Kalman filter and an incremental k-d tree for map management.

ROS 2 interfaces and coordinate frames

A ROS 2 LIO integration requires consistent message timestamps, valid frame identifiers, and a static transform between the LiDAR and IMU. The IMU and LiDAR must be rigidly mounted. Any movement between these sensors invalidates the extrinsic calibration assumed by the estimator.

The main ROS message types are defined in the official ROS interface packages:

sensor_msgs/msg/PointCloud2 for LiDAR point clouds.
sensor_msgs/msg/Imu for angular velocity, linear acceleration, and optional orientation.
nav_msgs/msg/Odometry for the estimated pose and twist.
geometry_msgs/msg/TransformStamped for TF transforms.

The relevant interface definitions are maintained in the sensor_msgs, nav_msgs, and tf2_ros ROS documentation. ROS coordinate conventions should follow REP 103. In particular, ROS mobile robots normally use x-forward, y-left, and z-up axes.

A minimal parameter structure for an LIO node may look like this:

lio_node:
  ros__parameters:
    lidar_topic: /points
    imu_topic: /imu/data
    odom_frame: odom
    base_frame: base_link
    lidar_frame: lidar_link
    imu_frame: imu_link
    publish_tf: true
    deskew_enabled: true

The exact parameter names depend on the selected implementation. A deployment must also publish the fixed LiDAR-to-IMU transform through a static TF publisher or a robot description processed by robot_state_publisher.

Key integration requirements

LIO quality depends more on calibration and timing than on the presence of a specific ROS package. A system can fail even when each individual sensor publishes valid messages. The most important engineering requirements are listed below.

Time synchronisation: LiDAR and IMU timestamps must use a consistent clock. Constant timestamp offset causes systematic scan-deskew errors.
Extrinsic calibration: The translation and rotation between imu_link and lidar_link must be measured or calibrated accurately.
IMU noise model: Accelerometer and gyroscope noise densities, random walk values, and bias behaviour should match the installed IMU.
Point-cloud fields: Some LIO packages require a per-point time field for deskewing. Not every LiDAR driver exposes this field in the same way.
Compute capacity: Point-cloud registration, local-map updates, and scan deskewing can exceed the capacity of a small onboard computer, especially with dense 3D LiDAR data.

LIO on Leo Rover and Raph Rover

On Leo Rover, LIO is typically an optional autonomy subsystem. Leo Rover can run ROS 2 on its Raspberry Pi-based onboard computer, but it does not provide autonomous navigation out of the box. A LiDAR, IMU, mounting hardware, power integration, TF configuration, and a navigation stack are required.

The differential-drive kinematics of Leo Rover provide useful additional information for validation. Wheel odometry can be compared with LIO output, or fused with it in a state estimator. Wheel odometry alone can drift on loose soil, ramps, wet surfaces, or during wheel slip. LIO can provide a more stable local pose estimate when sufficient geometric LiDAR structure is present.

Raph Rover is more suitable when the sensor payload, compute unit, battery system, or environmental enclosure exceeds the practical payload budget of a smaller research platform. The LIO architecture remains the same. The installation must preserve rigid sensor geometry and protect the LiDAR field of view from vibration, cable obstruction, and vehicle-mounted payloads.

Limitations and operational trade-offs

LIO cannot guarantee reliable localisation in every environment. Long uniform corridors, open fields with few returns, dust, rain, glass, vegetation motion, and repetitive structures reduce geometric constraints. Aggressive vibration can also degrade IMU measurements and shift sensor extrinsics.

For autonomous navigation, LIO is commonly connected to a mapping or localisation layer and then to Nav2. The LIO output should be treated as one source of robot state. If global positioning is required outdoors, GNSS/RTK can be fused at a higher level, provided its covariance, antenna position, and reference frame are configured correctly.

Normative references and technical sources

The following sources define the ROS conventions and message interfaces most relevant to an LIO deployment on a mobile robot.

LiDAR-inertial odometry (LIO)