ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

AMCL - Determining an obstacle from forbidden zone on map

asked 2017-03-07 05:34:50 -0500

dgrixti gravatar image


I have a robot which needs to navigate through a gap by using a map which I created using gmapping + manual editing using Photoshop. As you can see in the map below, there are black lines representing real walls on the map (the right line, opposite line and the gap lines). On the left there is open space however I want the robot to always go through the gap in a straight line and avoid making plans to go on the left zone to reach it goal (not turning around the gap).


In order to attempt to resolve this I have manually marked the left zone in a black line but now I am worried that AMCL might think the robot is not localizaed well because it "mistakes" it for another wall. I noticed that when the robot faces the left side it goes into unable to determine pose mode. Am I doing the wrong approach here? Is there a better way to mark a forbidden zone different from real obstacles on a small map?

image description

edit retag flag offensive close merge delete

3 Answers

Sort by » oldest newest most voted

answered 2017-03-09 11:04:38 -0500

Procópio gravatar image

yes, that will definetely affect your localization!

some dirty but fast solutions are: - use two maps, one for navigation with the walls and other for amcl (the original one) - instead of painting "walls" paint "points" close enough that your robot cannot pass between them. In this way most of your scans will reflect the real surrounding and, hopefully, amcl will disregard the "points" as noise.

more elegant solution: - create a special layer and a special sensor in your costmap config that will "see" these walls, which will not be in the map amcl is using.

edit flag offensive delete link more


Thanks very much. I have looked into the two maps solutions and I think something like this could work.

dgrixti gravatar image dgrixti  ( 2017-03-13 03:09:02 -0500 )edit

Why would you consider the third option to be more elegant? For the sake of clarity (i.e. as a human I know what I'm defining) and ease-of-use, using for amcl an original map (or maybe a slightly cleared one, where frequently moved objects are removed) and a drawn map with forbidden areas for gmapping seems the best. (I'm not trying to argue in the sense that you are not right, you probably are, I just don't see why, and would like to :)).

priestoferis gravatar image priestoferis  ( 2019-04-16 13:04:46 -0500 )edit

@priestoferis, assuming you meant "move_base" instead of "gmapping", that solution would work as long as you configure your sensors layers to not be able to erase the static map layer. That is a valid option, but would have problems on its own, but that is another story.

Procópio gravatar image Procópio  ( 2019-04-17 05:50:30 -0500 )edit

answered 2017-03-07 07:27:45 -0500

croesmann gravatar image

How well amcl performs depends significantly on your robot setup and environment. We are using the turtlebot with a kinect as range sensor. Hereby, the kinect point cloud is projected onto the plane. In comparison to actual laser range finders, the kinect has a very limited range and amcl fails frequently in our environment. Adding custom obstacles to the map image file made things even worse for us.

On the other hand, if you have a large field of view, a high sensor range and less open-space, the custom changes in your map might be negligible for amcl compared to the amount of true positive hits.

There is a package costmap_prohibition_layer which adds custom obstacles to a new costmap layer via the ros parameter server (just define them in a yaml-file). This could be an option for you.

edit flag offensive delete link more

answered 2017-03-07 05:48:00 -0500

Waleed gravatar image

Study this link , might be helpful

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2017-03-07 05:34:50 -0500

Seen: 1,514 times

Last updated: Mar 09 '17