Autonomy: Executive and Instruments Life in the Atacama 2004 Science & Technology Workshop Nicola Muscettola NASA Ames Reid Simmons Carnegie Mellon.

Slides:



Advertisements
Similar presentations
Making the System Operational
Advertisements

The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
MotoHawk Training Model-Based Design of Embedded Systems.
Solar-B FPP 1 Ted Tarbell, TRACE Operations 3 February 2003 MODA Mtg, ISAS The TRACE Model for Operations Ted Tarbell
Software development in robotics: frameworks, tools and the OpenRDK D. Calisi.
Susanne Biundo, Karen Myers, Kanna Rajan How is Planning & Scheduling Changing the World?
“Modeling the MER Mission” Chin Seah NASA Ames Research Center.
GLAST LAT ProjectISOC Peer Review - March 2, 2004 Document: LAT-PR Section 2.1 Requirements 1 Gamma-ray Large Area Space Telescope GLAST Large.
Safeguarding the Three Corner Sat Constellation By Stephen Levin-Stankevich Stephen Nauman.
Simulating A Satellite CSGC Mission Operations Team Cameron HatcherJames Burkert Brandon BobianAleks Jarosz.
SIMULATING ERRORS IN WEB SERVICES International Journal of Simulation: Systems, Sciences and Technology 2004 Nik Looker, Malcolm Munro and Jie Xu.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Software Verification and Validation (V&V) By Roger U. Fujii Presented by Donovan Faustino.
LÊ QU Ố C HUY ID: QLU OUTLINE  What is data mining ?  Major issues in data mining 2.
April 2003 Atacama Expedition HCI Field Research Report Angela Wagner Kristina McBlain.
Chapter 3 Memory Management: Virtual Memory
All rights reserved © Altec ExoMars 2018 Rover Operations Control Centre Available Tools for planning and Data Processing I. Musso.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Carnegie Mellon Life in the Atacama, Design Review, December 19, 2003 Science Planner Science Observer Life in the Atacama Design Review December 19, 2003.
Protocol Architectures. Simple Protocol Architecture Not an actual architecture, but a model for how they work Similar to “pseudocode,” used for teaching.
MARCH 27, Meeting Agenda  Prototype 1 Design Goals  Prototype 1 Demo  Framework Overview  Prototype 2 Design Goals  Timeline Moving Forward.
Cooperating AmigoBots Framework and Algorithms
Life in the Atacama, Design Review, December 19, 2003 Carnegie Mellon SPI and Context Imagers Life in the Atacama Design Review December 19, 2003 Stuart.
SPACE TELESCOPE SCIENCE INSTITUTE Operated for NASA by AURA COS Pipeline Language(s) We plan to develop CALCOS using Python and C Another programming language?
Cluster Reliability Project ISIS Vanderbilt University.
1 Software Testing and Quality Assurance Lecture 33 – Software Quality Assurance.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
1 Description and Benefits of JWST Commanding Operations Concept TIPS/JIM Meeting 17 July 2003 Vicki Balzano.
Science Investigation Life in the Atacama 2004 Science & Technology Workshop Nathalie A. Cabrol NASA Ames.
.1 RESEARCH & TECHNOLOGY DEVELOPMENT CENTER SYSTEM AND INFORMATION SCIENCES JHU/MIT Proprietary Titan MESSENGER Autonomy Experiment.
Chapter 4 Realtime Widely Distributed Instrumention System.
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.
DSL Distributed Systems Laboratory ATC 23 August Model Mission: Magnetospheric Multiscale (MMS) Mission Goal “To study the microphysics of three.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
1 Extending FPGA Verification Through The PLI Charles Howard Senior Research Engineer Southwest Research Institute San Antonio, Texas (210)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
Fault Tolerance Benchmarking. 2 Owerview What is Benchmarking? What is Dependability? What is Dependability Benchmarking? What is the relation between.
Accelerated Long Range Traverse (ALERT) Paul Springer Michael Mossey.
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Autonomy for General Assembly Reid Simmons Research Professor Robotics Institute Carnegie Mellon University.
Carnegie Mellon Zoë Vehicle Controller Design Design Review December 19, 2003 Michael Wagner 
Ground-Truth Strategy Life in the Atacama 2004 Science & Technology Workshop Edmond A. Grin NASA Ames.
Aquarius Mission Simulation A realistic simulation is essential for mission readiness preparations This requires the ability to produce realistic data,
CSI 1340 Introduction to Computer Science II Chapter 1 Software Engineering Principles.
A Binary Agent Technology for COTS Software Integrity Anant Agarwal Richard Schooler InCert Software.
Space Systems Laboratory Massachusetts Institute of Technology AUTONOMY MIT Graduate Student Open House March 24, 2000.
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.
T EST T OOLS U NIT VI This unit contains the overview of the test tools. Also prerequisites for applying these tools, tools selection and implementation.
Remote Operations Methods & Plan Life in the Atacama 2004 Science & Technology Workshop Nathalie A. Cabrol NASA Ames.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Avatar Explore PROPOSAL NUMBERS Not available SCIENCE TEAM Erick Dupuis, Canadian Space Agency RESEARCH OBJECTIVES Demonstrate an operational and technical.
Scarab Autonomous Traverse Carnegie Mellon December 2007 David Wettergreen.
Ocean Observatories Initiative OOI CI Kick-Off Meeting Devils Thumb Ranch, Colorado September 9-11, 2009 Observation Planning and Autonomous Mission Execution.
Mission Planning Life in the Atacama 2004 Science & Technology Workshop Paul Tompkins Carnegie Mellon.
1 Science Goal Monitor (SGM) Code 588 / Jenny Geiger.
Life in the Atacama, Design Review, December 19, 2003 Carnegie Mellon Software Architecture Life in the Atacama Design Review December 19, 2003 David Wettergreen.
NASA Ames Research Center
Project and Workshop Objectives
Maintaining software solutions
Navigation Life in the Atacama 2005 Science & Technology Workshop January 6-7, 2005 Dominic Jonak Carnegie Mellon.
AI in Space – Lessons From NASA’s Deep Space 1 Mission
Lecture 09:Software Testing
PRPv1 Discussion topics
EKSE: A Command Line Interface for EGS-CC based Systems
Presentation transcript:

Autonomy: Executive and Instruments Life in the Atacama 2004 Science & Technology Workshop Nicola Muscettola NASA Ames Reid Simmons Carnegie Mellon

Life in the Atacama 2004 Workshop1Carnegie Mellon Outline Rover Executive (RE) and Instrument Manager (IM): functionalities Brief technologic background Status Expectations for 2004 Field campaign

Life in the Atacama 2004 Workshop2Carnegie Mellon Functionality Goal: provide high-level rover control that is: on-board goal-directed context-aware robust easily reconfigurable … in other words, the rover’s conscience

Life in the Atacama 2004 Workshop3Carnegie Mellon Software functional diagram Mapper Health Monitor Rover Executive Vehicle Controller Mission Planner Far-field Evaluator Images Odometry Rover Interface Science Planner Stop Navigator Curve & Speed State Observer State Instrument Controllers Science Interface Near-field Detector Position Estimator State Telemetry Manager Plans Proprioception Images Commands Data Waypoints Telemetry Measurements Positions State (All) Faults Plans Goals Geom.Eval. Actions Instrument Manager

Life in the Atacama 2004 Workshop4Carnegie Mellon Rover Executive Activates planning (both Mission and Science) and receives plans to execute Keeps track of status of controlled software modules Executes recovery actions when faults occur Anomalous execution condition Task timeout or early end Software error causing software module crash Requests replanning in case of fault/opportunity

Life in the Atacama 2004 Workshop5Carnegie Mellon Instrument Manager Implements “science observation” interface to instruments “SPI Mosaic” rather than individual SPI commands in science planner Implements tightly coordinated multi-instrument observations Commands instrument calibration from information on (multi-)instrument performance Implements context-sensitive data cataloging Recovers from instrument faults

Life in the Atacama 2004 Workshop6Carnegie Mellon Rover Executive: Model-Based Planning Plan Runner Agent Relay Search Engine Plan Database Model Search Control

Life in the Atacama 2004 Workshop7Carnegie Mellon Instrument Manager: Procedural Execution Agent Relay Interface Model Procedures Store Active Procedure

Life in the Atacama 2004 Workshop8Carnegie Mellon Advantages of approach Unlike traditional flight software, task coordination information is explicit In model -> constraints “do A while B” In procedure -> tasks and links in task structure Addresses key complexity of complex flight software Correctness of interaction between parallel tasks If task coordination is explicit, it can be inspected, analyzed and tested with automated tools Expected result: more robust software decrease in time and cost to produce validated software

Life in the Atacama 2004 Workshop9Carnegie Mellon Reason for differences Rover Executive Coordination of larger number of parallel faults Ability to modify a run-time constraints without having to re-compile code Coordination between tasks does not need to be programmed Instrument Manager Programming with procedures is perceived as more natural especially for nominal operations Less overhead due to planning, faster reactions

Life in the Atacama 2004 Workshop10Carnegie Mellon Rover Executive: Fault Recovery Status Tested multiple fault recoveries in simulation Ready to go for field test on rover

Life in the Atacama 2004 Workshop11Carnegie Mellon Rover Executive: Performance Nominal Execution Multiple Fault Recoveries

Life in the Atacama 2004 Workshop12Carnegie Mellon Instrument Manager: Interfaces to instrument controllers Instrument Manager can currently command the SPI and PTU controllers (e.g., take a panorama) Current API implementation not frozen SPIcontroller connected to hardware PTUoperates with stubs FI VNSearly phase of API design Plow

Life in the Atacama 2004 Workshop13Carnegie Mellon Expectation for field campaign Rover Executive 2004: operate rover for one day without human intervention in the presence of faults 2005: demonstrate quick modification of onboard control model while mission is ongoing Instrument Manager 2004: execution of single and multiple instrument complex observations 2005: dynamic instrument calibration and instrument fault handling

Life in the Atacama 2004 Workshop14Carnegie Mellon Requirements for field campaign Logging on message incoming and outgoing message traffic Internal logs Ability to inject all faults and explicit field scenario that excercize all of them.