Robotics StackExchange | Archived questions

Robot Localization Erratic Behavior (GPS, IMU, Odometry)

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 dualekfnavsatexample.launch (Available Here) from the robotlocalization 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:

Hardware:

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.

EDIT 2:

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.

Asked by WillGrayMSU on 2018-05-01 19:47:57 UTC

Comments

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

Asked by stevejp on 2018-05-02 07:57:47 UTC

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

Asked by WillGrayMSU on 2018-05-02 16:00:20 UTC

Answers

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?

Asked by PeteBlackerThe3rd on 2018-05-02 02:26:15 UTC

Comments

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.

Asked by WillGrayMSU on 2018-05-02 16:18:03 UTC

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

Asked by stevejp on 2018-05-02 20:41:35 UTC

Comments

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.

Asked by WillGrayMSU on 2018-05-03 16:52:58 UTC

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.

Asked by WillGrayMSU on 2018-05-03 18:56:52 UTC