Posted by @Otobot42:
Hello,
There is a robot that I use in the RMF system. I have a few questions about turning off and on again for a certain period of time the control of the robot in question from the RMF system.
I send this robot to point ‘A’ with the task message ‘dispatch_go_to_place’. Here, the system, that is, the rmf_core structure, must be closed, the robot must not be included in the system, and after a certain period of time (for example, 30 seconds), it must be active and ready again. I did different research on this subject. I know that the robot’s status information can be changed by changing the ModeRequest data. As a thought, I think that this function should be activated in order to activate this situation.
- Is it right to change the status message in this way for the RMF system, which actively changes the robot status for certain periods of time?
1.1) If this system is correct, how can I make this function wait for a certain period of time (for example 30s) and activate it again using the rmf_api package.
- Are my thoughts mentioned above correct? If it is not correct, how should I proceed?
Purpose: A device (robot) goes to point A, waits for a certain time and goes to point B. When it reaches point A, the RMF system must shut down. The reason for this is to prevent it from being called from another point (for example, point K) while the tasks specific to that robot are continuing.
Thank you for your answers.
Edited by @Otobot42 at 2024-07-24T07:32:04Z
Posted by @aaronchongth:
Hi @Otobot42, I assume this is related to the discussion Waiting time between two stations for the delivery robot · open-rmf/rmf · Discussion #503 · GitHub.
RobotUpdateHandle::override_status will only override the status reported on the robot state message, it will have no effect on the robot’s action or RMF. Once the RobotUpdateHandle::override_status is called again with a nullopt, the status in the robot state message will resume what it is meant to be. For example, if a robot loses wifi connection, it is then unable to continue updating RMF it’s status, however the fleet adapter can be written such that if it doesn’t hear back from the robot for an extended period of time, RobotUpdateHandle::override_status("offline") can be performed and other systems in RMF will be able to know that this robot has gone offline. This will however not affect how RMF will attempt to interact with the robot.
As mentioned in Waiting time between two stations for the delivery robot · open-rmf/rmf · Discussion #503 · GitHub, we have recently added the wait_until action upstream. This is not propagated to the legacy full control fleet adapter for legacy reasons, but you can try it out with this change Adding for testing · open-rmf/rmf_ros2@3665c79 · GitHub. And submitting a task that looks like gist:d8bf7ba0d0cc6692f65f2cc11a03ce7b · GitHub, swapping out the locations with the name of the waypoints you want, and the timeout in seconds. This compose task json is made up of a go-to, a wait_until, and a go-to. Our simulations have been updated to use rmf_demos_fleet_adapter instead of the full control fleet adapter therefore I am unable to test it, but please give it a go.
Another possible workaround (not advised) would be to decommission the robot Stabilize commissioning feature by mxgrey · Pull Request #338 · open-rmf/rmf_ros2 · GitHub, after it has reached point A. This feature will ensure that no new tasks are assigned to the robot, until it is commissioned again. This is done via API calls over the task_api_requests and task_api_responses ROS 2 topics, you can reference how we are doing it on rmf-web, rmf-web/packages/api-server/api_server/routes/fleets.py at 034400e8d890528c5218903bac15e65f4ac442aa · open-rmf/rmf-web · GitHub. This is however a very roundabout way to implement what your team is trying to achieve.
As mentioned in Waiting time between two stations for the delivery robot · open-rmf/rmf · Discussion #503 · GitHub, the best and correct solution would be to implement a fleet adapter using the EasyFullControl API with the navigation stacks required.