0
$\begingroup$

Rosanswers logo

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

gmapping result http://answers.ros.org/upfiles/14109570815496716.png

Here is acumilation Lasers in rviz

Laser scans http://answers.ros.org/upfiles/14109573119452673.png

:: 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 to my starting point, but it doesn't look that bad to me.


Originally posted by wpd on ROS Answers with karma: 249 on 2014-09-16

Post score: 0


Original comments

Comment by wpd on 2014-09-16:
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?

Comment by bvbdort on 2014-09-17:
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.

Comment by wpd on 2014-09-17:
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)

Comment by wpd on 2014-09-17:
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...)

Comment by wpd on 2014-09-17:
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.

Comment by wpd on 2014-09-17:
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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by wpd with karma: 249 on 2014-09-17

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.