Gmapping produces false obstacles in the map at periodic intervals.
I'm using a Summit-X robot with ROS Indigo and Ubuntu 14.04. With gmapping (slam_gmapping) I map the area the robot has to navigate using a Hokuyo laser range finder.
Whenever the robot moves, the created map has pseudo obstacles which are added to the map at regular intervals during the mapping process i.e. even though there is empty space, the produced map shows obstacles.
I tried changing some of the gmapping parameters but reverted back to the original settings as the results were futile.
When I test the robot with move_base_amcl, it indeed tries to avoid and move around the pseudo obstacles. They are visible on the global costmap as well. Here's an image with the obstacles highlighted.
It appears as though there are small unmapped regions behind the robot,which are removed with multiple iterations, but the tail of non existent obstacles remain.
How do I eliminate this?
Thank you.
Edit:
After trying your suggestion.
After altering gmapping parameters.
My guess is that those readings come from the laser scanner hitting the robot itself (not 100% sure, but I think you see this on the top left image you posted). Those get incorporated at every SLAM update.
Can you verify that the laser is in fact seeing parts of the robot?
@mgruhler I used to map a smaller room where the robot in-fact swept multiple times but never left the trail of false objects as in the above case. But if your guess was true, what would be an effective method to verify it? At first I tried setting the laser scanner at different heights, but it didn't seem to have any effect on the map produced.
Sorry, I don't understand what you are saying about the "leaving the trail of false objects"...
Well, to verify if the laser is actually seeing the robot, all you need is
rviz;-) Check if there are laser points that are always at the position of the robot.You should then filter out the respective points, e.g. using the
laser_filterspackage to make sure that you don't include them in your SLAM algorithmBy that phrase I was referring to the false objects detected by the robot that appears like a trail behind it in the images. I tried your suggestion and guess you were right about it because, when I turn the bot, the objects also follow the bots direction in
Rviz.This i've shown in the new images attached.Now this was with whatever gmapping parameters I was using before. What's surprising is I was experimenting by varying the values of few parameters and for a certain configuration, the false objects detection or the robot detecting itself was removed and I could obtain a proper clear map as seen in the second image.
so, although this appears to provide a solution to the issue faced, I don't think what I did was a proper technical approach.
@spiritninja happy to hear you solved your problem. Is there something that you could use to answer your own question and marking it as fixed? Just as reference for future readers... Thanks.
@mgruhler What I did was a trial and error approach. It would be better if I could find a straightforward solution which I would definitely put up as an answer. Otherwise, I'll add this anyway. Thank you for helping out.
If the
LaserScans include the robot itself, should a laser filter not be used to exclude that and not have it be passed togmappingat all?I agree with @gvdhoorn that filtering the laserscan would be the straightforward solution....