Spacecraft Autonomy Seung H Chung Massachusetts Institute of Technology 16 851 Satellite Engineering Fall 2003 Why Autonomy Failures Anomalies Communication Coordination Courtesy of the Johns Hopkins University Applied Physics Laboratory Used with permission courtesy of NASA JPL courtesy of NASA New Horizons courtesy of NASA JPL Apollo 13 Quintuple fault three shorts tankline and pressure jacket burst panel flies off Europa Probe courtesy of NASA JPL Mars Polar Lander 2 Mars Outpost Massachusetts Institute of Technology Autonomy Technologies Fault Detection Isolation and Recovery Planning Scheduling Intelligent Data Understanding Path Planning Gradient method Mixed integer linear programming Prof John How Graph search Prof Brian Williams Localization Mapping Concurrent mapping and localization Prof John Leonard 3 Massachusetts Institute of Technology Why Fault Detection Isolation Recovery FDIR Improve the likelihood of mission success by minimizing the downtime Increase productivity Prevent loss of opportunities Reduce safety risk For manned missions longer system downtime implies higher risk to the astronauts 4 Massachusetts Institute of Technology FDIR Techniques If then else Hard coded set of FDIR statements Rule based Set of rules written by the engineers Fires a rule i e executes a rule when the rule is satisfied Example 24 ID 1A And Ishunt D 6A for 10 sec then Try Sec Bus Reg Off 27 Red Battery Charger is ON for 5 sec then rule 28 29 stop The core software is reusable Engineers must enumerate all possible faults and combinations thereof along with the corresponding recovery methods Verifying the validity of the rules is difficult 5 Massachusetts Institute of Technology Model based FDIR Technique Engineers model the behavior of the system i e components Computer detects isolates recovers faults by reasoning on the model of the system Both the model and the model based FDIR system can be reused Problem too difficult for a computer Model based FDIR System Observation 6 Command Massachusetts Institute of Technology Planning Scheduling Planning Given Set of actions a system can perform and the associated requirements and effects of the actions Current state Desired goal state Objective Compute a sequence of actions that achieves the desired goal state Scheduling Given Set of tasks to execute and the associated constraints i e time resource Objective Compute the proper order of the tasks that satisfies the constraints 7 Massachusetts Institute of Technology Planning Example Goal Take an image of Alpha Centauri Plan 1 Compute current position and attitude 2 Compute the necessary position and attitude for Alpha Centauri to be in view 3 Initialize and warm up the imaging system 4 Change the position and point toward Alpha Centauri 5 Open the shutter 6 Take image 8 Massachusetts Institute of Technology Why Planning Scheduling Simplify spacecraft commanding Simplify mission operations work Enable timely replanning when necessary without communication time delay issues 9 Massachusetts Institute of Technology Intelligent Data Understanding What is it Knowledge Discovery Is this something new something interesting Pattern Recognition What are the identifiable characteristics Classification and Clustering Does this belong to some category of information Why The communication bandwidth does not allow transmission of all available data Serendipitous events 10 Massachusetts Institute of Technology Remote Agent Experiment 11 Massachusetts Institute of Technology Model based Embedded and Robotic Systems Group Massachusetts Institute of Technology 16 851 Satellite Engineering Fall 2003 Model based Programs Reason in Terms of State Embedded programs interact with the system s sensors actuators Model based programs interact with the system s state Read sensors Read state Set actuators Set state Model based Embedded Program Embedded Program Obs Cntrl S Model based Executive Obs S Plant Cntrl S Plant Programmer must map between state and sensors actuators M B Executive maps between states and sensors actuators 13 Massachusetts Institute of Technology Model based Programming Example Engine Model thrust zero AND power in zero EngineA EngineB EngineA EngineB Off 0 01 offoffcmd thrust zero AND power in nominal 0 01 Standby Science Camera Science Camera Systems engineers think in terms of state trajectories standbystandbycmd thrust full AND power in nominal Failed standbystandbycmd firefirecmd 0 01 Firing goal fire one of the two engines set both engines to standby prior to firing the engine turn the camera off to avoid plume contamination in case of engine failure fire the backup Engineers reason how to achieve state trajectories using component models 14 Camera Model power in zero AND shutter closed Resettable Off 0 01 turnonturnon 0 01 cmd turnoffturnoffcmd power in nominal AND shutter open resetresetcmd On Massachusetts Institute of Technology Model based Executive Executable Specification goal fire one of the two engines set both engines to standby prior to firing the engine turn the camera off to avoid plume contamination in case of engine failure fire the backup Sequencer State Estimate Mode Estimation EngineA Configuration Goals Mode Reconfiguration EngineB Science Camera System Observation 15 Command Massachusetts Institute of Technology Mode Estimation S1 Observation Thrust 0 Engine A S2 Engine A Engine A S3 Possible Diagnoses Configuration Goal Engine A Firing Engine A 16 Massachusetts Institute of Technology Mode Reconfiguration Configuration goals Current State INPUT Configuration Goal GHe Trust on N2H4 Goal Interpreter P Goal State Driver Reactive Planner S Current State Tank full Pressure nominal Driver off Valve closed Thruster off OUPUT Command Command Turn driver on 17 Massachusetts Institute of Technology Hybrid Mode Estimation Failures can manifest themselves through coupling between a system s continuous dynamics and its evolution through different behavior modes must track over continuous state changes and discrete mode changes Symptoms initially on the same scale as sensor actuator noise need to extract mode estimates from subtle symptoms Hybrid Model Continuous Dynamics Hidden Markov Models x k 1 f c1 xc k uc k vc k m1 c yc k g c1 xc k vc k M m1 11 21 12 13 m3 22 m2 23 x k 1 f ci xc k uc k vc k mi c yc k g ci xc k vc k 33 18 Massachusetts Institute of Technology Difficulty with Autonomy Most problems require exponential time Unacceptable for real time systems that have hard