Revision history - ROS Answers: Open Source Q&A Forum

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0measurement. My guess is that what's happening is your odom0's yaw estimate starts to disagree strongly with your IMU's measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in. Give that a shot and let me know how it goes.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0measurement. My guess is that what's happening is your ~~odom0's yaw estimate~~ odometry's yaw measurement starts to disagree strongly with your IMU's yaw measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in. Give that a shot and let me know how it goes.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0measurement. My guess is that what's happening is your odometry's yaw measurement starts to disagree strongly with your IMU's yaw measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in. ~~Give that a shot and let~~

EDIT: I see you've already tried excluding yaw from odom0. This leads me ~~know how it goes.~~to believe what I said is true.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0 measurement. My guess is that what's happening is your odometry's yaw measurement starts to disagree strongly with your IMU's yaw measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in.

EDIT: I see you've already tried excluding yaw from odom0. This leads me to believe what I said is true.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0 measurement. My guess is that what's happening is your odometry's yaw measurement starts to disagree strongly with your IMU's yaw measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in.

EDIT: I see you've already tried excluding yaw from odom0. and it worked. This leads me to believe what I said is true.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

So your odom0 topic is providing yaw and yaw velocity? My guess is that whatever is producing that message is integrating the yaw velocities to produce a yaw estimate. robot_localization is already handling that integration, so you should remove yaw from your odom0 measurement. My guess is that what's happening is your odometry's yaw measurement starts to disagree strongly with your IMU's yaw measurement after a few turns, and so you'll see oscillations back and forth as the measurements come in.

EDIT: I see you've already tried excluding yaw from odom0 and it worked. This leads me to believe what I said is true.

A second possibility (and one that I don't really recommend) would be for you to make sure that your yaw variance value for odom0 is growing as the robot makes more turns. Unlike the IMU, the error on your odometry's yaw estimate should grow every time you get nonzero yaw velocity. The IMU, on the other hand, will have a more or less fixed error on its yaw measurements. Eventually, odom0's yaw variance will be so poor that it will be effectively ignored by the filter (though this means there isn't much value in including it anyway).

SECOND EDIT: @Huibuh was kind enough to send me a bag file, and I have two things to add:

To stop the oscillation when the robot first starts, you should change the launch by making the yaw measurements differentially integrated:

<!-- Configure imu0 (XSENS)-->
<param name="imu0" value="/imu_data"/>               
<rosparam param="imu0_config">[false, false, false,  <!-- x, y, z position -->
                               false, false, true,   <!-- roll, pitch, yaw angles-->
                               false, false, false,  <!-- x/y/z velocity -->
                               false, false, false]  <!-- roll/pitch/yaw velocity -->
</rosparam>
<rosparam param="imu0_differential">[false, false, false,   <!-- x, y, z position -->
                                     false, false, true]   <!-- THIS CHANGED! Yaw is now true -->
</rosparam>

Since the robot's yaw measurement from odometry starts at 0, we don't have to set it to true there (though it wouldn't hurt). However, the IMU will start at a non-zero heading. robot_localization allows you to integrate measurements differentially, so the first measurement becomes a "zero point" and subsequent measurements are made relative to that first measurement. As I recall, this is robot_pose_ekf's default behavior (someone correct me if I'm wrong), which is why you didn't see the issue when you used it.

However, my earlier point still stands: as the robot moves, the yaw odometry will start to disagree with the IMU, even if they both start out at 0. For that reason, I'd stick with absolute yaw from the IMU only, and yaw velocity from both the IMU (if you have it) and odometry.

There are other suggestions I'd make for your launch file, but the gist of them are covered in robot_localization's best practices tutorial.

Revision history [back]