# How to correctly conform to REP-145

Edit later down to try and clarify the question.

I'm writing a driver for a GNSS/INS solution. The data it provides is:

• An internally fused north- and gravity-oriented orientation
• Acclerations in a Z-down frame
• Rotational rates in a Z-down frame

There are two pieces of data I need to produce, per REP-145:

• imu/data_raw - The raw readings, converted to a front-left-up frame

However, unlike nav_msgs/Odometry, sensor_msgs/Imu doesn't have a separate frame_id for Twist information vs Pose information.

Thus, REP-145 tells us to produce orientation in ENU if that's what the sensor provides, but also to duplicate the accelerations and rotational rates from the data_raw topic.

So, my question is:

• imu/data_raw - Filled with REP-105-conformation (front-left-up) accelerations and rotational rates?
• imu/data:
• The angular_velocity and linear_acceleration portions filled now with ENU-transformed versions of the data in imu/data_raw?
• The orientation portion filled with the ENU orientation?

Or, should I fill the angular_velocity and linear_acceleration portions with front-left-up velocities and accelerations? In that case, which frame should be put into frame_id?

Or, should I fill everything (including imu/data_raw) with ENU-transformed accelerations/rotations?

Or, should imu/data_raw contain the sensor-specific data (front-right-down formatted), and imu/data contain everything transformed to ENU?

And most important, which format will be most accepted by robot_localization?

EDIT: I'm updating this question to try and make it more clear for future readers, hopefully.

We have the FLU fixed frame to the IMU, in which the data_raw (acceleration and angular rates) is published, which should have a frame_id of "imu_link" or whatever you'd like that is centered on the inertial unit with X pointing forward, Y pointing left, and Z pointing up. The accelerations and angular rates are measured w.r.t. this vehicle-fixed origin (standard REP-103, REP-105, and REP-145 stuff).

We then have an orientation which is measured in the globally fixed frame of UTM (standard on dual-antenna INS, moving-baseline differential GNSS, or INS that can gyrocompass or fuse course-over-ground heading). There is some frame_id associated with this orientation, centered somewhere on the equator. Assume that the data (which is almost always in the X=north, Y=east, Z=down convention) has been transformed to conform to REP-105 (X=east, Y=north, Z=up).

I should add that this is NOT just a UTM-heading issue: if this orientation is coming out of the sensor initialized to some arbitrary identity (e.g. the Redshift UM7 IMUs) you have the same issue.

Since sensor_msgs/Imu doesn't contain 2 frame_id's, thus cannot resolve the orientation's transform origin, I assume that' * we fill the frame_id with "imu_link" i.e. FLU, vehicle-fixed * we assign whatever orientation we want into the orientation field, assuming it conforms to REP-105 (so an ENU or FLU orientation, with some origin either arbitrary (e.g. identity on startup) or globally fixed (e.g. UTM) * If we fuse into robot_localization as an orientation, I assume (???) that robot_localization ...

edit retag close merge delete

Sort by » oldest newest most voted

However, unlike nav_msgs/Odometry, sensor_msgs/Imu doesn't have a separate frame_id for Twist information vs Pose information.

Yes, this is an issue that's been pointed out before. The message should really have frame_id fields for orientation, velocity, and acceleration. It makes processing IMU data awkward.

Or, should I fill the angular_velocity and linear_acceleration portions with front-left-up velocities and accelerations? In that case, which frame should be put into frame_id?

Do this. Put whatever you want in the frame_id, but then provide a static transform from base_link to that frame, and make that transform the sensor's offset w.r.t. the robot's origin.

more

OK, makes sense for fusing the orientation to base_link using the lever arm, but what about the order of rates and accelerations? They're in the body frame, and I assume in FLU convention? Then for the orientation, assuming ENU-oriented data from the sensor, we'd provide the 6DOF from the sensor measurement to the body frame assuming the axis are oriented such that 0 heading is with X pointing east?

To try and explain the 2nd half of that question better: if the sensor reads 0 heading when facing North, with the X axis of the sensor facing forward, then I assume I also need to augment the transform with the appropriate rotations to make it read 90 degrees when facing north.

( 2019-07-03 08:41:38 -0500 )edit

I edited my question above as well, but I think this answer makes sense and matches with my current understanding. Thank you!

( 2019-07-09 09:08:54 -0500 )edit