How do I make the robot stop aborting the navigation?

asked 2021-10-21 15:22:39 -0600

FFelizpe gravatar image

Hello there!

I've been working with the navigation stack in ROS Kinetic for a while now, and while things have been going fine, one thing has been bothering me, recently - the aborting routine.

The thing is, when the robot found an obstacle that it couldn't avoid, it used to do all the recovery behaviors and then abort the navigation. Then, I turned off all the recovery behaviors, and now it just aborts, first thing. The problem is, it aborts way too fast, ridiculously fast. In less than ten seconds, the robot stops and aborts navigation when stuck, before I can do anything to unstuck it.

I wanted a way either to increase the aborting cooldown - making it abort after more than a minute, for example -, or reduce it entirely. The problem with aborting is that it straight up cancels the route it was supposed to be navigating, so when the path is clear again, it won't get back to navigating, because the route was aborted. I'd prefer if the robot just stopped in place until the path was clear.

However, I'm not finding anything that can help me with that - changing the parameters of the recovery behavior doesn't help, because it's not exactly a recovery behavior, it seems, but something that happens after. Can someone give me a light on what to do?

Thanks in advance!

edit retag flag offensive close merge delete



Have you tried increasing controller_patience

(double, default: 15.0) How long the controller will wait in seconds without receiving a valid control before space-clearing operations are performed.

osilva gravatar image osilva  ( 2021-10-21 19:15:08 -0600 )edit

No, I didn't, I'll try it!

However, won't this prejudice the frequency on which the clear costmap will work clearing the map?

FFelizpe gravatar image FFelizpe  ( 2021-10-22 07:15:56 -0600 )edit

I learned this from another issue, not sure how all ties up, but see this link:


Planning retries when robot is stuck
ISSUE: Planner would attempt to only find one plan before executing recovery behavior. Hence, the robot would give up finding a plan very quickly.

SOLUTION: The following commit 93eea82 solves the issue. The key parameters in the file move_base_params.yaml to tune to solve this issue are the following: max_planning_retries, planner_frequency, planner_patience, and controller_patience. Their descriptions are described in the move_base wiki.
osilva gravatar image osilva  ( 2021-10-22 07:50:33 -0600 )edit

I know they are somehow interconnected based on Navigation Stack setup diagram but I need to dig more into how the inner works of move_base.

osilva gravatar image osilva  ( 2021-10-22 07:54:19 -0600 )edit

I think the key is that attempt_end adds controller_patience for move_base.cpp source code:

else {
          ROS_DEBUG_NAMED("move_base", "The local planner could not find a valid plan.");
          ros::Time attempt_end = last_valid_control_ + ros::Duration(controller_patience_);

      //check if we've tried to find a valid control for longer than our time limit
      if(ros::Time::now() > attempt_end){
        //we'll move into our obstacle clearing mode
        state_ = CLEARING;
        recovery_trigger_ = CONTROLLING_R;

osilva gravatar image osilva  ( 2021-10-22 08:18:59 -0600 )edit