Recent Changes - Search:

Research

Notes

Architecture

Faults

System

Planning

Background

OS

Misc

edit SideBar

Other

Other Robotic Middle-Wares


MOOS-IVP

http://oceanai.mit.edu/moos-ivp/pmwiki/pmwiki.php

MORSE

http://www.openrobots.org/morse/doc/stable/what_is_morse.html

Look into ACTRESS


ALLIANCE

I do not know what the acronym stands for. Developed in the late 90's at Oak Ridge National Laboratory.

Described in Papers#Parker98ALLIANCE

Lynne E. Parker seems to be the dominate (only?) researcher working on ALLIANCE. The last publication was in 2001 (Attach:Parker01Evaluating.pdf (citation below)), which was a brief calling for better quantitative analysis of robot architectures.

Parker is still active in research at University of Tennessee. I am looking into her latest work in robotics.

@article{parker2001evaluating, title={Evaluating success in autonomous multi-robot teams: experiences from ALLIANCE architecture implementations}, author={Parker, Lynne E}, journal={Journal of Experimental \& Theoretical Artificial Intelligence}, volume={13}, number={2}, pages={95--98}, year={2001}, publisher={Taylor \& Francis} }

ARINC 653

Avionics Application Standard Software Interface. It is a specification for safety critical real-time avionics.

Reliable Distributed Real-time and Embedded Systems Through Safe Middleware Adaptation is built on top of an ARINC 653 system.

Described in this paper:

Software Fault Protection with ARINC 653

@inproceedings{goldberg2007software, title={Software fault protection with ARINC 653}, author={Goldberg, Allen and Horvath, G}, booktitle={Aerospace Conference, 2007 IEEE}, pages={1--11}, year={2007}, organization={IEEE} }


Carnegie Mellon Navigation Toolkit (CARMEN)

As far as I can tell, this is one of the first systems to take the Graph approach, although they credit and cite 3T (perhaps due to the dominance of Three Level architectures at the time)).

Appears to be a precursor to Player Stage and ROS.

Robotics#Montemerlo03CARMEN


Coupled Layer Architecture for Robotic Autonomy (CLARAty)

Developed by NASA's Jet Propulsion Laboratory, CLARAty was intended to become Nasa's dominate robotic architecture. It is an evolution of the Three Level architecture, but with the deliberative and executive layers merged together. This merger was justified by the large about of variations in not only the demarcation between the levels, but the choice between which is dominate.

A 2001 paper lays out the intended architecture, as well as the justification for developing a new one.

Unfortunately, it would appear that the architecture has been abandoned. An utterly useless 2007 paper seemed intended to give the current status of the project, but it reads more like a white paper than a work of research (and it was presented at a NASA conference).

I am not sure if this work is still active.

Functional Layer

Decision Layer


cFE

NASA's core Flight Executive is an open source middle-ware framework for flight software. It runs on a variety of OSes (Linux, FreeRTOS, RTEMS, and VxWorks) thanks to a related NASA open source project: Operating System Abstraction Layer (OSAL).

The core Flight System (cFS) refers to a collection of applications and libraries that are packaged with cFE. Most are now available here.

The Lunar Reconnaissance Orbiter was one of the first missions to use cFE, and many missions since then have adopted it. Even the occasional CubeSat... hopefully more on this soon.

Refs:


OPRoS

A component based robotic middleware with fault tolerance built in. Each component has an associated XML file which describes possible faults and related information. Components may also implement some callback functions to aid in recovery.

source paper

It looks like triple modular redundancy or N-version can be supported, but this does not seem to be a focus: SEU's are not part of their fault model.

As far as I can tell, the work is not concerned with multiple robot scenarios or incorporating planning with fault tolerance.

Real-time support is mentioned as a future addition, but latest (English) work on the topic is light and not actually real time: Attach:Kan13SchedulingOPRoS.pdf. This paper describes a scheduling algorithm for use within the OPRoS execution engine, which decides the order in which to run components. However, the system is still built upon a commodity OS. The results themselves seem to show mostly that the original scheduling technique was horrible (jitter accumulates throughout execution).


Remote Agent / Livingstone

TODO: A better description of RA / Living

Remote Agent / Livingstone experiments performed on the Deep Space 1 satellite (DS1). For a short period of time, DS1 was under the direct control of Remote Agent, which successfully planned and executed several actions, such as rotating the satellite and photographing targets. There were also several simulated component failures, which were resolved with the Livingstone mode identification and reconfiguration module.

For a description of the DS1 Remote Agent experiment, see Spacecraft Autonomy Flight Experience: The DS1 Remote Agent Experiment.


Titan Executive

Titan was developed by the MERS group (TODO: link to page) as a successor to the Remote Agent system. Both follow the Model Based architecture.

My slides on Titan: Attach:Titan.pdf.


Wombat

Created by MITRE. The system is partitioned into a low level RT system that runs Ada code on RTEMS to provide low level reactionary control. This system is networked with general purpose systems that handle executive and deliberative functions.


YARP

YARP (Yet Another Robot Platform) seems to be taking on the role of a light-weight and less intrusive ROS. Their wiki even takes a jab at the behemoth: "YARP is definitely not an operating system."

What YARP is appears to be a library and set of tools designed to aid in the development of humanoid robots. This gives it a bias to expensive research robots and the problems faced by humanoids such as video processing (no mention of bipedal control, probably too difficult).

The library is linked at user level, and uses the ACE library for OS compatibility. Its main feature is to provide for communication between components in the observer pattern. It handles buffering, serialization, sharing, and memory management (of this I am not certain).

See white paper: YARP: Yet Another Robot Platform

Edit - History - Print - Recent Changes - Search
Page last modified on November 11, 2015, at 01:00 PM