NASA Ames Research Center

Slides:



Advertisements
Similar presentations
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

Design Concepts and Principles
WPI CS534 Showcase Jeff Martin. * Computer Software on Deep Space 1 * Used to execute plans/mission objectives * Model based * Constraint based * Fault.
Dale E. Gary Professor, Physics, Center for Solar-Terrestrial Research New Jersey Institute of Technology 1 3/16/2012OVSA Preliminary Design Review.
Susanne Biundo, Karen Myers, Kanna Rajan How is Planning & Scheduling Changing the World?
“Modeling the MER Mission” Chin Seah NASA Ames Research Center.
1 Software Testing and Quality Assurance Lecture 15 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
© Lethbridge/Laganière 2001 Chapter 7: Focusing on Users and Their Tasks1 7.1 User Centred Design (UCD) Software development should focus on the needs.
April 2003 Atacama Expedition HCI Field Research Report Angela Wagner Kristina McBlain.
Visual 3. 1 Lesson 3 Risk Assessment and Risk Mitigation.
Katanosh Morovat.   This concept is a formal approach for identifying the rules that encapsulate the structure, constraint, and control of the operation.
Carnegie Mellon Life in the Atacama, Design Review, December 19, 2003 Science Planner Science Observer Life in the Atacama Design Review December 19, 2003.
Mobile Robot Control Architectures “A Robust Layered Control System for a Mobile Robot” -- Brooks 1986 “On Three-Layer Architectures” -- Gat 1998? Presented.
1. 2 Purpose of This Presentation ◆ To explain how spacecraft can be virtualized by using a standard modeling method; ◆ To introduce the basic concept.
1 Description and Benefits of JWST Commanding Operations Concept TIPS/JIM Meeting 17 July 2003 Vicki Balzano.
.1 RESEARCH & TECHNOLOGY DEVELOPMENT CENTER SYSTEM AND INFORMATION SCIENCES JHU/MIT Proprietary Titan MESSENGER Autonomy Experiment.
Carnegie Mellon Zoë Computing Design Design Review December 19, 2003 Michael Wagner 
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Framework for MDO Studies Amitay Isaacs Center for Aerospace System Design and Engineering IIT Bombay.
University of Windsor School of Computer Science Topics in Artificial Intelligence Fall 2008 Sept 11, 2008.
Network UAV C3 Stage 1 Final Briefing Timothy X Brown University of Colorado at Boulder Interdisciplinary Telecommunications Program Electrical and Computer.
1 Structure of Aalborg University Welcome to Aalborg University.
31 March 2009 MMI OntDev 1 Autonomous Mission Operations for Sensor Webs Al Underbrink, Sentar, Inc.
6/23/2005 R. GARDNER OSG Baseline Services 1 OSG Baseline Services In my talk I’d like to discuss two questions:  What capabilities are we aiming for.
Mike Graves Summer 2005 University of Texas at Dallas Implicit Invocation: The Task Control Architecture Mike Graves CS6362 Term Paper Dr. Lawrence Chung.
1 Earth Science Technology Office The Earth Science (ES) Vision: An intelligent Web of Sensors IGARSS 2002 Paper 02_06_08:20 Eduardo Torres-Martinez –
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
June 28, 2000 Architecture Review 1 Examples: Implementing Common Solutions within CLARAty.
ESA Harwell Robotics & Autonomy Facility Study Workshop Autonomous Software Verification Presented By: Rick Blake.
SAS_05_Contingency_Lutz_Tal1 Contingency Software in Autonomous Systems Robyn Lutz, JPL/Caltech & ISU Doron Tal, USRA at NASA Ames Ann Patterson-Hine,
Rover and Instrument Capabilities Life in the Atacama 2004 Science & Technology Workshop Michael Wagner, James Teza, Stuart Heys Robotics Institute, Carnegie.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Autonomy: Executive and Instruments Life in the Atacama 2004 Science & Technology Workshop Nicola Muscettola NASA Ames Reid Simmons Carnegie Mellon.
Scarab Autonomous Traverse Carnegie Mellon December 2007 David Wettergreen.
Mission Planning Life in the Atacama 2004 Science & Technology Workshop Paul Tompkins Carnegie Mellon.
Life in the Atacama, Design Review, December 19, 2003 Carnegie Mellon Software Architecture Life in the Atacama Design Review December 19, 2003 David Wettergreen.
Air Force Institute of Technology
Cognitive Informatics for Biomedicine – Chapter 5
Trey Smith, Robotics Institute, Carnegie Mellon University
Kai Li, Allen D. Malony, Sameer Shende, Robert Bell
Chapter 19: Network Management
Generic Remote Interface Unit (RIU) Interface Control Document (ICD)
OPERATING SYSTEMS CS 3502 Fall 2017
SIE 515 Design Evaluation Lecture 7.
Chapter 4 – Requirements Engineering
Self Healing and Dynamic Construction Framework:
Presented by Munezero Immaculee Joselyne PhD in Software Engineering
What are the key components of your robot?
Project and Workshop Objectives
ISO New England System R&D Needs
Flooding Walkdown Guidance
Intelligent Systems Software Assurance Symposium 2004
Navigation Life in the Atacama 2005 Science & Technology Workshop January 6-7, 2005 Dominic Jonak Carnegie Mellon.
UNCLASSIFIED MASA Sword UNCLASSIFIED.
AI in Space – Lessons From NASA’s Deep Space 1 Mission
Model-Driven Analysis Frameworks for Embedded Systems
The Extensible Tool-chain for Evaluation of Architectural Models
Methodologies For Systems Analysis.
Requirements Analysis
Computational Elements of Robust Civil Infrastructure
Autonomous Integrated Power System Operation & Control
CS 501: Software Engineering Fall 1999
Systems Engineering for Mission-Driven Modeling
Project Introduction Spring 2017.
AIMS Equipment & Automation monitoring solution
Presented By: Darlene Banta
IV&V Planning & Execution Initiative
Review and comparison of the modeling approaches and risk analysis methods for complex ship system. Author: Sunil Basnet.
Presentation transcript:

NASA Ames Research Center Executive(s) Life in the Atacama Design Review December 19, 2003 Nicola Muscettola Vijayakumar Baskaran NASA Ames Research Center NASA Ames Research Center

Description and Motivation Model-Based Executive(s) for LITA Rover Executive Instrument Manager Modules were presented in September 2003 NASA Ames Research Center

Rover Architecture using IDEA Operator Interface Offboard Telemetry Router Mission-level agent Mission Planner Science Planner Waypoints IDEA Mission Executive Mission Executive Status Science Executive System-level agents Waypoint Curvature, Speed & Time Curvature, Speed & Time Navigator Health Monitor Onboard Stop Terrain Evaluation Odometry Stereo Mapper State Estimator Vehicle Controller Status Status Sensors Images NASA Ames Research Center

Description and Motivation Model-Based Executive(s) for LITA Rover Executive Instrument Manager Modules were presented in September 2003 Motivating System Requirements: 3.1, 4.4, 5.4.1 (but what does that mean really?), 5.5, 6.0 NASA Ames Research Center

NASA Ames Research Center Key Requirements Rover Executive: provide goal-driven commanding for high-level traverse and science operations “Go to waypoint” and “Perform Detailed Investigations” Instrument Manager: allows single goal commanding “Do mosaic” instead of sequence of individual snapshots Executive invokes planner(s) if necessary to optimize course of action Executive translates between abstract goals and low-level commands Executive issues commands and responses as a consequence of internal (synchronous) or external (asynchronous) events Executive must be robust to wide range of faults (to be defined) Executive must guarantee response within required time limits NASA Ames Research Center

Software Organization Science Interface Rover Interface Telemetry Goals Science Planner Mission Planner Health Monitor Telemetry Manager Measurements Plans Plans Faults State State Plans Measurements Rover Executive State Observer State (All) Positions Waypoints Stop Actions Instrument Manager Position Estimator Mapper Navigator Odometry Curvature & Speed Far-field Evaluator Near-field Detector Vehicle Controller Instrument Controllers Images Measurements Data Images Proprioception & Sun Image Commands Commands NASA Ames Research Center

Design Considerations Informing Design Principle: The logic of execution and recovery shall be fully inspectable A model-based approach combines a declarative model, a general-purpose plan synthesis engine and heuristics A model-based approach is expected to allow quick incremental encoding of new recoveries from failure conditions as they are discovered Metrics: Coverage of failure conditions Reaction time (as a function of model complexity) The design is influenced from Remote Agent and Gromit rover experience Reimplementation of the DS1 Executive as a model-based system vs the old procedural Executive in ESL Gromit (ATRV Junior) rover executive reimplement PRS-based executive from LAAS/CNRS NASA Ames Research Center

NASA Ames Research Center Technical Approach Multiple executives (Rover Executive and Instrument Manager) vs single executive Coupling between rover components Reaction time Currently focusing on single executive (consistent with Dave’s architecture concept) Modeled constraints can be switched on or off to support direct teleoperation modes (monitored mode of requirements 6.0) NASA Ames Research Center

Implementation Issues Prototype tests Simulator Mission Simulator Facility? Not clear if it is usable for real-time simulation Rover Multi-day scaled-down autonomous traverse with Gromit Expected timeframe: April 2004 Risks Complexity of incremental modeling Mitigations: full engagement of trained Ames personnel, training, better modeling tools/languages Reaction latency Mitigations: faster planning framework (new EUROPA), use of procedural task expansion (TDL) Issues Relation of executive to health monitoring and telemetry server. External modules or internal modules? What happens to executive during hybernation? Current design assumes it is always “active”, i.e., capable of reacting. Is this reasonable? Schedule issues: need to firm up ASAP instrument models, message/command dictionary, mission operations concept. NASA Ames Research Center