0
$\begingroup$

Rosanswers logo

Hi! I have a Turtlebot with Create base, a Hokuyo laser scanner, and no Kinect, running Groovy. When I use gmapping (through the gmapping_demo), or even when navigating in a static map (through amcl_demo), the pose seems to be reasonably accurate at first, but then I see a large jump in pose (several meters). gmapping produces the error "Transform from /base_link to /odom failed". Sometimes it rights itself after a while, but sometimes it just messes up the map. The pose jumps to locations both inside and outside the mapped region.

Symptoms are similar to unanswered question 58955.

Is the transform failure the likely cause of these jumps? Where should I look to find the cause of the transform failure?

Edit: I've been looking at the tf frames in rviz and some of the transforms using tf_echo.
My tree looks like: /map -> /odom -> /base_footprint -> /base_link -> (a lot of frames for various standoffs, plates, etc.)

The transform from /base_footprint to /base_link is static and looks OK.

The large pose jumps occur when the transform between /map and /odom zeros itself out (edit 2: keeps publishing, but with all zero values). This transform appears to be adjusting for the accumulated odometry errors, so when it zeros out, the robot model jumps to the pose from the odometry, which is generally off by a few meters.

I haven't seen any large changes in the transform between /odom and /base_footprint using tf_echo, but I haven't looked carefully at it yet.

I haven't yet looked at the transform between /base_link and /odom (which gmapping says is failing when the jumps occur).

So far, the /map -> /odom transform seems to have the largest problems, yet gmapping says the /odom -> /base_link transform is failing. Is the /odom frame failing? Is something failing to publish the correct transforms?

Thank you!

Edit 2: Here is a more complete description of the gmapping output:

gmapping usually prints this immediately upon jumps:

[ERROR] [1371054374.583403027]: Transform from base_link to odom failed
update frame 18556
update ld=1.09735 ad=2.69054
Laser Pose= 2.60559 0.20104 2.43665
m_count 27

Then it starts printing this:

[ WARN] [1371054380.206694798]: Clearing costmap to unstuck robot.
[ WARN] [1371054380.407737352]: Rotate recovery behavior started.
[ WARN] [1371054380.606770270]: Clearing costmap to unstuck robot.
[ WARN] [1371054380.806767690]: Rotate recovery behavior started.
[ERROR] [1371054381.006780153]: Aborting because a valid plan could not be found. Even after executing all recovery behaviors

Average Scan Matching Score=396.033
neff= 40.7624
Registering Scans:Done
[ERROR] [1371054386.480540756]: Transform from base_link to odom failed

update frame 18557
update ld=0.00494867 ad=0.52552
Laser Pose= 2.61022 0.199294 2.96217
m_count 28
Average Scan Matching Score=411.485
neff= 40.7294
Registering Scans:Done

Printouts like this continue until the /map -> /odom transform and robot position return to normal.

Occasionally, I see a printout like this:

[ WARN] [1371054758.986420773]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.3656 seconds
[ WARN] [1371054759.138883979]: Invalid Trajectory 0.000000, 0.000000, -1.000000, cost: -1.000000

Is this relatively normal? If not, where can I look for an example of normal output?

Thanks for the help!


Originally posted by shiloh on ROS Answers with karma: 46 on 2013-06-04

Post score: 2


Original comments

Comment by Ben_S on 2013-06-04:
Does your transform /odom -> /base_link also jump? Try visualizing your tf-frames in RViz while driving around your robot. Maybe your odometry is broken somehow...

Comment by jorge on 2013-06-04:
We are tracking this problem, but still don't have an answer. Check this video of our experiments: http://youtu.be/unLtvC2sBN4. Your jumps are somehow similar? Another interesting questions is whether the machine you use is very loaded. Please make a top so we can discard this possibility.

Comment by Ben_S on 2013-06-04:
@jorge: Is there a reason, why you are using the kinect to laserscan (i guess) for gmapping and not the high-fov laserscanner shown in blue? I guess your fixed frame in the video is /odom? @shiloh could you post a bag file where the jumps are happening?

Comment by jorge on 2013-06-05:
We are just evaluation gmapping with kinect; the laser scan is just to provide a reference. And yes, odom is the fixed frame.

Comment by shiloh on 2013-06-07:
@jorge: As opposed to the jumps in the video, mine are showing a large change in position as well as a rotation.

Comment by jorge on 2013-06-11:
/map -> /odom zeros itself means it keep published with all zero values? Or that it's not published for a while? Can you check the gmapping standard output messages when tf zeros?

Comment by shiloh on 2013-06-12:
/map -> /odom keeps publishing, but with all zero values.

Comment by Ben_S on 2013-06-12:
Would it be possible to post a bag file when this is happening?

Comment by fergs on 2013-06-13:
I second the request for a bag file! Jorge, if you have a bag file for a similar test to that video linked above, that would very interesting to look at as well.

Comment by jorge on 2013-06-16:
Well, I can publish the bag files, but we are preparing a second level of testing with ground truth that will be far more useful. If hope we will be able to post them at the end of this week or beginning of the next one.

Comment by jorge on 2013-06-25:
Sorry, prepare the multi-camera system is getting longer than we expected. Here you have the current files, just scan and tf: http://files.yujinrobot.com/turtlebot/gmapping_test.tgz. Use -s 90 when running the bag files because the robot don't move for more than 1 minute and half.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

Well, this is more sharing experience that a real answer, but it's too long for a comment; sorry a lot.

I have been playing around with the bag files recorded together with the video, and jumps follow this pattern: the robot rotates, pointing the kinect to unknown area, some scan matching fails (Scan Matching Failed, using odometry. Likelihood=-4266.67), so gmapping relays on odom, and when the rotation finish, filter updates but position is wrong. This is due to the narrow fov of kinect; same test with a laser works fine. So a possible solution is to be careful when building the map so the kinect pov don't move fast to an unmapped area. Doing full spins also helps a lot, as it compensates the narrow fov. And also tweaking some parameters helps (reduce angularUpdate, increase particles...), at the price of more CPU usage.

That said, the problem shiloh has looks like something different, related to tf failure. So shiloh, can you verify that odom -> base transform is correct?


Originally posted by jorge with karma: 2284 on 2013-06-10

This answer was NOT ACCEPTED on the original site

Post score: 3


Original comments

Comment by jorge on 2013-06-25:
I bit more of information: repeating the experiments with hector_slam gives similar results: very well with laser, horrible with kinect.

$\endgroup$
0
$\begingroup$

Rosanswers logo

I was using a Prolific USB-to-serial cable before to connect the netbook to the Create. Apparently, the Prolific cable does not work well with the Create. After changing the cable for an iRobot model 4522 direct USB cable, I stopped seeing the jumps while mapping.


Originally posted by shiloh with karma: 46 on 2013-06-27

This answer was ACCEPTED on the original site

Post score: 1

$\endgroup$

Your Answer

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