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

GMapping map changes over time

asked 2013-08-20 03:43:17 -0500

barrybear gravatar image

updated 2013-08-20 03:52:07 -0500

Hello all!

I've been conducting some exploration and mapping indoors using GMapping. However, I realize that as the robot moves and builds the map, certain areas of the map changes as the robot moves and worsen. I have a hunch that it could be the odometry data, but I need some verification of it. Also, would love to know what are the ways to improve the mapping and reduce any errors caused.

The robot was most of the time moving and turning at 0.1 m/s. The maximum speed I set was 0.2 m/s. Number of particles for the map is about 100.

alt text

The image above shows the two corridors not being parallel and at the bottom of the map being distorted.

Comparing this image:alt text

and this image:

alt text

just a lil difference in the robot's position caused so much error at the robot's initial position (in the first picture).

Overall map built:

alt text

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2013-08-20 23:10:23 -0500

Hi there,

Yes, if the only source of location information of your robot is odometry, then likely bad odometry is your problem.

Have you checked out the basic tuning guide for the navigation stack?

Especially the part on odometry (the following text is extracted from the referenced wiki page):

2.2 Odometry

Often, I'll have a lot of trouble getting a robot to localize correctly. It will constantly get lost and I'll spend a lot of time mucking with the parameters for AMCL only to find that the real culprit is the robot's odometry. As such, I always run two sanity checks to make sure that I believe the odometry of a robot.

The first test checks how reasonable the odometry is for rotation. I open up rviz, set the frame to "odom," display the laser scan the robot provides, set the decay time on that topic high (something like 20 seconds), and perform an in-place rotation. Then, I look at how closely the scans match each other on subsequent rotations. Ideally, the scans will fall right on top of each other, but some rotational drift is expected, so I just make sure that the scans aren't off by more than a degree or two.

The next test is a sanity check on odometry for translation. I'll set up rviz the same way with the robot a few meters away from a wall. Then, I'll drive the robot straight at the wall and look at the thickness of the wall as reported by the aggregated laser scans in rviz. Ideally, the wall should look like a single scan but I just make sure that it doesn't have a thickness of more than a few centimeters. If you drive a meter towards a wall and get scans spread out over half a meter though, something is likely wrong with the odometry.

I hope this helps

edit flag offensive delete link more

Comments

Yeap I did, it isn't too bad. Another sensor source would be a laser range scanner, Hokuyo URG-04LX-UG01.

barrybear gravatar image barrybear  ( 2013-08-20 23:22:07 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2013-08-20 03:43:17 -0500

Seen: 1,539 times

Last updated: Aug 20 '13