Qna-rmf_fleet_adapter #100
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This PR seems to include some updates and the addition of fleet adapters? shouldn't that be on the fleet adapter update? Also can we have the explanation in the description with a link to the discussion that this PR solves? It makes it WAY easier to track what discussion(s) this PR solves. |
|
I will add the info and remove the fleet adapter commits |
marcoag
reviewed
Oct 14, 2022
marcoag
requested changes
Oct 14, 2022
src/integration_doors.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
Is it a message DoorRequest? then we might use the quotes and say DoorRequest message?
What is door_in? shall we use quotes? add some clarification.
There was a problem hiding this comment.
Fixed by fc6ada5
src/integration_doors.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
Clarify: ...matches what the fleet adapter is for the your robot...
There was a problem hiding this comment.
Fixed by ec37eeb
marcoag
requested changes
Oct 14, 2022
src/integration_doors.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
Suggested change
| 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. |
What is door_in ? should it be highlighted as code?
There was a problem hiding this comment.
It seems it's a way point, should be clarified and highlighted.
There was a problem hiding this comment.
Fixed by b585255
src/integration_doors.md
Outdated
|
|
||
| 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: 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. |
There was a problem hiding this comment.
Please clarify this: "is for the your robot"
There was a problem hiding this comment.
Suggested change
| 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. |
marcoag
reviewed
Oct 14, 2022
Signed-off-by: Dev Manek <[email protected]>
Co-authored-by: Marco A. Gutierrez <[email protected]> Signed-off-by: Dev Manek <[email protected]> Signed-off-by: Dev Manek <[email protected]>
Co-authored-by: Marco A. Gutierrez <[email protected]> Signed-off-by: Dev Manek <[email protected]> Signed-off-by: Dev Manek <[email protected]>
Co-authored-by: Marco A. Gutierrez <[email protected]> Signed-off-by: Dev Manek <[email protected]> Signed-off-by: Dev Manek <[email protected]>
Signed-off-by: Dev Manek <[email protected]>
Signed-off-by: Dev Manek <[email protected]>
Signed-off-by: Dev Manek <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR solves discussions on fleet_adapter. Following discussions are resolved.