full control vs traffic light with specialized fleet managers

[Achllle]

When a fleet is adapted to RMF as full_control, RMF will take over full management of tasks and their execution. If my understanding is correct, the task doesn't get passed on to the proprietary fleet manager because that would mean that the fleet manager would manage its trajectories which would conflict with the fleet adapter's waypoint control.

Fleet managers are often highly specialized in their tasks and domains and so in most cases it makes sense to have the fleet manager be in charge of mission/task execution. That would for example allow for a delivery task where not one but 5 parts are picked up at once and unloaded at 5 different locations in an efficient manner. To make this example new task work with the full_control category, one would have to write the new MultiDelivery interfaces and execution logic in the FleetAdapter which likely won't be as good as the fleet manager's implementation. Alternatively, you could also rely on the proprietary fleet manager to manage the task, but expose a pause/resume interface (traffic_light adapter) so there's some level of traffic avoidance possible.

So even if you have the option to decide between full_control and traffic_light, I can see the latter being preferable in most scenarios in the field of industrial manufacturing/material handling. Is a scenario with most if not all fleet adapters being of type traffic_light something RMF would be well-suited to work with? Am I correct to assume that it's impossible to hand off a full task to a fleet manager and still expect to send it waypoint commands? Curious to hear how people are thinking about this.

[mxgrey]

I have a few different replies to address the concerns you've brought up. Each reply is independent and can be considered separately, so I'll put each one in its own section.

(1) Further development on the rmf_task library

Currently rmf_task and more generally the task management features in RMF are still in a prototyping stage. What you're seeing right now is not meant to be the end product. It's true that the capabilities right now are quite narrow, and that modifications to the source code are needed in order to support more complex task requirements, but that's not intended to be the final design.

We're currently investigating ways to use PDDL or a similar
general purpose domain definition language to describe task constraints and use a task planner with broader capabilities like Google OR Tools to generate task plans. At that point, I'm skeptical that proprietary fleet managers would have any kind of capability that can't be supported by RMF tools with a modest amount of configuring effort.

But I recognize that there are plenty of reasons to not accept this as a satisfactory answer, including:

1. This feature isn't available yet and we don't have a timeline to offer for it yet, so it's risky to rely on it
2. OEMs and/or system integrators may feel more comfort with their own solutions
3. There may be a desire for simpler and/or more predictable task planning logic that doesn't involve general purpose planners

(2) Integrate more directly with the traffic planner

The traffic planning and task planning are really separate concerns within RMF. The "Full Control" fleet adapter rolls these two concerns together into the minimal possible API for the convenience of system integrators, but this does not mean that RMF is strictly imposing a binary choice between "Full Control" and "Traffic Light". Those two APIs are only meant to be the easiest possible APIs to cover maybe 80%-90% of the use cases that we are currently anticipating. For more specific use cases, we can either develop more specific fleet adapter APIs or system integrators can use lower-level components of RMF (i.e. the tools in rmf_traffic_ros2) to build their fleet adapter.

For cases where the fleet manager wants to come up with the detailed task management steps but is okay with deferring to RMF for path planning and traffic management, their fleet adapter could directly use the rmf_traffic planner and the rmf_traffic_ros2 integration tools. Right now this would be a more difficult integration path than the "Full Control" or "Traffic Light" option, but we could try to develop a more narrow API for this if enough people want it.

(3) Allow custom tasks to be queued into the full control fleet adapter

Somewhat related to the previous section, we could do a refactor of the "Full Control" fleet adapter API so that it doesn't lock the user into depending on rmf_task and instead allows the system integrator to define custom tasks by specifying sequences of task phases. Perhaps we could even design it so that system integrators can define their own custom phases.

This option would allow for the most code reuse possible, and perhaps most importantly it would trivially provide infrastructure integration (i.e. talking to doors, lifts, dispensers, etc) while still allowing custom tasks to be defined without any changes needed to source code.

Am I correct to assume that it's impossible to hand off a full task to a fleet manager and still expect to send it waypoint commands?

This really depends on the fleet manager more than anything. I suspect many fleet managers out there today will be vertically integrated in a way that doesn't really accommodate this kind of use. But if anyone offers a fleet manager that is able+willing to determine the steps needed for a task while allowing a third party to specify the paths needed to complete those steps, then (2) or (3) may be an option. I have a feeling the most likely path forward will be for OEMs and/or system integrators to do (2) or (3) directly inside of their own fleet managers to make them natively RMF-complaint rather than use a fleet adapter layer.

(4) Having lots of "Traffic Light" fleets is okay, with some caveats

Is a scenario with most if not all fleet adapters being of type traffic_light something RMF would be well-suited to work with?

This should certainly be doable, with some important caveats. The traffic light system is designed to guarantee conflict-free traffic management, except at path endpoints. The assumption is that whenever traffic light fleets submit their path, that fleet has free reign at the start point and end point of the path, and that there is no risk of a conflict with another fleet before the robot leaves the start point or after the robot arrives at the end point. Deployments that use only traffic light fleets will have to make sure they arrange their deployment with this in mind, or that they make use of the upcoming reservation system to prevent endpoint conflicts.

That being said, I still hope to convince as many people as possible that the "Traffic Light" approach should be considered a stop gap while the industry gradually transitions, and not an end goal.

[Achllle]

Thanks for your elaborate reply, this really helps my understanding. Just wanted to provide my perspective on this:

I'm excited about this general task setup so that a large number of use cases can be covered, but I'd strongly agree with your points on why that not always may be the best option.
As you mentioned OEMs may feel more comfort with their own solutions. I'd put it even stronger than that: many of them are realizing that hardware is becoming commoditized and the value drivers lie in the fleet manager. They are unlikely to hand that off to some 3rd party system if it means possibly compromising their promised ROI. Liability is another concern with handing off capabilities. Although we may get there, I think we're looking at a timeline that is at least several years out. Simplicity + reliability is another concern, but oftentimes these OEMs and SIs have a deep understanding of a niche that we don't have. In my (industrial) experience, SIs don't have the ability to integrate with something like RMF, instead just picking robot brands that they've built custom integrations for. Lastly, from the 3 major mobile robot brands I looked at, only one (MiR) had an API that supported a full_control style adapter. All these factors added up make me think we can expect to see scenario (4) a ton in the beginning, with hopefully some (2)s and (3)s down the line.

Option (3) therefore seems like a really good strategy to support, although I'm vague on the feasibility of it. Regarding a native integration, I'm not convinced that fleet managers would from the onset be willing to strongly support a young system like RMF just yet, but they might as a first step be willing to provide better support for a fleet adapter, perhaps accepting some way to react to possible traffic conflicts and communicating their new intentions.

[mxgrey]

All these factors added up make me think we can expect to see scenario (4) a ton in the beginning, with hopefully some (2)s and (3)s down the line.

I expect a similar situation, although I wouldn't discount the value proposition of (1). Even in its very nascent state, rmf_task has more optimal automatic task planning capabilities than what we've seen from various system integrators and vendors (not all of course, but a considerable amount), so those companies whose product focus isn't around operations research could stand to benefit quite a bit from picking up rmf_task instead of developing their own task management pipeline. I can easily imagine this happening as robots move out of factories and into the healthcare and hospitality domain: the product focus will become the human interaction and navigating unstructured environments, so the optimal task management becomes less of a competitive concern.

Just as a broad statement, I'd like to emphasize that RMF is designed from top to bottom to be modular precisely because we expect that not everyone will want everything from it, but everything that's in it has been requested by someone due to an important business need. For everyone who asks us to not interfere with their task management, we have others asking us to just take care of task management for them entirely. For everyone who asks us not to interfere with their robot navigation, we have others asking us to just tell them exactly where the robot should go every step of the way. The overall framework is designed to meet all these different requests, but admittedly it's not currently as easy as it could be for people to integrate in all these different ways, because making each different type of integration "easy" requires us to design a custom high-level API for it, akin to what exists for "Full Control" or "Traffic Light". The tools are all there and the framework can support it all, but we're going to need more time before we can make it easy for absolutely everyone.