Wouldn't make sense to notify recovery behaviors with the reason move_base failed?

[corot]

Well, maybe there's a way to do so, but I failed to find one, so.... I propose to change the code on Kinetic to provide this extra information to the recovery behaviors

The idea is that pretty probably people are implementing (I did) behaviors that can solve only a particular move_base failure, but do nothing to solve other cases. So execute them is useless and increase the response time (and possibly the risk of collision!).

For example I created a recovery behavior that increase the allocated time for the SBPL planner. Obviously, this is useless if the robot is just stuck in a local planner local minima... Or for solving an oscillation loop, can make sense to try to execute some kind of escape plan.

Just an idea Please tell me if you think it makes sense and is worth the effort.

[spmaniato]

notify recovery behaviors with the reason move_base failed

So the idea is that all behaviors would be called anyway, but they would look at the reason first. And if the reason is irrelevant, they would return without doing anything?

Sounds good to me. But I think a more long-term solution would be to encode such logic in the move_base state machine, which is currently hardcoded. See the discussion: http://answers.ros.org/question/229869/customizing-extending-move_base With such as a "state machine plugin" execution of behaviors could be tied to specific triggers, possibly application-specific.

[corot]

Yes, exactly. Recovery behaviors that do not consider themselves appropriated for the problem will just inhibit and let the next one to go on. I agree it's not the most elegant solution, but probably pretty easy to implement.

That said, the discussions you pointed to and @DLu's branch look very interesting. I wonder if it's not time to develop an experimental move_base (on a kinetic branch of https://github.com/ros-planning/navigation_experimental) using an updated version of @DLu code as starting point.

[corot]

Another feature susceptible of being added to the hypothetical experimental move_base: #493

[PeterMitrano]

Yep, that's very possible. I've already implemented and tested that idea, but I'm waiting to hear back from a maintainer before I make a PR. here's what I did, it's branched off of indigo-devel

[corot]

Seems clear to me like current implementation of move_base is aging and needs some tune up. Given how widely uses it is now, and that some of the changes will affect the APIs, I see three options:

• clone current code to a move_base_2 package on navigation_experimental
• make a major upgrade for Kinetic, but it's already released, so probably too late for this.
• keep adding small and non-api-breaking changes to current move_base branches, specially kinetic-devel.

@DLu, @mikeferguson... should we open a discussion on this? what's the right place? Probably the SIG, but doesn't look very active recently

[PeterMitrano]

I'm just not entirely sure it makes sense to do that for ROS 1. ROS 2 is past its third alpha, and having a shiny new move_base implementation would be a great motivation for people to move forward.