ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
The behaviour you are describing is what I would expect for the given config.
As long as you do not use the obstacles layer with the global costmap, it has no way in knowing the current path is not feasible. Even if you trigger recovery behaviors, the map will be pretty much the same, so the global plan is unlikely to change.
"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?"
Yes, it is ok to use Case 1. If you want to "increase the utility" of your local planner, you can try to reduce the global planner frequency (but with obstacles layer active) to something like 0.1Hz, so you will allow the local to try to find an alternative, before replanning the global path.
It is hard to envision any improvements in case 2. What you are proposing pretty much falls into activating the obstacle layer in global costmap. The best I can think of is writing an external node that activate or deactivate the obstacle layer in global costmap according to some info from your local planner. But I do not see the advantage on that.