# Help with slam_gmapping

I am trying to run slam_gmapping on this bag file I collected with my robot and I am getting ridiculously bad results -- so ridiculously bad that my first inclination is to suspect that I am missing something fundamental in my setup.

Here is my setup:

I have a SICK LMS100 mounted upside down forward (by 0.267m) and to the right (by .256m) of the center of my robot. We run custom software on our robot, so I have written a translator that listens to the telemetry published by the robot and publishes TF frames according to my best understanding of how one should do that -- basically, I send transforms with a frame ID of "odom", a child ID of "base_link", and with an x, y, and rotation extracted from the x, y, and heading information (relative to the location at which I booted the robot).

Our LMS100 is configured to report scans over a 190 degree range (rather than the 270 degree range of which it is capable). I had to modify the LMS1xx driver to account for that. (Unfortunately, I modified the older LMS1xx driver, rather than the newer lms1xx driver. If I learn that the newer driver also needs this patch, I will submit it.)

Anyway, if somebody with more expertise than I in gmapping (which is pretty much everybody on this list) could take a look at my bag file and suggest what I should do to get better results, I would appreciate any tips you could give me.

• I have run rviz on the bag file with the fixed frame set to /odom and the laser scan decay time set to infinite, and the map from laser data & odometry alone looks ok -- there is certainly some drift in the odometry, but not much. And that result looks significantly better than the map produced by slam_gmapping.
• I wonder if the fact that the SICK is mounted upside down is causing a problem -- I think I have the static TF set up correctly to account for that:

node pkg="tf" type="static_transform_publisher" name="sick2bot" args="0.267 -0.256 0 0 0 3.14159 base_link laser 100"

• I wonder if the fact that the SICK is mounted right of center is causing a problem.
• I wonder if I should collect the data using the newer SICK driver. (Unfortunately, I'm at IROS right now, and I left my robot in Boston, so I'll have to wait a week to try that.)
• Our robot publishes telemetry at 200 Hz, the SICK publishes scans at 25 Hz; I wonder if that is causing a problem.

What else should I look at?

EDIT : Here is gmapping result

Here is acumilation Lasers in rviz

:: This looks much more like what I expected when I wheeled my robot down the hall (on the right), turned right, wheeled down the corridor, round the corner, down to the lunchroom, and back again. Clearly, there is some drift in the odometry as I return ...

edit retag close merge delete

I just found this question where the author posted code setting the x and y values in his odom_trans structure to -x and -y respectively. Is that common/required practice for publishing odom->base_link frames?

( 2014-09-16 21:50:49 -0500 )edit

Placement of laser doesnot effect gmapping , It can handle whether laser is up side down or not. Try running gmapping with reduced rate rosbag play -r 0.25 halls.bag --clock. Also please share the map ur getting currently.

( 2014-09-17 06:05:02 -0500 )edit

Thank you for your reply. I would expect that slam_gmapping should work regardless of the orientation and placement of the laser. The results I get look so bad that I expect I have set something up incorrectly... (continued next comment)

( 2014-09-17 09:35:27 -0500 )edit

Perhaps I specified the placement or orientation incorrectly -- I think they're correct, but perhaps somebody else could look at my description (upside down, 0.267m forward and 0.256m right of center) and my static transform and tell me I specified it incorrectly. (continued...)

( 2014-09-17 09:37:04 -0500 )edit

Perhaps I specify the odometry incorrectly. I'm confused by the question I referenced above where the author used -x and -y in the TF transform. That doesn't make sense to me, but perhaps that's what I'm supposed to do.

( 2014-09-17 09:38:34 -0500 )edit

Perhaps the lms100 is reporting distances in mm instead of meters. Again, I don't think any of these "Perhaps"'s are true. But they represent the paths I've taken to try to figure out what's going on. I'm hoping somebody will read this thread and suggest something else for me to check.

( 2014-09-17 09:40:04 -0500 )edit

Sort by » oldest newest most voted

OK, I found it.

The lms1xx driver (old and new) does not handle an lms100 configured to report scans of less than 270 degs. I had originally patched it to query the lms1xx for its configured range, but my patch needed more work. I fixed my patch, collected a new bag file and successfully created my map.

For anybody who looks at this later, my patch has been merged into the official version of the lms1xx driver on github. My fork is also available, although I don't anticipate doing any further development on that unless I run into another problem.

more

Hi, there is no problem with data, i use hector slam with your bag file and it was fine.

Please try changing gmapping Parameters

more

Thank you. That result looks fabulous! That's the sort of result I expected after viewing the accumulation laser result in RVIZ. From reading the page about hector slam, it appears that it does not use odometry data, so I wonder if this is an indication of something funny with my odometry.

( 2014-09-17 12:38:28 -0500 )edit

Do you have any suggestions as to which gmapping Parameters I should tweak? Do you have any guesses as to what might be wrong with my odometry?

( 2014-09-17 12:39:51 -0500 )edit

Not sure, try changing maxUrange, lstep, astep and motion noise params srr,srt,str,stt

( 2014-09-17 13:00:39 -0500 )edit

Hi, I have the same problem. Can you tell me what gmapping parametres you use?

( 2015-10-15 06:16:49 -0500 )edit

Hi giacomo, Unfortunately, I have moved on from the job where I collected that data, so I no longer have access to the data or the parameters I used. From reading through this thread, it would appear that the biggest problem was a buggy LMS100 driver (which I fixed).

( 2015-10-17 18:32:07 -0500 )edit