A Programmatic View of CLARAty Richard Volpe JPL Space Exploration Technology Program Office NASA Mars Technology Program 2009 Mars Science Laboratory.

Slides:



Advertisements
Similar presentations
CLARAty: Towards Standardized Abstractions and Interfaces for Robotics Systems Coupled Layer Architecture for Robotic Autonomy Issa A.D. Nesnas Jet Propulsion.
Advertisements

Advanced Multimission Operations System (AMMOS)
8.
CSE Design Lab – Milestone 2 James Hopkins Dave Festa Dennis O’Flaherty Karl Schwirz.
“Modeling the MER Mission” Chin Seah NASA Ames Research Center.
Lecture 13 Revision IMS Systems Analysis and Design.
Agent-Based Acceptability-Oriented Computing International Symposium on Software Reliability Engineering Fast Abstract by Shana Hyvat.
Simultaneous Localization and Map Building System for Prototype Mars Rover CECS 398 Capstone Design I October 24, 2001.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Object-Oriented Analysis and Design
Fuzzy control of a mobile robot Implementation using a MATLAB-based rapid prototyping system.
National Aeronautics and Space Administration Practices for Improving Robotic Software Reliability in Flight and Research Projects Khaled S. Ali and Issa.
The Design Discipline.
UML - Development Process 1 Software Development Process Using UML (2)
Modularly Adaptable Rover and Integrated Control System Mars Society International Conference 2003 – Eugene, Oregon.
05 December, 2002HDF & HDF-EOS Workshop VI1 SEEDS Standards Process Richard Ullman SEEDS Standards Formulation Team Lead
Multiple Autonomous Ground/Air Robot Coordination Exploration of AI techniques for implementing incremental learning. Development of a robot controller.
IEEE R lmap 23 Feb 2015.
Task Manager Issa A.D. Nesnas Vision Max Bajracharya (JPL) Alt. Task Manager Tara Estlin JPL - Issa A.D. Nesnas ARC – Anne Wright CMU – Reid Simmons U.
Distributed Network Scheduling Bradley J. Clement, Steven R. Schaffer Jet Propulsion Laboratory, California Institute of Technology Contact:
At A Glance VOLT is a freeware, platform independent tool set that coordinates cross-mission observation planning and scheduling among one or more space.
Mars 2020 Project Matt Wallace Deputy Project Manager August 3, 2015.
Testing Workflow In the Unified Process and Agile/Scrum processes.
IntroductionUnderstanding the IOOS ProjectThe SAIC Team OverviewSummaryPast PerformanceThe SAIC Team Approach 1 Agenda  Introduction  The SAIC Team.
.1 RESEARCH & TECHNOLOGY DEVELOPMENT CENTER SYSTEM AND INFORMATION SCIENCES JHU/MIT Proprietary Titan MESSENGER Autonomy Experiment.
Thomas C. Stein PDS Geosciences Node Washington University in St. Louis 1MS Supporting Active Surface Missions and Adding Value.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Page 1 Reconfigurable Communications Processor Principal Investigator: Chris Papachristou Task Number: NAG Electrical Engineering & Computer Science.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Boundary Assertion in Behavior-Based Robotics Stephen Cohorn - Dept. of Math, Physics & Engineering, Tarleton State University Mentor: Dr. Mircea Agapie.
DSL Distributed Systems Laboratory ATC 23 August Model Mission: Magnetospheric Multiscale (MMS) Mission Goal “To study the microphysics of three.
1 Distributed and Optimal Motion Planning for Multiple Mobile Robots Yi Guo and Lynne Parker Center for Engineering Science Advanced Research Computer.
DARPA ITO/MARS Project Update Vanderbilt University A Software Architecture and Tools for Autonomous Robots that Learn on Mission K. Kawamura, M. Wilkes,
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
Unified Robotic Software Development using CLARAty Issa A.D. Nesnas Mobility and Robotic Systems Section Autonomous Systems Division July 20, 2005
31 March 2009 MMI OntDev 1 Autonomous Mission Operations for Sensor Webs Al Underbrink, Sentar, Inc.
Accelerated Long Range Traverse (ALERT) Paul Springer Michael Mossey.
ST5 PDR June 19-20, 2001 NMP 2-1 EW M ILLENNIUM P ROGRA NNMM Program Overview Dr. Christopher Stevens Jet Propulsion Laboratory, California Institute of.
Seeker kick-off workshop “State of the art” Simon Lacroix Laboratoire d’Analyse et d’Architecture des Systèmes CNRS, Toulouse.
Abstract A Structured Approach for Modular Design: A Plug and Play Middleware for Sensory Modules, Actuation Platforms, Task Descriptions and Implementations.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
August 2003 At A Glance The IRC is a platform independent, extensible, and adaptive framework that provides robust, interactive, and distributed control.
June 28, 2000 Architecture Review 1 Examples: Implementing Common Solutions within CLARAty.
Component Design Elaborating the Design Model. Component Design Translation of the architectural design into a detailed (class-based or module- based)
Global Design Effort: Controls & LLRF Americas Region Team WBS x.2 Global Systems Program Overview for FY08/09.
SAS_05_Contingency_Lutz_Tal1 Contingency Software in Autonomous Systems Robyn Lutz, JPL/Caltech & ISU Doron Tal, USRA at NASA Ames Ann Patterson-Hine,
Chapter : 9 Architectural Design
CS3320-Chap21 Office Hours TR 1:00-2:15 PM W 2:30-3:30 PM By appointment.
From the customer’s perspective the SRS is: How smart people are going to solve the problem that was stated in the System Spec. A “contract”, more or less.
National Aeronautics and Space Administration Jet Propulsion Laboratory California Institute of Technology Pasadena, California CLARREO GPS RO/AJM-JPL.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
DSN CCSDS SLE SM Prototype Plan Erik Barkley December 2006.
Pre-decisional – for Planning and Discussion Purposes Only 1 Technology Planning for Future Mars Missions Samad Hayati Manager, Mars Technology Program.
Astrobiology Science and Technology for Exploring Planets (ASTEP) Mid-Year Review August 4, 2004 Robust Autonomous Instrument Placement for Rovers (JPL:
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
JSTAR Independent Test Capability (ITC) Core Flight System (CFS) Utilization October 26, 2015 Justin R Morris NASA IV&V Program.
Engineering and Science Directorate Organization Structure June 2016.
Towards Standards for Goal-Based Operations
Software Life Cycle “What happens in the ‘life’ of software”
System Design and Modeling
NASA Ames Research Center
IEEE Std 1074: Standard for Software Lifecycle
Model-Driven Analysis Frameworks for Embedded Systems
Autonomous Operations in Space
IEEE ICRA 2005 Planetary Rover Workshop April 22, 2005
Presented By: Darlene Banta
Presentation transcript:

A Programmatic View of CLARAty Richard Volpe JPL Space Exploration Technology Program Office NASA Mars Technology Program 2009 Mars Science Laboratory Project Jet Propulsion Laboratory California Institute of Technology

Overview Review of Technology Component Flow Chart Legacy & Current Robotics Flight Software CLARAty & Testbeds Competitively-Selected Technology Components’ Development Validation of Technology Components MDS Infusion Other Issues

Technology Component Flow

Legacy Technology

WITS Rover Interface

Legacy Software Selection Criteria (draft) Mars Application: Relevance of the technology to the Mars Exploration problem, particularly that expressed within the 2009 Mars Science Laboratory flight project Constraint Compliance: Ability of the technology component to live within expected mission constraints (CPU, memory, power, etc.) CLARAty Augmentation: Complementary versus duplicative nature of the technology component as compared to current CLARAty-based capabilities. Maturity: Maturity of the algorithms, and the software implementation Effort & Cost: Level of effort to capture the technology component, depending on complexity, documentation, intellectual property release, etc.

CLARAty and Testbeds

CLARAty Coupled Layer Architecture for Robotic Autonomy THE DECISION LAYER: Declarative model-based Mission and system constraints Global planning INTERFACE: Access to various levels Commanding and updates THE FUNCTIONAL LAYER: Object-oriented abstractions Autonomous behavior Basic system functionality

ROCKY 8 Development and Test Platforms ROCKY 7 K9 ROAMSDEXTER ATRV JR. FIDO FY01 Supported New In FY02

Multi-Level CLARAty / Subsystem Closed-Loop Control (for Rover) PASSTHROUGH Decision Layer Navigation Loco- motion Joint Control Decision Layer Navigation Decision Layer Navigation Planetary Rover Rover Level Navigation Level Motor Level Navigation Subsystem FL DL Subsystem Origins COTS systems (e.g. ATRV Jr.) Firmware (e.g. widget boards) Simulation (e.g. ROAMS) Legacy Loco- motion Joint Control Loco- motion Joint Control Loco- motion Joint Control

Goals enter at top Decision Layer Functional Layer Subsystem Layer granularity Elaboration – P&S, Exec Functional decomposition Subsystem details Rover and Instruments Granularity Matching between Layers of Decision, Function, and Subsystem Key points: Granularity penetration at each level may vary. Subsystem may exist at all levels of granularity. Decision Layer access to subsystem passes through Functional Layer, even at a single point. DL / FL interface independent of subsystem. Complete “subsystem” is accessed through stubbed-out FL System hardware Environment

Example: Simulation Goals enter at top Decision Layer Functional Layer Simulation Layer granularity Elaboration – P&S, Exec Functional decomposition Simulation details Rover and InstrumentsEnvironment Subsystem is the simulator. Primary work to be done is simulated environment development. Leverages: - FY02 CLARAty / ROAMS - ongoing MSL - MSF efforts at ARC

CLARATY INSTRUMENTS PACKAGE SCIENCE DATA PROC PKG Instrument Spectro- meter Science Processing Sim Spec Real Spec Sim Cam Rover Hardware (K9, R8, etc.) Spec Processing Roush Spec Proc Cam SIMULATION INSTRUMENT SIMULATORS Camera Simulator Spectrometer Simulator MSF Client Instrument Client Rover Client Terrain Model Spectral data K9 Client Instrument Client Rover Client CONDITIONAL EXECUTIVE Linux-based Planning System Proposed FY03 MSF – CLARAty Structure MOBILITY PACKAGE Rover Locomotor Motor Navigator Sim Motor Sim Rover Real Motor Sim Nav DEMs TERRAIN & ENV DATA SERVERMarsTERM CLIENT ROAMS High Level Rover Simulator Navigation Motor Simulator Real Cam Engineering Data Interface OO Terrain

Competitively Selected Technology Component Development

Competed Tasks Round 1 Selection Process 02/05/01 – Announcement of Research Opportunity released 02/28/01 – Proposal due date (36 proposals received) 05/03/01 – Selection of proposals Total funding (FY’01 – ’04): $5M Proposals (Awarded vs. Submitted) Awarded Funding Distribution Round 1 Selected Proposals

Real Rover(s) CLARAty Decision Layer CLARAty Functional Layer Real Rover(s) Real Terrain Sim Terrain(s) SIMULATION ENVIRONMENT Decision Layer GOALSSTATUS Component Technology Alternate Decision Layer Example: Roush Autonomous Science Algorithms Example: Washington Conditional Sequencer Volpe – 2/21/02 REPLACE INSERT Rover(s) Sim Instrument(s) Tech Component Capture in CLARAty High Detail Sim MTP Tech Components Primarily go to Functional Layer. IS Program Technology provides alternate Decision Capabilities.

Technology Validation

‘09 MSL Validation Scenario #1: Approach & Instrument Placement Description: Enable placement of a science instrument on a designated target, specified in imagery taken from a stand-off distance. Placement accuracy to be within 1cm or 0.1%, from a stand off distance not greater than 10m. rover Max designation range < 10m partial panorama instrument placement placement error ellipse goal designation error

Description: Enable autonomous traverse, obstacle avoidance, and position estimation providing up to 600m/sol with less than 3% error relative to starting position. start stop error ellipse goal traverse leg length < 600m actual path autonomously executed ‘09 MSL Validation Scenario #2: Long Range Traverse

Description: Enable processing of science data onboard the rover system. This will be used for the progressively more challenging issues of: intelligent data compression (inlier detection) and prioritization, anomaly recognition (outlier detection) with stop and communicate result, conditional actions based on either of first two. Example: “Terrain classification while doing long traverse” Layers detected in blue regions Rocks targeted for spectral analysis (green) Compound Horizon Determined (red) ‘09 MSL Validation Scenario #3: Onboard Science Data Processing

Technology Infusion Into MDS

MSL Flight Software MSL Rover Testing MTP Tech Dev Legacy S/W NOW Overview of Software Flow in Time MTP Tech Dev

Component Technology Development Technology Software Infrastructure MDS Core for MSL Existing Tech MDS Adaptation for MSL Flight Software Infrastructure CLARAty for MSL MSL CLARAty-based demos MDS-based demos ‘01‘02‘03‘04‘05‘00 CLARAty after MSL Currently funded competed tasks TBD NRA tasks pre-MSL demos pre-MSL MDS Core pre-MSL CLARAty LONG TRAVERSE INSTRUMENT PLACEMENT AUTO SCIENCE Technology Timeline for MSL

CLARAty and MDS Principal Attributes of Each System CLARAty (Coupled Layer Architecture for Robotic Autonomy) For research and development Rovers, robotic systems Tool suite for rapid prototyping Integrate disparate research efforts (NASA Centers, Universities, JPL) Interoperability across platforms (integration and comparison) MDS (Mission Data System) For JPL missions For complete spacecraft systems (control, fault protection, communication, end-to-end flight- ground system) Integration across project activities (systems engineering, software engineering, software reliability) Reuse across projects (accumulate multi-mission legacy)

CLARAty / MDS Infusion Configurations MDS CLARAty Decision Layer CLARAty for researchMDS for flight CLARAty Functional Layer Encapsulation with modular Inclusions Full Translation (Standard MDS Adaptation) MDS CLARAty Functional Layer Full Encapsulation MDS Translation with modular Inclusions Hardware flight configurationsdevelopment and test configurations CLARAty functional modules

Existing Tech Components in MDS on Rocky 7 Hardware Adaptor State Variables EstimatorsControllers Constraint Network ElaboratorsMPE Scheduler Component Scheduler Parameters Proxy State Variables MER NavigationMDS Framework ROAMS SimulationR7 with PPC 750Benchtop Hardware

Other Issues ITAR, IP, open-source, RETF New funded participants: MTP, IS, ASTEP, etc. Possible new unfunded participants CLARAty Development versus User communities - ‘CLARAty to Universities’ study underway - release and core-upgrade management MSL Mission Scenario - nonzero chance of change to fixed lander - level of autonomy continues to change