ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
What do you mean by unacceptable? Kalman filter-based techniques (such as robot_pose_ekf or robot_localization) are going to use the measurement's covariance matrix to determine "how much" of that measurement to trust. Ideally, your wheel encoder odometry error (covariance) should grow with time.
Do your wheel encoders produce velocity as well? If absolute measurements are not working well for you, you might want to try the robot_localization package, which lets you integrate velocities. Full disclosure, though: I maintain that package, so my advice is probably a little biased.
2 | No.2 Revision |
What do you mean by unacceptable? Kalman filter-based techniques (such as robot_pose_ekf or robot_localization) are going to use the measurement's covariance matrix to determine "how much" of that measurement to trust. Ideally, your wheel encoder odometry error (covariance) should grow with time.
Do your wheel encoders produce velocity as well? If absolute measurements are not working well for you, you might want to try the robot_localization package, which lets you integrate velocities. Full disclosure, though: I maintain that package, so my advice is probably a little biased.
3 | No.3 Revision |
What do you mean by unacceptable? Kalman filter-based techniques (such as robot_pose_ekf or robot_localization) are going to use the measurement's covariance matrix to determine "how much" of that measurement to trust. Ideally, your wheel encoder odometry error (covariance) should grow with time.
EDIT in response to author's edit: those covariance values are really small. The values on the diagonal imply that all of your variables have an error of 0.1. If your GPS has an error of 5 meters, then any EKF is going to more heavily weight the odometry measurement.
Then again, I believe robot_pose_ekf (and robot_localization, when properly configured) is not fusing the absolute odometry measurement, but rather the difference between it and the last measurement. This allows you to fuse multiple sources of odometry without them getting out of sync. How it manages the covariances in that case is beyond me.
In any case, you have two options: