Sometimes global_plannner generates a path inside the inscribed cost area

asked 2022-03-07 20:17:23 -0500

ayato
25 ●8 ●11 ●19

Hello,
I have developed a program to check if the robot can generate a path between specified coordinates before actually running the robot.
In many cases it was successful and generated the correct path as it would when actually running.
The correct path here is one that does not collide with any obstacles.

However, I observed that, with low probability, the path would encroach into the inscribed cost area.
I do not know the reason for this and would appreciate your advice.

The program I have developed uses the costmap and global_planner of move_base.
I am using static_layer, obstacle_layer, and inflation_layer plugins for costmap, and I have set the combination_method of obstacle_layer to 99.
In addition, the function is realized by calling the /move_base/GlobalPlanner/make_plan service.

I have the perception that if obstacle_layer was disabled as described above, cost would also be affected almost exclusively by the map loaded by static_layer.
For this reason, I do not understand why the result may change.

Also, when I checked, the potential map that publishrd by global_plannner was also intruding into the inscribed cost area when generating the incorrect path.

Please give me a clue.
Thanks in advance.

Comments

You are asking about the behavior of the global planner, right? Which algorithm have you configured the global planner to use?

Mike Scheutzow ( 2022-03-07 21:32:28 -0500 )edit

Hello @Mike Scheutzow, I use global_planner. I set use_dijkstra to true, use_quadratic to true and old_navfn_behavior to false.

ayato ( 2022-03-07 23:02:00 -0500 )edit

"the path would encroach into the inscribed cost area"

Please explain more precisely what you mean. Are you referring to the inscribed area created by inflating a lethal obstacle? Is the inflation happening in the global costmap or the local costmap? Have you tried turning off the visual display of the local costmap in rviz?

Mike Scheutzow ( 2022-03-11 06:39:21 -0500 )edit

"I thought that in order for the robots not to collide, it was necessary to generate paths connecting locations with lower costs than the inscribed cost"

Are you talking about collisions between two robots? If so, the other robot is not a Lethal obstacle unless you do something to put it on the global costmap. move_base does not do that automatically.

Mike Scheutzow ( 2022-03-11 06:53:45 -0500 )edit

@Mike Scheutzow,
"the path would encroach into the inscribed cost area"
The inscribed area that I said is created by inflation a lathal obstacle as you say. This is what happens in the global costmap. I have already turned off the visual display of the local costmap in rviz.

"I thought that in order for the robots not to collide, it was necessary to generate paths connecting locations with lower costs than the inscribed cost"
The "robots" is a typo, there is only one robot.

ayato ( 2022-03-13 21:46:11 -0500 )edit

add a comment

answered 2022-03-08 06:40:38 -0500

Mike Scheutzow
4918 ●2 ●430 ●45

updated 2022-03-08 06:59:13 -0500

Two things:

The global plan is only a suggestion. It may help a local planner make some decisions, but (in general) the local planner is not required to use it at all.
By setting combination_method=99, you are telling the costmap (and thus the global_planner) to ignore anything in obstacle_layer. Why does it surprise you that in the resulting global plan, the robot footprint might the pass over an obstacle? Note this won't be an actual problem if the local_planner is able to deviate from global plan to avoid the obstacle.

edit flag offensive delete link

Comments

@Mike Scheutzow
Sorry for the lack of explanation.

What I am trying to achieve now is to make sure that the coordinates of the waypoints I set are reasonable for the map as my robot run with waypoints.

As you say, I have set the obstacle_layer to be ignored, so ignoring sensor data such as scan data is not a problem.
However, I have set that static_layer and inflation_layer are valid, so checking against the map data is possible.
The check I would like to perform is if the waypoints are not set closer to the wall than the footprint distance, or if it happens that global_planner cannot generate the path during the actual robot run.
The event in question in this case is a problem with the path being generated through the inscribed cost area generated from the map data.

ayato ( 2022-03-08 19:11:08 -0500 )edit

You are being unclear whether we are talking about the ROS global_planner, or your own. The ROS one should be checking that the robot footprint does not collide with any LETHAL obstacle; this requires you give the ROS global_planner the footprint information. I have no way of knowing what your own planner does.

Mike Scheutzow ( 2022-03-09 06:45:15 -0500 )edit

@Mike Scheutzow,
I'm talking about global_planner in the navigation package all time. In my case, the global_costmap consists of static_layer, inflation_layer, and obstacle_layer. As mentioned above, the obstacle_layer is disabled. static_layer writes the lethal cost (254) to the costmap using the map data, while the inflation_layer uses the footprint width and distance from the robot to calculate the The inscribed cost (253) and other costs are written to the costmap. The value of cost is based on figure 6 on this page. I thought that in order for the robots not to collide, it was necessary to generate paths connecting locations with lower costs than the inscribed cost, and that global_planner was designed to compute such paths.
Is this idea wrong?

As a side note, my robot's footprint is circular.

ayato ( 2022-03-09 09:09:32 -0500 )edit

Sorry, I was confused when you write things like "the coordinates of the waypoints I set."

I believe that global_planner already does what you are asking for. How exactly are you configuring the robot footprint in move_base?

Mike Scheutzow ( 2022-03-09 13:17:44 -0500 )edit

@Mike Scheutzow,I'm sorry for the confusion I caused by trying to explain why I disabled the obstacle_layer.
As for footprint, I have it set as robot_radius=0.35 (which is based on actual values) and footprint_padding=0.05 (which is set in terms of margin).The parameter "footprint" is not set, so footprint=[].

ayato ( 2022-03-09 19:52:48 -0500 )edit

When you say "the parameter footprint is not set", do you mean the property does not exist on the param server, or do you mean it exists and is set to empty list [] ?

Mike Scheutzow ( 2022-03-10 07:47:53 -0500 )edit

@Mike Scheutzow,
When I set parameters, I write them in ~.yaml and load them in the launch file using <rosparam file="~.yaml" command="load">.I have described robot_radius and footprint_padding in costmap.yaml, but not footprint. However, when I checked with rqt_reconfigure, the default value [] was set. The result of rosparam get /move_base/global_costmap/footprint was also '[]'.

Is footprint an important clue?The costmap I see in rviz looks correct.

ayato ( 2022-03-10 20:31:09 -0500 )edit

I checked the source code and that footprint=[] is OK - it will be ignored.

Mike Scheutzow ( 2022-03-11 06:30:58 -0500 )edit

add a comment

Sometimes global_plannner generates a path inside the inscribed cost area

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Sometimes global_plannner generates a path inside the inscribed cost area edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Sometimes global_plannner generates a path inside the inscribed cost area