This is about wheelodometry on a real robot, no sensorfusion. When I start the system and measure odometry its quality is good ~2° per 90° and a 1 cm per meter. When I then teleop arround some time or even worse let move_base try to reach some goals and I measure again its of by 20-30%. How can this be? Covariance Matrix playing tricks on me maybe?
EDIT: Iam not talking about commulative error here. Its happens if after some time I take a new messurement from where its at at this moment, then 90° are only 50 and 1 meter is only 0.7 calculated by odometry.
Post score: 0
Comment by billy on 2020-05-08:
What sensors are used on the robot for feedback to the control system?
What type of motion control algo is being used?
How are measuring your 'ground truth' to estimate the error?
Comment by Dragonslayer on 2020-05-08:
Hi, its encoder odometry based on pr2 code. (4 wheel steering base). Its a real robot I meassure ground truth via measuring tape. At first I thought that a wheel encoder might go offline, thus a ~25% error would make sense, but all joint states are published. On the MC side i poll the encoder ticks with an interval timer to estimate velocity. Its a read and reset function so variable overturn can not be an issue. Iam now investigating timing/timer issues.
Comment by achille on 2020-06-14:
Try recording the encoder counts and IO over time and plot the results. What do you see? Covariance has little to do with this, it just tells you how 'sure' it is of its own estimate. I wrote an article about this here
Comment by Dragonslayer on 2020-06-15:
Thanks @achille, good article. At the moment I dont have the issue anymore, likely it was due to rtabmap using up CPU and the updates didnt get polled fast enough but the node expected it. I got a lot of control-loop "took to long" warnings.
Comment by achille on 2020-06-15:
It would be good if you could write it up in the form of an answer so others who stumble upon this question can learn from it as well. One thing to look at is the timestamps of incoming messages. For critical components like these, compute issues may always return and are hard to debug, so consider offloading some nodes to a separate device, like a Raspberry Pi.