Presentation is loading. Please wait.

Presentation is loading. Please wait.

Model-based Programming of Cooperating Explorers Brian C. Williams CSAIL Dept. Aeronautics and Astronautics Massachusetts Institute of Technology.

Similar presentations


Presentation on theme: "Model-based Programming of Cooperating Explorers Brian C. Williams CSAIL Dept. Aeronautics and Astronautics Massachusetts Institute of Technology."— 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 Embedded Program Model-based Embedded Program Obs Cntrl S Plant Obs Cntrl S Plant S Model-based Executive Programmer must map between Model-based executive maps state and sensors/actuators. between state and sensors/actuators.

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

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 (Courtesy of Mitch Ingham. Used with permission.) Mission-critical sequences: Launch & deployment Planetary fly-by Orbital insertion Entry, descent & landing images courtesy of NASA

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

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

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

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

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

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

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

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

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

21 Mars Entry Example (Courtesy of Mitch Ingham. Used with permission.) engine to standby planetary approach separate lander 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 cruise stage lander stage

22 Mars Entry Example (Courtesy of Mitch Ingham. Used with permission.) engine to standby planetary approach separate lander 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 cruise stage lander stage

23 Mars Entry Example (Courtesy of Mitch Ingham. Used with permission.) engine to standby planetary approach separate lander switch to inertial nav rotate to entry-orient & hold attitude simple state-based control specifications 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)

24 Descent Example Turn camera off and engine on 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 one per component … operating concurrently Engine Model (thrust = zero) AND (power_in = zero) (thrust = full) AND (power_in = nominal) (thrust = zero) AND (power_in = nominal) (power_in = zero) AND (shutter = closed) (power_in = nominal) AND (shutter = open) Off Standby Firing standby- cmd Failed Off On off- cmd standby- cmd fire- cmd turnoff – cmd turnoff – cmd Camera Model

27 Example: The model-based program sets engine = thrusting, and the deductive controller.... Mode Reconfiguration Mode Estimation Oxidizer tank Fuel tank 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 Selects valve configuration; plans actions to open six valves 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 Engine Model (thrust = zero) AND (power_in = zero) (thrust = full) AND (power_in = nominal) (thrust = zero) AND (power_in = nominal) (power_in = zero) AND (shutter = closed) (power_in = nominal) AND (shutter = open) Off Standby Firing standby- cmd Failed Off On off- cmd standby- cmd fire- cmd turnoff – cmd turnoff – cmd Camera Model Modeling Plant Dynamics using Probabilistic Concurrent, Constraint Automata (PCCA) Compact Encoding: – Concurrent probabilistic transitions – State constraints between variables Typical Example (DS1 spacecraft): – 80 Automata, 5 modes on average – 3000 propositional variables, 12,000 propositional clauses

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

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

32 RMPL Model-based ProgramTitan Model-based Executive Control Program Executes concurrently Preempts Asserts and queries states Chooses based on reward Control Sequencer: Generates goal states conditioned on state estimates State estimatesState goals Mode Estimation: Tracks likely States Observations Plant Mode Reconfiguration: Tracks least-cost state goals Commands Valve fails stuck closed Current Belief State Fire backup engine First Action least cost reachable goal state X 0 X 1 X N-1 X N

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

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 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. 1 1 1 1 0 A B C D E X Y Z F G 1 1 1 0 1 Or1 Or2 Or3 AND1 AND2 Symptom

36 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. 1 1 1 1 0 A B C D E X Y Z F G 1 1 1 0 1 Or2 Or3 AND1 AND2 Symptom

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. 1.Test Hypothesis 2.If inconsistent, learn reason for inconsistency (a Conflict). 3.Use conflicts to leap over similarly infeasible options to next best hypothesis.

38 Compare Most Likely Hypothesis to Observations Helium tank Oxidizer tankFuel tank Flow 1 = zero Pressure 1 = nominal Pressure 2 = nominal Acceleration = zero Main Engines It is most likely that all components are okay.

39 Isolate Conflicting Information Helium tank Oxidizer tankFuel tank Flow 1 = 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 tankFuel tank Flow 1 = zero Main Engine s The next hypothesis must remove the conflict

41 New Hypothesis Exposes Additional Conflicts Helium tank Oxidizer tankFuel tank Main Engine s Another conflict, try removing both Pressure 1 = nominal Pressure 2 = nominal Acceleration = zero

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

43 A* Increasin g Cost Infeasible Feasibl e

44 Conflict-directed A* Increasin g Cost Infeasible Feasibl e

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

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

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 the Level 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 Goal-directed Programs Planning and Scheduling Goal-directed Execution Reactive Behaviors

50 RMPL for Robotics 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 Reactive Model-based Programming Language(PMPL) Model-based Executive Control Programs Plant Models Goal-directed Execution Deductive Controllers

51 HOME TWOTWO O NEO NE Landing Site: ABC COLLECTION POINT RENDEZVOUS COLLECTION POINT Enroute Landing Site: XYZ SCIENCE AREA 3 SCIENCE AREA 1SCIENCE AREA 1 Diverge SCIENC E AREA 1 RMPL Model-based ProgramKirk Model-based Executive Control Program z Executes concurrently z Preempts z non-deterministic choice z A[l,u]timing z A at llocation Control Sequencer Predictive Strategy Selection Dynamic Scheduling Ensures Safe Execution Environment Model location estimates location goals Deductive Controller Achieves State via Path Planning Estimates using Localization Observations Commands Plant COLLECTION POINT HOME Landing Site: ABC Landing Site: XYZ Enroute RENDEZVOUS SCIENCE AREA 1 SCIENCE AREA 3 Diverge SCIENCE AREA 1 TVOTVO ONEONE

52 Example Scenario Properties: Mars rover operators have been leery of generative planners. z Are more comfortable with specifying contingencies. z Want strong guarantees of safety and robust to uncertainty. z Global path planning is on the edge Extend RMPL with planner-like capabilities..except planning ON E TW O HOME Landing Site: ABC COLLECTION POINT Enroute RENDEZVOU S Landing Site: XYZ SCIENCE AREA 1 Diverge SCIENCE AREA 1 SCIENCE AREA 3

53 Reactive Model-based Programming Idea: To describe group behaviors, start with concurrent language: p Primitive activities If c next A Conditional execution Unless c next A Preemption A, B Full concurrency Always A Iteration Add temporal constraints: A [l,u] Timing Add choice (non-deterministic or decision-theoretic): Choose {A, B} Contingency Parameterize by location: A at [l]

54 Example Enroute Activity: Enroute Corridor 2 Rendezvou s Corridor 1 Rescue Area

55 RMPL for Group-Enroute Temporal Constraints: Group-Enroute()[l,u] = { choose { do { Group-Fly- Path(PATH1_1,PATH1_2,PATH1_3,RE_POS)[l*90%,u*90%]; } maintaining PATH1_OK, do { Group-Fly- Path(PATH2_1,PATH2_2,PATH2_3,RE_POS)[l*90%,u*90%]; } maintaining PATH2_OK }; { Group-Transmit(OPS,ARRIVED)[0,2], do { Group-Wait(HOLD1,HOLD2)[0,u*10%] } watching PROCEED } at RE_POS }

56 RMPL for Group-Enroute Group-Enroute()[l,u] = { choose { do { Group-Fly- Path(PATH1_1,PATH1_2,PATH1_3,RE_POS)[l*90%,u*90%]; } maintaining PATH1_OK, do { Group-Fly- Path(PATH2_1,PATH2_2,PATH2_3,RE_POS)[l*90%,u*90%]; } maintaining PATH2_OK }; { Group-Transmit(OPS,ARRIVED)[0,2], do { Group-Wait(HOLD1,HOLD2)[0,u*10%] } watching PROCEED } at RE_POS } Location Constraints:

57 RMPL for Group-Enroute Group-Enroute()[l,u] = { choose { do { Group-Fly- Path(PATH1_1,PATH1_2,PATH1_3,RE_POS)[l*90%,u*90%]; } maintaining PATH1_OK, do { Group-Fly- Path(PATH2_1,PATH2_2,PATH2_3,RE_POS)[l*90%,u*90%]; } maintaining PATH2_OK }; { Group-Transmit(OPS,ARRIVED)[0,2], do { Group-Wait(HOLD1,HOLD2)[0,u*10%] } watching PROCEED } at RE_POS } Non-deterministic choice:

58 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

59 HOME TWOTWO O NEO NE Landing Site: ABC COLLECTION POINT RENDEZVOUS COLLECTION POINT Enroute Landing Site: XYZ SCIENCE AREA 3 SCIENCE AREA 1SCIENCE AREA 1 Diverge SCIENC E AREA 1 RMPL Model-based ProgramKirk Model-based Executive Control Program z Executes concurrently z Preempts z non-deterministic choice z A[l,u]timing z A at llocation Environment Model location estimateslocation goals Observations Commands Plant COLLECTION POINT HOME Landing Site: ABC Landing Site: XYZ Enroute RENDEZVOUS SCIENCE AREA 1 SCIENCE AREA 3 Diverge SCIENCE AREA 1 TVOTVO ONEONE Selects consistent threads of activity from redundant methods TracksFinds least locationcost paths Executive pre-plans activities pre-plans paths dynamically schedules [Tsmardinos et al.]

60 Enroute Activity Encoded as a Temporal Plan Network Start with flexible plan representation Activity (or sub-activity) Duration (temporal constraint) Enroute [450,540] Group TraverseGroup Wait Group Transmit Science Target [0, 0] [405, 486] [0, 0] [0, 54] [0, 0] [0, ] [0, 0] [0, 2] [0, 0]

61 Activity (or sub-activity) Duration (temporal constraint) Conditional node Enroute Activity Encoded as a Temporal Plan Network Add conditional nodes Enroute [450,540] Group TraverseGroup Wait Group Transmit Science Target [0, 0] [405, 486] [0, 0] [0, 54] [0, 0] [0, ] [0, 0] [0, 2] [0, 0] 3 Group Traverse [405, 486] 8

62 Enroute Activity Encoded as a Temporal Plan Network Add temporally extended, symbolic constraints Activity (or sub-activity) Duration (temporal constraint) Conditional node Symbolic constraint (Ask,Tell) Enroute [450,540] Group Traverse Group Wait Group Transmit Science Target [0, 0] [405, 486] [0, 0] [0, 54] [0, 0] [0, ] [0, 0] [0, 2] [0, 0] 3 Group Traverse [405, 486] 8 Ask( PATH1 = OK) Ask( PATH2 = OK) Ask( EXPLORE = OK) 671112 13

63 Instantiated Enroute Activity Add environmental constraints Activity (or sub-activity) Duration (temporal constraint) Conditional node Symbolic constraint (Ask,Tell)External constraints Group-Enroute [500,800] Group Traverse Group Wait Group Transmit Science Target [405, 486] [0, 54] [0, 2] 3 Group Traverse [405, 486] 8 Ask( PATH1 = OK) Ask( PATH2 = OK) Ask( EXPLORE = OK) 671112 1 5 1415 16 17 [450,540] [0,] [200,200] [450,450] [10,10] Tell(PATH1=OK) Tell( PROCEED)

64 Generates Schedulable Plan To Plan,... perform the following hierarchically: Trace trajectories Check schedulability Supporting and protecting goals (Asks) Group-Enroute [500,800] [450,540] [0,] Group TraverseGroup Wait Ask(PATH1=OK)Ask(PROCEED) [0,54][405,486] Science Target Group Traverse Ask(PATH2=OK) Group Transmit [0,] [405,486] [0,2] 3 8 671112 1 5 1415 16 17 Tell(PATH1=OK)Tell(PROCEED) [450,450][200,200] [10,10] [0,]

65 Supporting and Protecting Goals Resolving Unsupported Subgoals: Scan plan graph,identifying activities that support open sub-goals; force to co-occur. Resolving Threatened Subgoals: Search for inconsistent activities that co-occur, and impose ordering. Key computation is bound time of occurrence: Used Floyd-Warshall APSP algorithm O(V 3 ). Unsupported SubgoalThreatened Activities Goal: any UCAV at Target Activity: UAV1 at Base Activity: UCAV1 at Target Activities cant co-occurClose open goals Activity:UAVI at Targer 1 2 34 1 2 34

66 Randomized Experiments for Assessing Scaling and Robustness Randomized Experiments: Randomly generated range of scenarios with 1-50 vehicles. Each vehicle has two scenario options, each with five actions and 2 waypoints: 1. Go to waypoint 1 2. Observe science 3. Go to waypoint 2 4. Observe science 5. Return to collection point Waypoints generated randomly from environment with uniform distribution. Strategy Selection: TPN planner chooses one option per vehicle. Combined choices must be consistent with timing constraints and vehicle paths.

67 Kirk Strategy Selection: Scaling and Robustness Performance Improvement Through Incremental temporal consistency Conflict-directed Search (in progress) Planning Time vs. Number of UAVs Each vehicle visits 2 science sites and returns to collection point 35 30 25 20 15 10 5 0 0 5052520353015104540 Planning Time (min) Number of UAVs Kirk Oct. 02 Kirk April 03

68 HOME TWOTWO O NEO NE Landing Site: ABC COLLECTION POINT RENDEZVOUS COLLECTION POINT Enroute Landing Site: XYZ SCIENCE AREA 3 SCIENCE AREA 1SCIENCE AREA 1 Diverge SCIENC E AREA 1 RMPL Model-based ProgramKirk Model-based Executive Control Program z Executes concurrently z Preempts z non-deterministic choice z A[l,u]timing z A at llocation Environment Model location estimateslocation goals Observations Commands Plant COLLECTION POINT HOME Landing Site: ABC Landing Site: XYZ Enroute RENDEZVOUS SCIENCE AREA 1 SCIENCE AREA 3 Diverge SCIENCE AREA 1 TVOTVO ONEONE Selects consistent threads of activity from redundant methods TracksFinds least locationcost paths Executive pre-plans activities pre-plans paths dynamically schedules [Tsmardinos et al.]

69 Achieving Program States Combines Logical Decisions and Trajectory Planning Vehicle Waypoint Obstacle

70 Explorers Will Need to Be Dexterous (Courtesy of Frank Kirchner. Used with permission.)

71 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

72 Example: Coaching Heterogeneous Teams Search and Rescue Ocean Exploration A dozen vehicles is too many to micro manage Act as a coach: Specify evolution of state and location. (Courtesy of Jonathan How. Used with permission.)

73 Forest Fire Rescue Goal: retrieve family from fire. Rescue cannot take place until the local fire is suppressed. Retrofit one rescue vehicle for fire suppression Fire Line Ambulance Rescue Point Fire Forest

74 Kirk Model-based Execution System Overview Strategy Selection determines the optimal rules / strategies to accomplish mission goals. Activity Planning figures out within how to achieve mission goals within strategic framework using available low-level actions. Mission Controller Mission Developer state configuration goals environment and action data schedulable plan with rationale PMPL control program Strategy macro decomposition Strategy Selection TPN Planner Activity Planning Visibility Graph Generative Activity Planner Strategy Macro Library Operators, Tactics, Scenario Model Human / Computer Interface MILP Path-Planning

75 RMPL Control Program (defclass rescue-team (execute () (sequence (parallel [l1,u1] (tell-start(at family RescuePoint)) (tell-start(at uav1 Ambulance)) (tell-start(at uav2 Ambulance)) ) (parallel [l2,u2] (tell-atart(at family RescuePoint)) (ask-end(rescued family)) (ask-end(at uav1 Ambulance)) (ask-end(at uav2 Ambulance)) ) Initial State Intermediat e State Goal State Phase 1 Phase 2

76 Environment Model Terrain Map Object instantiations: –UAV uav1 –UAV uav2 –RESCU-READY uav1 –RESCUE-READY uav2 –IN-DISTRESS family –LOCATION Ambulance –LOCATION Fire –LOCATION RescuePoint

77 Vehicle Specifications Vehicle linearized dynamics Vehicle primitive operators: –Fly(V,A,B) move UAV V from location A to location B –Refit(V) Prepare UAV V to drop fire retardant –Drop(V,A) Drop fire retardant at location A with UAV V –Rescue(V,P,A) Rescue people P in distress with UAV V at location A

78 Kirk Model-based Execution System Overview Strategy Selection determines the optimal rules / strategies to accomplish mission goals. Activity Planning figures out within how to achieve mission goals within strategic framework using available low-level actions. Mission Controller Mission Developer state configuration goals environment and action data schedulable plan with rationale PMPL control program Strategy macro decomposition Strategy Selection TPN Planner Activity Planning Visibility Graph Generative Activity Planner Strategy Macro Library Operators, Tactics, Scenario Model Human / Computer Interface MILP Path-Planning

79 Kirk Constructs Vehicle Activity Plan Using a Generative Temporal Planner Approach: Encode Goal Plan using an LPGP-style encoding Prototype using LPGP [Fox/Long, CP03] Mission Goal State Plan Vehicle Operator Definitions Vehicle Activity Plan Translate to Planning Problem with Atomic Operators Use Atomic Generative Planner (GraphPlan-Blum & Furst) To Generate Operators and Precedence Extract Temporal Plan and Check Schedulability

80 Generated Activity Plan Kirk extracts a least commitment plan and generates a rationale Refit-Start Refit-Inv [10,+lNF] Refit-End Fly-lnv [20,+lNF] [20,+lNF] Fly-Start Fire CP-Start CP-lnv-1 [0,100] CP-lnv-1 [0,100] CP-lnv-1 [0,100] Fly-End CP-lnv-1 [0,100] CP-lnv-1 [0,100] CP-lnv-1 [0,100] CP-lnv-1 [0,100] [0,100] Fly-Start Fly-Inv [20,+lNF] Fly-Inv [20,+lNF] Suppress-Start Suppress-lnv [10,20] Suppress-End [10,20] CP-Midpoint

81 Kirk Model-based Execution System Overview Strategy Selection determines the optimal rules / strategies to accomplish mission goals. Activity Planning figures out within how to achieve mission goals within strategic framework using available low-level actions. Mission Controller Mission Developer state configuration goals environment and action data schedulable plan with rationale PMPL control program Strategy macro decomposition Strategy Selection TPN Planner Activity Planning Visibility Graph Generative Activity Planner Strategy Macro Library Operators, Tactics, Scenario Model Human / Computer Interface MILP Path-Planning

82 Output: Least Commitment Plan with Rationale Plan layered with rationale Rescue(UAV1,Troops,RSQ) Fly(UAV1,RSQ,Base) Fly(UAV1,Base,RSQ) Refit(UAV1) Control Program Phase I Fly(UAV2,Base,Radar) Control Program Phase II Attack(UAV2,Radar)Fly(UAV2,Radar,Base) [10,+INF] [20,+INF][30,60][20,+INF] [0,100] [10,20] [0,100] [20,+INF]

83 Kirk Ensures Plan Completeness, Consistency and Minimality Complete Plan A plan is complete IFF every precondition of every activity is achieved. An activitys precondition is achieved IFF: The precondition is the effect of a preceding activity (support), and No intervening step conflicts with the precondition (mutex). Consistent Plan The plan is consistent IFF the temporal constraints of its activities are consistent (the associated distance graph has no negative cycles), and no conflicting (mutex) activities can co-occur. Minimal Plan The plan is minimal IFF every constraint serves a purpose, i.e., If we remove any temporal or symbolic constraint from a minimal plan, the new plan is not equivalent to the original plan fact-J Start fact-K [l 1,u 1 ] [l 3,u 3 ] fact-O fact-M [l 2,u 2 ] fact-N [l 4,u 4 ] fact-P End Activity-AActivity-C Activity-B Activity-D fact-L

84 Plan-based HCI Proof of Concept: Coaching through Coordinated Views WAYPOINT1 UCAV2 BASE1 SAM1 UCAV1 RADAR1 HVT1 Action: FLY-TO Actor: UCAV2 Objects: WAYPOINT1 Action: FLY-TO Actor UCAV1 Objects: SAM1 Action: FLY-TO Actor: UCAV2 Objects: HVT1 Action: ATTACK Actor UCAV1 Objects: SAM1 Action: ATTACK Actor: UCAV2 Objects: HVT1 [10, 10] Action: FLY-TO Actor UCAV1 Action: FLY-TO Actor: UCAV2 Objects: BASE1 [5, NA] Set Current PlanRevertClear Screen (Courtesy of Howard Shrobe, Principal Research Scientist, MIT CSAIL. Used with permission.) Action: FLY-TO Actor: UCAV2 Objects: BASE1 [5,NA] Action: FLY-TO Actor: UCAV1 Objects: BASE1 Action: FLY-TO Actor: UCAV1 Objects: SAM1 [5,NA] Action: FLY-TO Actor: UCAV2 Objects: WAYPOINT1 Action: ATTACK Actor: UCAV1 Objects: SAM1 [10, 10] Action: FLY-TO Actor: UCAV2 Objects: HVT1 Action: ATTACK Actor: UCAV2 Objects: HVT1 [10, 10] Plan Top Level Activity UCAV2-FLY-TO-WAYPOINT beginning UCAV2-FLY-TO-WAYPOINT Establishes the following prerequisites: UCAV2-FLY-TO-WAYPOINT helps establish (AT UCAV2 WAYPOINT) a prerequisite of UCAV2-FLY-TO-TARGET UCAV2-FLY-TO-WAYPOINT establishes (AT UCAV2 WAYPOINT) UCAV2 executes a FLY-TO operation on WAYPOINT1 Activity UCAV1-FLY-TO-SAM beginning UCAV1-FLY-TO-SAM Establishes the following prerequisites: UCAV1-FLY-TO-SAM helps establish (AT UCAV1 SAM1) a prerequisite of UCAV1-FLY-TO-SAM UCAV1-FLY-TO-SAM establishes (AT UCAV1 SAM1) UCAV1 executes a FLY-TO operation on SAM1 UCAV1-FLY-TO-SAM finished, go on? [default Yes]:

85 Plan & Geography View WAYPOINT1 UCAV2 BASE1 SAM1 RADAR1 HVT1 UCAV1 (Courtesy of Howard Shrobe, Principal Research Scientist, MIT CSAIL. Used with permission.) Sequencing: Action: FLY-TO Actor: UCAV2 Objects: WAYPOINT1 Action: FLY-TO Actor UCAV1 Objects: SAM1 [5, NA] Action: FLY-TO Actor: UCAV2 Objects: HVT1 Action: ATTACK Actor UCAV1 Objects: SAM1 [10, 10] Action: ATTACK Actor: UCAV2 Objects: HVT1 [10, 10] Action: FLY-TO Actor UCAV1 Objects: BASE1 Action: FLY-TO Actor: UCAV2 Objects: BASE1 [5, NA]

86 Causal View Causality Explanation Action: FLY-TO Actor: UCAV2 Objects: BASE1 [5,NA] Action: FLY-TO Actor: UCAV1 Objects: BASE1 Action: FLY-TO Actor: UCAV1 Objects: SAM1 [5,NA] Action: FLY-TO Actor: UCAV2 Objects: WAYPOINT1 Action: ATTACK Actor: UCAV1 Objects: SAM1 [10, 10] Action: FLY-TO Actor: UCAV2 Objects: HVT1 Action: ATTACK Actor: UCAV2 Objects: HVT1 [10, 10] Plan Top Level UCAV2-ATTACK-TO-TARGET Has the following prerequisites: UCAV2-ATTACK-TO-TARGET requires (AT UCAV2 HVT1) This was established by Activity UCAV2-FLY-TO=TARGET achieving (AT UCAV2 HVT1) UCAV2-ATTACK-TO-TARGET Establishes the following prerequisites: UCAV2-ATTACK-TO-TARGET helps establish (DESTROYED HVT1) prerequisite of NEW UCAV2-ATTACK-TO-TARGET establishes (DESTROYED HVT1) (Courtesy of Howard Shrobe, Principal Research Scientist, MIT CSAIL. Used with permission.)

87 Model-based Programming of Robust Robotic Networks Long-lived systems achieve robustness by coordinating a complex network of internal devices. Programmers make a myriad of mistakes when programming these autonomic processes. Model-based programming simplifies this task by elevating the programmer to the level of a coach: –Makes hidden states directly accessible to the programmer. –Automatically mapping between states, observables and control variables. Model-based executives reasoning quickly and extensively by exploiting conflicts. Mission-level executives combine activity planning, logical decision making and control into a single hybrid decision problem.


Download ppt "Model-based Programming of Cooperating Explorers Brian C. Williams CSAIL Dept. Aeronautics and Astronautics Massachusetts Institute of Technology."

Similar presentations


Ads by Google