Global planner not updating path [closed]

edit

Hello,

I am using Ubuntu 16.04, ROS-kinetic to run the navigation stack (with global_planner and teb_local_planner) on a Youbot (on Gazebo).

Although I am able to send goals and get them executed properly, I have issues under the following scenario (configuration data follows):

When I add an obstacle(unmapped) into the environment(mapped), say blocking a certain path (alternative path available), and give a goal beyond the obstacle. I am running a rolling window for the local planner here, and the alternate path is not covered in the local costmap.

The issues I face:

Case 1: using obstacle layer in global costmap and local costmap: As soon as my laserscan detects the obstacle, marking of the global costmap starts and the planner issues a new global path upon sensing blocked path. Here, obviously the obstacle "avoidance" is being done by the global planner instead of the local planner.

Case 2: using obstacle layer only in the local costmap: The global costmap stays oblivious to the obstacle and upon reaching the blocked path, the local planner starts trying to look for alternative paths while the global planner directs it to continue moving along this path( since it is still unaware of obstacle). [Here, I believed that if unsuccessful in finding the path even after recovery behaviour, the global planner would issue a viable path. However, it never reaches even recovery stage as the local planner keeps probing the rolling window for trajectories.] As mentioned earlier, upon blocking this path, the alternative route is too far away to be included in the local costmap window [It achieves this when the window size is increased, but that takes up too much system processing for me to consider.] and the robot gets stuck.

Is it ok to stick with Case 1 and lower local planner's utility or Case 2 can be improved to cause global planner to take information from local costmap to replan when needed? or would some other plan of action be better?

I did read up similar questions like this one here. However, increasing the planner frequency doesn't seem to have any effect as probably the global planner still does not consider the path blocked?

I also came across this which suggests that a 'false' returned from computeVelocityCommands from localplanner would force globalplanner to consider an alternative route? Considering this, is there a way to allow 'max_controller_retries' after which the local planner would give up and issue this 'False'?

Thanks

The configuration files:

---> move_base_params

oscillation_distance: 0.1
oscillation_timeout: 5.0
base_global_planner: "global_planner/GlobalPlanner"
planner_frequency: 10.0
planner_patience: 1.0

base_local_planner: "teb_local_planner/TebLocalPlannerROS"
controller_frequency: 10.0
controller_patience: 15.0


shutdown_costmaps: true
clearing_rotation_allowed: false

recovery_behaviours:  [{name: potential_field_recovery, type: potential_field_recovery/PotentialFieldRecovery},{name: aggressive_reset, type: clear_costmap_recovery/ClearCostmapRecovery}]
aggressive_reset:
  reset_distance: 0.5
  layer_names: ["obstacle_layer"]

--> global_costmap_params : set for Case1

global_costmap:

  global_frame: /map
  robot_base_frame: base_footprint
  update_frequency: 4.0
  publish_frequency: 2.0
  static_map: true
  resolution: 0.05
  inflation_radius: 0.38
  cost_scaling_factor: 10.0


  transform_tolerance: 3.0
  plugins:
    - {name: static_layer,            type: "costmap_2d::StaticLayer"}
    - {name: obstacle_layer,          type: "costmap_2d ...