html5-img
1 / 87

Model-based Programming of Cooperating Explorers

Model-based Programming of Cooperating Explorers. Brian C. Williams CSAIL Dept. Aeronautics and Astronautics Massachusetts Institute of Technology. Programming Long-lived Embedded Systems. Large collections of devices must work in concert to achieve goals

ivo
Télécharger la présentation

Model-based Programming of Cooperating Explorers

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. Model-based Programming of • Cooperating Explorers • Brian C. Williams • CSAIL • Dept. Aeronautics and Astronautics • Massachusetts Institute of Technology

  2. Programming Long-lived Embedded Systems • Large collections of devices must work in concert to achieve goals • Devices indirectly observed and controlled • Need quick, robust response to anomalies throughout life • Must manage large levels of redundancy

  3. Coordination Recapitulated At The • Level of Cooperating Explorers (Courtesy of Jonathan How. Used with permission.)

  4. Coordination Issues Increase For • Dexterous Explorers (Courtesy of Frank Kirchner. Used with permission.)

  5. Outline • Model-based Programming • Autonomous Engineering Operations • – An Example • – Model based Execution • – Fast Reasoning using Conflicts • Cooperating Mobile Vehicles • – Predictive Strategy Selection • – Planning Out The Strategy

  6. Approach • Elevate programming and operation to • system-level coaching. • Model-based Programming • – State Aware: Coordinates behavior at the level • of intended state. •  Model-based Execution • – Fault Aware: Uses models to achieve intended • behavior under normal and faulty conditions.

  7. Why Model-based Programming? • Polar Lander Leading Diagnosis: • Legs deployed during descent. • Noise spike on leg sensors • latched by software monitors. • Laser altimeter registers 40m. • Begins polling leg monitors to determine touch down. • Read latched noise spike as touchdown. • Engine shutdown at ~40m. • Programmers often make • commonsense mistakes when • reasoning about hidden state. Objective: Support programmers with embedded languages that avoid these mistakes, by reasoning about hidden state automatically. Reactive Model-based Programming Language (RMPL)

  8. Model-based Programs • Interact Directly with State • Embedded programs interact with Model-based programs • plant sensors and actuators: interact with plant state: • Read sensors • Read state • Set actuators • Write state • Model-based • Embedded Program Embedded Program Obs Cntrl S Plant S’ Model-based Executive • Obs Cntrl • S • Plant Programmer must map between Model-based executive maps state and sensors/actuators. between state and sensors/actuators.

  9. RMPL Model-based Program Titan Model-based Executive Control Program • Executes concurrently • Preempts • Queries (hidden) states • Asserts (hidden) state Generates target goal states conditioned on state estimates • State goals • Tracks least • cost goal states System Model • State estimates • Tracks • likely • plant states Valve Stuck open • 0.01 • 0. 01 Open • Open Close • 0. 01 • Closed Stuck closed Observations Commands 0. 01 Plant inflow = outflow = 0

  10. Outline • Model-based Programming • Autonomous Engineering Operations • – An Example • – Model based Execution • – Fast Reasoning using Conflicts • Cooperating Mobile Vehicles • – Predictive Strategy Selection • – Planning Out The Strategy

  11. Motivation Mission-critical sequences: • Launch & deployment • Planetary fly-by • Orbital insertion • Entry, descent & landing images courtesy of NASA (Courtesy of Mitch Ingham. Used with permission.)

  12. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude separate lander (Courtesy of Mitch Ingham. Used with permission.)

  13. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude Descent engine to “standby”: separate lander (Courtesy of Mitch Ingham. Used with permission.)

  14. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude separate lander • Spacecraft approach: • 270 mins delay • relative position wrt Mars not • observable • based on ground computations • of cruise trajectory (Courtesy of Mitch Ingham. Used with permission.)

  15. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude separate lander • Switch navigation mode: • “Inertial” = IMU only (Courtesy of Mitch Ingham. Used with permission.)

  16. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude separate lander • Rotate spacecraft: • command ACS to entry orientation (Courtesy of Mitch Ingham. Used with permission.)

  17. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude separate lander • Rotate spacecraft: • once entry orientation achieved, • ACS holds attitude (Courtesy of Mitch Ingham. Used with permission.)

  18. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude Separate lander from cruise stage: separate lander cruise stage lander stage pyro latches (Courtesy of Mitch Ingham. Used with permission.)

  19. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude • Separate lander from cruise stage: • when entry orientation achieved, • fire primary pyro latch separate lander cruise stage lander stage pyro latches (Courtesy of Mitch Ingham. Used with permission.)

  20. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude • Separate lander from cruise stage: • when entry orientation achieved, • fire primary pyro latch separate lander cruise stage lander stage (Courtesy of Mitch Ingham. Used with permission.)

  21. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude • Separate lander from cruise stage: • in case of failure of primary latch, • fire backup pyro latch separate lander cruise stage lander stage (Courtesy of Mitch Ingham. Used with permission.)

  22. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude • Separate lander from cruise stage: • in case of failure of primary latch, • fire backup pyro latch separate lander cruise stage lander stage (Courtesy of Mitch Ingham. Used with permission.)

  23. Mars Entry Example engine to standby planetary approach switch to inertial nav rotate to entry-orient & hold attitude • simple state-based control • specifications separate lander • models are writable/inspectable by • systems engineers • handle timed plant & control • behavior • automated reasoning through low- • level plant interactions • fault-aware (in-the-loop recoveries) (Courtesy of Mitch Ingham. Used with permission.)

  24. Descent Example Turn camera off and engine on EngineA EngineB EngineA EngineB Science Camer Science Camera

  25. Model-based Program Control program specifies state trajectories: • OrbitInsert():: • (do-watching ((EngineA = Thrusting) OR • (EngineB = Thrusting)) • fires one of two engines • sets 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 • Plant Model describes behavior of each component: • – Nominal and Off nominal • – qualitative constraints • – likelihoods and costs • (parallel • (EngineA = Standby) • (EngineB = Standby) • (Camera = Off) • (do-watching (EngineA = Failed) • (when-donext ( (EngineA = Standby) AND • (Camera = Off) ) • (EngineA = Thrusting))) • (when-donext ( (EngineA = Failed) AND • (EngineB = Standby) AND • (Camera = Off) ) • (EngineB = Thrusting))))

  26. Plant Model • component modes… • described by finite domain constraints on variables… • deterministic and probabilistic transitions • cost/reward Camera Model Engine Model (thrust = zero) AND (power_in = zero) Off (power_in = zero) AND (shutter = closed) Off off- cmd standby- cmd Failed (thrust = zero) AND (power_in = nominal) turnoff – cmd turnoff – cmd Standby fire- cmd standby- cmd • (thrust = full) AND • (power_in = nominal) On (power_in = nominal) AND (shutter = open) Firing one per component … operating concurrently

  27. Example: The model-based program sets engine = thrusting, and the deductive controller . . . . Mode Estimation Mode Reconfiguration Oxidizer tank Fuel tank Selects valve configuration; plans actions to open six valves • Deduces that • thrust is off, and • the engine is healthy Deduces that a valve failed - stuck closed Determines valves on backup engine that will achieve thrust, and plans needed actions Mode Reconfiguration Mode Estimation

  28. Outline • Model-based Programming • Autonomous Engineering Operations • – An Example • – Model based Execution • – Fast Reasoning using Conflicts • Cooperating Mobile Vehicles • – Predictive Strategy Selection • – Planning Out The Strategy

  29. Modeling Plant Dynamics using Probabilistic • Concurrent, Constraint Automata (PCCA) • Compact Encoding: • – Concurrent probabilistic transitions • – State constraints between variables Camera Model Engine Model (thrust = zero) AND (power_in = zero) (power_in = zero) AND (shutter = closed) Off off- cmd standby- cmd Failed turnoff – cmd turnoff – cmd Off Standby fire- cmd standby- cmd • (thrust = full) AND • (power_in = nominal) (thrust = zero) AND (power_in = nominal) On (power_in = nominal) AND (shutter = open) Firing Typical Example (DS1 spacecraft): – 80 Automata, 5 modes on average – 3000 propositional variables, 12,000 propositional clauses

  30. A set of concurrent transitions, one per automata (e.g., 80). • Previous & Next states consistent with source & target of transitions • Assigns a value to each variable (e.g.,3,000 vars). • Consistent with all state constraints (e.g., 12,000).

  31. RMPL Model-based Program Titan Model-based Executive Control Program Control Sequencer: • Executes concurrently • Preempts • Asserts and queries states • Chooses based on reward Generates goal states conditioned on state estimates State estimates State goals Mode Estimation: Tracks likely States MAINTAIN(EAR OR EBR) Orbitlnsert(): (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)))) LEGENO: EAS (EngineA=Standby) EAF (EngineA=Failed) EAR (EngineA=Firing) EBS (EngineB=Standby) EBF (EngineB=Failed) EBR (EngineB=Firing) CO (Camera=Off) EAS EBS CO Observations Plant MAINTAIN(EAF) (EAS AND CO) EAS AND CO EAR (EAF AND EBS AND CO) EAF AND EBS AND CO EBR hierarchical constraint automata on state s

  32. RMPL Model-based Program Titan Model-based Executive X0 X1 XN-1 XN X0 X1 XN-1 XN S T Control Program Control Sequencer: • Executes concurrently • Preempts • Asserts and queries states • Chooses based on reward Generates goal states conditioned on state estimates State estimates State goals Mode Estimation: Tracks likely States Mode Reconfiguration: Tracks least-cost state goals Commands Observations Plant Valve fails stuck closed Fire backup engine X0 X1 XN-1 XN X0 X1 XN-1 XN least cost reachable goal state Current Belief State First Action

  33. Mode XN XN S T arg min RT*(m') s.t. M(m') entails G(m') s.t. M(m') is satisfiable arg max PT(m') s.t. M(m')^O(m') is satisfiable State estimates State goals OpSat: arg min f(x) s.t. C(x) is satisfiable D(x) is unsatisfiable Mode Estimation: Tracks likely States Mode Reconfiguration: Tracks least-cost state goals Commands Observations Plant Valve fails stuck closed Fire backup engine X0 X1 XN-1 XN X0 X1 XN-1 XN least cost reachable goal state Current Belief State First Action

  34. Outline • Model-based Programming • Autonomous Engineering Operations • – An Example • – Model based Execution • – Fast Reasoning using Conflicts • Cooperating Mobile Vehicles • – Predictive Strategy Selection • – Planning Out The Strategy

  35. Symptom A 1 1 1 Or1 X 0 F B 1 AND1 1 C 1 1 Y Or2 D G 1 AND2 Z E Or3 0 Diagnosis Formulation Consistency-based Diagnosis:Given symptoms, find diagnoses that are consistent with symptoms. Handle Novel Failures by Suspending Constraints:Make no presumptions about faulty component behavior.

  36. Symptom A 1 1 1 X 0 F B 1 AND1 1 C 1 1 Y Or2 D G 1 AND2 Z E Or3 0 Diagnosis Formulation Consistency-based Diagnosis:Given symptoms, find diagnoses that are consistent with symptoms. Handle Novel Failures by Suspending Constraints:Make no presumptions about faulty component behavior.

  37. Fast Reasoning Through Conflict • When you have eliminated the impossible, whatever remains, however improbable, must be the truth. -Sherlock Holmes. The Sign of the Four. • Test Hypothesis • If inconsistent, learn reason for inconsistency (a Conflict). • Use conflicts to leap over similarly infeasible options to next best hypothesis.

  38. Compare Most Likely Hypothesis to Observations Helium tank Oxidizer tank Fuel tank Flow1 = zero Pressure1 = nominal Pressure2 = nominal Main Engines Acceleration = zero It is most likely that all components are okay.

  39. Isolate Conflicting Information Helium tank Oxidizer tank Fuel tank Flow1= zero • Main • Engines The red component modes conflict with the model and observations.

  40. Leap to the Next Most Likely Hypothesis that Resolves the Conflict Helium tank Oxidizer tank Fuel tank Flow1= zero • Main • Engines The next hypothesis must remove the conflict

  41. New Hypothesis Exposes Additional Conflicts Helium tank Oxidizer tank Fuel tank Pressure2 = nominal Pressure1 = nominal • Main • Engines Acceleration = zero Another conflict, try removing both

  42. Final Hypothesis Resolves all Conflicts Helium tank Oxidizer tank Fuel tank Pressure1 = nominal Flow1 = zero Pressure2= nominal Flow2 = positive • Main • Engines Acceleration = zero Implementation: Conflict-directed A* search.

  43. A* Increasing Cost Infeasible Feasible

  44. Conflict-directed A* Increasing Cost Infeasible Feasible

  45. Conflict-directed A* Increasing Cost • Conflict 1 • Infeasible Feasible

  46. Conflict-directed A* Increasing Cost • Conflict 1 • Infeasible • Conflict 2 • Feasible • Conflicts are mapped to • feasible regions as implicants • (Kernel Assignments) • Want kernel assignment • containing the best cost state.

  47. Outline • Model-based Programming • Autonomous Engineering Operations • An Example • Model based Execution • Fast Reasoning using Conflicts • Cooperating Mobile Vehicles • Predictive Strategy Selection • Planning Out The Strategy

  48. Coordination is Recapitulated at theLevel of Cooperating Explorers (Courtesy of Jonathan How. Used with permission.)

  49. Traditional Robot Architectures • Explicit human guidance is at the lowest levels Goals Action descriptions Planning and Scheduling Goal-directed Execution Goal-directed Programs Reactive Behaviors

  50. RMPL for Robotics Reactive Model-based Programming Language(PMPL) Model-based Executive Control Programs Goal-directed Execution Plant Models Deductive Controllers What types of reasoning should the programmer/operator guide? • State/mode inference • Machine control • Scheduling • Method selection • Roadmap path planning • Optimal trajectory planning • Generative temporal planning

More Related