The frame_id of the Imu message must be the frame in which the Imu is mounted.-------
This resolves the issues with acceleration and angular velocity, which are commonly transformed into /base_link before use.
Orientation can also be transformed into /base_link as long as there are frames connecting /imu_link to /base_link. The missing information here is parent_frame_id.
So if I understand correctly, for an Imu message with frame_id = X
- the acceleration and velocities are measured in the frame X
- the orientation is between a fixed inertial frame and X
If this is so, perhaps it would be worth it to update to IMU message description to clarify. The question remains: what should be the convention for the frame name? imu? imu_link?
In practice, drivers should not publish tf information directly, that should be published by a joint_state_publisher or sensor fusion stage. Unfortunately, this is where the confusion arises if your /odom or /world frame is not gravity aligned.
This is good to know. Some 9-DoF IMU publish raw data, without fusing the readings into a single orientation. In my phidgets IMU driver, I handle this by publishing a IMU message with empty orientation field, and a separate Vector3f message for the Magnetic field. Then I fuse the two in a separate node (imu_filter_madgwick)
The output of the driver (and input to the filter) is:
* /imu/data_raw (sensor_msgs::Imu)
* /imu/mag (sensor_msgs::MagneticField)
The output of the filter is:
* /imu/data (sensor_msgs::Imu)
Is this a good pipeline? Also, should the imu_filter_madgwick publish a tf? It's not a true tf, since only the orientation field is valid.
Ivan