Good map with hector_mapping and with odometry-only - poor map with gmapping

asked 2015-02-01 10:32:36 -0600

Kristof
141 ●2 ●6 ●10

updated 2015-02-03 11:26:56 -0600

Using an XV11 lidar and calibrated odometry, I am able to build a good quality map using both hector_mapping (using scan results only) and pure odometry (using odometry only). However, I am unable to get a good map using gmapping (which combines scan results and odometry).

Odometry:

My robot has odometry that passes the tests listed in the navigation tuning guide - linear translation is perfect, rotation error seems to be reasonable as well.

Lidar:

Additionally, it is using an XV11 lidar as laser scanner, with the xv_11_laser_driver package.

Bagfile:

I've recorded a short bag file with /odom, /tf and /scan topics, using following command:

rosbag record -O second_data /scan /tf /odom

I then compressed the bagfile (rosbag compress second_data.bag), and put it available here.

Map results:

If I transform this bag file into a map using hector_mapping, the result looks perfect: image description

EDIT: Here are links to the hector_mapping generated pgm and yaml files.

Moreover, if I simply display the laserscan results in rviz in the /odom frame, with an infinite decay time, I get a very nice map as well: image description

Now, when I try to run this through gmapping, the map looks very poor: image description

EDIT: Here are links to the gmapping generated pgm and yaml files.

Commands:

To generate the gmapping map, I used:

rosparam set use_sim_time true
rosparam set slam_gmapping/delta 0.1  #set resolution to 0.1
rosrun gmapping slam_gmapping scan:=scan
rosbag play second_data.bag --clock
rosrun map_server map_saver

To generate the hector_mapping map, I used:

rosparam set use_sim_time true
roslaunch hector_mapping mapping_default.launch
rosbag play second_data.bag --clock
rosrun map_server map_saver

Launch file is available here.

PDF graph of tf tree is available here.

Question:

How come gmapping gives such poor results, compared to the two other approaches? Any suggestions to improve the gmapping results would be much appreciated.

Thank you,

Kristof

edit retag flag offensive close merge delete

Comments

I had a very similar experience with the xv-11 laser. I got the best results from gmapping by driving my robot in a straight line, super slow (around 0.02 m/s I think).

jseal ( 2015-02-06 23:48:19 -0600 )edit

@jseal interesting, thanks! Did you ever try setting the minimumScore parameter? Setting this to a very high value (see below) works very well for me.

Kristof ( 2015-02-07 03:34:41 -0600 )edit

I haven't, I'm not sure how I missed that one. I'm going to give it a try. I ended up stitching a couple of maps together with gimp to produce my final map.

jseal ( 2015-02-07 09:32:17 -0600 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2015-02-06 04:44:46 -0600

Kristof
141 ●2 ●6 ●10

updated 2015-02-08 01:50:08 -0600

I did a lot of different gmapping experiments - results can be found here.

Summary of what I tried that did NOT help:

Decreasing linear_update and angular_update to 0.1 (from default 1.0) (Note: increasing to 2.0 works a little bit better, presumably because this means the laser scans have become more dissimilar before being processed)
Increasing particles to 100, 500

Summary of what did help:

I had most success with setting the minimumScore to a very high value, as suggested here, and combining that with setting srr/srt/str to 0, and stt to 0.1 (to reflect rotational error, but near-perfect translational behavior), i.e.:

rosrun gmapping slam_gmapping scan:=scan _delta:=0.1 _maxUrange:=4.99 _xmin:=-5.0 _ymin:=-5.0 _xmax:=5.0 _ymax:=5.0 _particles:=30 _srr:=0 _srt:=0 _str:=0 _stt:=0.1 _minimumScore:=10000

(Note that the maxUrange, and particles values are the defaults; the xmin/ymin/xmax/ymax just make for a smaller map, by specifying much lower starting values than the default 100m)

The result is this (pgm): image description

Note that results change across runs - sometimes results would be slightly worse. In particular, the "_srr:=0 _srt:=0 _str:=0 _stt:=0.1" seems not very significant - with all these set to 0, and particles set to 1, that is with:

rosrun gmapping slam_gmapping scan:=scan _delta:=0.1 _maxUrange:=4.99 _xmin:=-5.0 _ymin:=-5.0 _xmax:=5.0 _ymax:=5.0 _particles:=1 _srr:=0 _srt:=0 _str:=0 _stt:=0 _minimumScore:=10000

I get this (pgm):

image_description

Slightly different, but well within the variance I get by running the previous command.

Lastly, by simply using the defaults for srr/srt/str/stt, i.e.:

rosrun gmapping slam_gmapping scan:=scan _delta:=0.1 _maxUrange:=4.99 _xmin:=-5.0 _ymin:=-5.0 _xmax:=5.0 _ymax:=5.0 _minimumScore:=10000

I get this (pgm):

image_description

Again slightly different, but well in line with what I get by running the first command.

So in summary, changing minimumScore to a very large value solves my problem. (I tried 500, 750, 1000, 10 000, with 10 000 best)

So this seems to solve my issue. I am still open to better solutions though, as this seems a bit of a hack, disabling a large part of gmapping's 'intelligence'.

edit flag offensive delete link

Comments

The documentation for minimumScore ("Can avoid jumping pose estimates [...] when using laser scanners with limited range (e.g. 5m).") suggests this might be a common problem with xv11 lidars (5m range). Have other xv11 lidar users a similar experience with gmapping?

Kristof ( 2015-02-07 03:32:32 -0600 )edit

Hi @Kristof, it would be interesting to check for a slightly larger map the parameters you used. I think gmapping performs well when there are objects within the range of the sensor. For e.g.. in corridors it would be a different story, I will check by varying the minimumScore with my bagfile.

AlexR ( 2015-02-07 22:49:30 -0600 )edit

add a comment

answered 2015-02-05 07:18:26 -0600

AlexR
654 ●18 ●26 ●38

I would suggest going through this answer. Gmapping results depends a lot on different parameters specially number of particles used, linear update rate and angular update rate. Tweaking these parameters in the gmapping.launch file can produce little better result.

edit flag offensive delete link

Comments

@AlexR, thanks I went through that answer, and in particular the reference to this answer seems promising - still testing, but will report back shortly.

Kristof ( 2015-02-06 03:01:55 -0600 )edit

add a comment

Good map with hector_mapping and with odometry-only - poor map with gmapping

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Good map with hector_mapping and with odometry-only - poor map with gmapping edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Good map with hector_mapping and with odometry-only - poor map with gmapping