The checkpoints example is illustrative and I’ll take that into account when doing initial design work that plugin interfaces can be made to exist which would allow you to do that. My goal is not to preclude behavior, but to have some set of X, Y, and Z behaviors which I feel are appropriate, generalizable, and sufficiently mature that I’m committing to its maintenance long-term.
The bits below are to provide you my thought process and context, no negative feelings or opinions at all. Please read in that spirit that I want to make sure there’s light shined onto why I think this way as a maintainer trying to provide a great user experience.
That’s not to say that others cannot use those interfaces and plugins to make the behavior they’re looking for. Its just that multi-robot scheduling, planning, and coordination is a wide field and there’s no single class of method that works for a broad enough distribution the user-base. The example you show is still largely single-robot planning with some business logic to stop to ask if continuing is cool - I think that’s a totally doable thing here, but that doesn’t help the person trying to do centralized coordination of a massive fleet nor decentralized active traffic management when other robots come into their zones. When I say “Nav2 supports all types of robots”, its because I and the working group have spent years building new planners, controllers, and capabilities to support that cross-section of circular/non-circular, differential, omnidirectional, ackermann, and arbitrary kinematic robot base types.
I don’t want to be put in a situation where I open the can of worms by making a statement that “Nav2 supports multi-robot navigation” and I’m becoming flooded with tickets / requests / complaints that I don’t support what they need (and on the surface is an absolutely reasonable capability request) and that I’ve said something deceptive or untrue in their opinion. That’s a bad user experience and what’s scientifically speaking referred to as “a bad time” for myself. I could easily see a world where if I committed to providing the level of behavior and cross-section of algorithms for multi-robot navigation as I’ve worked hard to provide in other areas, that could consume the next 3-5 years of my active development time - and that’s simply not our goals or aims at this moment. I’m not saying it won’t ever be, but isn’t today.
Additionally, the types of companies that are looking for multi-robot scheduling / coordination / planning are typically well-funded (due to being extremely profitable) with highly capable engineers working on such problems. A 1% change in performance of the fleet based on that multi-robot layer can result in millions of dollars of saved money for a client. As a result, I almost assume that a layer like that provides mere tutorial value for students and initial prototype value for startups since they will need to create something bespoke for their needs shortly after to compete in the growing market. When we work on adding a new significant capability to Nav2, its important to me that this is not a research-quality capability and this is ready for prime-time and can/should be used by companies in their production environments.
The problem that Open-RMF looks to solve is slightly different and more naturally lends itself to open-source development. Since we’re not trying to optimally coordinate a fleet but trying to handle discrepancies and issues between fleets, that indeed is something of interest and non-tutorial non-prototype level utility if made well. However the point above remains that I don’t want to make a statement about multi-robot-ing in Nav2, but that does not mean that I don’t think the stuff in Nav2 cannot be used in that way or that we should not consider those applications in our designs. But the plugins and specific developments to support it I believe should live somewhere outside of the main stack as to not draw in inappropriate conclusions from passive bystanders (e.g. navigation2_auxiliary , navigation2_multirobot, or part of Open-RMF’s organization). There are indeed intentional choices made already within Nav2 with an eye for needs of multi-robot users, but its notable that I never outright mention it. This is a very intentional decision until such a time when we can commit to providing and supporting for the long term the cross-section of common user needs in multi-robot fleet management within the Nav2 ecosystem’s core (multi-fleet coordination, centralized and decentralized fleet planning, fleet planning on graphs and freespace).
So with that context, please note that I’m not saying I’m going to throw out all multi-robot needs and particularly those that are required or beneficial for a stronger binding to Open-RMF. However, it won’t be a first-class citizen within Nav2’s provided implementations and at some point, we may need to make compromises which do preclude certain types of less-common multi-robot-ing in exchange for code quality / maintainability / utility for the primary user-base. From what you describe @grey , that’s all 100% on the table and I see no reason this couldn’t and shouldn’t be considered for what’s to come here. But rather than seeing a clearance feature builtin, you may instead find a nice plugin interface where it can be injected. I view integrations with Open-RMF as strategically important for Nav2 (and vise versa I imagine) to grow the pie of the ecosystem and maximize contributions.
I suppose in summary: plugins, plugins everywhere!
S