How to Improve filtered_odom results

Question

Hi, I have been working on robot localization by using IMU and Visual Odometry Sensors. I have successfully updated the configuration file and got the filtered_odom result. But, filtered Odom from the robot localization node is closely following raw odom data, and it didn't improve as expected as you can see in the figure below

I mean to say the two endpoints on the left-hand side of the image are actually the same start and end position of the robot in the real world. The yellow color path represents visual odometry and the red color path represents filtered Odom from the Robot localization EKF node.

I am wondering how can I improve this localization node performance. If you observe in my Odom data, there is no twist data (linear velocity values are zero). I have seen some ROS answers saying that using velocity in Odom data instead of position would improve the localization. My question is if I create a new Odom node that takes in visual Odom position values and calculates velocity. and use that node and velocities for robot localization would that improve the performance?

I have attached the example output data of my sensors and EKF config file

---

Originally posted by rcbot on ROS Answers with karma: 39 on 2021-11-04

Post score: 0

---

Original comments

Comment by Dragonslayer on 2021-11-04:
What kind of scale and speeds/accelerations are we talking here? What kind of robot is this? Might just be as good as it gets depending on the circumstances. How well does it work for simple movements, straight ahead, full circle? I think the "issue"/error is in the visual matching/odom itself. Got a link to that "velocity should improve result" topic please?

Using some sort of localization might be the solution, rtabmap, amcl etc.

Comment by rcbot on 2021-11-04:
Dragonslaye Thank you for your answer. we are working on a custom robot and we are driving it on very low speed 2 to 3 m/sec. here you can find the link text

Comment by Dragonslayer on 2021-11-07:
Could be imu0_config that there is no y component inputet. Last line "true, true, false" maybe? Nice config yaml with good parameter descriptions link Did you try the tests i suggested with simple geometric paths?

Comment by Mike Scheutzow on 2021-12-15:
In future questions you ask, please do not post images of text output. Instead, put the actual text into your description and format it with the 101010 button.

Comment by duck-development on 2021-12-16:
3m/s is realy fast for an mobile driving robot.

Answer 1

I think there are a couple things going on.

1. I think you may have an unrealistic expectation of what a state estimator like an EKF is going to do. You are providing one source of pose data from your wheel encoders. If the issue with your raw wheel odometry is that it is under- or over-estimating linear motion, the EKF won't fix that for you.
2. You are fusing absolute yaw from the wheel encoders, but the wheel encoder data is reporting very small errors; your yaw variance is 1.597e-9, which means you have a standard deviation of 3.99e-05. That seems unlikely. In any case, your IMU yaw velocity will get fused with that, but it's getting integrated first, so it won't have a strong effect.

In other words, you are fusing two sources of information into the EKF, but you are telling the EKF to really, really trust one source. And you won't be able to remove issues with uncalibrated wheel encoder data. If the wheel encoders are consistently under-reporting their position change, then that will get reflected in the EKF output.

I would only use velocity for your wheel encoder data if the wheel encoders themselves directly produce it. Just doing differentiation on the wheel encoder positions and sending that to the EKF to be integrated again won't solve anything. It's also what differential mode does anyway, so there would be no need to implement that in the wheel encoder generation node.

EDIT in response to comments:

find out whether my raw wheel odometry is under or overestimating the linear motion

I'd drive it in a long, straight line over a known distance (you'd have to measure this physically), and then compare the reported linear distance to the actual. I'd also recommend that you implement wheel odometry calibration. There are numerous sources for this online.

I am wondering how can I change these variance values to the required values

Is the odometry sensor closed source? If it's open source, you can look what the code is doing, or even fork it, fix it, and build it yourself. If the odometry sensor puts out joint state info, you might also consider using something like the differential drive controller in ros_control.

In general, I prefer odometry sources that let me work directly with velocity, rather than with absolute pose data. But pose data works too, provided that the covariance is correct.

---

Originally posted by Tom Moore with karma: 13689 on 2021-12-15

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by rcbot on 2021-12-15:
Thank you Tom for a clear and detailed explanation. If you don't mind, can you explain a bit more on how can I

1. find out whether my raw wheel odometry is under or overestimating the linear motion and fix the issue

2. I am using whatever raw data coming from the odometry sensor directly into the ekf_node. The variance values are directly coming from the wheel odometry. I am wondering how can I change these variance values to the required values. One way I can think of is, creating new node which can read this raw odometry data and change variance values, and publish the new data on a different topic. But, it caused some errors (caused by the change in timestamp I believe).

I have been trying to resolve these issues for a very long time. I really appreciate it if you can answer these questions.