[ros-users] sensor_msgs Low Cost/Android review

Chad Rockey chadrockey at gmail.com
Wed Nov 14 21:41:26 UTC 2012


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 at gmail.com
> wrote:

> On Wed, Nov 14, 2012 at 2:39 PM, Ivan Dryanovski <
> ivan.dryanovski at 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121114/a021ebd5/attachment-0004.html>


More information about the ros-users mailing list