1 / 34

Aero/Astro Open House MERS Research Group Model-based Embedded and Robotic Systems Group

Aero/Astro Open House MERS Research Group Model-based Embedded and Robotic Systems Group Space Systems Laboratory Massachusetts Institute of Technology Friday, March 21, 2003. Motivation. Apollo 13 quintuple fault. Autonomous systems handle Faults Anomalies Communication

juro
Télécharger la présentation

Aero/Astro Open House MERS Research Group Model-based Embedded and Robotic Systems Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Aero/Astro Open House MERS Research Group Model-based Embedded and Robotic Systems Group Space Systems Laboratory Massachusetts Institute of Technology Friday, March 21, 2003

  2. Motivation Apollo 13 quintuple fault • Autonomous systems handle • Faults • Anomalies • Communication • Commanding Cooperative Exploration Mars Outpost Earth Imager Europa Probe Distant Explorers Mercury Orbiter Mars Polar Lander failed due to a faulty sensor.

  3. Model-based Programming Paradigm • Spacecraft are highly complex systems, with significant interaction at the subsystem level • Spacecraft encounter harsh, uncertain environments. • Robustness in such systems requires: • high-reliability software; • fault protection built into the control sequence; • highly reactive sense-decide-act loop. • Using traditional embedded software approach, difficult to anticipate such low-level subsystem interaction and explicitly encode responses to each possible fault. Mars ‘98 Polar Lander • Leading Hypothesis: • Legs deploy during descent. • Noise spike on leg sensors latched by s/w monitors. • Laser altimeter registers 50m. • Begins polling leg monitors to determine touchdown. • Latched noise spike read as touchdown. • Engine shutdown at ~50m. • Lander impacts planetary surface at high velocity. Goal: provide an embedded language that operates on system state and reasons from commonsense models

  4. Robust Systems Should be“Fully State Aware” Embedded Program Model-basedEmbedded Program Obs Cntrl S’ Model-based Executive S Plant Obs Cntrl S Plant • Embedded programs interact withthe system’s sensors/actuators: • Read sensors • Set actuators • Model-based programs interact with the system’s state: • Read state • Set state Programmer must map between state and sensors/actuators. M-B Executive maps between states and sensors/actuators.

  5. Titan Model-based Executive e d d _ c RMPL Model-based Executive e d Valve Control Program Sequencer Stuck open 0.01 Configuration goals State estimates Open System Model 0. 01 Mode Estimation Mode Reconfiguration Open Close 0. 01 Stuck closed Closed 0.01 inflow = outflow = 0 Flight System Control Observations Commands RT Control Layer B(t) B(t+1)  S1(t+1) S1(t) S2(t) S2(t+1) … … Sm(t+1) Sn(t) Control • Diagnose and Reconfigure • Compiled Goal Interpreter • Reactive Planner Model • Mode Estimation • Compiled ME • Hybrid ME • Distributed ME Plant

  6. M-B Programming Example:Orbital Insertion Scenario Engine Model (thrust = zero) AND (power_in = zero) Off 0.01 off- cmd Failed standby- cmd (thrust = zero) AND (power_in = nominal) 0.01 EngineA EngineB EngineA EngineB Standby fire- cmd standby- cmd 0.01 (thrust = full) AND (power_in = nominal) Firing Science Camera Science Camera Systems engineers think in terms of state trajectories: Camera Model Off • must fire one of the two engines • set both engines to ‘standby’ • prior to firing engine, camera must be turned off to avoid plume contamination • in case of primary engine failure, fire backup engine instead (power_in = zero) AND (shutter = closed) turnoff- cmd turnon- cmd (power_in = nominal) AND (shutter = open) On

  7. M-B Programming Example:Orbital Insertion Scenario • Model-based Programming provides a way to encode the prescribed state trajectory into a control program: • assert and check states which may be “hidden”, rather than operating directly on observable or control variables • allow for embedded management of fault states RMPL code for OrbitInsert control program: (do-watching ((EngineA = Firing)OR (EngineB = Firing)) (parallel (EngineA = Standby) (EngineB = Standby) (Camera = Off) (do-watching (EngineA = Failed) (when-donext( (EngineA = Standby) AND (Camera = Off) ) (EngineA = Firing))) (when-donext ( (EngineA = Failed)AND (EngineB = Standby) AND (Camera = Off) ) (EngineB = Firing)))) goal is to fire one of the two engines; terminate when accomplished concurrently sets both engines to ‘standby’, and turns off camera to avoid plume contamination once primary engine is in standby and camera is off, proceed to fire engine (preempt this operation if engine is ever found to be in a faulty state) in case of primary engine failure, fire backup engine instead

  8. Mode Estimation Example S1 Configuration Goal: Engine A = Firing Observation: Thrust = 0 Engine A S2 Possible Diagnoses Engine A Engine A S3 Engine A

  9. Hybrid Model-based Programming:Motivation Mars Entry, Descent & Landing lander separates when entry attitude is achieved chute deploys when velocity drops to 493 m/s legs deploy 10 secs after heatshield is jettisoned chute jettisoned at 1300m, lander performs controlled gravity turn maneuver • Tight coupling of attitude/position control and spacecraft configuration control • Mars ‘98 mission failure demonstrates need for improved robustness in this type of “critical sequence” • To achieve this level of robustness, need to track and control both discrete and continuous spacecraft states (“hybrid” system)

  10. Hybrid Mode Estimation – Gesture Recognition • Robonaut – EVA astronaut’s assistant • Humanoid design requires no specialized robotic tools • Controlled by tele-operator, but autonomous modes under development • Stereo vision system • Tracks head and hand motion of human associate • Hybrid model of human associate supports Robonaut’s recognition of human gestures • Gestures of interest include pointing to a tool, holding hand up to indicate stop, “come closer” gestures, etc. • Continuous dynamics model of human arm includes inertial and damping terms • HMM model takes output of stereo vision system as observation • Transitions between motion control point states

  11. Mode Reconfiguration RMPL Model-based Executive Configuration goals Control Program Sequencer Current State Goal Interpreter State estimates Configuration goals System Model Goal State Mode Estimation Mode Reconfiguration Reactive Planner Command Flight System Control Observations Commands RT Control Layer INPUT • Configuration Goal • Trust = on • Current State • Tank = full • Pressure = nominal • Driver = off • Valve = closed • Thruster = off OUPUT • Command • Turn driver on

  12. Goal Interpreter Configuration goals Current State Goal Interpreter Goal State INPUT • Current State • Tank = full • Pressure = nominal • Driver = off • Valve = closed • Thruster = off • Configuration Goal • Trust = on OUPUT • Goal State • Tank = full • Pressure = nominal • Driver = off • Valve = on • Thruster = on Generate optimal goal state that achieves the Configuration Goal! • Goal Interpreter • Compiled Goal Interpreter Minimize online deduction by generating all partial goal interpretation offline! Online: Goal Configuration Goal State Partial Goal Interpretation Best-first Kernel Goal State Generator

  13. Example: The model-based program sets the state to thrusting, and the deductive controller . . . . Oxidizer tank Fuel tank Plans actions to open six valves Deduces that thrust is off, andthe engine is healthy Deduces that a valve failed - stuck closed Determines that valves on the backup enginewill achieve thrust, andplans needed actions.

  14. Reactive Planner Goal State Current State Reactive Planner Command INPUT • Current State • Tank = full • Pressure = nominal • Driver = off • Valve = closed • Thruster = off • Goal State • Tank = full • Pressure = nominal • Driver = off • Valve = on • Thruster = on OUPUT • Command • Turn driver on • Planner guarantees to: • Only generate non-destructive actions • Never propose actions that lead to dead-end plans • Ensure progress toward the goal • Operate at reactive time scale Driver Valve Reconfiguration Order • Tank = full • Pressure = nominal • Valve = on • Thruster = on • Driver = off Goal Goal Current Current On Open Off Closed idle cmd = off idle driver = on cmd = close On Open cmd = on idle driver = on cmd = open idle Off Closed cmd = reset cmd = off fail fail Resettable Stuck

  15. Divide and Conquer • Structural Decomposition • Compile model structure into equivalent tree structure • Effort depends on structural properties (graph width) • Reasoning on equivalent tree structure is very efficient (highly parallelizable) => Distributed Algorithm Precompilation PlantStructure(cyclic) TreeDecomposition(acyclic)

  16. Generate a plan for each grouped components. Execute each plan one at a time to achieve the goal Planning through Divide-and-Conquer Goal On Off Current Goal idle comp = on cmd = off On OffT, OffA OffT, OnA OnT, OnA OnT, OffA Current comp = on cmd = on idle Off idle comp = on bus = on cmdA = off comp = on bus = on cmdA = off fail OnT, OnA comp = on bus = on cmdA = on idle bus = on cmdT = off fail OnT, OffA comp = on bus = on cmdT = on comp = on bus = on cmdT = on idle fail OffT, OffA comp = on bus = on cmdA = off comp = on bus = on cmdA = off comp = on bus = on cmdA = off idle OffT, OnA Computer Antenna Transmitter Amplifier Bus Control Antenna Transmitter Amplifier

  17. Simulate Mission Objective of Mars ’03 Use NASA’s MERBoard to visualize the environment and control the rovers. Demonstrate the ability to achieve mission autonomously MIT-NASA Ames Mars ’03 Simulation Center Analyze this rock!

  18. Future Missions SPHERES MER 2003 Mars 2007 Courtesy JPL

  19. New Slides

  20. Plant Model Implementation

  21. Next Generation RMPL • Tentatively called ROOMPL, for “Reactive, Object-Oriented Model-based Programming Language”. Language Design Goals • Surface / Syntax • consistent, across plant and control specifications. • analyzable, for static (i.e. pre-runtime) correctness. • Below the Surface • extensible – amenable to language experimentation by non-programming language experts. • Long Term • apply to general purpose programming domains. • dynamic, reflective.

  22. Plant Models • instances of “primitive classes” are CCA’s (MPL components)

  23. Example: Engine models

  24. Control Programs • Instances of non-primitive classes are HCA’s • Classes still have modes • Goals established with try blocks • Preemption at block level with watch(similar to RMPL when)

  25. Implementation Notes • Implementing language in OCAML • has a bunch of language hacking tools. • Initially, will generate MOF. • Later, will use C interface to talk to current executive components.

  26. Old Slides

  27. Compiled Mode Estimation 0.084 SL(S) U(S) G(S) 0.002 0.084 0.017 C(V) SH(S) U(S) U(V) B(C) U(C) SL(S) • Dissents represent same model in a smaller theory. • Off-line Operations (Press1 = nom)  G(S)  SH(S)  U(S) (Thrust = on)  O(V)  U(V) .... Model Compilation • On-line Operations • Most Likely Diagnosis: • Sensor = Stuck Low • Valve = Closed • Catalyst Bed = Good Partial Diagnosis Trigger

  28. Mode Estimation RMPL Model-based Executive Control Program Sequencer State estimates Configuration goals System Model Mode Estimation Mode Reconfiguration Flight System Control Observations Commands RT Control Layer • Mode estimation relies on: • Commands • Observations • System Model • Encoded as propositional logic with probabilistic transitions to determine the most likely state of the system. OPSAT

  29. Mode Reconfiguration (GI)

  30. Hybrid Model-based Programming:Approach Model-basedControl Programs S’ Plant Model Model-based Executive Cntrl Obs S Plant • extend M-B Programming to include: • assertion of discrete & continuous states • conditional branching on discrete states, continuous states & time • requires integration of engines for discrete state reconfiguration, and continuous control (e.g. spacecraft attitude control system) • need both discrete & continuous state estimation capability cont. & discrete state estimates attitude & position goals hardware config goals Discrete Controller Hybrid Mode Estimation Continuous Controller Hybrid Model-based Executive

  31. Hybrid Mode Estimation Hybrid Model Continuous Dynamics Hidden Markov Models m1 t11 t13 t12 t21 m3 t22 t23 t33 m2 old estimate: Xk-1={mi,xk-1} newestimate: Xk={mj,xk} X+k-1={mj,xk-1} yc(k) ^ KalmanFilter Bank ^ Xk Mode Estimation xci(k) Pi(k) uc(k-1) Hybrid Mode Estimation tracks a set of trajectories Ck • 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

  32. Plant Model Implementation pt(t) nominal modes t 0.1 0.2 fault modes Pt = 99.9% • Physical plant modeled as Timed Concurrent Constraint Automata: • variant of factored POSMDP (time continuous, but observations and decisions at discrete points) constraints guarded & timed probabilistic transitions modal rewards

More Related