Summary

When reacting to navigation failures, it is essential to know why it failed to be able to react to it in a reasonable way.

Explanation

• Even inside the stack, planner's ComputePathToPose and controller's FollowPath provide no additional information than success/failure and a std_msgs/Empty.
• From the outside of navigation, there is also no way of knowing the overall reason for a navigation failure (e.g. Planner or Controller failure, no progress, ...). Calling the NavigateToPose action, the resulting response is just a std_msgs/Empty.

Example where feedback could be useful: In the behavior trees, we often see recovery actions for planner/controller failures. This makes sense if the computation failed because the robot is stuck somehow and turning/waiting can resolve the issue. But if the planner failed because the goal is occupied, it makes no sense that the robot backs up or turns around as soon as it sees it. Different reactions depending on the cause for failure are needed.

What can we do about it?

First of all: Do you agree that this is problematic?

I am not sure what the best way of dealing with this issue is and wanted to openly ask what you think about it.

Some ideas:

• Planner and controllers could loosely publish failure reasons on separate topics for anyone to react to it
• Alternatively, they could use the blackboard for this
• The action interfaces could have error fields

Still, I don't see a clean way of dealing with failure reasons in the behavior trees, the architecture doesn't seem to allow for it.