Comparison of Architectures
Abstractions Provided
Trying to break out just what abstractions are provided by different architectures. I am using the general three levels described in Three Level as a way to understand each system because this seems like a necessary way to partition the systems. A consequence of the robotic domain is the need to deal with things on a reactive time scale, to tackle planning problems, and then some glue to make everything work well in the real world.
Abstraction Table
| Deliberative | Executive | Reaction |
3T | AP composes RAPs together, forming a partially ordered plan | RAP - a sequence of skills, turns skills on an off. | A Skill Manager deals with a network of skills (decided by RAP) |
Titan | Temporal planning engines are available, but not standard. | RMPL provides the control language for the system. | The Titan executive is supposedly reactive. |
Wombat | Java code running on commodity hardware. | Tied together by a network (TODO: expand) | RTEMS runs Ada code, actual guarantees made. |
CARMEN | Pre-cursor to ROS; user space modules | Common tasks (Navigation, Path Planning, Localization) | Interaction with hardware (standardized interfaces), communication |
ATLANTIS | General planner, only advises the lower levels. | RAP, modified to deal with activities. | A controller (written in ALFA), turns on and off primitive activities as directed by the sequencer. |
Skill - A unit of action for the robot. Has defined input and output specifications. Input comes from other skills or sensors, outputs are to actuators or other skills.
Going Deeper
We are not concerned with the deliberation layer. Instead the focus should be on the reactive, low level components and how they interact with the sequencer / executive.
So, let's try the table again.
System Abstractions
| Executive | Reaction |
3T | The sequencer is a RAP interpreter which selects the skills to activate as well as event monitors. | Skills represent simple, reactive behavior. A network of these skills runs simultaneously, some using the output of others as input. Stops when an event monitor is activated, a timeout occurs, or the deliberative level interjects. |
CLARAty | The Decision Layer is a merger of the Deliberative and Executive layers found in Three Level architectures. It can connect to any object in the Functional Level, affording the granularity needed for the task at hand. State is queried from these objects. | The Functional Layer is composed of objects which likely represent physical systems. Methods correspond to functionality, and data to the state of that hardware. Local planners can be attached, usually at a object that represents a hardware sub-system (for example, a path planner attached to the navigation sub-system). |
Wombat | A Graph of Java programs running on commodity OSes and hardware handle all higher level processing, like navigation and obstacle avoidance. Communication with the reactive layer is handled by UDP messages over Ethernet. | RTEMS, on an embedded processor runs Ada code. This code monitors wheel encoders, watches for new control inputs from the network, and adjusts the control voltage for the brakes, power, and left-to-right power ratio (tracked vehicle). Timing guarantees can be made about all of this code; how often it will run and the execution time. |
CARMEN | | |
Player Stage | Player does not distinguish between the three layers as described by the Three Level architecture, and instead takes a Graph approach. "Drivers" act as nodes in a graph, and Player manages the communication between them. |
ROS | | |
AD | | |
ATLANTIS | Based off of RAP, but with modifications to deal with continuous activities (instead of discrete actions). Must provide concurrency mechanisms, cleanup suspended activities, and "cognizant" failures. | A restricted Lisp like language (ALFA) is used to write the controller and the primitive activities which the robot is capable of performing. Activities are continuous. |
RAP | A partially ordered net of actions (and sub-nets; hierarchical in nature) moves the system towards a single goal. Multiple goals are represented by multiple nets (called RAPs). Restricted so that a reactive time-scale is achieved; all resulting problems should be handled by the deliberative planner creating the RAPs. | The RAP interpreter sends "primitive actions" to a hardware interface. The hardware interface is responsible for performing these simple actions as well as updating the world model. The world model is restricted to only the current state and the updates should just be observations. |
Operating Systems
| Description | Abstraction |
RTEMS | | |
seL4 | seL4 doesn't provide specific abstractions for the robotics area. Instead, it offers a µ-kernel which has been verified and modified to be able to make guarantees about WCET time for interrupts. |
VxWorks | It is a pain to find out about VxWorks as it is a commercial, closed source product. I think it may be okay to assume that it provides what one would expect from a RTOS: preemptable kernel with some sort of admission control, RT scheduling, and stuff like that. |