From 278ca0c7e4a39c2194d5d281dc9f12f9865f1a3d Mon Sep 17 00:00:00 2001 From: Dev Manek Date: Thu, 29 Sep 2022 19:11:27 +0530 Subject: [PATCH 1/7] solved discussions/207 Signed-off-by: Dev Manek --- src/integration_doors.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index cecb6a5..54928c3 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -1,4 +1,3 @@ - ## Doors ### Map Requirements @@ -15,14 +14,22 @@ Doors can be integrated with RMF using a ROS 2 door node and a door adapter, whi The door node will have to be implemented based on the make and model of the door that is being integrated in order to address the specific API of the door controller module. The communication protocol will also be dependent on the door and controller model, which might be some form of `REST`, `RPCXML`, etc. The door node is in charge of publishing its state and receiving commands over ROS 2, using the messages and topics listed below: -| Message Types | ROS2 Topic | Description | -|---------------|------------|-------------| -| `rmf_door_msgs/DoorState` | `/door_states` | State of the door published by the door node -| `rmf_door_msgs/DoorRequest` | `/door_requests` | Direct requests subscribed by the door node and published by the door adapter +| Message Types | ROS2 Topic | Description | +| --------------------------- | ------------------------ | ------------------------------------------------------------------------------------- | +| `rmf_door_msgs/DoorState` | `/door_states` | State of the door published by the door node | +| `rmf_door_msgs/DoorRequest` | `/door_requests` | Direct requests subscribed by the door node and published by the door adapter | | `rmf_door_msgs/DoorRequest` | `/adapter_door_requests` | Requests to be sent to the door adapter/supervisor to request safe operation of doors | - The door adapter stands in between the rest of the RMF core systems, fleet adapters, and the door node, and acts like a state supervisor ensuring that the doors are not acting on requests that might obstruct an ongoing mobile robot task or accidentally closing on it. It keeps track of the door state from the door node, and receives requests from the `adapter_door_requests` topic which are published by either fleet adapters or other parts of the RMF core system. Only when the door adapter deems that a request is safe enough to be performed, it will instruct the door node using a request. It should also be noted that direct requests sent to the door node, without going through the door adapter will be negated by the door adapter, to return it to its prior state in order to prevent disruptions during operations with mobile robots. ## Door Adapter Template + To make the process of integrating doors with RMF even simpler, we have open-sourced a [template package](https://github.com/open-rmf/door_adapter_template) where users only need to update certain blocks of code with the API calls to their specific door controller. + +## Triggering Door Request before robot reaches the door + +There is no way to trigger a door request before a robot reaches the door by default however it can be implemented by the user by following the steps below:- + +The fleet adapter integration can track the position of the robot, and if it is detected that robot is "close enough" to a door,a DoorRequest can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but that should only take a fraction of a second if the network is decent. + +Note:- User should make sure that `requester_id` matches what the fleet adapter is for the your robot, which will be fleet_name/robot_name. Using the correct `requester_id` for the robot means that the task management system will automatically clear the DoorOpen request once the robot reaches door_out. If a different requester_id is used, then the fleet adapter integration will need to clear the request itself by sending a DoorClose request with the same `requester_id` once the robot has moved far enough away from the door. From 9ebbd417ced0935595f41f84376a3f2d6d1b5d7a Mon Sep 17 00:00:00 2001 From: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Date: Fri, 14 Oct 2022 10:28:58 +0530 Subject: [PATCH 2/7] Apply suggestions from code review Co-authored-by: Marco A. Gutierrez Signed-off-by: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Signed-off-by: Dev Manek --- src/integration_doors.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index 54928c3..8a1286a 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -28,8 +28,8 @@ To make the process of integrating doors with RMF even simpler, we have open-sou ## Triggering Door Request before robot reaches the door -There is no way to trigger a door request before a robot reaches the door by default however it can be implemented by the user by following the steps below:- +There is no way to trigger a door request before a robot reaches the door by default however it can be implemented by the user by following the steps below: -The fleet adapter integration can track the position of the robot, and if it is detected that robot is "close enough" to a door,a DoorRequest can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but that should only take a fraction of a second if the network is decent. +The fleet adapter integration can track the position of the robot, and if it is detected that robot is "close enough" to a door,a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but that should only take a fraction of a second if the network is decent. -Note:- User should make sure that `requester_id` matches what the fleet adapter is for the your robot, which will be fleet_name/robot_name. Using the correct `requester_id` for the robot means that the task management system will automatically clear the DoorOpen request once the robot reaches door_out. If a different requester_id is used, then the fleet adapter integration will need to clear the request itself by sending a DoorClose request with the same `requester_id` once the robot has moved far enough away from the door. +Note: The user should make sure that `requester_id` matches what the fleet adapter is for the your robot, which will be fleet_name/robot_name. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`. If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. From 3f3ece5b6f8bc1e7e54162577c769d42005a7895 Mon Sep 17 00:00:00 2001 From: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Date: Fri, 14 Oct 2022 12:31:02 +0530 Subject: [PATCH 3/7] Apply suggestions from code review Co-authored-by: Marco A. Gutierrez Signed-off-by: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Signed-off-by: Dev Manek --- src/integration_doors.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index 8a1286a..963a013 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -26,10 +26,10 @@ The door adapter stands in between the rest of the RMF core systems, fleet adapt To make the process of integrating doors with RMF even simpler, we have open-sourced a [template package](https://github.com/open-rmf/door_adapter_template) where users only need to update certain blocks of code with the API calls to their specific door controller. -## Triggering Door Request before robot reaches the door +## Triggering a Door Request before robot reaches the door -There is no way to trigger a door request before a robot reaches the door by default however it can be implemented by the user by following the steps below: +There is no way to trigger a door request before a robot reaches the door by default, however it can be implemented by the user by following the steps below: -The fleet adapter integration can track the position of the robot, and if it is detected that robot is "close enough" to a door,a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but that should only take a fraction of a second if the network is decent. +The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. Note: The user should make sure that `requester_id` matches what the fleet adapter is for the your robot, which will be fleet_name/robot_name. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`. If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. From 4e7140a7e276eb00de71c10be5e1b0e5d003fdb9 Mon Sep 17 00:00:00 2001 From: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Date: Fri, 14 Oct 2022 12:31:47 +0530 Subject: [PATCH 4/7] Update src/integration_doors.md Co-authored-by: Marco A. Gutierrez Signed-off-by: Dev Manek <58616961+thedevmanek@users.noreply.github.com> Signed-off-by: Dev Manek --- src/integration_doors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index 963a013..6b8bff9 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -32,4 +32,4 @@ There is no way to trigger a door request before a robot reaches the door by def The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. -Note: The user should make sure that `requester_id` matches what the fleet adapter is for the your robot, which will be fleet_name/robot_name. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`. If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. +Note: The user should make sure that `requester_id` matches what the fleet adapter is using for your robot, which will be `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`. If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. From 954e142f8723eb6c97af7341046e2d794d55b8bc Mon Sep 17 00:00:00 2001 From: Dev Manek Date: Fri, 14 Oct 2022 12:35:14 +0530 Subject: [PATCH 5/7] fixed `door_in` and `door_out` def Signed-off-by: Dev Manek --- src/integration_doors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index 6b8bff9..1371c88 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -30,6 +30,6 @@ To make the process of integrating doors with RMF even simpler, we have open-sou There is no way to trigger a door request before a robot reaches the door by default, however it can be implemented by the user by following the steps below: -The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at door_in to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. +The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at `door_in`(area near the door and inside the room) to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. -Note: The user should make sure that `requester_id` matches what the fleet adapter is using for your robot, which will be `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`. If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. +Note: The user should make sure that `requester_id` matches what the fleet adapter is using for your robot, which will be `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`(area near the door and outside the room). If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. From 5920d41218e0801ac079d519b1db00c6dd7dc6c0 Mon Sep 17 00:00:00 2001 From: Dev Manek Date: Fri, 14 Oct 2022 12:40:19 +0530 Subject: [PATCH 6/7] Clarifies the issue of `request_id` Signed-off-by: Dev Manek --- src/integration_doors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index 1371c88..f5ce7c2 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -32,4 +32,4 @@ There is no way to trigger a door request before a robot reaches the door by def The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at `door_in`(area near the door and inside the room) to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. -Note: The user should make sure that `requester_id` matches what the fleet adapter is using for your robot, which will be `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`(area near the door and outside the room). If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. +Note: The user should make sure that `requester_id` matches the id that the fleet adapter is using for your robot, that is `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`(area near the door and outside the room). If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. From 004e296c017f7a5610188feb23af9cebb7a52e53 Mon Sep 17 00:00:00 2001 From: Dev Manek Date: Fri, 14 Oct 2022 12:50:24 +0530 Subject: [PATCH 7/7] Fixes issue regarding `DoorRequest`. Signed-off-by: Dev Manek --- src/integration_doors.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/integration_doors.md b/src/integration_doors.md index f5ce7c2..b20d6b2 100644 --- a/src/integration_doors.md +++ b/src/integration_doors.md @@ -30,6 +30,6 @@ To make the process of integrating doors with RMF even simpler, we have open-sou There is no way to trigger a door request before a robot reaches the door by default, however it can be implemented by the user by following the steps below: -The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a door request can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at `door_in`(area near the door and inside the room) to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. +The fleet adapter integration can track the position of the robot. If it is detected that the robot is "close enough" to a door, a [DoorRequest.msg](https://github.com/open-rmf/rmf_internal_msgs/blob/main/rmf_door_msgs/msg/DoorRequest.msg) can be published to the `adapter_door_requests` topic. The robot will still stop for a moment at `door_in`(area near the door and inside the room) to make sure that the door is open before proceeding, but this should only take a fraction of a second if the network is decent. -Note: The user should make sure that `requester_id` matches the id that the fleet adapter is using for your robot, that is `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the `DoorOpen` request once the robot reaches `door_out`(area near the door and outside the room). If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a `DoorClose` request with the same `requester_id` once the robot has moved far enough away from the door. +Note: The user should make sure that `requester_id` matches the id that the fleet adapter is using for your robot, that is `fleet_name/robot_name`. Using the correct `requester_id` for the robot means that the task management system will automatically clear the [`DoorOpen`](https://github.com/open-rmf/rmf_ros2/blob/main/rmf_fleet_adapter/src/rmf_fleet_adapter/phases/DoorOpen.cpp) request once the robot reaches `door_out`(area near the door and outside the room). If a different `requester_id` is used, then the fleet adapter integration will need to clear the request itself by sending a [`DoorClose` ](https://github.com/open-rmf/rmf_ros2/blob/main/rmf_fleet_adapter/src/rmf_fleet_adapter/phases/DoorClose.cpp) request with the same `requester_id` once the robot has moved far enough away from the door.