rmf_task

Overview

The rmf_task repository contains two packages, rmf_task and rmf_task_sequence.

rmf_task

Provides APIs and base classes for defining and managing Tasks in RMF.

• rmf_task::Task is a pure abstract interface for an executable Task. What this task represents, how it can be modelled and finally executed are left for the user to implement. To aid such implementations, the following classes are available:
  • Active: A pure abstract interface to manage the runtime execution of a Task.
  • Booking: Stores basic information about the task.
  • Description: An abstract interface to define the specifics of a task which when implemented help differentiate different tasks from one another.
  • Model: A pure abstract interface to compute the Estimate state of the robot after the task is completed along with an invariant_duration which is the time component of the task that does not change regardless of where the robot starts.
  • Tag: Static information about the task.
• rmf_task::TaskPlanner: API which solves the problem of optimal allocation of tasks among available robots. For a given collection of tasks and robots belonging to a fleet (ie, they share physical and kinematic traits), the planner determines the best ordering of tasks across robots such that tasks are completed in the shortest durations given their requested start times. It does this while also accounting for resource constraints of the robots such as battery level and automatically injects recharging tasks in the robot’s task itinerary when needed. Here tasks are represented by Requests which are made up of Booking and Description elements respectively.

rmf_task_sequence

Provides an out-of-the-box implementation of rmf_task.

• rmf_task_sequence::Task, which assumes a task to be composed of a sequence of phases that need to be executed in-order for the task to be completed. A phase inturn may be composed of a set of Events.
• The following events that are presently available (contributions are welcome):
  • Bundle
  • DropOff
  • GoToPlace
  • PerformAction
  • PickUp
  • Placeholder
  • WaitFor
• See Usage for information on how composed tasks are integrated with the rest of Open-RMF.

Full API documentation:

• rmf_task
• rmf_task_sequence

Usage

• rmf_task_sequence contains implementations of the models for the out of the box events and phases. The implementations of how to command the actual robot to perform these events, ie, the Active components, are defined in rmf_fleet_adapter These flexible task definitions are conveyed via json payloads whose schemas are defined in rmf_api_msgs. The schemas for the “description” field are provided in rmf_fleet_adapter here. The fleet adapter currently only supports tasks that are defined as a sequence of phases as defined in rmf_task_sequence. It can very easily be extended to support other user implemented task definitions.
• Users can specify how the robot should react when a task is canceled or interrupted at any given phase. Each phase can have its own unique response and can be described here See Examples below on how to submit tasks to RMF. These tasks can either be directly assigned to a specific robot or have RMF determine the optimal allocation based on its multi-fleet task allocation framework. This is described in greater detail here

Note: When stringing together activities (same as events) in a compose task description (same as flexible task), users need to populate a category and description for each activity. The schemas for various descriptions are provided here. See event_description__X where X is the name of the event. Then, care must be taken to ensure the category is populated with this same X.

Examples

Examples of constructing and submitting custom tasks is provided in the rmf_demos repository https://github.com/open-rmf/rmf_demos/tree/main/rmf_demos_tasks

ROSCon Presentations with more information

• ROSCon2022: How custom tasks are defined, assigned, and executed in Open-RMF
  • Slides
  • Video