<div>Wed, Nov 14, 2012 at 4:41 PM, Chad Rockey <span dir="ltr"><<a href="mailto:chadrockey@gmail.com" target="_blank">chadrockey@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The frame_id of the Imu message must be the frame in which the Imu is mounted.<div>-------</div><div><br><div>This resolves the issues with acceleration and angular velocity, which are commonly transformed into /base_link before use.</div>




<div><br></div><div>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.<br></div></div></blockquote><div><br>
</div><div><div>So if I understand correctly, for an Imu message with frame_id = X</div><div> - the acceleration and velocities are measured in the frame X</div><div> - the orientation is between a fixed inertial frame and X</div>
<div><br></div><div>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?</div></div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>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.<br>
</div></div></blockquote><div><br></div><div>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)</div>
<div><br></div><div>The output of the driver (and input to the filter) is:</div><div> * /imu/data_raw (sensor_msgs::Imu)</div><div> * /imu/mag (sensor_msgs::MagneticField)</div><div>The output of the filter is:</div><div>
  * /imu/data (sensor_msgs::Imu)</div><div><br></div><div>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.</div><div><br></div>
<div>Ivan</div>