ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

# DWA planner not respecting "inflation space"

Hello,

Project is running Kinetic, Gazebo 7.16, on Ubuntu 16.04 in a PC.

I am trying to utilize the navigation stack on a physical robot. First step is to get it to work in Gazebo. Image below shows the robot in RViz following a global path plan (red line) made by the dwa_local_planner package (https://wiki.ros.org/dwa_local_planne...) through “inflated space” that should be treated as a no-go zone:

The local planner is lauched like so:

<arg name="base_local_planner" default="dwa_local_planner/DWAPlannerROS"/>
…
<node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
…
<param name="base_local_planner" value="$(arg base_local_planner)"/> <!--load the parameters for the planners using a yaml file--> <rosparam file="$(find jimmy_navigation)/config/planner.yaml" command="load"/>
…
</node>


The yaml file for configuring the local planner uses all the defaults as I am not changing any parameters for DWA.

In the common costmap yaml file, I have inflation_radius: 0.5, and it does show in the parameter server:

* /move_base/global_costmap/inflation/inflation_radius: 0.5

* /move_base/local_costmap/inflation/inflation_radius: 0.5

The map given by the map_server is good, the cost maps seem to recognize the walls in the map (as RViz shows a space around the walls), and inflation_radius is set. How do I prevent the planner from squeezing through spaces that are not big enough for the robot? By big enough for the robot I mean the robot should be able to fit between the inflation space on the map. Essentially I want it to respect inflation space. Any, and all advice is welcome!!

I tried to keep the question short, if any info is needed or missing, please let me know and I will gladly add it.

Thank you very much!

edit retag close merge delete

I'm not a navigation expert, and I may also be misunderstanding you, but from the image I have the impression the planner is actually doing what it is supposed to do.

The line does not seem to actually "go into" any of the inflated obstacles.

The trick with "inflation" is that it blows up the obstacles, but at the same time reduces the size of the robot. So now checking for collisions is transformed into "does this point ever get contained in any of the inflated obstacles?".

I'm not entirely sure, but perhaps you expected the robot (as in: the regular shape of it) to not "fit" between the inflated areas (ie: the black bands)?

Afaict, that's not how it works.

( 2020-05-12 08:51:30 -0600 )edit

Thanks @gvdhoorn. I am trying to figure out how to make the thing go through doors without banging up the wall. Now that I think about it, I need to figure out how to define space that is considered no-go space. In the image I need to define a 5cm distance that the robot will stay away from both walls, and the remaining distance needs to be taken into account by the global and local planners. Any advice on where to look for something like this? and thanks so much for all your help. I am very, very grateful for your answers and comments!

( 2020-05-12 09:01:47 -0600 )edit

Well, as I wrote: I'm not really into navigation.

I just wanted to mention that perhaps what you describe is actually the normal behaviour.

By big enough for the robot I mean the robot should be able to fit between the inflation space on the map.

this is what I referred to in my first comment: the "point representation" of your robot is able to fit "between the inflat[ed] space". That's why the planner can plan a path there.

( 2020-05-12 10:38:32 -0600 )edit

( 2020-05-13 14:35:30 -0600 )edit

@David Lu it's pretty big. about 70cm by 50cm

( 2020-05-13 14:44:08 -0600 )edit

Sort by » oldest newest most voted

In an ideal world, where you didn't have to go through doors, you would want to set your inscribed_radius to 0.7 to ensure your robot could move about freely while never being in collision. However, that will make going through a narrow door impossible.

Use inscribed_radius=0.5 and inflation_radius to a number greater than that like say 0.8. This should make your robot drive through the center of the door, but will not guarantee it won't collide if it, say, decides to turn in place in the middle of the door.

more

@David Lu thanks for your answer. I'm completely new to navigation, so pardon my follow up... Where do I set the inscribed_radius? It's not loaded in the parameter server, nor is it on the inflation_cost_map plugin. It is mentioned on the page you linked to (costmap_2d) but the parameter is not listed. could you let me know where I can set it? Thanks in advance for your help!

( 2020-05-16 16:23:20 -0600 )edit

I apologize, I answered this question based on memory, and inscribed radius is indeed not a parameter. It is calculated based on your footprint parameter. Can you post your footprint?

( 2020-06-05 17:05:10 -0600 )edit

Hi, The footprint is footprint: [[-0.37, -0.3], [-0.37, 0.3], [0.37, 0.3], [0.37, -0.3]]. You can see the entire common costmap file here: https://github.com/Toronto-Robotics-c... . The robot potentially CAN fit through that opening, but keeps getting stuck (aborts goal), so I think I need to now focus on the recovery behaviors to just push it through that space.

( 2020-06-08 06:32:56 -0600 )edit

@David Lu I have the navigation stack, I tried changing the inflation radius in the common_costmap_params and it literally doesn't do anything. I have the package in the directory catkin_ws/src/turtlebot3_navigation. I don't know what I am doing wrong. I am in gazebo simulation right now. Maybe this is why?Maybe it would work in real life?

( 2021-09-04 02:17:34 -0600 )edit