Ask Your Question
1

How to correctly conform to REP-145

asked 2019-06-13 14:36:41 -0500

zlacelle gravatar image

updated 2019-07-09 09:07:41 -0500

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
  • imu/data - The raw readings with the orientation data added

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 ... (more)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2019-07-03 04:48:16 -0500

Tom Moore gravatar image

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.

edit flag offensive delete link more

Comments

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.

zlacelle gravatar imagezlacelle ( 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!

zlacelle gravatar imagezlacelle ( 2019-07-09 09:08:54 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2019-06-13 14:36:41 -0500

Seen: 148 times

Last updated: Jul 09