This performable action enables robots to travel to multiple waypoints and wait there within a single task. The expected task behavior would be:
Robot goes to a waypoint and waits for X seconds (configurable)
If the robot receives a move-off signal (configurable), it will end the waiting action and move to the next waypoint
Robot repeats Steps 1. and 2. with subsequent waypoints on a list until it has travelled to all the waypoints in the task.
During the waiting process, the robot may only move off if the default timeout has been reached, or if it receives a move-off signal. This move-off signal can be configured by the user depending on the user case. The plugin provides 2 out-of-the-box move-off signals as well as the option for users to customize their own.
mission: The waiting action would be mission-based, i.e. the fleet adapter would trigger a MiR mission specified in the config when the robot starts waiting, and end the waiting action when the mission is completed.
plc: The waiting action would begin and the fleet adapter monitors the state of the specified PLC register. Once it turns to 1 or True, the waiting action ends.
custom: Users can customize their own move-off signal by writing their own MoveOff module and provide it to the fleet config. A skeleton of the module and a sample implementation of customizing a move-off signal using RMF Alert.msg is provided in rmf_move_off.py and rmf_move_off_on_alert.py respectively.
For cases where users might want the move-off signal to vary from task to task within the same fleet, they may provide the move-off behavior in their task description instead of the fleet config. Any move-off signal config provided in a task description will override the default fleet behavior imported from the fleet config.
Note: still a WIP, and the base branch will be updated after the previous PR gets merged.
This PR provides a
wait_untilPerformAction plugin for the MiR fleet adapter. It depends on and follows https://github.com/open-rmf/fleet_adapter_mir/pull/36.This performable action enables robots to travel to multiple waypoints and wait there within a single task. The expected task behavior would be:
During the waiting process, the robot may only move off if the default timeout has been reached, or if it receives a move-off signal. This move-off signal can be configured by the user depending on the user case. The plugin provides 2 out-of-the-box move-off signals as well as the option for users to customize their own.
mission: The waiting action would be mission-based, i.e. the fleet adapter would trigger a MiR mission specified in the config when the robot starts waiting, and end the waiting action when the mission is completed.plc: The waiting action would begin and the fleet adapter monitors the state of the specified PLC register. Once it turns to1orTrue, the waiting action ends.custom: Users can customize their own move-off signal by writing their ownMoveOffmodule and provide it to the fleet config. A skeleton of the module and a sample implementation of customizing a move-off signal using RMFAlert.msgis provided inrmf_move_off.pyandrmf_move_off_on_alert.pyrespectively.For cases where users might want the move-off signal to vary from task to task within the same fleet, they may provide the move-off behavior in their task description instead of the fleet config. Any move-off signal config provided in a task description will override the default fleet behavior imported from the fleet config.
Note: still a WIP, and the base branch will be updated after the previous PR gets merged.