june 28, 2000 architecture review 1 the decision layer

June 28, 2000 Architecture Review 1

The Decision Layer


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


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


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)


• 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 DefinitionsScience

T1 T2

On OffOff

CenterOnRock

CenterOnRockLookForRock Move

LookForRock

Science Goal ConstraintTime

Time

Inst

Power

Activity Resource Constraint

Sample Task Tree

Sample Goal-Net


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)


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


Background: Decision Layer State

Medium Term Plan

Short Term Plan

Increased Detail

Long Term Mission Plan

Data-Buffer

Shutter-Door open closed open

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


• 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 OffOff

Scan(target)

Inst_On Point(target)

Turn_On Turn(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


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

navigateToLocn

centerOnDoor

monitorPickupSpeak

centerOnDoor

lookForDoor Speak

notifySenderlookFor

Door

Example TDL Task Tree

Example TDL Task Definition


Executive Layer

Planner/Exec Examples:Remote Agent Experiment (RAX)

Planner

Ground

goals

planSmart

ExecutiveMIR

sensorreadings

s/c state

MissionManager

initial planstate 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


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

CASPERw/ Rocky 7

Planning Layer

Executive Layer

Behavior Layer


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


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


New Decision Layer Functionality:Merging Planning and Executive Functionality

activities

ExecutionHistory

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

June 28, 2000 Architecture Review 16Functional 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 StateDetermination

PlanModifications

GoalUpdates

Plan Info,Conflict Status

Plan Info,State Feedback

ResourceQueries & Estimations

Commands

PlanModifications

Timeline Updates

Activity/StateUpdates

StateQueries

June 28, 2000 Architecture Review 17Functional 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

ActivityDatabase

Library of Planner/Exec Functionality

Plan/Exec StateDetermination

GoalUpdates

PlanModifications

Plan Info,Conflict Status

CommandsResource

Queries & Estimations

Activity/State

Updates

Timeline Updates

StateQueries

Dispatcher

Activities


• 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


• 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


Commands

State Updates

The Line


• 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


Commands

State Updates

Command Sequences/ Saved Plans

The Line


• 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 ofState Value

StateUpdates Commands

Low level controllers and hardware


Goals Goals

Goal Net

MeasurementModel

StateVariables


• 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


StateUpdates Commands

Low level controllers and hardware


Goals Goals

Goal Net

MeasurementModel

StateVariables

Modules to be replaced by Planner/Exec


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

june 28, 2000 architecture review 1 the decision layer

Documents