# robot_localization tf transform jitters when stopping motion

Hi there,

We're trying to use r_l on an outdoor ground vehicle with an IMU affixed to the top, and two RTK GPS receivers fore and aft. The IMU provides roll and pitch at 10 Hz (as imu0), and the GPS provides relative position (meters from base station) and yaw, and optionally pitch, at 10 Hz (as pose0). We don't have any wheel encoders, so we don't have a typical odometry source. As a result, we simply use a static transform from map to odom, and we are using r_l to generate a transform from odom to base_link.

r_l seems to provide a very accurate transform most of the time (judged by visual inspection of rviz), but when the vehicle stops the estimated position of base_link jitters (or oscillates) for 1-2 seconds by 0.1-0.5 meters primarily along the vehicle's X axis, then stops at the correct position. However, if we remove imu0 as an input into r_l, the transform stops smoothly and quickly (as does the physical vehicle).

This jitter occurs even when the following are true:

• The IMU and GPS do not provide competing measurements for the same axes of motion (i.e., we remove pitch from the GPS input)
• The covariance matrix diagonal on the IMU is temporarily set to 1e12 (for debug purposes), which we would imagine would cause the r_l filters to more or less ignore the IMU input
• The IMU data are all temporarily set to 0 (for debug purposes), and only an irrelevant axis (e.g., Z'') is configured to be active

An example GPS message and IMU message are below, as is the YAML configuration for r_l.

Any thoughts would be much appreciated! Thank you!

imu0:

---
seq: 4
stamp:
secs: 1487210998
nsecs: 225980997
orientation:
x: 0.0
y: 0.0
z: 0.0
w: 1.0
orientation_covariance: [1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0]
angular_velocity:
x: 0.0
y: 0.0
z: 0.0
angular_velocity_covariance: [1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0]
linear_acceleration:
x: 0.0
y: 0.0
z: 0.0
linear_acceleration_covariance: [1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0, 0.0, 0.0, 0.0, 1000000000000.0]
---


pose0:

---
seq: 2395
stamp:
secs: 1487211196
nsecs: 500669002
frame_id: odom
pose:
pose:
position:
x: -3.85235159044
y: -5.17830684957
z: 0.00309827089337
orientation:
x: 0.00792342224031
y: -0.0124397107908
z: 0.53716653655
w: 0.843347250536
covariance: [0.01, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-12, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01]
---


r_l YAML configuration ...

edit retag close merge delete

Both of your GPS sensors output in the odom frame, correct? How are you accounting for their offsets from the vehicle center?

( 2017-02-21 03:24:22 -0600 )edit

Thanks Tom! I'm actually just computing an average of their values, weighted to account for the aft receiver being slightly closer to center. I'm then outputting that as a PoseWithCovarianceStamped in the odom frame and using it with r_l.

( 2017-02-21 21:23:46 -0600 )edit

Sort by ยป oldest newest most voted

I think I'd have to see a bag file and full configuration. Re: this point

The IMU data are all temporarily set to 0 (for debug purposes), and only an irrelevant axis (e.g., Z'') is configured to be active

How is your IMU mounted, and what is the base_link->imu transform? I am also very suspicious of the fact that your IMU Z acceleration has (a) a value of 0 and (b) a massive covariance in the sample message. Covariance values can have subtle effects, even in other axes.

more

OK, since we have good pose via RTK GPS I may try to hack something together on my own for now, then follow up if it seems like an EKF is necessary. Re IMU accel and covariance, those were just testing values--same issue with normal/correct values. I was just trying to isolate the issue. Thanks!

( 2017-03-02 13:49:32 -0600 )edit