# Interrupting the separation of the rmf core process for a period of time in a spread of the RMF robot system. (#504)

**URL:** <https://discourse.openrobotics.org/t/interrupting-the-separation-of-the-rmf-core-process-for-a-period-of-time-in-a-spread-of-the-rmf-robot-system-504/44685>\
**Category:** Open-RMF General\
**Tags:** rmf-github-discuss\
**Created:** [July 24, 2024, 7:29am UTC](https://discourse.openrobotics.org/t/interrupting-the-separation-of-the-rmf-core-process-for-a-period-of-time-in-a-spread-of-the-rmf-robot-system-504/44685 "2024-07-24T07:29:17Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [July 24, 2024, 7:29am UTC](https://discourse.openrobotics.org/t/interrupting-the-separation-of-the-rmf-core-process-for-a-period-of-time-in-a-spread-of-the-rmf-robot-system-504/44685/1 "2024-07-24T07:29:17Z")

</div>

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](https://github.com/open-rmf/rmf_demos/blob/main/rmf_demos_tasks/rmf_demos_tasks/dispatch_go_to_place.py)’. 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](https://github.com/open-rmf/rmf_ros2/blob/main/rmf_fleet_adapter/src/rmf_fleet_adapter/agv/RobotUpdateHandle.cpp#L321) function should be activated in order to activate this situation.

1. Is it right to change the status message in [this](https://github.com/open-rmf/rmf_ros2/blob/main/rmf_fleet_adapter/src/rmf_fleet_adapter/agv/RobotUpdateHandle.cpp#L321) 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](https://github.com/open-rmf/rmf_api_msgs/tree/main) package.
2. 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

---

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [July 25, 2024, 4:36am UTC](https://discourse.openrobotics.org/t/interrupting-the-separation-of-the-rmf-core-process-for-a-period-of-time-in-a-spread-of-the-rmf-robot-system-504/44685/2 "2024-07-25T04:36:31Z")

</div>

Posted by @aaronchongth:

Hi @Otobot42, I assume this is related to the discussion [https://github.com/open-rmf/rmf/discussions/503](https://github.com/open-rmf/rmf/discussions/503).

`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 [https://github.com/open-rmf/rmf/discussions/503](https://github.com/open-rmf/rmf/discussions/503), 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](https://github.com/open-rmf/rmf_ros2/commit/3665c79d0dca9ff6352f490db1117e733c32642c). And submitting a task that looks like [gist:d8bf7ba0d0cc6692f65f2cc11a03ce7b · GitHub](https://gist.github.com/aaronchongth/d8bf7ba0d0cc6692f65f2cc11a03ce7b), 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](https://github.com/open-rmf/rmf_ros2/pull/338), 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](https://github.com/open-rmf/rmf-web/blob/034400e8d890528c5218903bac15e65f4ac442aa/packages/api-server/api_server/routes/fleets.py#L79-L182). This is however a very roundabout way to implement what your team is trying to achieve.

As mentioned in [https://github.com/open-rmf/rmf/discussions/503](https://github.com/open-rmf/rmf/discussions/503), the best and correct solution would be to implement a fleet adapter using the `EasyFullControl` API with the navigation stacks required.