IMU

IMU – definition

An IMU, or Inertial Measurement Unit, is an electronic sensor module that measures a robot’s motion using inertial sensors. In mobile robotics, an IMU typically contains a 3-axis gyroscope and a 3-axis accelerometer. Some units also include a 3-axis magnetometer, but this is not required by the ROS sensor_msgs/msg/Imu message. On UGV platforms, the IMU is used to estimate angular velocity, linear acceleration, and orientation-related states after sensor fusion.

In ROS and ROS 2, IMU data is represented primarily by the sensor_msgs/msg/Imu message type. This message includes orientation, angular velocity, linear acceleration, and their covariance matrices. The message format is part of the standard ROS sensor interface and is used by localization, state estimation, SLAM, and navigation components. For a ground robot such as Leo Rover or Raph Rover, the IMU is not a complete localization system. It is one sensor in a larger estimation pipeline that usually also includes wheel odometry, LiDAR, cameras, GPS, or RTK GNSS.

From a robotics perspective, the IMU is important because wheel odometry alone drifts during slip, uneven terrain, and rapid heading changes. An IMU helps stabilize orientation estimates, improve dead reckoning over short intervals, and support motion compensation in perception stacks. This is especially relevant on differential-drive UGVs operating outdoors, on ramps, gravel, or grass, where non-ideal wheel-ground contact is common.

How an IMU works in mobile UGV systems

An IMU measures inertial quantities in the sensor frame. The gyroscope outputs angular velocity, usually in rad/s. The accelerometer outputs specific force, usually in m/s². If gravity is not removed by the device firmware, the accelerometer reading includes gravitational acceleration. Orientation may be provided directly by the sensor’s onboard filter, or computed later in the robot software stack.

For UGVs, IMU processing usually follows this sequence:

raw sensor readout from the hardware interface
timestamping and publication to ROS 2 topics
frame assignment according to ROS TF conventions
optional bias correction and filtering
fusion with wheel odometry, GNSS, LiDAR, or visual odometry

The short-term motion model is based on integration. In simplified form:

ω(t) -> integrate -> orientation
a(t) - g -> integrate -> velocity -> integrate -> position

In practice, direct integration of IMU data causes drift because gyroscope bias and accelerometer noise accumulate quickly. For that reason, IMU-only navigation is not sufficient for typical ground robots. The sensor becomes useful when fused with other sources in an Extended Kalman Filter, Unscented Kalman Filter, factor graph, or tightly coupled visual-inertial or inertial-GNSS estimator.

IMU data in ROS 2

In ROS 2, the canonical interface is sensor_msgs/msg/Imu. The message fields are standardized and expected by many packages, including robot_localization, localization pipelines used with Nav2, and perception systems that consume orientation or angular velocity. ROS also relies on a consistent frame tree defined in TF2.

The most important ROS 2 IMU fields are:

Field	Meaning	Typical unit
`header.frame_id`	sensor frame name	string
`orientation`	estimated sensor orientation	quaternion
`angular_velocity`	turn rate from gyroscope	rad/s
`linear_acceleration`	specific force from accelerometer	m/s²
`*_covariance`	measurement uncertainty	3×3 matrix

ROS conventions matter. If orientation is unavailable, the orientation covariance should indicate that the estimate is not provided, according to the message definition. Frame consistency is also critical. The IMU frame should be defined relative to base_link in TF, and axis orientation must match the physical mounting. A sign error in the yaw axis or an incorrect static transform will degrade localization immediately.

ros2 topic echo /imu/data
ros2 topic hz /imu/data
ros2 run tf2_ros tf2_echo base_link imu_link

Key parameters and metrics

For robotic integration, the useful IMU specification is not only the sensor type. The critical factors are timing, noise, bias stability, and calibration quality. Data sheet values should be checked against the intended estimator update rate and platform dynamics.

The main IMU parameters are:

sampling rate – common ROS topic rates are 50 Hz, 100 Hz, 200 Hz, or higher
gyroscope range – for example ±250, ±500, ±1000, or ±2000 deg/s
accelerometer range – for example ±2 g, ±4 g, ±8 g, or ±16 g
noise density – affects short-term estimate quality
bias instability – affects long-term drift
timestamp quality – important for fusion with LiDAR, cameras, and wheel encoders
covariance values – used by ROS estimators to weight measurements properly

On a small rover, a 100-200 Hz IMU stream is common and usually sufficient for state estimation. Lower rates may still work for basic heading stabilization, but they are less effective for dynamic fusion. High rate data is only useful if timestamps are accurate and synchronized with the rest of the sensor stack.

Integration on Leo Rover and Raph Rover

On Leo Rover, the IMU is typically integrated as part of a ROS 2-based sensing stack running on the onboard Raspberry Pi compute unit or on an attached companion computer. Since Leo Rover is a differential-drive platform and not an autonomous vehicle out of the box, the IMU usually complements wheel odometry and a perception sensor such as LiDAR or a depth camera. Its main role is to improve heading observability, detect pitch and roll on uneven terrain, and support localization during wheel slip.

On Raph Rover, the same principles apply, but the larger payload budget allows more advanced sensor sets and higher-grade inertial units. In field deployments, the IMU is often fused with RTK GNSS, 3D LiDAR, or visual-inertial pipelines. This is useful in agriculture, construction, and inspection scenarios where terrain is less structured and motion is more aggressive than in laboratory environments.

A typical ROS 2 fusion setup uses robot_localization with wheel odometry and IMU:

ekf_filter_node:
  ros__parameters:
    frequency: 50.0
    base_link_frame: base_link
    odom_frame: odom
    world_frame: odom
    imu0: /imu/data
    odom0: /wheel/odometry
    imu0_config: [false, false, false,
                  true,  true,  true,
                  false, false, false,
                  true,  true,  true,
                  true,  true,  true]
    imu0_remove_gravitational_acceleration: true

This configuration pattern is common in ROS 2 deployments, but the exact parameter set depends on the estimator and sensor characteristics.

Limitations and trade-offs

An IMU improves state estimation, but it does not remove the need for external references. Low-cost MEMS IMUs are sensitive to bias drift, vibration, thermal effects, and mounting errors. On wheeled UGVs, the most common integration issues are poor calibration, wrong covariance settings, and mechanical vibration from the chassis or gearbox.

The practical limitations are:

yaw drifts without an external reference such as wheel odometry, magnetometer, LiDAR, or GNSS heading
position from pure inertial integration diverges rapidly
magnetometers are often unreliable near motors, power wiring, and metal structures
consumer-grade IMUs vary significantly in timestamp accuracy and temperature stability

For Leo Rover and Raph Rover, this means the IMU should be treated as one estimator input, not as a standalone navigation solution.

Normative references and standards

The technical meaning of IMU data in ROS is grounded in the standard message definitions and TF frame conventions. The most relevant references are the ROS 2 message specification for sensor_msgs/msg/Imu, REP 103 for standard units and coordinate conventions, and REP 105 for coordinate frames used on mobile platforms. For hardware interpretation, sensor data sheets from IMU manufacturers define measurement ranges, noise density, bias stability, and output rate. For integrated navigation, IEEE and vendor documentation for GNSS/INS systems provide the formal terminology for inertial sensing and fused state estimation.

IMU