ROS 2 System Modes

The system modes concept assumes that a robotics system is built from components with a lifecycle. It adds a notion of (sub-)systems, hiararchically grouping these nodes, as well as a notion of modes that determine the configuration of these nodes and (sub-)systems in terms of their parameter values.

A list of (current and future) requirements for system modes can be found here: requirements.

General information about this repository, including legal information, project context, build instructions and known issues/limitations, are given in README.md in the repository root.

System Modes Package

The system modes concept is implemented as a package for ROS 2. This package provides a library for system mode inference, a mode manager, and a mode monitor.

System Modes Library

The library consists of the parser of the system modes model and the mode inference mechanism.

Hierarchal System Modeling

We assume the system to comprise of loosely-coupled - potentially distributed - components with a runtime lifecycle; hereinafter referred to as ‘nodes’. We call semantic grouping of these nodes a (sub-)system. We assume that these (sub-)systems can again be hierarchically grouped into further (sub-)systems, see system-of-systems. All nodes and (sub-)systems that belong to a certain (sub-)system are referred to as parts of this (sub-)system.

The introduced notion of (sub-)systems does not refer to a concrete software entity, but rather a virtual abstraction that allows efficient and consistent handling of node groups.

Note: In a first stage of this concept, we assume that the entire system can be specified up-front. Later revisions of this concept might have to take care of changing systems, i.e. further nodes and/or (sub-)systems joining at runtime.

Lifecycle

Within this package, we assume that nodes are ROS 2 Lifecycle Nodes. We extend the ROS 2 default lifecycle by the following aspects:

1. We introduce modes that are specializations of the ACTIVE state, see System Modes.
2. We introduce an optional transition from ACTIVE to activating to allow changing modes without deactivating the node.

We additionally establish the same lifecycle for the (sub-)systems introduced above. Hence, all parts of a system can be assumed to have the same lifecycle.

System Modes

System modes extend the ACTIVE state of the ROS 2 lifecycle and allow to specify different configurations of nodes and (sub-)systems:

• Modes of nodes consist of parameter values.
• Modes of (sub-)system) consist of modes of their parts.

For example, a node representing an actuator might provide different modes that specify certain maximum speed or maximum torque values. An actuation sub-system, grouping several actuator nodes, might provide modes that activate/deactivate certain contained actuator nodes and/or change their modes based on its own modes.

Both, the system hierarchy as well as the system modes are specified in a system modes and hierarchy model file (SHM file, yaml format) that can be parsed by the mode inference mechanism. The SMH file adheres to the following format (curly brackets indicate placeholders, square brackets indicate optional parts, ellipses indicate repeatability):

{system}:
  ros__parameters:
    type: system
    parts:
      {node}
      […]
    modes:
      __DEFAULT__:
        {node}: {state}[.{MODE}]
        […]
      {MODE}:
        {node}: {state}[.{MODE}]
        […]
      […]
[…]

{node}:
  ros__parameters:
    type: node
    modes:
      __DEFAULT__:
        ros__parameters:
          {parameter}: {value}
          […]
      {MODE}:
        ros__parameters:
          {parameter}: {value}
          […]
      […]
[…]

The system_modes_examples package shows a simple example consisting of modes for one system and two nodes. The model file of the example can be found here.

Mode Inference

Since the introduced (sub-)systems are not concrete software entities, their state and mode has to be inferred from the states and modes of their parts. This inference mechanism is part of the system modes library and is used by the mode manager and mode monitor that are also included in this package. We can show that system states and modes can be deterministically inferred under the following conditions:

1. Nodes can be asked for their state, mode, and parameters This is true, since the lifecycle nodes provide the according lifecycle state service (GetState) and the mode manager provides the according mode service (GetMode).
2. Target states and modes are known Before attempting a state or mode change for a system or node, the mode manager publishes information about the request. The according topics might need to be latched in order to allow nodes to do the inference after joining a running system.

Mode Observer

Additionally, the library comprises a Mode Observer that serves as a local cache of states and modes of all observed system parts. The mode observer will try to obtain the current state and mode initially via sevrice calls (GetState, GetMode) and subsequently monitors according transitions events and mode events.

The mode observer is supposed to be instantiated within a ROS 2 node to have states and modes available locally for fast access, see this exemplary ModeObserverNode used for testing.

Mode Manager

The mode manager is a ROS node that accepts an SHM file (see above) as command line parameter. It parses the SHM file and creates the according services, publishers, and subscribers to manage the system and its modes.

File truncated at 100 lines see the full file

Changelog for package system_modes_examples

0.9.0 (2020-07-21)

• More flexibility in specifying the default mode, any mode can be now default mode https://github.com/micro-ROS/system_modes/issues/69

0.8.0 (2020-04-22)

• Launch integration, i.e. launch actions, events, and event handlers for system modes

0.7.1 (2020-04-22)

• Improved metadata for ROS 2 package releases

0.7.0 (2020-04-22)

• Launch tests now using launch_ros node action https://github.com/micro-ROS/system_modes/pull/72
• Introduced separate interface package, system_modes_msgs https://github.com/micro-ROS/system_modes/pull/74

0.6.0 (2020-03-16)

• Introduced mode observer https://github.com/micro-ROS/system_modes/issues/59
• Mode manager prevents redundant mode changes https://github.com/micro-ROS/system_modes/pull/67
• Minor bugfix in inference

0.5.0 (2020-03-16)

• Atomic parameter setting https://github.com/micro-ROS/system_modes/issues/59
• Bug fixing
• More tests

0.4.2 (2020-12-17)

• Error handling and rules feature no longer experimental
• Fixed bugs in monitor and tests

0.4.1 (2020-10-29)

• Include experimental error handling and rules feature
• https://github.com/micro-ROS/system_modes/issues/13
• CI for ubuntu 20.04 ROS 2 rolling

0.4.0 (2020-09-30)

• publish inferred state and mode transitions
• https://github.com/micro-ROS/system_modes/issues/42

0.3.0 (2020-07-23)

• removed boost dependencies (was: program options)
• changed mode service specifications (less redundancy)
• https://github.com/micro-ROS/system_modes/issues/24

0.2.3 (2020-07-23)

• improved StateAndMode struct
• testing

0.2.2 (2020-07-13)

• introduced StateAndMode struct to bundle lifecycle state and system mode

0.2.0 (2020-02-13)

• integration with ROS 2 launch
• updated docs

0.1.6 (2019-10-31)

• fixed QoS configuration for parameter event subscribers

0.1.5 (2019-10-21

• migration to ROS 2 eloquent elusor

0.1.2 (2019-03-18)

• fixed dependencies in package.xml

0.1.1 (2019-03-08)

• first public release for ROS 2 system modes