Hi,
Is multi-stop delivery currently supported? One scenario will be kitchen staff need to get meals delivered to different rooms located on different floors.
There isn’t a stable public API for it, but as a feature it can be added very easily.
In the long term, we have plans to support “composing” task descriptions, i.e. being able to specify stages of various tasks by piecing together sequences of primitive actions like “Go to place”, “Dock”, “Pick up”, “Drop off”. However, that’s still pretty low on our to-do list, so I can’t offer an estimate for when that will be available.
In the meantime, if this task type is needed urgently then I can suggest two approaches:
Open an Issue or use this Discussion to design a “standardized” description of a multi-stop delivery (e.g. discuss requirements and make sure the design is applicable to all relevant use cases among members of the community). Then someone (either from Open Robotics or elsewhere) could open a PR to add the new task type to the stable public API of RMF.
You can fork the RMF repos and add the task as necessary. Making the task work in RMF is mostly a matter of creating a modified version of this function and adding a new rmf_task_msgs message for it, then nesting it into this message and adding a section for it to the end of this if-sequence.
The forking changes that I just described would end up deprecated and removed once we add the ability to compose task descriptions, but that’s how it needs to be done if this task type needs to be implemented right away.
The ability to “compose” task descriptions using the primitives is really interesting, and I’m looking forward to it.
Is there a way we can help on working on this ? Do you have a design document on how you plan to do that, and how much effort it would take?
There’s no public design document on it currently; we just have some notes about the idea scattered around internally at Open Robotics. I expect it will start to be a high priority item in late September or early October, once we’ve gotten past a few upcoming milestones.
To get a sense of how we would implement it, you could look at the current list of “phase types” which are used in our internal implementation to define the different task types. Internally we already implement tasks by just composing “phases” into a sequence, so the idea is to expose some of these phases to the public as part of a stable API and thereby allow anyone to define any kind of task by specifying their own phase sequence.
We would not expose all of the phases publicly; only the ones that make sense as building blocks for performing a task. For example, DoorOpen is not something that should ever need to be an explicit step in a task description; instead, we would only expose GoToPlace in the public API as a building block, and then the implementation of GoToPlace can internally use DoorOpen as needed.
So in terms of design for this feature, the most important question is: Which phases should be exposed to the public as task building blocks, and what should the parameters be for those phases? And related, are there new phases we need to introduce to cover more task types that we haven’t dealt with yet?