RMF integration does not yet support parallel work orders

[aaronchongth]

Background

#42, under Signalling in PR description

More comments: #42 (comment), #42 (comment)

The current implementation of RMF as a transporter workcell uses its main BT to both dispatch as well as track the entire multi-stop delivery task, signalling the correct workcell whenever it reaches it (by listening to RMF dispenser requests and results).

This causes the RMF transportation workcell to be unable to handle parallel work orders that require AMR deliveries, as

• the first work order's BT is still running, tracking the ongoing delivery
• it prevents an AMR mismatch at workcells (mentioned in Introduce a RMF transportation workcell #42, Signalling), where in the case of 2 orders involving workcell_1, workcell_1 is waiting for amr_1 to handle the first order, however amr_2 reaches first.

Some ideas

With these cases in mind, there will be a need to iterate on the RMF integration. With my still-flawed knowledge of the Nexus ecosystem, I'm wondering if we can have each workcell (based on the work order) dispatch an RMF transporter request to themselves, before doing any work. So each workcell is responsible for the dispatch of the AMR to themselves only.

For multi workcell with transportation, I foresee the first workcell in the order will need to perform the basic RMF dispatch request, and get allocated an AMR, whereas other subsequent workcells in the order, will need to use RMF's direct dispatching, to request for the same AMR.

1. work order comes in with sequence workcell_1 and workcell_2
2. workcell_1 performs dispatch request for AMR, gets assigned amr_1
3. 'amr_1reachesworkcell_1, signals, the workcell does its job, and signals workcell_2`
4. workcell_2 performs a direct dispatch, requesting for amr_1 (this queues up the next RMF task), signals workcell_1
5. workcell_1 completes the job, signals amr_1 to complete the current RMF task
6. amr_1 starts the next queued direct dispatch and heads to workcell_2
   the workflow goes on

The reason for the overlapping signals between workcell_1 and workcell_2 is to prevent another work order from snatching amr_1 in that short window that workcell_1 is done.

Off the top of my head, I can think of the issue where multiple work orders are sent out at the same time, and they all get piled onto the same AMR by RMF. We can explore using the decommissioning function of RMF, to prevent allocating new work orders onto AMRs that are already busy. This will ensure each AMR will only ever be handling tasks from 1 work order, and only when the AMR is no longer needed for the current work order, will it be recommissioned, to accept new tasks.

Thinking out loud for now, and still not super familiar with the codebase, happy to discuss more or be corrected if I misunderstand some concepts.

[aaronchongth]

Some notes per discussion,

• To resolve parallelism, we'll experiment with
  • max_jobs for workcell orchestrators as well. Will need to ensure that signalling is done properly via unique IDs.
  • RMF integration as a transporter, to handle bidding with RMF bidding via bid notices, with the new concept of "dry runs"
• Perhaps consider targeting rolling binaries, so we are not tied to source builds

With more context about the transporter bidding on the system orchestrator level, this might allow us to expand the idea written in the original description, and start using direct dispatches only from each workcell. This may allow us to do-away with the RMF workcell and have a call-for-amr workcell capability instead