You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should allow users to cancel tasks that have already been started.
Each Phase type already implements a cancel behavior, but there may be Task types whose state changes while completing phases, and that may complicate what it means to "cancel" the task. For example, what should be the behavior of canceling a Delivery Task after the robot has already picked up the item to deliver it? Should the robot return the item to its pickup location? Should the robot just finish the delivery? Should the robot bring it to some other discarding location?
Implementation considerations
To achieve robust cancellation behavior, we should have a way for the Task instance to generate new cancellation phases based on the current phase of the task. There are many ways this could be implemented, but the API that I would recommend is to change Task::cancel() to return a std::shared_ptr<Task> which contains a new Task instance that describes the steps a robot must complete to safely cancel its current task. If no steps are needed, then this could simply return a nullptr. When the return value is not null, then the returned task becomes the new active task of the robot.
The text was updated successfully, but these errors were encountered:
* support apis for task dispatcher
* append rmf_adapter.battery
* fix def_property for battery
* add dispatcher node to expand test scrips
* create a simple example for dispatcher node
* make loop and delivery test scripts work, compatible to task dispatcher
* fix test_adpater link in setup.py
* fix link on examples, update bindings according to feedbacks
* update rmf_battery bindings
* restructure pkg and clean setup.py
* fix typo
* update graph wp bind: is charger
Feature request
Cancel tasks that are already being performed.
Description
We should allow users to cancel tasks that have already been started.
Each
Phase
type already implements acancel
behavior, but there may beTask
types whose state changes while completing phases, and that may complicate what it means to "cancel" the task. For example, what should be the behavior of canceling a Delivery Task after the robot has already picked up the item to deliver it? Should the robot return the item to its pickup location? Should the robot just finish the delivery? Should the robot bring it to some other discarding location?Implementation considerations
To achieve robust cancellation behavior, we should have a way for the
Task
instance to generate new cancellation phases based on the current phase of the task. There are many ways this could be implemented, but the API that I would recommend is to changeTask::cancel()
to return astd::shared_ptr<Task>
which contains a newTask
instance that describes the steps a robot must complete to safely cancel its current task. If no steps are needed, then this could simply return a nullptr. When the return value is not null, then the returned task becomes the new active task of the robot.The text was updated successfully, but these errors were encountered: