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
Copy file name to clipboardExpand all lines: _docs/concepts/client_library/system_modes/index.md
+30-20Lines changed: 30 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,18 +15,20 @@ Table of contents
15
15
-[Mode Inference](#mode-inference)
16
16
-[Mode Manager](#mode-manager)
17
17
-[Roadmap](#roadmap)
18
+
-[2018](#2018)
19
+
-[2019](#2019)
20
+
-[2020](#2020)
18
21
-[Acknowledgments](#acknowledgments)
19
22
20
-
21
23
## Introduction and Goal
22
24
23
25
Modern robotic software architectures often follow a layered approach. The layer with the core algorithms for SLAM, vision-based object recognition, motion planning, etc. is often referred to as *skill layer* or *functional layer*. To perform a complex task, these skills are orchestrated by one or more upper layers named *executive layer and planning layer*. Other common names are *task and mission layer* or *deliberation layer(s)*. In the following, we used the latter term.
24
26
25
27
We observed three different but closely interwoven aspects to be handled on the deliberation layer:
26
28
27
-
1.**Task Handling**: Orchestration of the actual task, the *straight-forward*, *error-free* flow.
28
-
2.**Contingency Handling**: Handling of task-specific contingencies, e.g., expectable retries and failure attempts, obstacles, low battery.
29
-
3.**System Error Handling**: Handling of exceptions, e.g., sensor/actuator failures.
29
+
1.**Task Handling**: Orchestration of the actual task, the *straight-forward*, *error-free* flow.
30
+
2.**Contingency Handling**: Handling of task-specific contingencies, e.g., expectable retries and failure attempts, obstacles, low battery.
31
+
3.**System Error Handling**: Handling of exceptions, e.g., sensor/actuator failures.
30
32
31
33
The mechanisms being used to orchestrate the skills are service and action calls, re-parameterizations, set values, activating/deactivating of components, etc. We distinguish between *function-oriented calls* to a running skill component (set values, action queries, etc.) and *system-oriented calls* to individual or multiple components (switching between component modes, restart, shutdown, etc.).
32
34
@@ -44,18 +46,16 @@ This goal is illustrated in the following example architecture, which is describ
44
46
45
47
The main features of the approach are (detailed in the remainder):
46
48
47
-
1._Extended Lifecycle_: Extensible concept to specify the runtime states of components, i.e ROS 2 lifecycle nodes.
48
-
2._System Hierarchy and Modes_: Modeling approach for specifying a ROS system in terms of its system hierarchy and _system modes_, i.e. different (sub-)system configurations.
49
-
3._Mode Manager_: A module to manage and change the system runtime configuration.
50
-
4._Mode Inference_: A module for deriving the entire system state and mode from observable system information, i.e. states, modes, and parameters of its components.
51
-
5._Diagnostics_: Diagnosis module for deriving relevant information from the operating systems, the hardware and the functional components.
52
-
49
+
1._Extended Lifecycle_: Extensible concept to specify the runtime states of components, i.e ROS 2 lifecycle nodes.
50
+
2._System Hierarchy and Modes_: Modeling approach for specifying a ROS system in terms of its system hierarchy and _system modes_, i.e. different (sub-)system configurations.
51
+
3._Mode Manager_: A module to manage and change the system runtime configuration.
52
+
4._Mode Inference_: A module for deriving the entire system state and mode from observable system information, i.e. states, modes, and parameters of its components.
53
+
5._Diagnostics_: Diagnosis module for deriving relevant information from the operating systems, the hardware and the functional components.
53
54
54
55
## Requirements
55
56
56
57
The list of requirements is maintained in the doc folder of the micro-ROS system modes repository, at: https://github.com/micro-ROS/system_modes/blob/master/system_modes/doc/requirements.md
57
58
58
-
59
59
## Background: ROS 2 Lifecycle
60
60
61
61
Our approach is based on the ROS 2 Lifecycle. The primary goal of the ROS 2 lifecycle is to allows greater control over the state of a ROS system. It allows consistent initialization, restart and/or replacing of system parts during runtime. It provides a default lifecycle for managed ROS 2 nodes and a matching set of tools for managing lifecycle nodes.
@@ -64,7 +64,6 @@ The description of the concept can be found at: [http://design.ros2.org/articl
64
64
The implementation of the Lifecycle Node is described at:
* Specific implementation of mode manager for micro-ROS as may be necessary.
113
-
* Diagnostics framework for micro-ROS, interoperating with ROS 2 diagnostics.
114
-
* MCU-specific diagnostics functions for resource usage on RTOS layer, latencies, statistics from middleware, etc.
115
-
* Integration of mode manager with real-time executor and/or roslaunch.
116
-
* Lightweight concept for specifying error propagations between nodes and subsystems.
109
+
### 2018
117
110
118
-
_Note: The extension of the ACTIVE state by modes (substates) was originally planned for 2020 but brought forward in 2018._
111
+
- Requirements for behavior system composition in robotics systems
112
+
- Modeling concept to specify system hierarchy as well as system modes of systems, subsystems, and their mapping along the system hierarchy down to nodes
113
+
- Python prototype of system modes concept (ROS-independent)
119
114
115
+
### 2019
116
+
117
+
- Extended lifecycle concept and implementation for ROS 2 C++
118
+
- Mode inference and mode manager for ROS 2 C++
119
+
- ROS diagnostics port from ROS 1 to ROS 2
120
+
- Concept for bottom-up system modes rules
121
+
122
+
### 2020
123
+
124
+
- Diagnostics framework for micro-ROS, interoperating with ROS 2 diagnostics
125
+
- MCU-specific diagnostics functions for resource usage on RTOS layer, latencies, statistics from middleware, etc.
126
+
- Integration of mode manager with real-time executor and/or roslaunch
127
+
- Lightweight concept for specifying error propagations between nodes and subsystems
128
+
129
+
_Note: The extension of the ACTIVE state by modes (substates) was originally planned for 2020 but brought forward in 2018._
0 commit comments