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 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 > >