Revision history [back]

A couple notes:

1) The work in Hydro Navigation gives you more control over the costmap, and may be of use to you.

2) The package global_planner is a refactoring of NavFn and is in my opinion, much cleaner and easier to work with.

To actually answer your question, there are three separate things than affect the behavior you're talking about.

• The Costmap Itself
• The Potential Field Calculation
• The Path Planning done using gradient descent

I believe the problem you're seeing comes from either the first or third thing. If its the costmap itself, you should be able to see the costmap using roslaunch pr2_navigation_global rviz_move_base.launch or something similar. If the costmap is causing the "large influence" then the adjustments need to be made there.

The other possibility is that you're seeing weird behavior when the gradient descent algorithm bumps up next to a lethal obstacle and falls back on a non-gradient descent based approach.

I'm happy to answer more questions. A picture of the behavior you're seeing (with the planned path and obstacles) would be most helpful.

A couple notes:

1) The work in Hydro Navigation gives you more control over the costmap, and may be of use to you.

2) The package global_planner is a refactoring of NavFn and is in my opinion, much cleaner and easier to work with.

To actually answer your question, there are three separate things than affect the behavior you're talking about.

• The Costmap Itself
• The Potential Field Calculation
• The Path Planning done using gradient descent

I believe the problem you're seeing comes from either the first or third thing. If its the costmap itself, you should be able to see the costmap using roslaunch pr2_navigation_global rviz_move_base.launch or something similar. If the costmap is causing the "large influence" then the adjustments need to be made there.

The other possibility is that you're seeing weird behavior when the gradient descent algorithm bumps up next to a lethal obstacle and falls back on a non-gradient descent based approach.

Edit: You're right about the problem being in the initial costmap. Check out the diagram in this documentation. The key thing to note is the difference between the inflation radius and the inscribed radius. (The number of times I'm happy to answer more questions. A picture confused these is sad.) The /inflated_obstacles topic publishes all the obstacles that are inflated using the inscribed radius, which when using a circular robot, is equal to robot_radius. These are all the cells with value 253 in the diagram.

If the inflation radius is smaller than the robot radius changes the inflated_obstacles, since its not going to inflate beyond the inflation radius, even though it should.

If the inflation radius is equal to the robot radius, you only get the leftmost part of the diagram. The only values in the costmap will be lethal values that indicate places where if the robot's center is in that cell, the robot will be in collision. This is probably the behavior you're seeing (with the planned path and obstacles) would be most helpful.