0
$\begingroup$

Rosanswers logo

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 assumes (???) that this orientation requires no transform, and is simply already in the frame it's calculating (e.g. odom).

Originally posted by zlacelle on ROS Answers with karma: 30 on 2019-06-13

Post score: 1

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

Rosanswers logo

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.

Originally posted by Tom Moore with karma: 13689 on 2019-07-03

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by zlacelle on 2019-07-03:
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.

Comment by zlacelle on 2019-07-09:
I edited my question above as well, but I think this answer makes sense and matches with my current understanding. Thank you!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.