ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Large pose jumps in gmapping

asked 2013-06-04 07:09:33 -0500

shiloh gravatar image

updated 2013-11-18 19:29:51 -0500

tfoote gravatar image

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 ...
edit retag flag offensive close merge delete



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...

Ben_S gravatar image Ben_S  ( 2013-06-04 10:38:02 -0500 )edit

We are tracking this problem, but still don't have an answer. Check this video of our experiments: 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.

jorge gravatar image jorge  ( 2013-06-04 15:02:02 -0500 )edit

@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?

Ben_S gravatar image Ben_S  ( 2013-06-04 22:27:22 -0500 )edit

We are just evaluation gmapping with kinect; the laser scan is just to provide a reference. And yes, odom is the fixed frame.

jorge gravatar image jorge  ( 2013-06-05 00:03:56 -0500 )edit

@jorge: As opposed to the jumps in the video, mine are showing a large change in position as well as a rotation.

shiloh gravatar image shiloh  ( 2013-06-07 08:38:37 -0500 )edit

/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?

jorge gravatar image jorge  ( 2013-06-11 13:50:49 -0500 )edit

/map -> /odom keeps publishing, but with all zero values.

shiloh gravatar image shiloh  ( 2013-06-12 06:29:00 -0500 )edit

Would it be possible to post a bag file when this is happening?

Ben_S gravatar image Ben_S  ( 2013-06-12 07:27:01 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2013-06-27 06:26:05 -0500

shiloh gravatar image

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.

edit flag offensive delete link more

answered 2013-06-10 21:33:27 -0500

jorge gravatar image

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?

edit flag offensive delete link more


I bit more of information: repeating the experiments with hector_slam gives similar results: very well with laser, horrible with kinect.

jorge gravatar image jorge  ( 2013-06-25 21:00:59 -0500 )edit

Question Tools

1 follower


Asked: 2013-06-04 07:09:33 -0500

Seen: 4,948 times

Last updated: Jun 27 '13