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 movebaseamcl, 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.
Asked by spiritninja on 2019-03-07 00:45:54 UTC
Comments
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?
Asked by mgruhler on 2019-03-07 07:09:32 UTC
@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.
Asked by spiritninja on 2019-03-07 07:36:24 UTC
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 algorithmAsked by mgruhler on 2019-03-07 08:59:07 UTC
By 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.
Asked by spiritninja on 2019-03-11 00:27:03 UTC
@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.
Asked by mgruhler on 2019-03-11 01:39:14 UTC
@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.
Asked by spiritninja on 2019-03-11 02:30:40 UTC
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?Asked by gvdhoorn on 2019-03-11 02:53:38 UTC
I agree with @gvdhoorn that filtering the laserscan would be the straightforward solution....
Asked by mgruhler on 2019-03-11 06:43:08 UTC
I too agree with @gvdhoorn 's suggestion. I would have done that first if the robot system supported installations of new packages. But the one being used currently is a closed loop hardware.
On the other hand, I wouldn't want to leave that unattended, so i'm trying on a recorded bag file of laser scan data to check the influence of
laser_filter.Asked by spiritninja on 2019-03-11 23:08:00 UTC
@spiritninja @gvdhoorn @mgruhler I am using gmapping slam with multiple turtlebot3s in the same world. When they are moving past each other, my gmapping slam shows them as obstacles for each static snapshot of the laser scan and this messes up the OGM map building and localization of the robots. Would using laser_filters here help with not registering the other robot as an obstacle?
Asked by hunterlineage1 on 2023-04-21 12:04:25 UTC