Skip to content

Implementation of the Execution Layer Algorithm with ROSA ($A_2$)

The Execution Layer Algorithm, sometimes designated as $A_2$, plays a crucial role in the Execution-Cognition Machine (ECM) architecture. Its primary function is to transform a set of actions selected by the Cognition Algorithm ($A_1$) into executable actions that result in solving the user's problem. $A_2$ is responsible for the execution of these actions, ensuring that they are carried out in an orderly and effective manner, adapting to the needs of the problem and the execution context.

Implementation of $A_2$ Using SequenceActionServer and ROS2 (ROSA Approximation)

For explaining the architecture of $A_2$ internals, we begin with the setup of our ECM at a low level. Since the theoretical expansion of A' should be supported by the execution layer, the following TSP protocol is proposed.

2.3.1 Task-Sequence Protocol (TSP)

Let's imagine the simplest case, suppose a problem ( p ∈ P ) could be solved with a single action, such as pressing the letter "K" key in the keyboard. The Task-Sequence Protocol (PTS) encapsulates this action in an object called ActionPackage.

An ActionPackage consists of two key elements:

  • Function: Reference to our action ( b ∈ B ), such as a keystroke. Note how this function can be passed to the ActionPackage by using the ItemRegistry. Just ensure to register the function with the appropiate decorator and then pass the id to the package.

  • Arguments: Here you can pass details relevant to the action, such as the specific key "K". These arguments can be passed as args or kwargs

ActionPackage Structure

After we are able to make actions. We want to be able to combine them in further ways, such as compositing, so we archive the A' expansion property. For this, using ROS2 Behavior Trees (BT) directly in our ECM would be impractical, as it would force the LLM to build an XML and a set of unnecessary components. Instead, we use an approach based on SequencePackages.

A SequencePackage is a set of actions with behavior defined by the SequenceType, which determines whether the actions should be executed in parallel, linearly, conditionally, etc. This allows for the efficient execution of the keystroke action "K".

SequencePackage Structure

When multiple sequences are related to achieving the same objective, they are encapsulated in what is called a Task. A task is a set of related sequences, ordered by priority (defined in each sequence individually). This allows the system to generate more complex plans that include concurrent action execution and even mechanisms for feedback, interruption, or sequence succession in a straightforward manner for the LLM. Although it is possible to send the task directly to the TaskRegistry controller, we will show a cleaner way to manage tasks with ROSA, so by now, just focus on on the how the priority of the task can affect the execution of the plan.

Task Priorities Structure

SequenceActionServer vs ROSA

The SequenceActionServer or SAS (also called IODA as a deprecated name) is responsible for converting requests from higher levels into executable actions for the Gateway using the TSP. It's crucial to remember the separation of responsibilities at higher and lower levels:

  • ROSA: This layer is an interface for building request as a set of actions to be executed.
  • SAS and Lower Levels: These are responsible for HOW to execute those actions, given a plan.

Within the question of how to execute a plan given by a higher level, we find different problems to solve, differentiated into 3 modules represented in the following diagram:

SAS Structure

  • ROS2 Topics: Using the communication functionalities offered by ROS2, we encapsulate all the Tasks from higher levels in JSON format, which can be read asynchronously through callbacks in the ActionClient (ROS2 Actions). In this way, all tasks will be published in the /resquest topic, while the feedback will be returned in /feedback

  • SequenceActionClient: Also known as "Request Responder," it reads the requests published on the topics and applies the TSP protocol to define which behavior to execute next (interrupt, execute, put on hold, etc.). For each sequence it decides to start, it will receive feedback produced and forward it to higher levels for processing. Responsibility: Define WHEN to execute each sequence.

  • SequenceActionServer: Also known as "Request Controller," it receives sequences sent by the client and executes without the ability to cancel. Its responsibility is to define the type of execution according to the task's topology and its possible BT actions. Responsibility: Define WHO to call to execute the sequence.

  • SequenceTypes: Encapsulated within the "Request Controller" in the general diagram, it is responsible for defining the order and conditions of execution for each received sequence. Responsibility: Define HOW to execute the received sequence.

  • UPI Listener: Not shown in Figure 8, it is responsible for receiving asynchronous user requests sent from the UPI in the hardware-layer and sending them directly to higher layers via the ROS2 topics. Its response will be received in the same way as the rest of the sequences, with a different priority if necessary.

2.4 ROSA and ALB

In the previous sections, we have discussed the mechanism to implement a ECM at a low level. However, due to its complexity and level of abstraction, ROSA (ROS Agent) was created.

ROSA serves as an interface that simplifies the entire TSP into a set of simple functions to be executed by higher layers. This means it converts the rest of the objects into ROS2-Agnostic, eliminating the restrictions caused by dependency among these components. ROSA effectively turns the entire system below it into a black-box model that EXECUTES the sent commands.

On the other hand, (although is not necessary to interact with) to eliminate concurrency issues and the linking of functions from lower levels to higher levels, the ALB (Application Layer Builder) is responsible for launching all ROS2 nodes and maintaining the resources used within the same memory space of a single process (multithreaded). Thus, a set of objects created by different layers can be accessed without the need to use pipelines or alternative methods to the system. The ALB will be managed by ROSA so the user doesn't have to interact with ROS2 nodes.