Clarification of Odom and imu twist

[Michael Wimble]

When I generate Odom, it has a twist z value based upon wheel distance. When I generate imu, it has a twist based on a compass. When I use rviz to look at the imu frame pose based on the Odom frame I see twice the twist. Am I supposed to generate zero twist in the Odom frame? What should I be doing to not see twice the twist?

Sent from my iPhone

[Mark Johnston]

Not an 'expert' but my exposure to this was explained that there is often a need when multiple things generate a twist (you have 2) to have a node take them both in and sort them out then post the master odom mix to the /odem topic.    Here are some direct notes I have on this but they may come across as jibberish so sorry for that.  Main point is I believe you have to have logic to sort them out and prioritize then post output once.  Some of this note is specific to an architecture from a year ago and may have been changed.

---------- Start of a note I have ---------------

Because we generally want to know location of the 'base_link' (main robot base) the odometry publishers must 

publish a transform (typically to base_link) as well as the nav_msgs/Odometry message for velocity (in 3d).

Odometry publishes estimated pose (robot position) in geometry_msgs/PoseWithCovariance and then also 

publishes velocities in geometry_msgs/TwistWithCovariance. Both have estimate accuracy/error in the covariance estimate.

Odom_Mix: When you have a lot of things generating odometry info like fiducials, encoders and even sonars you may need

a node to take those in and produce a master /odem topic.  This prioritizes, makes sense of data and decides on /odom output

---------------- End Notes --------------------

I hope this is not an error in my humble understanding of this but it seems reasonable.  sorry I cannot vouch for where I heard this and will not drag possible names onto this email but I assure you they are all HBRC members (at large)

Mark

[Ralph Gnauck]

Michael,

I think what you see is normal.

The best way to view the raw  IMU pose is use the ROS  rviz-imu-plugin/imu (click add on the 'Displays' panel and choose this item), if it is not there you may need to use apt-get to install it. (don't use the rviz-plugin-tutorials/imu, it is different, not what I am mentioning).

Choose your IMU frame as the global frame, and under the plugin check the 'enable axis' option.

Then you will see a set of  axes that should move as you expect in response to moving the IMU.

If this works your IMU is working, once fused properly the base_link should move as expected relative to the odom frame.

The reason you see double rotations when using the odom frame as a global frame is convoluted and I think mainly due to a "Bug/Limitation" of the IMU message format.

This relates to the fact that there is only a single frame_id in the imu message data structure, but it really needs two.

There has been  a  discussions on ROS answers about this issue.

[ros-users] REP 145 - Conventions for IMU Sensor Drivers

[ros-users] REP 145 - Conventions for IMU Sensor Drivers

The problem is that the frame_id in the IMU is set to be the imu_link, this is fixed to the robot and moves with the robot.

This is the correct frame to use for the velocity and acceleration terms in the IMU data but the absolute pose (x,y,x,roll,pitch,yaw) should be referenced to a global frame (odom/map etc) but there is no field in the message to say this. (note that the odom message that has similar data does have two frame fields so  this is handled properly for odom messages).

One way around this is to only fuse the velocity components from the IMU message and ignore the absolute roll/pitch/yaw (this is what I am doing).

There may be some accepted conventions in use like the robot_localization node may automatically infer the global frame to use when fusing IMU absolute data so it just works, but don't quote me on this!!

However I think you want to use absolute heading  from your magnetometer, the accuracy you actually get with a magnetometer will be interesting, most examples I have seen (and tried) find the magnetometer to be not much use as there is far to much magnetic interference in the environment for it to be of any value (metal things, buried cables/pipes etc all mess it up), test it well.

You may find some additional help here:

What frame is sensor_msgs::Imu.orientation relative to? - ROS Answers: Open Source Q&A Forum

What frame is sensor_msgs::Imu.orientation relative to? - ROS Answers: Open... I have been looking at REP 103 and REP 105 along with nav_msgs::Odometry and sensor_msgs::Imu and I would like t...

When using the imu for absolute orientation with robot_localization node I think it should be treated in a similar way to absolute position data from a GPS so follow  the tutorials for that to get the idea.

I have not done this so cannot add any more details.

Ralph

---

From: Michael Wimble <mwi...@gmail.com>
To: "hbrob...@googlegroups.com" <hbrob...@googlegroups.com>
Sent: Monday, February 6, 2017 12:04 AM
Subject: [HBRobotics] Clarification of Odom and imu twist

When I generate Odom, it has a twist z value based upon wheel distance. When I generate imu, it has a twist based on a compass. When I use rviz to look at the imu frame pose based on the Odom frame I see twice the twist. Am I supposed to generate zero twist in the Odom frame? What should I be doing to not see twice the twist?

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+unsub...@googlegroups.com.
To post to this group, send email to hbrob...@googlegroups.com.
Visit this group at https://groups.google.com/group/hbrobotics.
For more options, visit https://groups.google.com/d/optout.