ROS 2 Task Manager

Task Manager ROS 2 package is a solution to start, handle and track tasks from multiple different sources in a centralized way on a single robot. If you want to:

• have an easy way to start new tasks from any local or web source: UI, voice control, command line, etc.
• track all the currently active tasks and their end results on your robot,
• automatically cancel the previous task if a new conflicting one is given,
• combine multiple smaller tasks into a Mission,
• implement custom behavior for example on task start and end,

Task Manager is your solution!

Features

1. Tasks
2. Active tasks
3. Result tracking
4. Missions
5. Task Cancelling
6. Global STOP-task
7. Wait task

Tasks

Any existing ROS 2 service or action can be declared as a “Task” in a parameter file. In addition to default service and action features, tasks have the following properties:

• Blocking tasks: Any task can be marked as a blocking task. Only a single blocking task can be active at a time in the whole system, and if another blocking task request is received, Task Manager will cancel the previous blocking task automatically. For example, tasks navigate_to_pose and change_map should never be active at the same time.
• Cancel-on-stop: Tasks can be cancelled automatically when the global “STOP” task is called.
• Single-goal or reentrant execution: Task can be executed in two different modes:
  • Single-goal behavior (default): Only one task of the same type can be active at once, and a new task request of same type will cancel the previous one.
  • Reentrant: Task runs in parallel with any new coming requests for the same task.
• Cancel reported as success: For some continuous tasks, such as record_video, user might want to stop the task execution by cancelling it but still report the end status as DONE.

For each task request, there are two useful fields:

• Task ID: Unique identifier for the task. Auto-generated if left empty.
• Task Source: The source of the task. For example “CLOUD”, “Voice control”, “CLI”.

To start a task, send a goal to the action server /task_manager/execute_task. For example

ros2 action send_goal /task_manager/execute_task task_manager_msgs/action/ExecuteTask '{task_name: system/cancel_task, source: CLI, task_data: "{\"cancelled_tasks\": [\"example_task_id\"]}"}'

Note that the task_data is the json-formatted version of the action or service message interface.

Tasks provide their end status with the task_status field in the result using TaskStatus enumeration.

Active tasks list

It is possible to track all the currently active tasks that have their status as IN_PROGRESS by subscribing to /task_manager/active_tasks topic. The task’s end status is also published to this topic just before the task is removed from the list.

Active tasks list can be useful for example to:

• display all the currently active tasks on the robot in the UI,
• track task starts and ends to execute some custom logic, for example to record rosbags automatically during tasks or to display visual and sound effects on the robot.

An example of published active tasks

Result tracking

Results for all the tasks are published to /task_manager/results topic. This makes it very easy to send the results forward for example to the Cloud or UI, no matter where the task was started from. Task results are always json-formatted.

Note that the task’s result can be an empty json "{}" if there was an error during task parsing.

An example of published task result

Missions

Task Manager provides a way to combine multiple tasks into a larger Mission. This can be useful when implementing features such as Photo Documentation, which combines multiple smaller navigation and take_photo tasks.

• Mission is just another task that will be active in addition to its subtasks.
• All the subtasks will execute as independent tasks: Their results are published in the same way to /task_manager/results as for normal tasks.
• Mission reports all the subtask statuses in the mission result. Subtask results are not published here.
• If any of these subtasks encounter a failure, the entire mission is deemed unsuccessful. Furthermore, a subtask can be designated as skippable by setting the allow_skipping field, enabling it to be bypassed in case of execution failure.

Mission can be started by calling system/mission task.

Example UI implementation for displaying a Mission that consists of "Navigation" and "Take Photo" tasks.

Task Cancelling

Tasks can be cancelled by calling a system/cancel_tasks task with the Task IDs that should be cancelled. This provides an easy way to cancel any executing task, no matter which ROS Node started it.

Tasks that are implemented using ROS Services cannot be cancelled due to their nature. Trying to cancel such a task will make Task Manager wait for a predefined time for the task to finish and return an ERROR status if it doesn’t.

Global STOP-task

Task manager provides a system/stop task, which can be called to stop all the active tasks that have their parameter cancel_on_stop set to True.

Wait task

The system/wait task is a blocking task which waits for a given time (duration > 0.0) or until it is cancelled (duration <= 0.0).

Examples

Examples and their run instructions can be found in examples folder for:

• Task execution, tracking and Missions

File truncated at 100 lines see the full file