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.
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.
I am interested in improving Imu tools, as standardized frameworks do not yet exist. It would be good to discuss these issues and develop these tools on the drivers sig:
On Wed, Nov 14, 2012 at 11:52 AM, Ivan Dryanovski
<ivan.dryanovski@gmail.com> wrote:
On Wed, Nov 14, 2012 at 2:39 PM, Ivan Dryanovski
<ivan.dryanovski@gmail.com> wrote:
Are there established conventions about the frame_id of imu messages, and the IMU pipeline of filters/publishers?
The problem becomes even worse when we consider that the Imu message [1] combines orientation data with linear acc. and angular velocities. The linear acceleration and angular velocities are usually provided in the sensor's own frame, but the orientation only makes sense in a fixed frame.
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users