Overview 3: Resource Management
Resource managers fill in the gap between the tasks and components by implementing the process of allocating and deallocating a specific component (i.e., a resource). Because a resource can be requested by multiple actions and could be dynamically combined from multiple sub-resources, an accounting and error propagation system, Resource Registrar (RR), is used inside every resource manager and its interface.
"What is a resource?"
A resource can be anything that is needed to perform a task. All components, e.g., cameras, LIDARs, manipulators, data processing algorithms, can be viewed as resources. A resource can be composed of subresources. For example, a whole robot can be a single resource, composed of aforementioned components as sub-resources.
"What does the management imply?"
In short, managing means starting and stopping resources whenever necessary. Such management also involves "bookkeeping" to have an overview of how many consumers are using the resource and/or which sub-resurces the resource is consuming itself.
"Why manage the resources?"
There are two reasons for that: energy/computation conservation and adaptability (video demo). First, deployed robots are constrained by their computational and energy capacity. The less power they consume, the longer they go, the less idling processes they have, the more CPU and memory is available. Thus, instead of having all components initialized, especially all sensors, while only a portion of them is used at a time is unsurprisingly wasteful. Initialize and use them when actually required.
The second aspect is adaptability. The robot could be upgraded while deployed (new data processing resources added, etc.) or some parts of it may break down. In order to adapt to new conditions the robot must be reconfigured, and yes, that means starting and stopping resources.
"What tools can I use right now?"
From resource management's perspective, TeMoto comes out-of-the-box with:
Process Manager: A ROS node, which can dynamically invoke programs, including ROS executables, ROS launch files and regular executables. Running programs are then monitored for process failures (via segmentation faults, unexpected shutdowns, etc), which are reported to the consumers of the failed resource.
Component Manager: A ROS node, which maintains information about components (including published/subscribed topics, package names) and can dynamically compose them based on component templates. Components are ROS based programs (nodes/launch files) which provide sensing or data processing functionalities. A component template outlines the structure of a composed component, e.g., a combination of a manipulator arm and a force-torque sensor with compliance controller. Templates can then be used to dynamically combine individual components and replace faulty ones.
Visualization Manager: Visualization Manager uses RViz as the main platform for visualization, where each displayable data type is displayed via dynamically loadable RViz plugins. Thus data can be visualized programmatically on demand.
Context Manager: Context Manager maintains a model of the world as hierarchical relations between maps and world objects in a tree structure. The world model is shared with other robots (other instances of Context Manager) via RIS, allowing to build and utilize a common world model in collaborative tasks.
Consider a scenario (Fig. 1) where a user-defined action requests a resource (filtered camera image) composed of multiple sub-resources: a camera and filter algorithm. In this example, two resource managers are implemented: the Component Manager and the Processs Manager. The former maintains the knowledge about sensors, algorithms, etc., and their combinations. The latter can start, stop, and monitor OS processes on request. First, the action (Action_1 in Fig. 1) requests for the filtered camera (Fig. 1a) from Component Manager, which knows that this resource consists of two sub-resources. Hence the Component Manager requests the Process manager to start the camera and the filter processes (ROS nodes). Next, another action (Action_2 in Fig. 1) independently requests for the same filtered camera stream (Fig. 1b), but since this resource has already been allocated, the Component Manager can return the same response as for the Action_1 and track that two clients are consuming this resource. Finally, the camera fails unexpectedly and all consumers of this resource are notified (Fig. 1c), which in this case is just the Component Manager. The Component Manager on the other hand knows that Action_1 and Action_2 consume a resource that depends on this failed sub-resource and thus notifies them. It is up to Action_1 and Action_2 to implement a suitable response behavior (either terminate, ask for an alternative, invoke any other routines, etc.).
Figure 1: An example scenario demonstrating the recurring challenges (allocation, dependency and status info management) that RR solves. Action_1 requests a resource (filtered camera) that is composed of multiple sub-resources, a camera and a filter algorithm (a). Action_2 independently from Action_1 requests also for the same filtered camera resource without causing another allocation of the sub-resources (b). A sub-resource failure is reported to all consumers in the dependency chain (c).
All resource managers are structurally very similar, that is, all resource managers are implemented as ROS nodes and thus are accessed via ROS messages and services. Each resource manager has also an Interface, which provides the user a simplified API for sending resurce requests to the managers (Fig. 2).
Figure 2 Illustrates the idea of accessing different resource managers through respective manager interfaces.
Figure 3