Posted by @DDDWY:
Could you please tell me how to gracefully remove and add robots from RMF without restarting it? For example, I may encounter situations where robots are manually turned off or experience failures, causing them to go offline. I want to remove the offline robots from RMF and add them back when they come online again.
I have already seen the remove_robot
method in #105, but I did not find it in the latest main branch. Could you please tell me the development progress of this feature? Or is there any other way to remove and add robots? I believe this will be a very common scenario in actual operations.
Chosen answer
Answer chosen by @DDDWY at 2024-07-12T02:16:02Z.
Answered by @mxgrey:
We call this “commissioning”, and it was added in this PR: Stabilize commissioning feature by mxgrey · Pull Request #338 · open-rmf/rmf_ros2 · GitHub
The Python API for the feature can be found here, and the json schema for the web API can be found here.
Posted by @mxgrey:
We call this “commissioning”, and it was added in this PR: Stabilize commissioning feature by mxgrey · Pull Request #338 · open-rmf/rmf_ros2 · GitHub
The Python API for the feature can be found here, and the json schema for the web API can be found here.
This is the chosen answer.
Posted by @DDDWY:
Your answer explains how to handle tasks assigned to a decommissioned robot. I appreciate you informing me about this because I will certainly encounter this issue in the future. However, currently, I want to know how to decommission a robot. Let me give you an example:
When a robot is driving on a one-way path set as a mutually exclusive group and the robot malfunctions and cannot be restarted, the robot’s position report will stop at the last reported location. Upon discovering that the robot is offline, I remove the robot from the RMF map. In reality, this might involve manually detecting the robot’s fault and moving it to another location for repair. After the robot is repaired and begins normal status reporting again, I would like to add the robot back to the map without needing to restart RMF.
I have three questions:
How can I safely remove the robot from the RMF map when it goes offline?
How can I add the offline robot back to the RMF map without restarting RMF?
After the robot goes offline on the mutually exclusive path and is processed offline, you have already informed me that the related tasks will be handled safely. Will the mutually exclusive group be released?
Posted by @mxgrey:
How can I safely remove the robot from the RMF map when it goes offline?
When you decommission the robot AND cancel its ongoing task, it will automatically be removed from the traffic schedule. Its position may still get reported, but it will not trigger traffic negotiations if it is not executing any task.
How can I add the offline robot back to the RMF map without restarting RMF?
You add a decommissioned robot back into action by updating its commission parameters back to true
. There is no need to restart the adapter when doing this.
If there is any special sequence you need to run to reconnect to the robot after it powers back on, then that’s something you need to take care of in your integration code (usually written in Python using rmf_fleet_adapter_python
). That’s not something that the core RMF libraries can do for you since it’s platform-dependent.
Will the mutually exclusive group be released?
Mutex groups will not be automatically released by a decommissioning because RMF cannot know when it is safe to release it. I recommend having a UI that displays mutex groups on a dashboard with buttons to manually release them. We’re working on releasing a FOSS implementation of such a UI in https//github.com/open-rmf/rmf-web
Posted by @DDDWY:
I understand your meaning regarding the first two points now, and I really appreciate your explanation.
Regarding “Will the mutually exclusive group be released?”
Handling this on the UI is a very good idea. When can we expect this feature to be released?
Actually, the processing logic I want to implement is quite simple:
When the robot goes offline, check if it currently occupies Mutex groups.
If it does, then release the Mutex groups.
Therefore, I need two methods: one to check if the robot is occupying any Mutex groups, and another to release specified Mutex groups.
Do you think this is achievable?
Posted by @mxgrey:
Handling this on the UI is a very good idea. When can we expect this feature to be released?
The ability is already supported in the core libraries (main
branch and jazzy
release), and we’ve implemented the front end in rmf-web, we just haven’t quite reached a point where the front end has been released yet.
The PR for the feature is here: Mutex group manual release by mxgrey · Pull Request #339 · open-rmf/rmf_ros2 · GitHub
The PR indicates the topic and message to publish to do a manual release.
When the robot goes offline, check if it currently occupies Mutex groups.
If it does, then release the Mutex groups.
You’ll be able to see which mutex groups are being held by looking at the robot state which is published over websockets. Then you can iterate over those groups and publish the necessary manual release requests.
Posted by @aaronchongth:
@DDDWY you can access the mutex-release feature on the frontend on branch deploy/hammer-humble
, which supports only ROS 2 Humble at the moment.
We are in the midst of updating all our web related dependencies on both the backend and frontend, so support for Jazzy is on the way.
Posted by @DDDWY:
Thank you very much for your reply. It has been very helpful to me. Thank you.