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 ...
I just found this question where the author posted code setting the
xandyvalues in hisodom_transstructure to-xand-yrespectively. Is that common/required practice for publishing odom->base_link frames?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.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)
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...)
Perhaps I specify the odometry incorrectly. I'm confused by the question I referenced above where the author used
-xand-yin the TF transform. That doesn't make sense to me, but perhaps that's what I'm supposed to do.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.