# IMU message definition

Hi all,

I am working on a driver for the CH Robotics UM7 Inertial Measuring Unit. It is becoming apparent that there are some differences of opinion on how IMU data is to be interpreted for the ROS system.

Following is my opinion on how it should be done, hoping for some discussion confirming or correcting my understanding.

1. An IMU is mounted in a fixed location and orientation relative to the vehicle. It uses a body axes coordinate system. REP –103 defines these axes as: x = forward, y = left, and z = up.

Forward should be interpreted as being pointed in the “forward” vehicle direction of motion.

Left is lateral motion perpendicular to the X axis and pointed toward the left.

Up is directly away from the Earth’s center.

2. Only the Z axis has a relationship to the outside world and is usually determined using accelerometers that measure the direction of gravity during unaccelerated motion. The X and Y axes, being orthogonal to the Z axis, are tangent to an idealized Earth’s surface but have no specified direction relative to the Earth.

3. If the vehicle is level on the Earth’s surface, the X and Y accelerometers should report about 0 m/sec^2 and the Z axis accel should be approx +9.8 m/sec^2 reflecting an apparent upward acceleration away from gravity force.

4. The rate gyros should be in accordance with the right hand rule as stated in REP –103.

Rotation about the Y axis (pitch motion) should be positive in the nose down direction.

Rotation about the X axis (roll motion) should be positive for right side down motion.

Rotation about the Z axis (yaw) should be positive for CCW rotation looking down on the vehicle.

5. An IMU will commonly calculate attitude information using its rate gyro and accelerometer data. Such attitude data, whether in the form of Euler angles, Quaternions or other means should be with respect to the body axes and polarities are the same as for the rate gyros above. Data values should vary over the range of +/- pi radians.

6. IMUs also commonly provide magnetometer and/or compass information. For ROS, such data should reflect the direction of North relative to X axis. I.e. if the robot is pointed northeast, a compass reading should be –pi/4. (note: the preceding is a strawman since I don’t have a firm opinion) Range should be +/- pi. Magnetometer data should also indicate North with respect to the body axes.
An IMU often provides an optional feature in which the zero angle of yaw is set and maintained at the North direction as indicated by the magnetometer. This is a convenience to the user since it provides long term stability of the yaw angle as opposed to continuous integrator drift. It does not convert the IMU into an NED (or ENU) system. A driver should allow selection of this option or not. .

7. Use of either NED or ENU navigation coordinates has no effect on the data sent from an IMU. Transformation from IMU body axis to either NED or ENU coordinate systems is the responsibility of navigation software, not the IMU.

8. I come from the autopilot world and body oriented data is useful for direct control of the vehicle, Earth axis oriented data does not replace body data.

9. I don’t go into IMU use of gps data, since I haven’t used it (my robots are indoors people). That data probably needs definition too.

10. I think the standards provided for ROS are too general to define clear interfaces using the standard messages. E.g. imu/data is used for different purposes, like body and various earth axes, There should probably be specific data definitions for each proposed use.

Thanks, Alex Brown

Originally posted by Alex Brown on ROS Answers with karma: 176 on 2015-01-06

Post score: 9

Comment by Alex Brown on 2015-01-07:
I missed one of the most important issues: Most IMU sensors provide data in an X (forward), Y(right) and Z(down) coordinates. The proper transformation to ROS coordinates is a 180 degree rotation about the X axis, or more simply, negate (change sign) of Y and Z.

Comment by Martin Günther on 2015-01-08:
Agree, but as long as it's a right-handed coordinate system, it doesn't matter. Where "up" is is defined by the IMU output and not where the screws are. If you mount the IMU "upside down" on a robot, you can reflect that in the robot's URDF.

Comment by Alex Brown on 2015-01-09:
Ah, but for we people who build simpler robots, we use the data directly with no URDF transformations. So it only works one way.

Comment by Thomas D on 2015-01-12:
Due to different mounting positions the IMU message should have no concept of "forward vehicle direction of motion" or any other vehicle characteristics. That would imply that the source code would have to be modified if the IMU was mounted in any position other than that assumed by the driver.

Comment by Alex Brown on 2015-01-12:
I think I agree. The IMU itself has no concept of mounting. But the robot has to know the transform between an arbitrary mounting orientation and the robot. Specifying/suggesting a standard location eliminates the need for a transform. Or correct it in the URDF as martin suggests

Comment by natejgardner on 2017-05-23:
Was #6 ever solved? What is the usual best practice for IMUs with magnetometers? My IMU orientation vector is relative to earth, but angular velocity and acceleration are relative to the IMU frame. How do I rectify this in a single message, which obviously can't live in two frames?

ROS REP 145 is under review to try to resolve some of these issues: PR discussion https://github.com/ros-infrastructure/rep/pull/95

Future URL: http://www.ros.org/reps/rep-0145.html

Originally posted by tfoote with karma: 58457 on 2015-03-09

This answer was ACCEPTED on the original site

Post score: 0

I think I agree on all your points, but let's use an example to test: consider the case where we roll the IMU in the positive direction (so roll is +90 degrees), and then, while it is on its side, rotate it counter-clockwise 90 degrees. In other words, I want to do an extrinsic rotation of the IMU of +90 degrees of roll, then +90 degrees of yaw (with the intrinsic, IMU-frame rotation being +90 degrees roll, +90 degrees pitch). What do you expect the IMU to read for (a) orientation and (b) rotation rate? For (a), I expect the IMU to read +90 degrees roll, and +90 degrees yaw. For (b), while we are rolling it, I expect to see positive roll rate, and then when we carry out the second rotation, I expect to see positive pitch rate.

Originally posted by Tom Moore with karma: 13689 on 2015-01-07

This answer was NOT ACCEPTED on the original site

Post score: 4

Comment by paulbovbel on 2015-01-09:
+1. Have you found any drivers (or simulated IMUs) where this does not take place?

Comment by Tom Moore on 2015-01-12:
I'm pretty sure there's an issue with the hector_gazebo_plugins simulated IMU.

Fully agree with all of your points.

Perhaps you could also have a look at the imu_tools/imu_filter_madgwick package. You only need to provide the angular velocity and linear acceleration values from your device (optionally also magnetometer readings), and they will be fused to arrive at an orientation that follows the standards you outlined above.

Edit in response to Alex's comment:

I guess there's something wrong with what you visualize, but to be sure, I first tested that the IMU I use (Phidgets Spatial 3/3/3) actually follows the conventions you outlined, and it does (all on the imu/data_raw topic):

angular_velcocity:

• Rotation about the Y axis (pitch motion) is positive in the nose down direction.
• Rotation about the X axis (roll motion) is positive for right side down motion.
• Rotation about the Z axis (yaw) is positive for CCW rotation looking down on the vehicle.

linear_acceleration:

• When stationary, x and y are around 0, z is around +9.8. All increase when jerked into the direction of their respective axis.

This leaves the visualization part. What I do is:

1. Launch this imu.launch file. The file contains both the IMU driver and the imu filter node. Note that I set publish_tf to false, since IIRC it was either wrong or at least misleading, and that I set the fixed frame to imu.
2. Run rviz, set the fixed frame to imu and add a visualization of type rviz_imu_plugin (part of the imu_tools package). Set imu/data as the input topic.
3. Run rqt_plot and plot imu/data_raw/angular_velocity and imu/data_raw/linear_acceleration.

Hope this helps!

Originally posted by Martin Günther with karma: 11816 on 2015-01-07

This answer was NOT ACCEPTED on the original site

Post score: 4

Comment by Alex Brown on 2015-01-07:
I installed the filter and remapped my driver output to imu/data_raw. The orientation on the filter's imu/data topic closely tracks my drivers output, but all opposite polarity. Does this make any sense to you? I verified that topics are coming from driver & filter respectively.

Comment by Martin Günther on 2015-01-08:
See update.

Comment by Alex Brown on 2015-01-10:
Can't get RVIZ to work, not even rqt_plot which won't accept topics in command line or gui. It used to! But, for some reason, the imu/data from the filter is now in agreement with the imu/data_raw from my driver. rates, accels & orientation. I don't know what happened before.

Comment by Jasmin on 2017-02-27:
hey Martin, I'm also using the Phidgets Spatial 3/3/3 1042 , and I'm a little bit confused regarding the expected variations in accelerations and velocities when moving it as you described. (0 1 2) are respectively (x y z) ? what neutral position you are using?

On board with all of the above.

Regarding your comment: many/most IMUs have a reference orientation shown on the device (e.g. http://www.ecnmag.com/sites/ecnmag.com/files/USR1001507_134852_MicroStrain3DMGX335InertialSensor_0.png). I think it would make sense to output the orientation in terms of the 'orientation of the reference frame in the world frame'. Correspondingly, we should output the angular_velocity and acceleration in this reference frame as well.

Counterintuitively, the um6 driver manipulates the data internally (https://github.com/ros-drivers/um6/blob/indigo-devel/src/main.cpp#L205), with the goal of providing a more intuitive IMU orientation (ENU instead of NED). I think this kind of hidden-transformation adds confusion instead - the data frame no longer matches the reference image on the device.

I think it makes sense to leave setting up a proper base_link->imu_link transform to whoever is integrating the IMU on the robot. The only time it would be appropriate to do a driver-side transform would be to convert from left-handed to right-handed.

--- EDIT

I think a REP (amendment) would go a long way to reinforcing standards for IMU output, particularly regarding orientation data in the world-fixed and rotation/acceleration data in the device's reference frame, the adherence to right-handedness in the rotations, and the orientation of the device's acceleration vector due to gravity (up not down).

Originally posted by paulbovbel with karma: 4518 on 2015-01-07

This answer was NOT ACCEPTED on the original site

Post score: 4

Comment by Alex Brown on 2015-01-07:
In my experience designing commercial aircraft autopilots, acceleration and angular rate signals were always in the aircraft body axis. I think your suggestion perhaps makes more sense for a navigation device using the data; which could make the transform itself.

Comment by Tom Moore on 2015-01-08:
I'd prefer to see the orientation reported in a world-fixed frame, and the angular velocity and acceleration reported in the IMU's body frame. The Odometry message handles its orientation and angular velocity this way (pose in one frame, twist in another).

Comment by Alex Brown on 2015-01-08:
I think that if you chose to use the mag update option, which slaves the yaw axis to magnetic north, you pretty much have a world-fixed frame. Does this work for you?

Comment by Tom Moore on 2015-01-08:
Sorry, I'm referring not to the UM7 specifically, but to the interpretation of IMU data within ROS.

Comment by paulbovbel on 2015-01-09:
Tom, that makes sense, and I think what I stated lines up with that. My point was to reinforce that the velocity and acceleration data should be output in the reference frame of the device, and not in an arbitrary 'ROS friendly' frame such as 'device is right side up'.

Comment by paulbovbel on 2015-01-09:
This has only been an issue in the UM6. The microstrain issues you have found seem to be related to programmer error, or perhaps incompatibilities between sensors. I'm still waiting to get a GX2 from out of our PR2.

Comment by Alex Brown on 2015-01-09:
Perhaps I'm confused. Are you proposing that the IMU driver receive additional data so that it knows the IMU orientation with respect to an external world frame?

Comment by Alex Brown on 2015-01-10:
Tom, I just got it , I think. Your last comment about not referring to the UM7 meant that its implementation is satisfactory; and that other IMUs should have the same. I'd agree, but it should be optional. My indoor use requires that mag update be off to avoid magnetic influences..

Comment by paulbovbel on 2015-01-10:
No, but the orientation published by the IMU is an orientation in the 'world' reference frame, in practice the initial position of the IMU.