# Presentation: 406329

## Robotic Autonomy Architectureand Task Review

_***CLARAty Management:***_
**Richard Volpe, Ph.D. *****(Program Manager)***
**Issa A.D. Nesnas, Ph.D. *****(Task Manager)***

**Robotic Autonomy Architecture****and Task Review**

**Jet Propulsion Laboratory****California Institute of Technology****June 28, 2000**

## Review Agenda

_**Review Agenda**_
**  ****9:00 -   9:10 ****	****Introduction****  9:10 - 10:15****	****Architecture Overview****10:15 - 10:30****	****questions****10:30 - 11:30****	****Functional Layer****11:30 - 11:45****	****questions****11:45 -   1:15****	****- lunch -    ****  1:15 -   2:15****	****Decision Layer****  2:15 -   2:30****	****questions****  2:30 -   3:30****	****Examples****  3:30 -   4:30****	****Discussion**

**Notes:**
Add names?
Add breaks?

## Outline of the Architecture Overview

*	***General Introduction:**
- Background of this Task
- Impeding Issues
- Reasons for Commonality
- Constraints on the Solution
**	****Architecture Introduction:**
- Two Layer Design
- The Functional Layer
- The Decision Layer
- Execution Timeline
*	***Implementation Concepts:**
- Implementation Tools
- Heritage and Leveraging
- Prototyping Status

## Robotic Autonomy Architecture TaskHistorical Antecedents

**Late 80’s:  **Volpe participates in Chimera Robotics OS effort at CMU.  ControlShell developed at Stanford.  Telerobot Testbed culminates at JPL.
**Early 90’s:** Several system development efforts undertaken in parallel at JPL: RSI (C/VxWorks), MOTES (Ada/VxWorks), Satellite Servicing (C/Z), Robby (LISP/C/VxWorks), Microrover (Forth/C), etc.
**Mid 90’s:** Mars rover research work centralized with Rocky 7 (ControlShell/VxWorks).  First flight rover (C).
**Late 90’s:**  Expansion and division of rover work at JPL (Rocky 7, FIDO, Athena, DARPA) with no adherence to centralized architecture.  Remote Agent Experiment effort at Ames and JPL (LISP/C/VxWorks).
**Late ’98:**  Mission Data Systems Project Starts at JPL to address spacecraft control issues with a new state-based architecture.
**Early ’99:**  Hayati moves to JPL program office and requests Nesnas to investigate software transfer, design, and commonality issue amongst JPL research and flight robotics efforts.
**Fall ’99:**  Hayati / Ruoff develop concept for new Autonomy Architecture task to be funded out of the Exploration Technology Program, with explicit desire to leverage MDS product for robotics.
**Dec. ’99:**  New task starts.

## Impeding Issues

_***Impeding Issues***_
**Programmatic Vision:**  Architecture and infrastructure are  often not recognized as exciting/necessary areas of work.
**Not Invented Here:**  Fear of unknown performance, quality, and support.
**Flexibility:** Each system/engineer has specific needs.
**Overhead:**  Resource constrained tasks lack time to import from, or export to a larger software system.
**Critical Mass:**  Might be useful once in place, but no one wants to buy in early.
**Learning Curve**:  Resistance to transition from old method.
**Technical Vision:** Only meaningful if you're primarily a system architect; otherwise typically falls in one of the above categories.

**Notes:**
closet

## So, why do we need a new architecture?

**Duplicative efforts prevent attainment of critical mass:**
***Parallel Duplication:*** At least 4 major JPL rover efforts are using 4 different software environments (Rocky 7/8, Athena-Rover and MusesCN, FIDO/SRR, TMR).  Similar story for Ames, CMU, etc.
***Serial Duplication:***  New starts of projects often wipe the slate clean to eliminate old system problems and lack of familiarity or trust with previous product.  Typically, software with legacy is due solely to a single individual, not the community.
**Follow software community lead**:
***Open source movement:  ***The value of shared software is illustrated by*** ***Linux, GNU, and newly announced Intel Computer Vision Library effort.
***Object oriented design:***  It dominates software development, especially in industry,  but is under-utilized in robotics.
**Leveraging complimentary efforts:**
***MDS and X2000:***  JPL has large scale efforts in spacecraft hardware (X2000) and software (Mission Data System) which promise an infrastructure to be leveraged and expanded.
***Software sharing:***  Across related tasks within NASA is often arduous and rare.

## Constraints on the Solution

**MDS Compliance: **Robotics software developed in parallel with MDS should seek compliance to the fluid MDS architecture, in order to leverage its products.
**Span Many Divides:**
- Disparate robotics problems.
- Product life cycle from basic research to flight systems.
- JPL research projects in different groups, sections, or divisions.
- NASA research projects at different institutions.
**Leverage existing software and research/flight efforts:  **In particular, the large scale effort of the Mission Data System.
**Leverage standard practices: **To avoid reinvention of the wheel, and bring NASA robotics efforts in line with techniques and solutions commonly employed in commercial products and within the global software community.
**Community acceptance:** Independent of the technical correctness of any solution, an infrastructure standard must be adopted and used to be successful.

**Notes:**
Put in Community acceptance ?

## Slide 8

**Notes:**
An alternative:
STRATA
Strata is the Template of a Robotics and Autonomy Tiered Architecture

## A New View of Architecture Hierarchy

- Executive

- Functional

_***A New View of Architecture Hierarchy***_

**    ****Typical 3 **_**Level**_** Architecture**
*Functional Level is flat – typically a thin **layer over the hardware*
*Planner has no access to Functional Layer.*
*Abstraction and granularity is mixed with intelligence.*

**Notes:**
Fonts too small
Green color change.

## The Functional Layer

_***The Functional Layer***_

***Object-oriented Hierarchy:*** captures granularity and abstraction of the system.
***Resident State:*** the state of the system components is contained in the appropriate objects and obtained from it by query.  This includes state variables values, object state machine status, resource usage, health monitoring, etc.
***Local Planners:*** part of the appropriate object.  For instance, trajectory planners for arm motion or driving.
***Resource Usage Predictors:*** part of the appropriate objects.  The prediction can have specified levels of fidelity.  For high levels, access of subordinate objects may be needed.
***Encoded Functionality:*** objects contain basic functionality for themselves, accessible from within the Functional Layer, as well as the Decision Layer.
***Simulation:*** system simulation can be obtained at various levels of fidelity by disconnecting subordinate objects from superior ones.
***Test and Debug:*** objects contain test and debug interfaces and have external exercisers.

**Notes:**
Test and debug: remove all, add external exercisers.

## Functional Layer Object-Oriented Hierarchy

**Implementation Instance:** *Functional Layer* software controlling the system is an instance of software derived from more abstract classes.

**       ****My Rover’s**
**Arm**

**    ****My Rover’s**
**Locomotor**

**Abstraction dimension:  **In addition to system, granularity, and intelligence.

**Inheritance:** Abstraction dimension is best described by the inheritance properties of an object oriented description

**Aggregate Functionality:  **Centralizes and enhances capabilities.

**Notes:**
Manipulator -> appendage
Replace by coordinated system

Just abstraction axis

## The Decision Layer

***Goal Net:***  temporal constraint network at planning level, task tree at executive level.
***Goals:*** specified as constraints on state over time.  Consistent with MDS, and ASPEN/CASPER. Runtime loadable.  (“What not to do.”)
***Tasks:*** specified as explicitly parallel or sequential activities that are tightly linked. Consistent with TDL. Compiled in. (“What to do.”)
***Commands:*** termination fringes of goal net where the Functional Layer is accessed.
***The Line:*** the lower border of the elaborated goal net.  It is floating, according to the current elaboration.  When projected on the Functional Layer, it denotes the border below which the system is a “black box”.
***State:*** the state of the Functional Layer is obtained by query. The state of the Decision Layer, which is essentially its plan, the active elaboration, and history of execution, is maintained by this layer.  It may be save, or reloaded, in whole or part.

**Notes:**
Color gradient here

## Decision/Functional Layer Connectivity

_**Lower Granularity**_
- Enable global decisions that are lacking in Functional Layer.
- Utilize better decision making capability for smaller scale issues.
- Bypass built-in default capabilities of Functional Layer.
- Take advantage of faster planner or exec.
_**Higher Granularity**_
- Take advantage of built in capabilities of Functional Layer
- Avoid second guessing Functional Layer algorithms and error handling.
- Approach planning and commanding at appropriate level of granularity for the problem – don’t micro-manage the system.
- Allow the use of slower Decision Layer tools.

## Timeline Interaction

***Elaboration/Planning:***  expansion of goals/activities, along with resource prediction requests from Functional Layer
***Scheduling:*** rearrangement of activities based on resource constraints.
***Execution:*** Executive expands activities into task trees or directly into commands.  Conditional activities plus state feedback cause changes in resource usage values.
***Plan Repair:***  Planner iteratively repairs the plan based on the new projections of resources.

**Notes:**
Change elaboration to Elaboration/Planning
Change Planning to scheduling.
Move resource stuff to scheduling 

## Implementation and Tool Choices

**UML: **The Universal Modeling Language, used for system design an documentation.  Desired full use of  UML, including templates.  Possible use of auto code generation.
**Development Tools such as Rhapsody, Visio:  **choice dependent on cost, capabilities, and flexibility.  Direct coding according to UML description is fine.
**Standard Template Library: **maximal use of public domain standards employed by the software community. (Pending VxWorks issues.)
**C++ Language:** Object oriented implementation.
**Documentation:**  multiple levels of documentation including UML description directly.  Investigating possible C++ equivalent to JavaDoc.
**OS support: **VxWorks, Linux, Solaris

## Heritage and Leveraging

_**Initial**_** move of some existing software and techniques **
**into a common framework.**
**Planetary Dexterous Manipulators:** inherit PDM object oriented kernel of Functional Layer
**Software Libraries and Packages** slated for incorporation:
*Vision:* JPL Stereo vision; Intel open-source software when available
*Path Planning:* CMU Morphin/D*
*Planning:* JPL CASPER
*Estimation:* JPL LRSR/SRR estimation
*Executive:* CMU TDL
*Dynamics:* JPL DARTS++
**Test Platforms: **Rocky 7 & 8, PDM rover manipulation testbed

_**Initial**_** move of some existing software and techniques **
**into a common framework.**

**Notes:**
Change Heritage to Inheritance ?

Sample pieces for architecture prototype this year.  MAKE THIS CLEAR.

“And hopefully yours in the future” 

## Prototyping Status

_**Functional Layer**_
***UML description:  ***Initial stage of system description being completed; extensions starting.
***Basic Functionality:*** Rocky 7 mobility, manipulation, and visual processing reuse from PDM task.
***Hiding Hardware Details:*** Motor classes modified to handle Rocky 7 (DIO, LM629) and Rocky 8 (I2C, PIC, HCTL1100) motor control hardware.
***Enhancements:*** New functionality added to handle continuous driving/steering.
***Navigation:*** Integration of Morphin/D* in progress as part of IS program effort.
_**Decision Layer**_
***First Planner:***  Tests have begun with CASPER planner and its mini-exec controlling Rocky 7.
***First Executive:*** Plans to leverage CLEaR task effort for integration of CASPER with TDL.
***Resource Management:*** Initial investigation of APIs for resource information from Functional Layer.