1. June 28, 2000 Architecture Review 1 The Decision Layer

2. June 28, 2000 Architecture Review 2 Outline Goals & Objectives Approach Decision Layer Background –Elaboration Definitions –Declarative vs. Procedural Knowledge –Decision Layer State –Planning/Scheduling Systems –Executive Systems –Planner and Executive Examples in Architecture Interface to Functional Layer –Floating Line –Resource Prediction –Saved Plans; Direct Commanding MDS Relevance –Goal Elaboration –Planning in MDS

3. June 28, 2000 Architecture Review 3 Goals & Objectives Framework: Provide framework for using different types of planning and executive functionality, as well as other types of goal elaboration Abstraction Flexibility: Provide capability for using planning and exec functions at different levels of abstraction and temporal granularity MDS Compliance: Be compliant and parallel with Mission Data System (MDS) spacecraft architecture Research/Flight Project Flexibility: –Provide flexibility needed for different research and flight projects –Enable different level of capabilities depending on user and application Functionality: Increase functionality and robustness at higher level Development Ease: Allow for easy development of decision layer capabilities that can handle goals for different robotic platforms and/or high-level mission strategy Representation: Enable easy representation of resource and state constraints

4. June 28, 2000 Architecture Review 4 Approach Framework Design: Implement a framework that allows separate or tightly coupled planning and executive components Representation Flexibility: Allow both declarative and procedural knowledge representations Planning/Exec Heritage: Leverage off of existing planning/scheduling systems and execution systems that have been utilized for rover/robot applications MDS Heritage: Leverage off of “above the line” software being created for MDS architecture S/W Integration: Enable multiple planning and executive approaches to be integrated Elaboration Capability: Ensure that other types of goal elaboration can be utilized in this framework (e.g., scripting, code) Testing: Validate using different robotic platforms (both real and simulated)

5. June 28, 2000 Architecture Review 5 Goal: constraint on a particular state over a certain time interval. Activity: Planning construct that extends over a certain time interval and can represent a goal, exert constraints, represent an abstract activity, and/or correspond to a command. Task: Executive construct that usually corresponds to lower-level activities that are further decomposed and scheduled by the exec. Schedule (or Goal-Net): temporal constraint network of goals, activities, and tasks. Low-level nodes in network usually correspond to commands. Elaboration: the decision process of achieving a goal (e.g., expansion, scripting, straight code, etc.) Background: Elaboration Definitions Science T1 T2 On Off CenterOnRock LookForRock Move LookForRock Science Goal Constraint Time Inst Power Activity Resource Constraint Sample Task Tree Sample Goal-Net

6. June 28, 2000 Architecture Review 6 Background: Declarative vs. Procedural Knowledge Declarative Representation: –Knowledge is given but method of using knowledge is not specified –Knowledge can be viewed as data to program –Most planning/scheduling systems primarily use declarative knowledge Procedural Representation: –Knowledge and necessary control information is specified –Knowledge can be viewed as a program –Used by an interpreter that follows instructions given in knowledge. –Most executive systems primarily use procedural knowledge. MDS View: –“Express domain knowledge explicitly in models rather than implicitly in program logic.” (Dvorak, 2000)

7. June 28, 2000 Architecture Review 7 Declarative vs. Procedural, cont. Load_vehicle(Obj,Veh,Loc) Preconditions: at-obj(Obj,Loc1), can-carry(Veh,Obj), at-vehicle(Veh,Loc) Effects: inside-vehicle(Obj,Veh), ¬at-obj(Obj,Loc) Drive_vehicle(Veh,Loc1,Loc2) Preconditions: at-vehicle(Veh,Loc1), near(Loc1,Loc2), enough_fuel(Veh,Loc1,Loc2), enough_time(Veh,Loc1,Loc2) Effects: at-vehicle(Veh,Loc1), ¬at-vehicle(Veh,Loc2) Sample Declarative Activity Definitions If: object needs to be moved, vehicle is near object, vehicle can carry object, new location is in driving distance, vehicle has enough fuel, there is enough time left in day Then: load the object into the vehicle Sample Procedural Rule Definition

8. June 28, 2000 Architecture Review 8 Background: Decision Layer State Medium Term Plan Short Term Plan Increased Detail Long Term Mission Plan Data-Buffer Shutter-Door openclosedopen Take image Activity Database: –Maintains state of Decision Layer –Includes state and resource timelines –Can be modified by both planning and exec functionalities –Holds both execution history and future plan projections Hierarchical Plan projections: –For long-term projections, abstract plan is created –Plan is extended as time proceeds –For near-term projections, more detailed plan is built

9. June 28, 2000 Architecture Review 9 Planning Techniques: –Use precondition/effect analysis (i.e., subgoaling) and/or decomposition –Output is ordered (or partially-ordered) list of activities Scheduling Techniques: –Use different search methods (e.g., backtracking, iterative repair) to create a schedule of activities –Schedule satisfies resource, state and temporal constraints. –Looks at issues such as aggregate resources and temporal duration. Batch vs. Iterative Approaches Declarative Domain definition: –activity requirements –resource/state constraints –temporal constraints –predicted resource usages –predicated states of the world, etc. Background: Planning/Scheduling Systems On Off Scan(target) Inst_On Point(target) Turn_OnTurn(target) Activity mast_placement { position x, y, z; angle heading; duration = 300s; reservations = mast, mast_sv change_to “deployed”, health_sv must_be “exec”, drive_motors, day_night_sv must_be “day”; } Activity Subgoaling Sample Schedule Sample Activity Definition

10. June 28, 2000 Architecture Review 10 Background: Executive Systems Executive Features: –Procedural expansion of goals into low- level commands –Quick response time to environment/state changes –Task synchronization –Exception handling –Closed-loop control –Issuing commands to low-level controller Minimum Functionality: –Acts as dispatcher –No additional procedural expansion –May monitor activities and state feedback and pass information up Maximum Functionality: –Acts as engine for sequence generation –Input high-level goals are broken down into commands –Modify sequences based on state feedback Goal deliverMail (int room) { double x, y; getRoomCoordinates(room, &x, &y); spawn navigate to Locn(x,y); spawn centerOnDoor(x,y) with sequential execution previous, terminate in 0:0:03.0; spawn speak (“Xavier here with your mail”) with sequential execution centerOnDoor, terminate at monitorPickup completed; spawn monitorPickup() with sequential execution centerOnDoor; } deliverMail Move navigate ToLocn center OnDoor monitor Pickup Speak center OnDoor lookFor Door Speak notify Sender lookFor Door Example TDL Task Tree Example TDL Task Definition

11. June 28, 2000 Architecture Review 11 Executive Layer Planner/Exec Examples: Remote Agent Experiment (RAX) Planner Ground goals plan Smart Executive MIR sensor readings s/c state Mission Manager initial plan state commands RAX Architecture RAX Approach: –Batch planning system (RAX-PS) that performs resource/state analysis & generates temporally flexible plans –Smart Executive (ESL) that performs multi-threaded execution –Demonstrated onboard DS1 [Benard, 1998] Relation to 3-Layer Architecture: –Example of 3 layer architecture –Batch planning system only runs when required (allocated 4 hours) –Planner and exec have different representations and operate on different abstraction levels Relation to Our Architecture: –3-layer approach can be easily mapped into our framework –Planner and exec can operate strictly on different abstraction levels Planning Layer Behavior Layer

12. June 28, 2000 Architecture Review 12 Planner/Exec Examples: CASPER Continuous Planning System CASPER Approach : –Generates plan, performs resource/state analysis and re-plans dynamically –Plan is continually updated in light of changing operating context –Simple Executive that dispatches activities and updates state info –Demonstrated for ST4, AMM, Rocky7/Rocky8, DSN [Chien, 2000] Relation to 3-Layer Architecture: –Not typical 3 layer architecture –Planning operates on a shorter time scale –Planner and exec functionalities operate more closely –Lacking in full execution capabilities Relation to Our Architecture: –Enables planner to operate on more detailed activities and in a shorter time scale –Enables extension of exec capabilities Rover plans; state updates WITS (Ground) ORCAA Onboard s/w CASPER Commands, Sensor feedback CASPER w/ Rocky 7 Planning Layer Executive Layer Behavior Layer

13. June 28, 2000 Architecture Review 13 Planner/Exec Examples: TDL/TCM Executive TDL/TCM Approach : –Provides task level control –Expands abstract goals into task trees –Execute low-level commands (e.g., closed-loop control, synchronization) –Monitors their execution –Handles exceptions –Demonstrated on several robot platforms [Simmons, 1998] Relation to 3-Layer Architecture: –Provides middle layer –Mediates between planning layer and the behavior layer –Little resource management Relation to Our Architecture: –Again, can map all (or part of) 3-layer approach into our architecture –Allows for exec capabilities to be used at different levels of abstraction and used with or without planning Planning Layer Executive Layer Behavior Layer

14. June 28, 2000 Architecture Review 14 Background: Many Relevant Planning/Executive Systems Other examples of 3 layer architectures: –Atlantis (Gat, 1992); 3T (Bonasso,1995); Ames Arch (Washington, 1999); LAAS Arch (Alami, 1998) Many examples of particular layers: –Planner/Schedulers: –CASPER/ASPEN (Chien, 1999); CPS (Bresina, 1999); AP (Elsaesser, 1991); IxTet (Alami, 1998) –Executives: –TDL/TCA (Simmons, 1998); ESL (Gat, 1997); RAPs (Firby, 1989); PRS (Geogeff, 1989); PRS-Lite (Myers, 1996) Intent: Architecture intent is to allow for easy integration Flexible framework: 3-layer and more tightly integrated approaches should fit into framework

15. June 28, 2000 Architecture Review 15 New Decision Layer Functionality: Merging Planning and Executive Functionality activities Execution History Now Planning Horizon time Plan Freeze Executive Domain Planner Domain timelines Exec Freeze Abstraction Level: Can use all functionality at different levels of abstraction and temporal granularity Executive Capabilities: Primarily used in near-term plan modification Planning Capabilities: Primarily used in long-term plan modification Procedural Expansion: Will allow for procedural expansion of future plan activities (e.g., looping, if/thens, coupling) Resource Analysis: Will allow for sophisticated resource and state analysis of near-term plan activities System Flexibility: Overall improve system responsiveness and increase flexibility of representation

16. June 28, 2000 Architecture Review 16 Functional Layer Motivation: –plan projection through incremental refinements –maintaining plan consistency –handling new goal requests Executive: –procedurally expanding activities –task synchronization –exception handling –closed-loop control –issuing commands to the Functional Layer Activity Database(s): –represent current plan for both the planner and exec –two tightly-coupled DBs –reflect the same information for each system –will support flexible time- point representation. Next Step: Planner/Exec Integration (Planned for FY01) Exec-Side Activity DB Plan-Side Activity DB Planner/Exec DB Synchronization Executive (TDL) Planner (CASPER) Plan/Exec State Determination Plan Modifications Goal Updates Plan Info, Conflict Status Plan Info, State Feedback Resource Queries & Estimations Commands Plan Modifications Timeline Updates Activity/State Updates State Queries

17. June 28, 2000 Architecture Review 17 Functional Layer Activity Database(s): –represent current plan –supports both declarative and procedural representations –tracks resource and state projections –inputs goal updates –inputs state and resource updates –receives plan modifications –support flexible time-point representation Planner/Exec Library: –contains both planner and exec functionality –can refine both near and short term plan –works on all layers of abstractions Future Planner/Exec Integration Activity Database Library of Planner/Exec Functionality Plan/Exec State Determination Goal Updates Plan Modifications Plan Info, Conflict Status Commands Resource Queries & Estimations Activity/ State Updates Timeline Updates State Queries Dispatcher Activities

18. June 28, 2000 Architecture Review 18 Interface: –Activities/tasks (i.e., commands) on fringe of Goal Net are dispatched to Functional Layer –Activity/State/Resource updates passed up to timelines Floating Line: –DL goals can be elaborated into very detailed tasks which are passed to the Functional Layer –Or might have minor elaboration and most control decisions handled by Functional Layer –Elaboration can be to different layers of granularity depending on user and application Possible Functionality Duplication: –Some functionality may be duplicated in Decision and Functional Layer –Will allow flexibility in how much control is given to each layer and can be user-dependent. Interface to Functional Level: Floating Line … … … … … … … … HARDWARE ENVIRONMENT … … … The Line Commands State Updates The Line

19. June 28, 2000 Architecture Review 19 Resource Knowledge: –Information on resource predication is kept in Functional Layer Resource Queries: –Decision Layer can query Functional Layer for resource usage predictions –Queries can contain relevant parameters and other plan information –Queries can be at a detailed or cursory level Resource Estimations: –Functional Layer will return resource estimations based on input queries –More detailed queries may require more computational resources to resolve Interface to Functional Level: Resource Prediction … … … … … … … … HARDWARE ENVIRONMENT … … … The Line Resource Queries & Estimations Commands State Updates The Line

20. June 28, 2000 Architecture Review 20 Direct Commanding: –Commanding sequences can be submitted directly from ground ops –Will be simply executed by Decision Layer –No further modification Saved Plans: –Plans or sub-plans can be saved and recalled at future times –Can be loaded into planner for further modification –Can be passed directly to exec –Can still do state updates to modify plan if necessary Interface to Functional Level: Direct Commanding … … … … … … … … HARDWARE ENVIRONMENT … … … The Line Resource Queries & Estimations Commands State Updates Command Sequences/ Saved Plans The Line

21. June 28, 2000 Architecture Review 21 Goal Elaboration: –MDS decision process of building and modifying constraint networks –Elaborators add new subgoals, new time-points, and new temporal constraints. Goal Achieving Module (GAM): –Responsible for a particular state-variable –Accepts goals and ensures they are achieved –GAMs act as Execs; provide commands to “below the line” controllers Goal-Net: –MDS representation of schedule as a temporal constraint network –Encourages all nodes at this level to be represented as goals –Executable (low-level) goals result in commands Goal Elaboration in MDS GAM Measurements Goals Estimates of State Value State Updates Commands Low level controllers and hardware Estimates of State Value Goals Goal Net Measurement Model State Variables

22. June 28, 2000 Architecture Review 22 Planning: –One form of goal elaboration –Can perform goal elaboration for a set of state variables –Can be used in conjunction with other Elaborators/GAMs. Executive: –Existing MDS capability –Could be responsible for multiple state variables –Can be used in conjunction with other GAMs. Global vs. Distributed Planning: –Planning functions can be distributed among different parts of the systems (e.g., GAMs) –More global knowledge availability will increase plan optimality –Better utilization of resources and states Using Planning in MDS GAM Measurements Goals Estimates of State Value State Updates Commands Low level controllers and hardware Estimates of State Value Goals Goal Net Measurement Model State Variables Modules to be replaced by Planner/Exec

23. June 28, 2000 Architecture Review 23 Conclusions Flexible Framework Design: Implement a framework that allows typical 3 layer architecture or tightly coupled planner/exec Representation: Allow both declarative and procedural knowledge representations Abstraction: Provide capability for using planning/exec functions at different levels of abstraction and temporal granularity Interface: Enable flexible Functional Level interface and resource query/estimation capabilities Heritage: Leverage off of existing planning/scheduling and execution systems and off of MDS software development S/W Integration: Enable multiple planning and executive approaches to be integrated