Qna-rmf_fleet_adapter

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 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:
+
+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`](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.