Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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