0
$\begingroup$

Rosanswers logo

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.


Originally posted by Dragonslayer on ROS Answers with karma: 574 on 2020-04-17

Post score: 0


Original comments

Comment by billy on 2020-05-08:
Interesting problem

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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.

Relevant read regarding odometry: article


Originally posted by Dragonslayer with karma: 574 on 2020-06-16

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

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