Posted by @ItamarEliakim-R:
Before proceeding, is there an existing issue or discussion for this?
Description
Hey,
I’m currently working on a feature that allows changing task priority after a bid has been assigned to a specific fleet. This enhancement was requested by our customer who manages several robots in a large facility and needs to reprioritize tasks when urgent packages arrive.
The solution involves adapting our custom API server (not the default RMF one) to introduce a new task prioritization schema in the task_api_requests. This update then propagates to the Dispatcher and TaskManager.
However, I’ve noticed that there’s a distinction between the DirectQueue and Queue(Dispatch Task). I’m curious about the reasoning behind this separation—why not consolidate both into a single structure?
Looking forward to your insights!
Thanks,
Itamar
Edited by @ItamarEliakim-R at 2024-08-17T21:40:00Z
Posted by @Yadunund:
Hi @ItamarEliakim-R,
I’ve moved this ticket to our Discussion board.
The solution involves adapting our custom API server (not the default RMF one) to introduce a new task prioritization schema in the task_api_requests. This update then propagates to the Dispatcher and TaskManager.
There is an on-going effort to include priority in task updates so perhaps you can chime in on whether the implementation there aligns with the changes you’ve made. Perhaps you can upstream some of your efforts.
However, I’ve noticed that there’s a distinction between the DirectQueue and Queue(Dispatch Task). I’m curious about the reasoning behind this separation—why not consolidate both into a single structure?
The BinaryPrioritization we support does not allow us to retain the ordering of direct assignments while allocating dispatch tasks around these direct assignments. Hence a single data structure is not feasible since by default fleets respond to both dispatch and direct requests. Perhaps once we support more sophisticated priorities in our TaskPlanner, we can look towards converging on a single data structure.
For now, we’ve found it efficient to retain different data structures as one could rely on the direct pipeline to guarantee that the next task executed is the one submitted by the user via this pipeline even if there are dispatch tasks queued. See this implementation.
Posted by @mxgrey:
Just adding to everything Yadu is saying:
To be blunt, I don’t really recommend mixing direct tasks and dispatched tasks in the same system. The fundamental problem is this: What is the source of truth that decides the order that tasks should be run?
The order of dispatched tasks will be determined by a planner which is free to reorder tasks whenever the situation on the ground changes. It’s always trying to minimize a cost function.
Direct tasks will be ordered according to whatever the requester specifies. It’s not clear how these can be ordered relative to dispatched tasks, so we handle them separately: direct tasks are run first, then dispatched tasks are run when there are no direct tasks.
As Yadu said, we’d appreciate any thoughts and feedback on how users would like to see direct and dispatched tasks being executed together.
Posted by @ItamarEliakim-R:
Apologies for the delayed response. I didn’t realize the conversation had shifted from rmf_ros2 to this thread.
@Yadunund, @mxgrey Thank you both for your thoughtful insights. I greatly appreciate your responses!
It’s encouraging to see the ongoing work on priority reporting. I’ve been working on a similar concept and would love to contribute upstream.
Regarding the direct vs. queued tasks, there’s a strong case for unifying these approaches within the design. There are scenarios, from individual robot tasks to fleet-wide operations, where this consolidation would be beneficial. Currently, the direct queue seems to override the priority parameter, causing tasks to jump ahead regardless of the priority level in the dispatch queue. For instance, imagine a scenario where several tasks are directly requested while others are queued with higher priority. In this case, it makes sense for the system to finish the higher-priority tasks before assigning any direct requests to the robots. This logic can be applied across different use cases, from cleaning operations to logistics management.
Additionally, by unifying the logic for both queues, we can unify areas of the code, such as reporting task states over WS. Currently, the direct task queue isn’t transmitted over WS in the same manner as the dispatch task queue. I plan to submit a PR soon, aiming for consistent behavior with minimal modifications.
I’ll need to further evaluate the design to ensure a seamless integration of the two queues. However, I’m confident we can achieve a cleaner, more structured codebase by consolidating them, creating a single source of truth, with an additional attribute on the direct queue to specify its direct-robot assignment.
It’s not urgent, but definitely an effort that I’d love starting as a side project to contribute to and improve the feedback I get from our customers.