Proposed new messages to replace IMU message.

[tfoote]

From https://groups.google.com/forum/#!topic/ros-sig-drivers/2NvgNBOjcFQ

Also connected to ros-infrastructure/rep#95

I'm opening this for more review and to restart the discussion.

I see that we need a few things to be implemented before this can be merged.

• homogenize this with the REP 145 proposal, REP: 145 ros-infrastructure/rep#95
• Implement some python methods to convert forward and backwards between the old IMU message and the trio of new messages. And a node that can used to convert each way.
• Provide an IMU transport lib (in c++ and python) that will provide the necessary synchronization helper methods to handle the parallel transport in a way that keeps things synchronized.

[mikepurvis]

There'd be a comment here explaining what these mean and what their relationship is to sensor_frame?

[peci1]

Isn't this duplicating info from header?

[mintar]

No. From https://groups.google.com/g/ros-sig-drivers/c/2NvgNBOjcFQ/m/LfG6fhFbIBwJ:

Overview of frames for AHRS

/map # semi-global reference
|
---> ahrs_fix_ned/enu
|
---> odom
       | ---> base_link
                 |------> imu_link (the frame in which the ahrs sensor is mounted, possibly anywhere)

The sensor_frame should always be the frame of the IMU (/imu_link in this example). The way I understood the original proposal, the header.stamp should be the reference frame, like this:

• if reference_frame_type == ENU then header.stamp = ahrs_fix_enu
• if reference_frame_type == NED then header.stamp = ahrs_fix_ned
• if reference_frame_type == ENU_FLOATING then header.stamp = ahrs_fix_enu_floating
• if reference_frame_type == NED_FLOATING then header.stamp = ahrs_fix_ned_floating

... where the TF frames ahrs_fix_enu_floating and ahrs_fix_ned_floating don't exist (= are not connected to the /map frame). This is a bit weird, but the "floating" reference frames mean that the attitude is relative to some arbitrary reference frame (usually the startup pose of the sensor), and the transformation between /map and the startup pose is not known.

[mintar]

Something along these lines should probably added as a comment to this message.

[peci1]

Maybe consider adding bool is_gravity_compensated? Defaulting to false sounds good as that is the old behavior.

[peci1]

Define these right above reference_frame_type to make it more clear these belong to it?

[peci1]

Prefix the constants with REFERENCE_FRAME_?

[mintar]

We should probably copy the comment from the sensor_msgs/Imu message here:

common_msgs/sensor_msgs/msg/Imu.msg

Lines 5 to 8 in 20a833b

	# If the covariance of the measurement is known, it should be filled in (if all you know is the
	# variance of each measurement, e.g. from the datasheet, just put those along the diagonal)
	# A covariance matrix of all zeros will be interpreted as "covariance unknown", and to use the
	# data a covariance will have to be assumed or gotten from some other source

[Timple]

Why not enforce one of these?

Now all subscribers should handle this. I would like it better when there is only one definition within the ROS ecosystem.

[peci1]

Can you clarify how the enforcing should be done?

[Timple]

Stating in the message header-comment that ENU convention should be used.

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/if-you-work-with-imu-data-share-sample-and-get-thanked/30203/4