As some of our other actions, the move_base action doesn't have recovery behaviours at the moment, such that failures in the action often cause failures in subsequent actions. For instance, in a pick and place scenario, there are occasions on which the robot doesn't reach its goal, but continues with the subsequent actions (e.g. perceiving or picking/placing), thus failing there as well.
Often times, adequate plan dispatch/scenario execution recovery strategies (e.g. simply retrying the action) can prevent such issues, but some recovery in the action itself would be useful as well.
Proposed solution
Since failures are sometimes caused by an inability to create a path plan, one recovery might be to try a simpler navigation strategy (e.g. straight line motion with simple collision avoidance) if the ROS navigation component, which is essentially used by the action, fails to reach a goal. This would be somewhat similar to what we have recently started doing with the ROPOD platform.
Another recovery might be to dynamically relax the navigation constraints (e.g. reduce the inflation of obstacles), though that might lead to potentially unsafe behaviour.
A smarter recovery, which should be considered in the long term, might reuse previously used paths. This is then related to @argenos's problem of long-term experience reuse.
Short description
As some of our other actions, the
move_baseaction doesn't have recovery behaviours at the moment, such that failures in the action often cause failures in subsequent actions. For instance, in a pick and place scenario, there are occasions on which the robot doesn't reach its goal, but continues with the subsequent actions (e.g. perceiving or picking/placing), thus failing there as well.Often times, adequate plan dispatch/scenario execution recovery strategies (e.g. simply retrying the action) can prevent such issues, but some recovery in the action itself would be useful as well.
Proposed solution
Since failures are sometimes caused by an inability to create a path plan, one recovery might be to try a simpler navigation strategy (e.g. straight line motion with simple collision avoidance) if the ROS navigation component, which is essentially used by the action, fails to reach a goal. This would be somewhat similar to what we have recently started doing with the ROPOD platform.
Another recovery might be to dynamically relax the navigation constraints (e.g. reduce the inflation of obstacles), though that might lead to potentially unsafe behaviour.
A smarter recovery, which should be considered in the long term, might reuse previously used paths. This is then related to @argenos's problem of long-term experience reuse.