|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.11.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2025-10-21 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.11.1 (2025-07-21)
2.11.0 (2025-06-09)
- Migrate reservation node to target_link_libraries (#437)
- Remove unused variable (#435) Minnor code quality issue.
- Contributors: Arjo Chakravarty, Luca Della Vedova
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |
Launch files
Messages
Services
Plugins
Recent questions tagged rmf_reservation_node at Robotics Stack Exchange
|
rmf_reservation_node package from rmf_ros2 repormf_charging_schedule rmf_fleet_adapter rmf_fleet_adapter_python rmf_reservation_node rmf_task_ros2 rmf_traffic_ros2 rmf_websocket |
ROS Distro
|
Package Summary
| Tags | No category tags. |
| Version | 2.10.1 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | Internal ROS infrastructure for RMF |
| Checkout URI | https://github.com/open-rmf/rmf_ros2.git |
| VCS Type | git |
| VCS Version | kilted |
| Last Updated | 2025-07-02 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Arjo Chakravarty
Authors
rmf_reservation_node package
The goal of this package is to provide a simple parking reservation node in RMF. Before a robot goes to its next destination the fleet adapter asks the reservation-node if its next destination is available. If the destination is available the robot will immediately proceed to the next destination, otherwise it will allocate a free parking spot for the robot to wait at till the next destination becomes available in a FIFO manner. If you need more advanced methods than FIFO, feel free to hack this package. To enable the use of this package you need to add the following to your fleet configuration yaml at the fleet level and run the reservation node:
use_parking_reservations: True
We recommend disabling responsive_wait when you do so. An example is available in rmf_demos.
Expected Behaviour
Basic queueing
You should never need to interact with this package directly. Rather, you can simply dispatch a task using the traditional methods. If you have rmf_demos installed you can run the office world. We can start by commanding the tinyRobot2 to go to the pantry.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot2 --use_sim_time
The robot should proceed as expected. We can then ask tinyRobot1 to also go to the pantry. Nothing should happen as the pantry is already occupied and tinyRobot1 is at its parking spot.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
We can ask tinyRobot2 to move to the lounge after this.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
This should immediately trigger 2 things:
-
tinyRobot2will move to the lounge -
tinyRobot1will proceed to move to the pantry taking tinyRobot2’s place.
Moving to a waitpoint
If we continue from the previous example. Lets ask tinyRobot1 and tinyRobot2 to swap places starting at the pantry and lounge respectively.
ros2 run rmf_demos_tasks dispatch_go_to_place -p pantry -F tinyRobot -R tinyRobot1 --use_sim_time
You should see tinyRobot1 move totinyRobot2_charger as lounge is not a designated wait point. You can then command tinyRobot2 to the lounge.
ros2 run rmf_demos_tasks dispatch_go_to_place -p lounge -F tinyRobot -R tinyRobot2 --use_sim_time
tinyRobot1 and tinyRobot2 should now proceed to swap places.
If there are at least as many parking spots as robots on any given floor, then you should never have a deadlock.
Protocol Used Behind the Scenes
The reservation node has no information about the state of the graph, it simply maintains a list of available parking spots internally. The fleet adapter does most of the heavy lifting in the GoToPlace event. When a GoToPlace event is started we first check if the robot is already at one of the target locations. The fleet adapter submits a ReservationRequest message with the desired end parameters. The parameters are listed in terms of cost (where the cost function is distance). The reservation node will issue a ticket for said request. When ready to proceed, send a claim message with the ticket and list of potential waiting points ordered by distance. The reservation node will then try to award the lowest cost target location. If the destination is not available yet then it will award the lowest cost waiting point to the robot. The fleet adapter will release the previous location as it starts to move to its next location.
Known Issues
- At start up if there is no idle task, the reservation node will not know where the robots are. It is advised to send 1
GoToPlacetask for every robot that is added to the world.
Quality Declaration
This package claims to be in the Quality Level 4 category. See the Quality Declaration for more details._
Changelog for package rmf_reservation_node
2.10.1 (2025-05-13)
2.10.0 (2025-05-09)
- Completely Excise Reservation Cancellation pathways (#416)
- Contributors: Arjo Chakravarty
2.9.0 (2024-11-27)
- Adds a simple parking spot management system. (#325)
- Contributors: Arjo Chakravarty
2.8.0 (2024-06-12)
2.7.1 (2024-06-10)
2.7.0 (2024-06-08)
2.6.0 (2024-03-13)
2.5.0 (2023-12-22)
2.4.0 (2023-12-15)
2.3.2 (2023-08-28)
2.3.1 (2023-08-10)
2.3.0 (2023-06-07)
2.2.0 (2023-06-06)
2.1.5 (2023-05-20)
2.1.4 (2023-05-02)
2.1.3 (2023-04-26)
2.0.0 (2022-04-29)
1.5.0 (2022-03-15)
1.4.0 (2021-09-02)
Package Dependencies
| Deps | Name |
|---|---|
| ament_cmake | |
| ament_lint_auto | |
| ament_lint_common | |
| rmf_building_map_msgs | |
| rmf_reservation_msgs | |
| rmf_fleet_adapter |
System Dependencies
Dependant Packages
| Name | Deps |
|---|---|
| rmf_demos |