Gracefully add and remove robots.

[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.

[mxgrey]

We call this "commissioning", and it was added in this PR: open-rmf/rmf_ros2#338

The Python API for the feature can be found here, and the json schema for the web API can be found here.

[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

[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?

[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: open-rmf/rmf_ros2#339

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.

[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.

[DDDWY]

Thank you very much for your reply. It has been very helpful to me. Thank you.