Ordination
(re-)order behaviors that execute a task.
Introduction
The Ordination stack is one of the five high-level components of the Autopilot Inference. It is responsible for managing the cooperation between the various functionalities of the Autopilot Inference. This includes determining when and how individual functionalities should be activated and called upon.
The Ordination stack distinguishes between two types of functionalities:
- Functionalities that provide information to others, such as the position of the robot, the position of an Aruco marker, or the planned path.
- Functionalities that execute an actual operation in the real world, such as actions for moving the robot or services for providing feedback to the user.
The Ordination stack manages the cooperation between these functionalities by either activating or deactivating individual functionalities, thereby avoiding unnecessary use of resources. Additionally, it schedules the sequence in which functionality shares information or executes an operation at a particular moment in the process. This ensures that the execution of a behavior is only started when all required information is available.
The Ordination stack does not define or design the processes for managing the cooperation between the functionalities. Instead, the actual definition of each process is captured by the other four stacks in the Autopilot Inference, i.e., the Perception stack, the Navigation stack, the Interaction stack, and the Cognition stack, each supporting their own set of capabilities and thus also the process definitions to manage their cooperation.
Capabilities
The capabilities that the ordination stack provides have been designed to support the robot in managing the internal functionalities, i.e., its ROS2 nodes, and thereby creating an expected behavior externally. Therefore, the capabilities are related to the activation of functionalities, i.e., node management, and following predefined sequences of robotic operations that together result in the execution of a task, i.e., operation management.
Node management is a capability for managing the internal configuration of ROS2 functionalities, i.e., ROS2 nodes. It ensures that a chain of ROS2 nodes is activated, for example, because this chain of ROS2 nodes produces a vital piece of information that is required by other parts of the system. But it also allows to save computation resources in case a capability is not required for the current task of the robot, as those functionalities can be de-activated. An example of a capability is the localization capability of a robot, which typically requires a chain of ROS2 nodes to fuse pose estimates derived from a detected Aruco marker and from a scan matching algorithm between LiDAR data and a known map. This example is depicted in the illustration below, where the system is requested to go from a localization capability to enabling a navigation capability. Further, the node management capability should also detect if a ROS2 node in this chain crashes, so that the node is re-initialized and re-activated, thereby preventing that that entire capability is down and the robot stalls its operation.
Operation management is a capability for managing the timing on when a specific operation of some ROS2 node should be triggered. Triggering can be done by publishing on a specific topic, or by calling a specific service or action. Altogether, the collection of which operation(s) to trigger, and when, will result in a pre-determined behavior of the robot. Such behavior can be set for execution, or commanded, by a user. In robotics, it is commonly accepted that an engineer will program this trigger sequence based on user-needs. Hereto, the engineer will make a program of how these triggers follow-up on each other, thereby taking into consideration that a trigger might return a success or a fail. In addition, there can be multiple behaviors a robot should be able to execute, in which there is often an overlap in the pre-programmed sequence triggers. Therefore, a modular approach in which parts of one behavior definition can be re-used in another behavior definition is desirable. The illustration below depicts the general idea of how the flow of triggers results in a collective sequence of triggers defining robot behavior, Herein, so-called “sequence” nodes are triggered from left to right, while in case of the “Fail?“ node it will first attempt to trigger its left child and: go back up its parent in case the left-child returned a success; or continue to its right child in case the left child returned a fail. Our capability should thus be able to execute such behavior definitions.
