|
| 1 | +# Lifecycle and System Modes |
| 2 | + |
| 3 | +Table of Contents |
| 4 | +* [Introduction and goal](#introductionandgoal) |
| 5 | +* [Requirements](#requirements) |
| 6 | +* [Background: ROS 2 Lifecycle](#backgroundros2lifecycle) |
| 7 | +* [Main features](#mainfeatures) |
| 8 | + * [Extended lifecycle](#extendedlifecycle) |
| 9 | + * [System hierarchy and modes](#systemhierarchyandmodes) |
| 10 | + * [Mode manager](#modemanager) |
| 11 | +* [Roadmap](#roadmap) |
| 12 | +* [Related Work](#relatedwork) |
| 13 | +* [Acknowledgments](#acknowledgments) |
| 14 | + |
| 15 | +TODO CHECK FUNCTIONING OF THE LINKS ABOVE (AND THE GENERATED IDS FOR THE SECTION HEADERS). |
| 16 | + |
| 17 | +## Introduction and Goal |
| 18 | + |
| 19 | +Modern robotic software architectures 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 layer and mission layer* or *deliberation layer(s)*. In the following, we used the last term. |
| 20 | + |
| 21 | +We observed three different but closely interwoven aspects to be handled on the deliberation layer: |
| 22 | + |
| 23 | +1. **Task Handling**: Orchestration of the actual task, the *straight-forward*, *error-free* flow |
| 24 | +2. **Contingency Handling**: Handling of task-specific contingencies, e.g., expectable retries and failure attempts, obstacles, low battery. |
| 25 | +3. **System Error Handling**: Handling of exceptions, e.g., sensor/actuator failures. |
| 26 | + |
| 27 | +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 (e.g., set values, action queries) and *system-oriented calls* to individual or multiple components (e.g., switching between component modes, restart, shutdown). |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +Analogously, we distinguish between *function-oriented notifications* from the skill layer in form a feedback on long-running service calls, messages on relevant events in the environment, etc. and *system-oriented notifications* about component failures, hardware errors, etc. |
| 32 | + |
| 33 | +Our observation is that interweaving of task, contingency and system error handling generally leads to a high complexity of the control flow on the deliberation layer. Yet, we hypothesize that this complexity can be reduced by introducing abstractions for system-oriented calls and notifications. |
| 34 | + |
| 35 | +Therefore, our **goal** within this work is to provide suitable abstractions and framework functions for (1.) system runtime configuration and (2.) system error and contingency diagnosis, to reduce the effort for the application developer of designing and implementing the task, contingency and error handling. |
| 36 | + |
| 37 | +This goal is illustrated in the following high-level architecture: |
| 38 | + |
| 39 | + |
| 40 | + |
| 41 | +The envisioned key elements to achieve this goal are: |
| 42 | + |
| 43 | +1. Extensible concept to specify the runtime states of components (i.e ROS nodes). |
| 44 | +2. Modeling approach for specifying system modes based on these component states. |
| 45 | +3. Diagnosis module for deriving relevant information from the operating systems, the hardware and the functional components. |
| 46 | +4. Mode manager module for system runtime configuration. |
| 47 | + |
| 48 | + |
| 49 | +## Requirements |
| 50 | + |
| 51 | +The list of requirements is maintained in the doc folder of the micro-ROS system modes repository at **TODO INSERT LINK**. |
| 52 | + |
| 53 | + |
| 54 | +## Background: ROS 2 Lifecycle |
| 55 | + |
| 56 | +Our approach is based on the ROS 2 Lifecycle. The primary goal of the ROS 2 lifecycle is TODO INSERT TEXT. |
| 57 | + |
| 58 | +The description of the concept can be found at [http://design.ros2.org/articles/node_lifecycle.html](http://design.ros2.org/articles/node_lifecycle.html). The implementation is described at [https://index.ros.org/doc/ros2/Managed-Nodes/](https://index.ros.org/doc/ros2/Managed-Nodes/). |
| 59 | + |
| 60 | + |
| 61 | + |
| 62 | +## Main Features |
| 63 | + |
| 64 | +### Extended Lifecycle |
| 65 | + |
| 66 | +In micro-ROS, we extended the ROS 2 lifecycle by allowing to specify specific modes (i.e. substates) for the ACTIVE state based on the standard parameters mechanism. We implemented this concept in rcl and rclcpp for ROS 2 and micro-ROS. |
| 67 | + |
| 68 | +The documentation and code can be found at TODO INSERT LINK. |
| 69 | + |
| 70 | + |
| 71 | +### System Hierarchy and Modes |
| 72 | + |
| 73 | +We provide a modeling concept for specifying the hierarchical composition of systems recursively from nodes and for specifying the states and modes of systems and subsystems with the extended lifecycle, analogously to nodes. This system hierarchy and modes model also includes an application-specific the mapping of the states and modes along the system hierarchy down to nodes. |
| 74 | + |
| 75 | +The description of this model can be found at TODO INSERT LINK. |
| 76 | + |
| 77 | + |
| 78 | +### Mode manager |
| 79 | + |
| 80 | +The mode manager allows for runtime system adaptation based on such a system hierarchy and modes model. It parses the model and provides all services and topics to request state and mode changes and to monitor these changes. |
| 81 | + |
| 82 | +The documentation and code can be found at TODO INSERT LINK. A small demo is provided at TODO INSERT LINK. |
| 83 | + |
| 84 | + |
| 85 | +## Roadmap |
| 86 | + |
| 87 | +**2018** |
| 88 | +* Designed extended lifecycle concept and implemented this concept in rcl and rclcpp for ROS 2 and micro-ROS. |
| 89 | +* Designed modeling concept to specify system hierarchy as well as to model states and modes of system and subsystems and their mapping along the system hierarchy down to nodes. |
| 90 | +* Implemented mode manager in C++ for ROS 2. |
| 91 | + |
| 92 | +**2019** |
| 93 | +* Specific implementation of mode manager for micro-ROS as may be necessary. |
| 94 | +* Diagnostics framework for micro-ROS, interoperating with ROS 2 diagnostics. |
| 95 | +* MCU-specific diagnostics functions for resource usage on RTOS layer, latencies, statistics from middleware, ... |
| 96 | +* Integration of mode manager with real-time executor. |
| 97 | + |
| 98 | +**2020** |
| 99 | +* Lightweight concept for specifying error propagations between nodes and subsystems. |
| 100 | + |
| 101 | +_Note: The extension of the ACTIVE state by modes (substates) was originally planned for 2020 but brought forward in 2018._ |
| 102 | + |
| 103 | + |
| 104 | +## Related Work |
| 105 | + |
| 106 | +In this section, we provide an overview to related approaches and link to the corresponding APIs. |
| 107 | + |
| 108 | +### AADL |
| 109 | + |
| 110 | +INSERT SOME WORDS ON AADL AND LINK DOCUMENTATION - OR REMOVE THIS SECTION. |
| 111 | + |
| 112 | + |
| 113 | +## Acknowledgments |
| 114 | + |
| 115 | +This activity has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant agreement n° 780785). |
0 commit comments