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
- 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 ...
