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

slam in gmapping auto turnaround

asked 2011-07-05 13:12:41 -0600

gong gravatar image

updated 2014-01-28 17:09:58 -0600

ngrennan gravatar image

I make a experiment as follow.

1、the robot is static.

2、provide corridor laser information like this:

image description

3、suppose the robot move following x-axis from (0, 0) as a speed 0.2m/s, and provide the odom data to simulate the process. In this case, the direction of the robot is always 0 degree. However, the result is:

image description

If the robot have enough time for running, the trajectory would be a circle. Unbelievable!

edit retag flag offensive close merge delete


It looks as there is very little overlap from consecutive scans. Is this also like that in the raw data?
dornhege gravatar image dornhege  ( 2011-07-05 22:25:50 -0600 )edit
The robot is static, so the scan data is always the same. Does this would have problem? Why the overlap from consecutive scans would have problem? Raw data? Do you mean the scan data before Gmaping?
gong gravatar image gong  ( 2011-07-06 01:46:06 -0600 )edit
In 3.: Did you provide odom that signals the robot moving at 0.2m/s and always the same static scan? That cannot work.
dornhege gravatar image dornhege  ( 2011-07-06 02:08:17 -0600 )edit
yes, you are right. But why it can not work?
gong gravatar image gong  ( 2011-07-06 06:51:22 -0600 )edit
gmapping is basically an algorithm that merges odometry and laser information into a map. You are now feeding laser from one source (static) and odometry from a different one (moving), thus any try to merge that can only be wrong - what would you expect as the map here, anyways?
dornhege gravatar image dornhege  ( 2011-07-06 07:12:53 -0600 )edit
I want to simulate a process in which the robot move straight in a corridor. In this process, the scan data would always the same or can be consider the same though odom is changing.
gong gravatar image gong  ( 2011-07-06 07:33:55 -0600 )edit
The reason why I'm designed this experiment is to find out what cause the map have drift the robot error or parameter setting error, etc.
gong gravatar image gong  ( 2011-07-06 07:42:14 -0600 )edit
The valid range seems to be only 2m, so there is very little overlap to match/correct anything. Maybe setting linear_update and angular_update quite low can do what you want (at the cost of computation).
dornhege gravatar image dornhege  ( 2011-07-06 09:13:43 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2011-07-17 14:24:21 -0600

gong gravatar image

updated 2011-07-17 14:38:52 -0600

When I was deploying the laser scan parameters(angle resolution and scan frequency), I found the size of laser data array is wrong. If the array setting more than actual size, there would be always have wrong data for Gmapping. Otherwise, there would be memory error.

Here also solve the problem in:

Relate problem:

This is the result(the actual scene): image description

I would like to thank dornhege, Brian Gerkey, dlaz, mbj and Ivan Dryanovski for help in finding out the problem.

edit flag offensive delete link more

Question Tools


Asked: 2011-07-05 13:12:41 -0600

Seen: 1,127 times

Last updated: Jul 17 '11