Ask Your Question

robot_localization adjusting launch file

asked 2014-09-23 03:43:55 -0500

mister_kay gravatar image

updated 2014-09-23 04:01:51 -0500


I have a bagfile of a drive with a vehicle around a building. Inside there is a visual odometry topic (nav_msgs/Odometry Message), an IMU topic (sensor_msgs/Imu Message), a GPS topic (sensor_msgs/NavSatFix Message and remapped via gps_common nav_msgs/Odometry Message ) and a Wheel Odometry topic (nav_msgs/Odometry Message).

I would like to fuse the data with the package robot_localization. After working with it for a while I encountered some things which I am not sure about.

  1. The Wheel Odometry topics frame_id is a local navigation frame which has no available transformation to my bodyframe (base_link) or my odom frame. Therefore linear and angular velocities are expressed in this local navigation frame rather than in body coordinates. (I don' t know why this is). Also there are no values given for pose and twist covariance (zeros) and Z-position, z-velocity, velocity over roll and pitch remain zero the entire time.

Can I fuse this wheel odometry in "robot_localization" and how would that be done? I think about remapping the topic to a new topic adding the covariance info. Do I have to set

<param name="odom0_differential" value="true" />

for the wheel odometry? What would be good values for the covariance matrix?

  1. My visual odometry topic is computed via "viso2ros", there are static covariance matrices for pose and twist. In the solution of the filter I can see (rviz displaying the odometry/filtered topic) that the computed solution follows rather strictly the visual odometry. I figure the covariance values should be increased. Could that be?

  2. What would be the settings in the launch file for my configuration (as described above), where odom0=wheelodometry, odom1=visual_odometry, odom2=gps (xsens, only x,y,z available plus covariances) and imu0=xsens.


<rosparam param="odom0_config">[false, false, true, false, false, true, false,  false, true, false, false, true] </rosparam>
<rosparam param="odom1_config">[true, true, false, true, true, false,  true,  true, true, false, false, true]</rosparam>
<rosparam param="odom2_config">[true, true, false, false,  false, false, false,  false, false, false, false, false ]</rosparam>
<rosparam param="imu0_config">[false, false, false, true,  true,  false, false, false, false, true,  true,  false ]</rosparam>

<param name="odom0_differential" value="true"/>
<param name="odom1_differential" value="false"/>
<param name="odom2_differential" value="false">
<param name="imu0_differential" value="false"/>

The odom and world-frame are called "utm". I am glad for any help! Update: I receive the warnings:

  1. "Could not obtain transform from wheel_odometry to utm. Error was "wheel_odometry passed to lookupTransform argument source_frame doesnot exist."

  2. "Could not obtain transform from gpsfix to utm. Error was " lookup would require extrapolation into the future."

edit retag flag offensive close merge delete


My response to this is going to be lengthy, but I need a bit more info: is this robot meant to operate in 2D or 3D?

Tom Moore gravatar imageTom Moore ( 2014-09-23 10:03:38 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2014-09-23 19:04:01 -0500

Tom Moore gravatar image

(@mister_kay was kind enough to provide me with a bag file, so some of my response will relate to that data.)

There are some changes you need to make to your launch files and also some changes you need to make to your sensor data.

First, just so we're on the same page, it appears from plotting your GPS data in Google Earth that you started facing more or less directly north, then drove forward a bit, made a left turn, and then carried on going straight and turning left until you sort of completed a square. Please let me know if this is incorrect.

Assuming I'm correct, though:

  • First, your wheel odometry data. Do you have access to the node that generates it? I would change its frame_id to "odom," fix its velocities so they're in base_link (or in your case, mustang_base), and then make sure to fill out the child_frame_id with that value. More importantly, however, you need to fix your orientation data. If you watch the output of your wheel odometry message, you will see that your yaw angle (once converted from a quaternion) is turning right after each leg, i.e., the value decreases. However, we know from the GPS data that the robot actually turned left. See REP-103. When you turn left, your yaw angle should increase, and turning right should result in a decrease.

    The Z, roll, pitch, and their respective velocities will remain zero, as this information is probably coming just from wheel encoders, which simply measure wheel rotations and therefore cannot measure 3D pose and velocity variables.

    As for the covariances, you should give them non-zero values. robot_localization can handle zero covariances, but it does so by changing them to a small positive value. This means that the measurements from any data source with zero covariances will be "trusted" too much by the filter.

    If for whatever reason you are unable to modify the velocity data, I would configure your odometry data this way (after you fix the sign of your yaw data, of course):

    <param name="odom0" value="wheel_odometry"/>

    <rosparam param="odom0_config">[true, true, true, false, false, true, false, false, false, false, false false]</rosparam>

    <param name="odom0_differential" value="true"/>

  • The same goes for your visual odometry data. Its yaw velocity angle seems to be negated. Also, for some reason, its data is reported in the UTM frame. There are other issues with your UTM frame handling that are causing some grief, but for now, I would report this data in the frame_id = odom frame, with its child_frame_id set to mustang_base. It's possible that the reason your state estimate followed the visual odometry so closely is that you wheel odometry couldn't be transformed into the correct frame, and was being ignored.

    <param name="odom1" value="wheel_odometry"/>

    <rosparam param="odom1_config">[false, false, false, false, false, false, true, true, true, true, true, true]</rosparam>

    <param name="odom1_differential" value="false"/>

  • Your GPS data looks to be very close to ...

edit flag offensive delete link more


Thank you very much for your help. Your effort is highly appreciated! I will try to fix the diff. sensor settings. The thing is that mustang_base(base_link) as well as the frame "utm" is referenced in a North-East-Down system. Therefore when driving a left curve the angular vel. around z is negative

mister_kay gravatar imagemister_kay ( 2014-09-24 09:01:01 -0500 )edit

I believe +X is east in the UTM grid and +Y is north. Z points up out of the ground, making the coordinate frame right-handed (at least, that's what utm_odometry_node appears to produce). In any case, robot_localization (and ROS itself) assume a right-handed coordinate frame.

Tom Moore gravatar imageTom Moore ( 2014-09-24 10:53:44 -0500 )edit

That is a good point. It occured to me too, that the "utm_odometry_node" in gps_common has the coordinate frame structue you described. This structure differs from "our" North, East Down system. There are still a lot of things which I have to think about ...

mister_kay gravatar imagemister_kay ( 2014-09-26 05:52:28 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2014-09-23 03:43:55 -0500

Seen: 1,929 times

Last updated: Sep 23 '14