Wed, Nov 14, 2012 at 4:41 PM, Chad Rockey <chadrockey@gmail.com> wrote:

> 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