0
$\begingroup$

Rosanswers logo

So i've got my laserscan and my odometry and i load up amcl and it doesn't seem to be working - it's pose estimates are literally miles off the map.

I can load up my laserscans in rviz - they look pretty good.

Is there a good way to verify that my odometry drivers are producing sensible output? I can watch them with rostopic echo, but I don't know how to compare the values well.

I am hoping that there is an easy/good way to select where i am on the map and then have it just trust my odometry so i can see if they're at all accurate or not.


Originally posted by Murph on ROS Answers with karma: 1033 on 2011-03-18

Post score: 7


Original comments

Comment by Eric Perko on 2011-03-18:
Publishing new messsages on /odom is likely optional, but you'll definitely have to keep publishing you odometry tf transform to keep that fresh. I like to publish my odometry at a fixed rate so that I can use it as a "trigger" for nodes that should run at the same rate as my odometry estimation.

Comment by Murph on 2011-03-18:
Also, small side question, would it be good practice to tell my odometry driver to keep publishing unchanged readings when the robot stays still or should i omit those messages?

$\endgroup$

3 Answers 3

0
$\begingroup$

Rosanswers logo

The basic check I use for odometry is to have rviz accumulate laser scans in the odometric frame, and verify visually that they're coherent.

Set the Fixed Frame to odom (or whatever the name of your odometric frame is) and turn up the decay time on the laser scans (e.g., to 600 seconds). Drive the robot around, and see what happens with the accumulated laser scans. If the odometry is reasonable, you'll see a crude "map" being built. It should be obvious immediately whether there's something seriously wrong.


Originally posted by Brian Gerkey with karma: 2916 on 2011-03-20

This answer was ACCEPTED on the original site

Post score: 11


Original comments

Comment by Mercy on 2014-01-22:
Where you get the decay time? In which file it resides?

Comment by Procópio on 2014-01-22:
you set the decay time in rviz, in the config of the visualization of your laser data.

Comment by sarthak on 2017-04-28:
Do I need to transform laser scan to odom frame?

Comment by Procópio on 2017-05-09:
no, you don't. you will visualize the scans with respect to the odom frame.

$\endgroup$
0
$\begingroup$

Rosanswers logo

The rviz node can visualize Odometry data. Maybe display that along with the map.


Originally posted by joq with karma: 25443 on 2011-03-18

This answer was NOT ACCEPTED on the original site

Post score: 4

$\endgroup$
0
$\begingroup$

Rosanswers logo

You could make your robot follow a predefined path in his own odometry frame. By comparing its real movements VS the predefines ones, you can have a basic idea of how fine is your odometry.

You could for instance make your robot follow a 1m square like this:

Move forward 1m
Stop
Rotate +90 Deg.
Rapeat 4 times

And compare the real movements of your robot VS the odometry estimate. Check this tutorial, it shows how to send simple navigation goals in the robot's odometry frame.

You could also drive your robot manually along a predefined path (using a joystick for example) and check the odometry estimate.

Raph


Originally posted by raphael favier with karma: 1382 on 2011-03-19

This answer was NOT ACCEPTED on the original site

Post score: 3


Original comments

Comment by mjcarroll on 2011-03-19:
This is very similar to UMBMark, a way of measuring and correcting odometry data in mobile robots. There are many publicly-available papers from University of Michigan, and it is worthwhile to read a few to get a good idea on how to do odometry calibration and correction.

Comment by Mercy on 2014-01-23:
@raphael favier, Can you please elaborate how teleop can be used to check odometry? In rviz there is no affect of teleop i.e we don't know to which co-ordinate it's moving?

$\endgroup$

Your Answer

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