Ask Your Question
0

Odometry Quality degrading over time - What could be going on?

asked 2020-04-17 15:10:34 -0500

Dragonslayer gravatar image

updated 2020-05-07 08:35:25 -0500

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.

edit retag flag offensive close merge delete

Comments

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?

billy gravatar image billy  ( 2020-05-08 00:31:43 -0500 )edit

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.

Dragonslayer gravatar image Dragonslayer  ( 2020-05-08 09:26:58 -0500 )edit

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

achille gravatar image achille  ( 2020-06-14 16:10:12 -0500 )edit

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.

Dragonslayer gravatar image Dragonslayer  ( 2020-06-15 07:44:04 -0500 )edit

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.

achille gravatar image achille  ( 2020-06-15 12:28:38 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2020-06-16 09:21:34 -0500

Dragonslayer gravatar image

updated 2020-06-16 09:23:22 -0500

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

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2020-04-17 15:10:34 -0500

Seen: 50 times

Last updated: Jun 16 '20