Do all fleet adapters share the same graph?

[Achllle]

Reposting from the old org

In the situation where there are several fleets partially sharing the same space and fleets are restricted to certain areas (common in industrial manufacturing), do each of these fleets need to share the same navigation graph? If they do, is the bidding/negotation system responsible for ensuring that these robots don't leave their working areas, even when a traffic conflict arises?

If they don't share the same graph, how is that overlap coordinated? I'm not clear on this from looking through the code and documentation.

[mxgrey]

In the situation where there are several fleets partially sharing the same space and fleets are restricted to certain areas (common in industrial manufacturing), do each of these fleets need to share the same navigation graph?

Nope, RMF is specifically designed to support cases where robots do not share a navigation graph. In fact, the core traffic scheduling and negotiation system does not involve any navigation graphs at all, so it's possible for freespace robots that have no navigation graph whatsoever to participate in the scheduling and negotiation system.

If they don't share the same graph, how is that overlap coordinated? I'm not clear on this from looking through the code and documentation.

The traffic schedule and negotiation works off of piece-wise cubic spline trajectories, so as long as a robot's prediction of its future trajectory can be reasonably approximated with piece-wise cubic splines (and I would argue it is always possible to give a fair approximation of any realistic motion using piece-wise cubic splines), it can work with the traffic system. These piece-wise cubic spline trajectories are tested against each other for conflicts, and when a conflict is detected, a negotiation is started between the fleets of the conflicting robots. The out-of-the-box fleet adapter APIs use navigation graphs for convenience, but it's not a fundamental requirement of the overall system.

If they do, is the bidding/negotation system responsible for ensuring that these robots don't leave their working areas, even when a traffic conflict arises?

The bidding system is specific to assigning tasks to the different fleets, whenever there is redundancy in which fleet can perform a task. The traffic negotiation system is a separate (complementary) system for resolving issues that robots may have with navigating around each other.

[Achllle]

Thanks for your answer!

The RMF core overview > Traffic deconfliction > prevention chapter states

In the future we intend to provide a similar utility for AMRs (Autonomous Mobile Robots) that can perform ad hoc motion planning around unanticipated obstacles.

In the airport demo, the TinyRobots (Ubiquity Magni) are launched with a nav graph. In this case it seems like this "AMR" is treated like an AGV. And then these trajectories are converted to piecewise cubic splines for the traffic scheduler/negotiation. Is my understanding correct? At a high level, what needs to be implemented to fully support AMRs?

[mxgrey]

it seems like this "AMR" is treated like an AGV.

That's right, the current out-of-the-box full control fleet adapter is targeting an AGV style robot which does not navigate through free space.

At a high level, what needs to be implemented to fully support AMRs?

To fully support AMRs (by which I mean robots that can move through free space) we would need a free space motion planner that can contend with moving obstacles. We already have such a planner (using a kinodynamic RRT* algorithm) underway. I will try to remember to post an update here when it is merged in.