[Feature request]:

[rajgavhale]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

We’re currently working on an Open‑RMF deployment and encountered a situation where we need to restrict only one robot in a fleet from accessing a specific lane or location.
We initially attempted to use lane closures, but realized that since the planner instance is shared fleet-wide, the closure affects all robots in the fleet. Our idea is to assign a dedicated planner instance per robot to allow robot-specific constraints like lane restrictions.
Would you consider this a viable solution, or are there any unintended side effects or better design alternatives within RMF?
@mxgrey

Implementation Considerations

No response

Alternatives

No response

Additional information

No response

[mxgrey]

Our idea is to assign a dedicated planner instance per robot to allow robot-specific constraints like lane restrictions.

There are some reasons we use the same traffic planner for all robots in a fleet. One simple reason is better performance due to shared planner caching, but that reason isn't very important. The more important reason is using one traffic planner for all robots in a fleet allows us to treat all robots within a fleet as fungible, meaning if a fleet is compatible with a certain task, then any one of the fleet's robots can perform that task equally well. We rely on this assumption during the task bidding process, and we continue to rely on it after the task has been assigned, so that we can freely reassign the task within the fleet at any time.

If we allow robots within a fleet to have inconsistent lane closures, then there can be situations where some robots within the fleet can successfully complete certain tasks but not others. Whenever task reassignment gets performed, it's possible that tasks will end up getting assigned to robots that cannot perform them because the lane(s) to one of the task destinations has been closed.

To make this work properly, you would need to update the task planner to support different traffic planners for each robot. Currently rmf_task::Parameters only supports one.

One approach might be to add an "override traffic planner" as a component of State and then have the task planner check for the override when calculating travel. This means the implementation of TravelEstimator will need to be updated to consider an override traffic planner. That might be accomplished by adding a std::shared_ptr<rmf_traffic::agv::Planner> argument to TravelEstimator::estimate and then changing the cache to also account for a std::shared_ptr<_> in its key.

[mxgrey]

If you can provide specific examples on why you would want to close lanes for specific robots in a fleet but not all of them, I'd be interested in learning more about the use case in general. Understanding that might help with the design of the next generation interfaces.