Revision history [back]

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

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):

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 the 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):

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

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

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

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):

Note that results change across runs - sometimes results would be slightly worse. In particular, the "_srr:=0 "_srr:=0 _srt:=0 _str:=0 _stt:=0.1" _stt:=0.1" seems not very significant - with the 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):

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):

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

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

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

Summary of what I tried that did NOT help:

• Increasing linear_update and angular_update to 0.1
• 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):

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):

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):

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

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

Summary of what I tried that did NOT help:

• Increasing Decreasing linear_update and angular_update to 0.10.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):

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):

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):

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