Ordination

Components that give the robot the ability to plan and (re-)order behaviors that execute a task.

Introduction

One of the 5 high-level components of the Autopilot Inference is the Ordination stack. The Ordination stack should ensure that the robot is able to manage its capabilities, i.e., managing when and how a capability should either be activated or executed, thereby fulfilling a particular task or mode of operation. There are two type of capabilities:

• A capability that provides information to the rest of the system, such as localization, or information about the dock.
• A capability that executes an actual operation in the real world, such as behavior for moving to a waypoint.

These capabilities depend on each other: before moving to a particular waypoint the robot should establish a proper position first. Within the Ordination stack one is able to design the cooperation between these capabilities, i.e., their internal management, so that the robot itself is able to perform its operation. Important to note is that the capabilities themselves are not defined, or designed, within the Ordination stack. Instead, each of the other 4 stacks in the Autopilot Inference, i.e., the Perception stack, the Navigation stack, the Interaction stack and the Cognition stack, each support particular capabilities. These capabilities are either known by the Ordination stack beforehand, or they are automatically loaded during initialization. Therefore, there is no actual output of the Ordination stack but instead ensures the configuration and activation of other functionalities as well as the creation of messages (topics, services or actions) that will trigger specific operations of the other functionalities within the system.

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. Therefore, the capabilities of the Ordination stack are related to the activation of functionalities and specifying specific operations to be performed.

 

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. 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 of 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 success or 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, , form a collective in 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 success; or continue to its right child in case the left child returned fail. Our capability should thus be able to execute such behavior definitions.

Info

Avular collaborators are authorized to read the details of the developments, which is found on the Development-Ordination