Comment by osilva for 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!

I learned this from another issue, not sure how all ties up, but see this link: From: https://github.com/icclab/icclab_summit_xl/commit/93eea82d67f4a3a4308f33254fa0a135acf5f0a8 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.