0
$\begingroup$

Rosanswers logo

Hi,

I am using robot_localization. I'm using the typical setup

EKF1 fuses encoders + IMU
EKF2 fuses encoders + IMU + GPS

My question is about encoder covariances. The robot_localization documentation says

  • If the odometry provides both position and linear velocity, fuse the linear velocity.
  • If the odometry provides both orientation and angular velocity, fuse the orientation.

Following this advice I am fusing the orientation that the wheel encoders report, but I don't know what to set the encoders pose covariance to. Logically I would think the pose covariance should grow every time you move. It would just keep growing and growing without bound. But when I look at the example pose covariance diagonals of the diff_drive_contoller package it says to use static values

pose_covariance_diagonal: [0.001, 0.001, 1000000.0, 1000000.0, 1000000.0, 0.03]

I'm very confused because diff_drive_controller seems like a commonly used package but those covariances don't make sense to me.


Originally posted by shoemakerlevy9 on ROS Answers with karma: 545 on 2018-07-27

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Okay, I'll give my opinion on some of the statements you've made (not sure I can hit everything).

  1. Unless the orientation estimate that your wheel odometry provides is based on an internal imu, I would disagree with fusing the orientation over the angular velocity. Wheel odometry orientation will drift over time and throw off your yaw estimate. If your imu is calibrated properly (magnetometer) it should be able to provide you with a better orientation estimate. I'm not sure why it says that in the r_l docs, maybe I'm misinterpreting it and someone else can shed some light.

  2. Regarding the high diff_drive_controller covariances: I assume the inflated covariance values correspond to Z, roll, and pitch. For a vehicle navigating in 2D, the robot would not be measuring these values. I think that in older versions of robot_localization and robot_pose_ekf, it was common practice to inflate the covariance for measurements which you did not want to include in the measurement update (high covariance means measurements will have low impact on state estimate in update). Not with robot_localization you can set in your configuration which measurements you want to fuse as outlined here.

  3. Regarding your statement "Logically I would think the pose covariance should grow every time you move": I assume you are referring to the covariance of position odometry coming from wheel encoders - logically I would agree with this because most of the time the position odometry on a vehicle is just coming from integration, so over time this estimate would accumulate error. All I can say on this is that if you only fuse velocity information coming from the wheel odometry you shouldn't need to worry about setting these covariances. What you'll find if you only fuse linear / angular wheel velocity in your first EKF is that the covariance for your X and Y pose coming out of that EKF does grow over time (as you'd expect).


Originally posted by stevejp with karma: 929 on 2018-07-27

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by Tom Moore on 2018-07-30:
@shoemakerlevy9, yes, that is bad/outdated advice. It only makes sense if the orientation data is absolute, and not subject to drift. If you are fusing wheel encoder data, just fuse the velocities.

r_l never used the "inflate covariances to ignore" model; just disable that variable in the config.

Comment by jayess on 2018-07-30:
@Tom Moore I'm guessing that your comment was intended for @shoemakerlevy9

Comment by Tom Moore on 2018-07-30:
Yes, apologies. Updated.

Comment by jayess on 2018-07-30:
No worries

Comment by robot_new_user on 2019-08-27:
@jayess @Tom Moore @stevejp can you please provide some suggestions on how to estimate the covariance for the velocities if those are not available beforehand?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.