Posted by @Odin-byte:
I am wondering what would be best practice to allow for a robot to only bid on delivery task if he has storage space left and how pass the information down to the robot which item he should unload before triggering its docking service, as the robot need to dock backwards to unload the item stored in the back position for example.
Is there any current implementation of this? Which parts of rmf would I need to modify?
Chosen answer
Answer chosen by @Odin-byte at 2024-08-26T09:09:42Z.
Answered by @mxgrey:
Everything Yadu said is correct, but it sounds like the original question is meant for a system that does multiple pick-up and multiple drop-off, all coming in as ad hoc tasks, so I’ll add a few points to consider when trying to implement such a system.
First, to mix together multiple ad-hoc pickups (i.e. multiple pickups that are not part of the same task description) you will need to separate the pickup and the drop-off phases of each delivery into two different tasks. Ordinarily a “task” in RMF is atomic, meaning once a task start, the robot will not do any other task until its current task is finished. So if the delivery task description contains both a pick-up and a drop-off then no other delivery will happen until the drop-off is finished. At that point there’s no question about whether storage space is available because the robot will always drop off whatever it picks up before it attempts another pickup.
If you do choose to break down each delivery into separate pickup and drop-off tasks you’re running some significant risks of those tasks being distributed wrongly because right now we do not support constraints between tasks. Without task constraints it’s possible that the pickup task will be sent to a different robot in the fleet than the drop-off task for the same item. This is because each fleet will distribute tasks to whatever robots are available in a way that minimizes the overall time spent on the tasks.
To get around this problem in the current task dispatching system, you would have to do something like this:
- Make each robot its own “fleet” so that tasks cannot be reassigned across different robots
- Dispatch the pickup portion of the task
- Wait until the pickup has been assigned and completed
- Dispatch the drop-off portion of the task to the specific robot that performed the pickup (the dispatch request schema lets you request a specific fleet for the task)
Suffice it to say, I think there are going to be some considerable challenges right now with mixing together multiple simultaneous ad hoc pickup and drop-off tasks. This is something we definitely want to support in the next generation and it’s worth beginning a discussion about how to do that nicely, but the current generation will pose some challenges.
Posted by @Yadunund:
You can rely on the Confirmation API to implement logic to accept/reject delivery tasks based on what you describe.
For passing information down to robots at runtime, if you describe your task as composable task with a PerformAction event, you can include whatever information you need to pass down within the description field of the PerformAction event. You can then implement the runtime logic using the ActionExecutor API.
Posted by @mxgrey:
Everything Yadu said is correct, but it sounds like the original question is meant for a system that does multiple pick-up and multiple drop-off, all coming in as ad hoc tasks, so I’ll add a few points to consider when trying to implement such a system.
First, to mix together multiple ad-hoc pickups (i.e. multiple pickups that are not part of the same task description) you will need to separate the pickup and the drop-off phases of each delivery into two different tasks. Ordinarily a “task” in RMF is atomic, meaning once a task start, the robot will not do any other task until its current task is finished. So if the delivery task description contains both a pick-up and a drop-off then no other delivery will happen until the drop-off is finished. At that point there’s no question about whether storage space is available because the robot will always drop off whatever it picks up before it attempts another pickup.
If you do choose to break down each delivery into separate pickup and drop-off tasks you’re running some significant risks of those tasks being distributed wrongly because right now we do not support constraints between tasks. Without task constraints it’s possible that the pickup task will be sent to a different robot in the fleet than the drop-off task for the same item. This is because each fleet will distribute tasks to whatever robots are available in a way that minimizes the overall time spent on the tasks.
To get around this problem in the current task dispatching system, you would have to do something like this:
- Make each robot its own “fleet” so that tasks cannot be reassigned across different robots
- Dispatch the pickup portion of the task
- Wait until the pickup has been assigned and completed
- Dispatch the drop-off portion of the task to the specific robot that performed the pickup (the dispatch request schema lets you request a specific fleet for the task)
Suffice it to say, I think there are going to be some considerable challenges right now with mixing together multiple simultaneous ad hoc pickup and drop-off tasks. This is something we definitely want to support in the next generation and it’s worth beginning a discussion about how to do that nicely, but the current generation will pose some challenges.
Edited by @mxgrey at 2024-08-26T03:25:55Z
This is the chosen answer.
Posted by @Odin-byte:
Thanks for your answer! Correct me if I am wrong, but it is also possible to specify the robot that should get assigned a task within a specified fleet. If I assign a task to a specific robot within a specific fleet, would these tasks be safe from reassignment by the planner?
Or could it happen, that I for example while using the rmf_demo_tasks dispatch scripts, where you can specify a fleet and a robot, I dispatch a task to a specific robot this task then is reassigned to another robot by the task allocator?
Posted by @mxgrey:
Task requests that get “dispatched” can be given a specific fleet to assign the task to, but they cannot be given a specific robot.
There is a different task request pipeline, which we usually call “direct task requests” that let you indicate the specific robot to perform the task. However, direct task requests are not passed through RMF’s task planner, they are simply accepted immediately by whichever robot they are assigned to. They are also not optimized, so they will run in whatever order they get issued. Direct task requests are always fulfilled before any dispatched requests are executed, so direct and dispatched tasks do not mix very well.
You could get what you want by doing all the task planning outside of Open-RMF and then issuing direct task requests to the specific robots.
Posted by @Odin-byte:
Good to now. That gives me enough possibilities to figure out a good mix for my use case! Thanks for your time!
Edited by @Odin-byte at 2024-08-27T09:08:37Z