Operational principles
The principles under which the robot is operating are meant as background information so that a user understands how the robot reacts to the situation in which it is executing tasks. The first section discusses some important aspects on how a user may prepare the robot for an operation, i.e., during deployment-time. The second section discusses how the robot transforms this preparation into the actual execution of the operation as a list of behaviors. The page on behaviors then describes what a user might expect from the behaviors and autonomous capabilities of the robot when it is executing its operation, i.e., in which situations it should be able to go to a next waypoint, or avoid obstacles.
Preparing for an operation
The Cognition stack is responsible for capturing all relevant information that is required for the robot to conduct the operation. The information concepts that are known to the Autopilot Inference, and how they are connected to each other, is presented in the illustration below as well as in the definition after that.
This will be information about:
- Jobs: a job is defined as a list of tasks.
- Tasks: a task specifies the what and where to a robot , such as, Goto -some- waypoint, Follow -some- path, Dock -at some dock-, or Undock. A task is either a compound task or a primitive task. Primitive tasks can immediately be executed by behaviors, while compound tasks may only be composed into primitive tasks.
- Behaviors: a behavior specifies the how to a robot. There can be multiple ways in which a robot may execute a tasks, such as a Goto waypoint task can be executed via the behaviors MoveThroughPoses or MoveAlongPath, depending on whether it is constrained to a specific path. But there may also be a single manner of execution, such as a Dock task is executed via the one behavior MoveInDock, or the UnDock task is executed via the behavior MoveOutDock.
- Constraints: a constraint is a limitation on the autonomy of the robot and thereby limits the decision space of the robot as to how a task is to be executed, such as a constraint on the path of task or, in future, go- and nogo-areas defined via a polygon.
- Policy: a policy is a preference on the autonomy of the robot and thereby makes a trade-off in the decision space of the robot as to how a task is to be executed, such as a maximum distance to the path of a Follow path task.
- Maps: a map is an occupancy grid of the environment in which the robot operates. The boundary of the map, implying when a robot may use the map for localization, is defined by a polygon. In case there is no map of the area, then the robot may switch to GNSS-RTK for navigation.
- Paths: a path is a specification of how a robot should move from a starting waypoint to a final waypoint, or destination.
- Cover Area: an area that has perimeter defined by a polygon and that serves as the goal of a Cover Area task.
- Artifacts: an artifact is a something that exists in the real world or can visualized in the real-world, such as an Aruco marker or a Waypoint. The artifact can be part of a task, such a the object to go to, while the behavior for executing that task needs the pose of the artifact directly rather than the artifact.
A user may define a new Job using Avular’s GUI called Cerebra Studio, or directly a list of behaviors for immediate execution via Avular’s ROS2 API. For now, our explanation continuous with Cerebra Studio. Using Cerebra Studio a user can specify a job, which is a sequence of tasks with constraints and policies on how to execute that specific task. A user is only able to select a task from a predefined set, which for now are limited to GotoWaypoint, FollowPath, Wait and CoverArea.
We have adopted the concept of “Hierarchical Task Planning” to define tasks. Herein, some tasks are known as compound tasks, while other are defined as primitive tasks. A compound task can be decomposed into primitive task(s), and a primitive task can directly be executed by the robot using one of the known behaviors. One might define a job as a compound task, but there is a difference between the two. Jobs are a predefined list of tasks that should be executed in that same order, while when decomposing a compound task into primitive tasks the system may take the current situation into account. So for one situation the actual primitive tasks planned for execution might differ for the same compound task in a different situation. The same applies to primitive tasks and behaviors. The same primitive task may have various alternative behaviors to be executed and the system will decide which behavior is best depending on the situation. However, we have not implemented this situation-dependent-task-decomposition yet. Some examples of compound task and primitive task are listed below. Note that the Autopilot has some behaviors implemented that are not yet defined as a task in Cerebra Studio.
Compound task |
Primitive task |
|---|---|
| WarnPeople(goal: artifact) | FollowPath(goal: artifact) + Speak()) |
Primitive task |
Behavior |
|---|---|
| GotoWaypoint(goal: artifact, constraint: path) | MoveAlongPath(goal: empty, constraint: path), if path exists |
| MoveThroughPoses(goal: artifact-pose, constraint: empty), else | |
| FollowPath(constraint: path) | MoveAlongPath(goal: empty, constraint: path) |
| Speak(constraint: setence) | Speak(constraint: sentence) |
| Wait(constraint: time) | Wait(constraint: time) |
| CoverArea(goal: cover-area, constraint: go-area, nogo-area) | CoverArea(cover-area: some-polygon, go-area: some-polygon, nogo-area: some-polygon) |
The example below illustrates how a compound task (blue) to warn people at the main-square, for which the robot needs to follow a specific path, i.e., the NorthRoute. This compound task is first decomposed into a path-constraint FollowPath task (blue) and a Speak task (blue), that will both be further decomposed into the behaviors MoveAlongPath and Speak, respectively.
Maps are data-concepts of the cognition stack that are used by the robot for localization, navigation and path planning. Maps are represented by an occupancy grid, as depicted below, in which a grid-cell is either occupied, free, or unknown. Paths are data concepts that are used by the robot when a specific path needs to be followed. Paths are represented as a list of poses without any time indication as to when the robot needs to be at that pose. Herein, a pose is a vector constructed from a linear (Carthesian) position and a quaternion orientation (in the global frame).
| Map | Path |
|---|---|
 |
A path in 2D from the origin (0, 0) towards (3, 0) becomes # pose = [x, y, z, qx, qy, qz, qw] |
Artifacts are data-concepts that represent the semantic meaning of real-world objects that also have a pose in the real-world. At this moment the cognition stack supports Aruco markers as real-world objects having a marker-id and a pose, and Waypoints having a pose. Registration of new markers is supported by the Autopilot Inference, for which the interested reader is referred to the code examples, yet for convenience we have already included markers 0, 1 and 2 in the cognition stack upon delivery.
| Artifact | |
|---|---|
| Aruco marker | Waypoint |
 |
 |
The Ordination stack starts an initialization phase directly after the robot was turned on. During the initialization phase Ordination stack requests all the behaviors that are supported by the other stacks, i.e., which they are able to execute. The format in which these behaviors are stored is a so-called behavior-tree. The precise definition of a behavior-tree follows an xml-structure, but a user-friendly interface called Groot is available to design a behavior-tree visually as a tree structure and then convert it into an xml-structure. Each stack in the Autopilot Inference is responsible for managing which behaviors it is able to execute, for example, the Navigation stack will maintain its behavior-tree xml for the execution of the MoveInDock behavior.
During initialization, the Ordination stack will request the behavior-tree xml’s of all the other four stacks, i.e., from Cognition, Perception, Navigation and Interaction, and loads these xml’s in a local memory.
Info
Note that the behaviors are loaded into the Ordination stack, but the mapping from tasks to behaviors is part of the Cognition stack, and the Cognition stack has a predefined mapping thereby assuming that all predefined behaviors known to the Cognition stack are also available in the Ordination stack.
Executing the operation
The Cognition stack and the Ordination stack together ensure that the robot will execute the job that is defined by the user. This execution is triggered by calling a service of the Cognition stack to start execution the job in which the unique identifier of the job is embedded in the call. Internally, the Cognition stack will set a flag of the job that this job is “in execution“, after which the specific tasks within that job are acquired and further decomposed into a list of behaviors that are the be executed sequentially. See also the sequence diagram below. The ordination stack will then poll the next behavior of this behavior list and return a successful execution or a failed execution. Once the last behavior is executed the Cognition stack will report a success or false statement on the execution of the job. Specific details on what the execution of a behavior entails will be presented in the Ordination stack.
