Before proceeding, is there an existing issue or discussion for this?
Description
Hi i have a question regarding rmf_traffic and fleet adapters.
In my company we currently have a custom fleet manager that oversees various types of robots. We want to integrate OpenRMF alongside it—specifically leveraging the traffic core (for path conflict resolution), as well as the door and elevator cores—so our robots can seamlessly share space with other OpenRMF fleet adapters.
Our primary constraint is that we need to dispatch missions natively through our own fleet manager, rather than submitting them as standard OpenRMF tasks.
The Challenge
Ideally, when our fleet manager commands a robot to navigate, we want the OpenRMF traffic core to simply recognize the robot's intended path and intervene (e.g., stopping the robot) only when a traffic conflict, door, or elevator is encountered.
We realized that standard fleet adapters heavily rely on active RMF tasks to function. Based on the documentation, a Traffic Light Fleet Adapter seems to be exactly what we need. However, we also noted the following in the docs:
The Traffic Light control category is compatible with the core RMF scheduling system, but we have not yet implemented a reusable API for it. To implement a Traffic Light fleet adapter, a system integrator would have to use the core traffic schedule and negotiation APIs directly, as well as implement the integration with the various infrastructure APIs (e.g. doors, lifts, and dispensers).
Questions
Since we will need to build this integration directly against the core APIs, we were hoping the maintainers or community could provide some guidance:
-
Reference Implementations: Are there any existing examples, community forks, or open-source projects where someone has built a custom Traffic Light adapter that we could use as a reference?
-
Best Practices: Are there specific gotchas, recommended patterns, or architectural considerations we should be aware of when hooking a custom fleet manager directly into the core schedule/negotiation and infrastructure APIs?
-
Roadmap: Is a reusable Traffic Light API on the near-term roadmap for OpenRMF, or should we fully commit to building this direct integration for the foreseeable future?
Any insights, pointers, or warnings before we dive into the core APIs would be greatly appreciated. Thank you!
Before proceeding, is there an existing issue or discussion for this?
Description
Hi i have a question regarding rmf_traffic and fleet adapters.
In my company we currently have a custom fleet manager that oversees various types of robots. We want to integrate OpenRMF alongside it—specifically leveraging the traffic core (for path conflict resolution), as well as the door and elevator cores—so our robots can seamlessly share space with other OpenRMF fleet adapters.
Our primary constraint is that we need to dispatch missions natively through our own fleet manager, rather than submitting them as standard OpenRMF tasks.
The Challenge
Ideally, when our fleet manager commands a robot to navigate, we want the OpenRMF traffic core to simply recognize the robot's intended path and intervene (e.g., stopping the robot) only when a traffic conflict, door, or elevator is encountered.
We realized that standard fleet adapters heavily rely on active RMF tasks to function. Based on the documentation, a Traffic Light Fleet Adapter seems to be exactly what we need. However, we also noted the following in the docs:
The Traffic Light control category is compatible with the core RMF scheduling system, but we have not yet implemented a reusable API for it. To implement a Traffic Light fleet adapter, a system integrator would have to use the core traffic schedule and negotiation APIs directly, as well as implement the integration with the various infrastructure APIs (e.g. doors, lifts, and dispensers).Questions
Since we will need to build this integration directly against the core APIs, we were hoping the maintainers or community could provide some guidance:
Reference Implementations: Are there any existing examples, community forks, or open-source projects where someone has built a custom Traffic Light adapter that we could use as a reference?
Best Practices: Are there specific gotchas, recommended patterns, or architectural considerations we should be aware of when hooking a custom fleet manager directly into the core schedule/negotiation and infrastructure APIs?
Roadmap: Is a reusable Traffic Light API on the near-term roadmap for OpenRMF, or should we fully commit to building this direct integration for the foreseeable future?
Any insights, pointers, or warnings before we dive into the core APIs would be greatly appreciated. Thank you!