Frame Conventions

An IMU device may measure data with respect to two frames, specified by the manufacturer:

• The sensor frame represents the device's internal reference frame (the "input reference axes", IRA). It may be found in the device specification documents, and is sometimes indicated directly on the package of the device. This frame is fixed to the device (i.e. it is a moving coordinate frame).
• If an orientation estimate is provided (see Data Reporting), the device world frame represents the external reference with respect to which the sensor frame is indicated. Two out of three degrees of freedom of the sensor frame w.r.t. the world frame are usually considered "fixed" through gravity, with the relevant conventions from REP 103 [1] :
  • For NED type IMUs, the orientation of the world frame is x-north, y-east, z-down, relative to magnetic north.
  • For ENU type IMUs, the orientation of the world frame is x-east, y-north, z-up, relative to magnetic north.
• If the device does not have an absolute yaw reference (magnetometer), the world frame will only be aligned in roll and pitch (due to gravity), while the orientation around the z axis can be arbitrary.
• If the device does not have an absolute gravity reference (accelerometer), the world frame is not aligned to any external reference and aligned entirely to the power-on orientation of the sensor.
• The frame_id for all message types published by an IMU represents the sensor frame - the default frame ID for IMUs is imu_link. In compliance with REP 0103 [1], and as a hint to integrators, the default frame name for IMUs that use an NED world reference should be imu_link_ned.
  • The configuration of the sensor frame relative to other frames (e.g. base_link) represents the mounting position and orientation of the IMU [2].
  • The world frame orientation depends on the IMU device, and is not explicitly defined in the transform tree.
• The device has an associated neutral orientation, defined as the orientation of the device where the body and the world frame align [3].

Data Reporting

• To maintain interoperability with ROS conventions, all frames must be right handed. If any data is reported left handed the driver must convert it to right handed by inverting the y axis.
• All data from a sensor should be published with respect to a single consistent sensor frame. If any data is reported in an inconsistent frame of reference relative to the other data, the driver must transform it into the sensor frame before publishing.
• Otherwise, all data should be published by the driver as it is reported by the device. Any subsequent modifications to the data (e.g. filtering, transformations) should be delegated to a downstream consumer of the data [3].
• A prominent note should be made in the driver documentation regarding any internal data manipulation that does not comply with the requirements in this document.

Transformation

Applying a transformation to IMU data requires transforming both the body and the world frames. After a transformation, the output data represents the output of a simulated IMU having the new body and world frames.

Topics

The following topics are expected to be common to many devices - an IMU device driver is expected to publish at least one. Note that some of these topics may be also published by support libraries, rather than the base driver implementation. All message types below are supplemented with a std_msgs/Header, containing time and coordinate frame information.

• imu/data_raw (sensor_msgs/Imu)
  • Sensor output grouping accelerometer (linear_acceleration) and gyroscope (angular_velocity) data.
• imu/data (sensor_msgs/Imu)
  • Same as imu/data_raw, with an included quaternion orientation estimate (orientation).
• imu/mag (sensor_msgs/MagneticField)
  • Sensor output containing magnetometer data.

All message types provide a covariance matrix (see REP 103 [1]) alongside the data field (*_covariance). If the data's covariance is unknown, all elements of the covariance matrix should be set to 0, unless overridden by a parameter. If a data field is unreported, the first element (0) of the covariance matrix should be set to -1.

Common Parameters

IMU driver implementations should read as many of these parameters as are relevant.

• ~frame_id (string, default: imu_link or imu_link_ned)
  • The frame ID to set in outgoing messages.
• ~linear_acceleration_stddev (double)
  • Square root of the linear_acceleration_covariance diagonal elements in m/s^2. Overrides any values reported by the sensor.
• ~angular_velocity_stddev (double)
  • Square root of the angular_velocity_covariance diagonal elements in rad/s. Overrides any values reported by the sensor.
• ~magnetic_field_stddev (double)
  • Square root of the magnetic_field_covariance diagonal elements in Tesla. Overrides any values reported by the sensor.
• ~orientation_stddev (double)
  • Square root of the orientation_covariance diagonal elements in rad. Overrides any values reported by the sensor.