ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Robot Localization Erratic Behavior (GPS, IMU, Odometry)

asked 2018-05-01 19:47:57 -0600

WillGrayMSU gravatar image

updated 2018-05-03 19:46:33 -0600

Hello ROS community,

I'm currently attempting to fuse GPS, IMU, and Odometry data as detailed on the Robot Localization docs(See Here. I used the dual_ekf_navsat_example.launch (Available Here) from the robot_localization GitHub as an example. The parameters are the same, with the names of the topics changed match my publishers.

The problem I am having is the robot starts "shaking" in Rviz whenever I start-up the ekfs and navsat transform. The shaking only grows worse as the robot begins to move causing the robot jump all around the Rviz visualization. I've recorded a video of this behavior, you can watch it here. (Please excuse the window flickering, I think it's a side effect of VLC)

I am curious if anyone else has experience with this issue, and has some solutions that may help in remedying the problem. The GPS is using RTK corrections and is extremely accurate. In reading through ROS answers, this issue seems similar, but I have accounted for magnetic declination and the orientation of the IMU. I have a strong hunch the IMU is at least partially responsible for the erratic behavior. Though I have tried IMU recalibration to no improvement. This issue is not present in the simulated robot, but has been a road block for weeks now. The ROS driver we're using for the IMU is available here.

I would appreciate any support and would be happy to provide any further information needed. Thank you in advance!

Robot's System:

  • x86 64-Bit
  • 4.13.0-38-generic Kernal
  • Ubuntu 16.04.1
  • ROS Kinetic


EDIT: The video link should work now, I had forgot to set the permissions correctly.

In response to Pete Blacker, the first kalman filter is fusing strictly IMU and Odometry data. Without this Kalman filter the robot does not shake. However, the second Kalman filter causes the map frame to behave erratically.

As requested, here is a bag file showing the same behavior. It's all the topics so it's a lot of data.

I've also uploaded my localization and IMU launch files with their parameter yaml's as well. You can find them here.


I've uploaded the URDF of the robot if looking at the way the frames are laid out will help. It's in the same place as the other ROS files, it's available at the link above.

I've also generated another bag file of the relevant topics, it's available here. The real robot drove in a square (a really rough sqaure) about 9-10 meters on each side. This time, I've set the IMU and the Odom differential parameter for the EKF to false. I've also changed the IMU's orientation as well to be correct according to the diagram on the IMU, I think this helped but I'm still seeing similar erratic behavior in Rviz.

edit retag flag offensive close merge delete



Looks like the video you posted requires permission to view. Also if you can post a bag file that would be helpful!

stevejp gravatar image stevejp  ( 2018-05-02 07:57:47 -0600 )edit

Oops! Didn't have the sharing permission set correctly, it should work now.

WillGrayMSU gravatar image WillGrayMSU  ( 2018-05-02 16:00:20 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2018-05-02 20:41:35 -0600

stevejp gravatar image

I had a quick look at the bag file you posted (thanks for doing that). One thing I noticed is that you are not fusing any sources of absolute yaw orientation. In your first EKF (odom one), you do actually specify that the yaw should be fused from your imu, but by setting the imu_differential parameter to true, robot_localization will only look at the difference between yaw measurements. So what happens is the r_l nodes initialize the filter estimate with an orientation of unit quaternion (i.e., 0 deg yaw), and all subsequent imu data which impacts yaw is only changing it relative to the starting estimate of 0 degrees.

To fix this, you could include the imu yaw measurements without setting the differential parameter to true. I've used the GX5-25 before and can verify that if you set everything up correctly (e.g., magnetic calibration on robot, proper declination specified, proper base_link to imu_link transform, etc.), it can provide sufficiently accurate heading estimates.

There might be other issues with your setup, so if you're still having problems feel free to update your question with another bag file (a good test would be driving a 10 m x 10 m box so you know roughly what your odometry should look like).

edit flag offensive delete link more


Just a question, when you used the GX5-25 did you have to change the Y values from the default? Because on the GX5-25 when X+ is forward and Z+ is up, then Y is+ is right. It was my understanding that ROS assumed the X+ is Forward, Y+ is Left, and Z+ is Up by default.

WillGrayMSU gravatar image WillGrayMSU  ( 2018-05-03 16:52:58 -0600 )edit

Follow Up: I think I may have had the mounting on the robot wrong. I've corrected it and the differential parameter, but I'm still experiencing issues with the same erratic behavior. I'll update the question with a new bag file, and my urdf.

WillGrayMSU gravatar image WillGrayMSU  ( 2018-05-03 18:56:52 -0600 )edit

answered 2018-05-02 02:26:15 -0600

A couple of questions. Does the erratic behaviour exist for the location estimates of both EKF nodes? If so then it is a problem with fusing the imu and odometry information. Is the coordinate frame of the IMU set correctly?

edit flag offensive delete link more


The erratic behavior exists in both EKF nodes, but manifests in different ways due the outputs being used differently. I provided a bag file of data and my launch and configuration files, see the edit in my original question.

WillGrayMSU gravatar image WillGrayMSU  ( 2018-05-02 16:18:03 -0600 )edit

Question Tools



Asked: 2018-05-01 19:47:57 -0600

Seen: 1,467 times

Last updated: May 03 '18