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.
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:
https://groups.google.com/forum/?fromgroups#!forum/ros-sig-drivers
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.
>
> [1] http://www.ros.org/doc/api/sensor_msgs/html/msg/Imu.html
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
(text/plain)