Open sourcing ROS 2 Task Manager package

Introduction

We are proud to announce the open-sourcing of our Task Manager ROS 2 package, a centralized solution designed to initiate, monitor, and manage tasks on a single robot. By making this package publicly available, we aim to assist the robotics community in addressing current challenges related to robot task management.

Task Manager’s journey began in 2020 when we embarked on the development of Karelics Cloud, our Fleet Management platform. A crucial aspect of this endeavor was the need to execute user-defined tasks and automated system tasks on robots. This required us to find solutions to various key problems:

1. How to implement tasks?
2. In what format should Karelics Cloud make requests to start tasks on the robots?
3. How to start these tasks easily also from any external source, such as voice control, command line or joystick inputs?
4. How to handle task conflicts, such as when one user requests to change the map from the UI just after another user has started a navigation task using a voice command on the same robot?
5. How to track all the currently active tasks?
6. How to send task results to Cloud also from the tasks that were started from external sources?
7. How to combine multiple smaller tasks into bigger missions?

Through numerous iterations, we have refined our solution, culminating in the Task Manager package, now a core component of our Karelics Brain software stack deployed across various robot models like Leo Rover and Spot.

So, how does Task Manager address these aforementioned challenges?

Tasks

Task Manager leverages existing ROS 2 actions and services to implement tasks. With a simple configuration file, these actions and services can be utilized as tasks. In addition to standard action and service features, tasks offer the following functionalities:

• Task information, including a unique ID and the source of initiation.
• Trackability and monitoring from any ROS Node.
• Automatic cancellation of conflicting tasks.
• Capability to compose tasks into larger missions.

Task Manager provides an execute_task action to start new tasks, taking a task ID, task name, task source and json-formatted task data as an input. All task calls happen through this action, abstracting the underlying task implementation details from the client side. Consequently, clients like Karelics Cloud or voice control systems do not need to distinguish between service or action implementations. This simplifies client-side logic, requiring only a single action client for task invocation.

Task data and results are provided in JSON format, as we need to support multiple action and service message formats through a single action topic. JSON is also commonly used in web and cloud interfaces, where data is transmitted to the robot, typically through protocols like MQTT. Utilizing JSON allows us to pass this data directly to the Task Manager without needing to convert it back and forth from a ROS message format.

Conflicting tasks

A traditional approach is to handle any conflicting tasks on the UI / Cloud side. For example, users would be blocked from being able to run a “change map” -task, while a navigation task is running. However, since we wanted to be able to launch tasks from multiple different sources even when offline, this kind of online-based task management was not an option for us.

Task Manager implements task conflict resolution locally by introducing a “blocking” task property, configurable during setup. Only one blocking task can be active at a time system-wide. Upon receiving a request for a new blocking task, Task Manager automatically cancels the previous one. Additionally, by default, only one task of the same type can be active concurrently. For example, giving a second navigation task would cancel the already running one. This behavior is often implemented on the action server side, but having this logic built into Task Manager eliminates the need to reimplement it in every action server. Also, this way the task’s end status on task cancellation is correctly marked as CANCELED, instead of ABORTED.

Task results and active tasks

It is important for us to see all the currently active tasks and their results in the Cloud, even if they are started locally on the robot using command line or voice commands. By centralizing task initiation through Task Manager, it can easily monitor all the active tasks and their results and publish them into separate topics.

Missions

One approach we previously considered was defining missions on the Cloud side and then sending subtasks individually to a robot. While this method is commonly used, our specific use cases at construction sites often involve areas where the robot may not always have a stable network connection. Therefore, it is crucial that the robot can receive and execute a full mission, even if it goes offline during the execution.

Task Manager offers a “system/mission” task, which accepts a list of subtasks as input. If any of these subtasks fail, the entire mission is considered to have failed. Additionally, the system allows for skipping certain subtasks if there are failures during execution.

Nav2 example

The best way to demonstrate Task Manager features is by an example. The Task Manager repository provides examples with Nav2.

Two example tasks, “navigate_to_pose” and “spin”, are declared using a parameter file, leveraging existing Nav2 action servers

Task Manager parameters for Nav2. Note that both of the tasks are marked as “blocking”, meaning that starting either one of them while another one is still running cancels the running task.

Task Manager parameters for Nav2. Note that both of the tasks are marked as “blocking”, meaning that starting either one of them while another one is still running cancels the running task.

We have created an example Python script showing example executions of these tasks. First a normal navigation task is initiated. After 5 seconds, a spin task is started, automatically canceling the first navigation task. After some time, once the spin task has finished, we start a Mission which combines 4 navigation tasks and spin tasks in between them.

Task and Mission setup.

Turtlebot 3 Waffle running the Task Manager and Nav2 examples:

Active tasks and task results can be tracked from ROS topics:

Next steps

As part of our upcoming implementation steps, we aim to incorporate several new features into Task Manager. These include the ability to schedule tasks, pause and resume them, provide action feedback, and include timestamps for task start and end times. We are eager to gather feedback from the community to enhance Task Manager further. Your input is highly valued and greatly appreciated!

Lastly, we would like to express our gratitude for everyone who has been part of designing, implementing, testing and maintaining Task Manager over the years. Without you this work would not have been possible!