Ordered task decomposition theory and practice
Download
1 / 68

Part 2 - PowerPoint PPT Presentation


  • 328 Views
  • Updated On :

Ordered Task Decomposition: Theory and Practice Part 2 Dana S. Nau Dept. of Computer Science, and Institute for Systems Research University of Maryland, College Park, MD Approach (and Outline) Day 1 Day 2 Very quick review Comments Continue where I left off Theory

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Part 2' - lotus


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ordered task decomposition theory and practice l.jpg

Ordered Task Decomposition:Theory and Practice

Part 2

Dana S. Nau

Dept. of Computer Science, and

Institute for Systems Research

University of Maryland, College Park, MD


Approach and outline l.jpg
Approach (and Outline)

Day 1

Day 2

  • Very quick review

  • Comments

  • Continue where I left off

Theory

1. Principles ofHTN planning

4. Ordered Task

Decomposition

5. SHOP

2. Computerbridge

3. Electronic Designand Manufacturing

6. Evacuationplanning

Applications


What activities should a planning system plan l.jpg
What Activities Should a Planning System Plan?

  • In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect

  • Examples:

    • picking up a block

    • moving a truck

  • In human planning, we also plan lots of other activities


What activities should a planning system plan4 l.jpg
What Activities Should a Planning System Plan?

  • In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect

  • Examples:

    • picking up a block

    • moving a truck

  • In human planning, we also plan lots of other activities

  • Example 1:

    • Planning information-gathering operations

travel by air

airport(x,a)

airport(y,b)

ticket (a,b)

travel (x,a)

fly(a,b)

travel(b,y)


What activities should a planning system plan5 l.jpg
What Activities Should a Planning System Plan?

  • In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect

  • Examples:

    • picking up a block

    • moving a truck

  • In human planning, we also plan lots of other activities

  • Example 2:

    • Planning bookkeeping operations

travel by air

store some infoabout the ticket

airport(x,a)

airport(y,b)

ticket (a,b)

travel (x,a)

fly(a,b)

travel(b,y)


What activities should a planning system plan6 l.jpg
What Activities Should a Planning System Plan?

  • In AI planning, researchers traditionally have only allowed the planner to plan activities that will have a direct physical effect

  • Examples:

    • picking up a block

    • moving a truck

  • In human planning, we also plan lots of other activities

  • Example 3:

    • Planning when/how to create and retrieve plans

travel by air

plan how to travel to Cyprusstore this plan into the current state

finish work

at the office

pack forthe trip

execute thestored plan


Homework assignment l.jpg
Homework Assignment

  • Yesterday, I asked you to formulate and execute a plan for going to the beach

  • Analyze that plan, to see if it contains any of the following activities:

    (1) information-gathering operations

    (2) bookkeeping operations

    (3) planning when/how create and retrieve plans


Concrete example l.jpg
Concrete Example

  • Malik Ghallab and Piergiorgio Bertoli and I plan to go bicycling on Sunday (instead of going to the barbecue)

  • One part of the plan:

    • Find a bicycle shop

    • Find out if they have suitable bicycles

    • If so, then plan how to go to it

  • This involves information-gathering, bookkeeping, and planning when to do other planning


Concrete example9 l.jpg
Concrete Example

  • Malik Ghallab and Piergiorgio Bertoli and I plan to go bicycling on Sunday (instead of going to the barbecue)

  • One part of the plan:

    • Find a bicycle shop

    • Find out if they have suitable bicycles

    • If so, then plan how to go to it

  • This involves information-gathering, bookkeeping, and planning when to do other planning

  • Another information-gathering part of the plan:

    • Would you like to join us?

    • If so, please let us know!


Review of ordered task decomposition l.jpg
Review ofOrdered Task Decomposition

  • Goal-directed, but generates actions in the same order in which they will later be executed

  • Whenever we want to plan the next task

    • we’ve already planned everything that comes before it

    • Thus, we know the current state of the world

task tm

task tn

op1

op2

opi

s0

s1

s2

Si–1


Answer to a question from yesterday l.jpg
Answer to a Question from Yesterday

  • Question: Suppose there’s an action bthat will come late in the planand will cause a lot of backtracking.

  • In this case we might like to planfor b first. Won’t total-orderplanning preclude us from doing that?

task t

m1

m2

m3

m4

a1

b

a2

b

a3

b

a4

b


Answer to a question from yesterday12 l.jpg
Answer to a Question from Yesterday

  • Question: Suppose there’s an action bthat will come late in the planand will cause a lot of backtracking.

  • In this case we might like to planfor b first. Won’t total-orderplanning preclude us from doing that?

  • Answer: Not necessarily

  • One way to do it:Tell the planner to create a plan for band retrieve that plan later

task t

m1

m2

m3

m4

a1

b

a2

b

a3

b

a4

b

task t

m

find a plan p for b

store p

task t’

m1

m2

m3

m4

a1

do p

a2

do p

a3

do p

a4

do p


Answer to a question from yesterday13 l.jpg
Answer to a Question from Yesterday

  • Question: Suppose there’s an action bthat will come late in the planand will cause a lot of backtracking.

  • In this case we might like to planfor b first. Won’t total-orderplanning preclude us from doing that?

  • Answer: Not necessarily

  • Another way to do it:Tell the planner to start by checkingb’s preconditions, withoutactually planning for b

task t

m1

m2

m3

m4

a1

b

a2

b

a3

b

a4

b

task t

m

check b’s preconditions

task t’

m1

m2

m3

m4

a1

b

a2

b

a3

b

a4

b


Answer to another question l.jpg
Answer to Another Question

  • Question: With total-order planning,can we interleave subgoals?

task t

m1

m2

load a

load b

deliver a

deliver b


Answer to another question15 l.jpg
Answer to Another Question

  • Question: With total-order planning,can we interleave subgoals?

  • Answer:

    • Not in SHOP, because all of thesubtasks will be totally ordered

    • Sometimes we can circumventthis, by using methods that putthe subtasks into a different order

      • In some cases this is natural;in other cases it is clumsy

    • We have an extension to theSHOP algorithm called M-SHOP[Nau et al., TR, 2000], in which someof the subtasks can be unordered

task t

m1

m2

load a

load b

deliver a

deliver b

task t

load all

deliver all

load a

load b

deliver a

deliver b


Answer continued l.jpg

two differenttask lists

Answer (Continued)

  • Basic idea for M-SHOP:

    • When we have several tasklists without an orderingbetween them, do this:

      loop if all of the task lists are empty, then exit remove the first item from one of the task lists decompose it, and put its subtasks at the front of the task listrepeat

    • Need a way to handle protected conditions

      • How we do this is described in [Nau et al., 2000]

    • M-SHOP is available at http://www.cs.umd.edu/projects/shopas part of the latest software distribution for SHOP

      • Currently they are separate programs

      • In the next release, they’ll be merged into a single program

load and deliver a

load and deliver a

m1

m2

load a

deliver a

load b

deliver b


Answer continued17 l.jpg
Answer (Continued)

  • M-SHOP doesn’t fullyimplement partiallyordered task lists

    • It can take multiple task listsas part of its input

    • It doesn’t allow methods to have subtasks that are partially ordered

  • However

    • To allow methods to have partially ordered subtasks is an easy generalization

    • We’ve written down the algorithm, but haven’t implemented it yet

load and deliver a

load and deliver a

m1

m2

load a

deliver a

load b

deliver b


Review of the shop algorithm l.jpg
Review of the SHOP Algorithm

state S; task list T=( t1 ,t2,…)

operator instance o

procedure SHOP (state S, task-list T, domain D) 1. if T = nil thenreturn nil2. t1= the first task in T3. U = the remaining tasks in T4. ift is primitive & an operator instance o matches t1then5. P = SHOP (o(S), U, D)6. ifP = FAIL then return FAIL7. return cons(o,P)8. else ift is non-primitive & a method instance m matches t1 in S & m’s preconditions can be inferred from S then9. return SHOP (S, append (m(t1), U), D)10. else11. return FAIL12. endifend SHOP

state o(S) ; task list T=(t2, …)

nondeterministic choice among all methods m whose preconditions can be inferred from S

task list T=( t1 ,t2,…)

method instance m

task list T=( u1,…,uk ,t2,…)


Encoding the blocks world algorithm into shop l.jpg
Encoding the Blocks World Algorithm into SHOP

loop

if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

and

x can be moved to a location such thatx and all blocks beneath x will be in locations consistent with the goal

then move x to that location

else if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

then move x to the table

else exit

endif

repeat


How to encode x or a block beneath it is in a location inconsistent with the goal l.jpg
How to Encode “x or a block beneath it is in a location inconsistent with the goal”

(:- (need-to-move ?x)

;; need to move x if x needs to go from one block to another

((on ?x ?y) (goal (on ?x ?z)) (different ?y ?z))

;; need to move x if x needs to go from table to block

((on-table ?x) (goal (on ?x ?z)))

;; need to move x if x needs to go from block to table

((on ?x ?y) (goal (on-table ?x)))

;; need to move x if x is on y and y needs to be clear

((on ?x ?y) (goal (clear ?y)))

;; need to move x if x is on z and something else needs to be on z

((on ?x ?z) (goal (on ?y ?z)) (different ?x ?y))

;; need to move x if x is on something else that needs to be moved

((on ?x ?w) (need-to-move ?w)))


Example continued l.jpg
Example (Continued)

loop

if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

and

x can be moved to a location such thatx and all blocks beneath it will be in locations consistent with the goal

then move x to that location

else if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

then move x to the table

else exit

endif

repeat


Operators for moving blocks l.jpg
Operators for Moving Blocks

(:operator (!pickup ?x)

((clear ?x) (on-table ?x))

((holding ?x)))

(:operator (!putdown ?x)

((holding ?x))

((on-table ?x) (clear ?x)))

(:operator (!stack ?x ?y)

((holding ?x) (clear ?y))

((on ?x ?y) (clear ?x)))

(:operator (!unstack ?x ?y)

((clear ?x) (on ?x ?y))

((holding ?x) (clear ?y)))

c

a

b

a

b

c

a

a

b

b

c

c


Example continued23 l.jpg
Example (Continued)

loop

if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

and

x can be moved to a location such thatx and all blocks beneath it will be in locations consistent with the goal

then move x to that location

else if there is a clear block x such that

x or a block beneath x is in a location inconsistent with the goal

then move x to the table

else exit

endif

repeat


Representing tasks l.jpg
Representing Tasks

Initial state:(clear c) (clear b)(on c a) (ontable b)(ontable a) (handempty)

Goals:(on a b)

(on b c)

  • Suppose we use the task list

    • ((achieve (on a b)) (achieve (on b c)))

  • This won’t do what we want

    • First it will perform the task (achieve (on a b))

    • Then it will perform the task (achieve (on b c))

  • Instead, we need a task list something like

    • ((achieve (on a b) (on b c)))

  • Need to keep track of

    • which goals we have achieved and need to preserve

    • which goals remain to be achieved

  • How to do this?

a

b

c

c

a

b


Bookkeeping l.jpg
Bookkeeping

  • Keeping track of what the goals are

    • Insert information about this into the current state

    • This is convenient because it lets us use precondition-matching to match methods to goals

  • Keeping track of the goals that we have achieved and need to preserve

    • Insert information about this into the task list

    • Could also have put this into the current state instead

      • That’s what we do in other domains, such as the logistics domain [Nau et al., 2000]


Bookkeeping operator and methods l.jpg
Bookkeeping Operator and Methods

(:operator (!assert ?atoms) ; ?atoms is a list of atoms to assert

() ; no preconditions

?atoms ; put the list of atoms into the current state

0) ; this operator has no cost

(:method (assert-goals (?first . ?rest) ?atoms) ; recursively build a list

() ; of atoms to assert into

'((assert-goals ?rest ((goal ?first) . ?atoms)))) ; the current state

(:method (assert-goals nil ?atoms) ; we’ve built the entire list, so assert it

()

'((!assert ?atoms)))

(:method (achieve-goals ?goals) ; assert all the goals into the current state,

() ; then call move-block to achieve them

'((assert-goals ?goals nil) (move-block nil)))


Slide27 l.jpg

if there is a clear block x such that - x or a block beneath x is in a location inconsistent with the goal and - x can be moved to a location such that x and all blocks beneath it will be in locations consistent with the goalthen move x to that location

(:method (move-block ?nomove)

;; method for moving x from y to z

(:first (clear ?x) (eval (not (member '?x '?nomove))) (on ?x ?y)

(goal (on ?x ?z)) (different ?x ?z) (clear ?z) (not (need-to-move ?z)))

'((!unstack ?x ?y) (!stack ?x ?z) (move-block (?x . ?nomove)))

;; method for moving x from y to table

(:first (clear ?x) (eval (not (member '?x '?nomove)))

(on ?x ?y) (goal (on-table ?x)))

'((!unstack ?x ?y) (!putdown ?x) (move-block (?x . ?nomove)))

;; method for moving x from table to y

(:first (clear ?x) (eval (not (member '?x '?nomove)))

(on-table ?x) (goal (on ?x ?y)) (clear ?y) (not (need-to-move ?y)))

'((!pickup ?x) (!stack ?x ?y) (move-block (?x . ?nomove)))


Slide28 l.jpg

else if there is a clear block x such that x or a block beneath x is in a location inconsistent with the goalthen move x to the tableelse exitendif

(:method (move-block ?nomove)

;; method for moving x out of the way

((clear ?x) (eval (not (member '?x '?nomove)))

(on ?x ?y) (need-to-move ?x))

'((!unstack ?x ?y) (!putdown ?x) (move-block ?nomove))

;; if none of the above preconditions were satisfied, then we're done

nil

nil)


Question l.jpg
Question

  • I can run SHOP on the blocks world for you right now.

  • Would you like me to do so?


Experimental comparison l.jpg
Experimental Comparison

  • Experimental comparison

    • Planning domains:

      • Blocks world

      • Logistics

      • UM Translog

    • Planning systems compared:

      • Blackbox - Graphplan plus satisfiability

      • IPP - Graphplan plus ADL

      • TLplan - forward search with modal-logic pruning rules

      • UMCP - “classical” HTN planning

      • SHOP - Ordered Task Decomposition


Blocks world l.jpg

Time

Blocks World

  • 100 randomlygenerated problems

  • 167-MHz Sun Ultrawith 64 MB of RAM

  • Blackbox and IPPcould not solveany of these problems

  • TLplan’s running timewas only slightly worsethan SHOP’s

    • TLplan’s pruning rules [Bacchus et al., 2000] have expressive power similar to SHOP’s

    • Using its pruning rules, they encoded a block-stacking algorithmsimilar to ours

Number of actions in plan


Logistics l.jpg
Logistics

Time

  • 110 randomlygenerated problems

  • Same machineas before

  • As before, Blackboxand IPP could notsolve any of theseproblems

  • TLplan ransomewhat slowerthan SHOP(about an order ofmagnitude on largeproblems)

Number of actions in plan


Logistics continued l.jpg
Logistics (Continued)

Time

  • 30 problems fromthe Blackboxdistribution

  • SHOP and TLplanon the samemachine as before

  • Blackbox on a fastermachine, with 8GBof RAM

  • SHOP was about anorder of magnitudefaster than TLplan

  • TLplan was about two orders ofmagnitude fasterthan Blackbox

Number of actions in plan


Um translog l.jpg
UM Translog

  • HTN planning domain [Andrews et al., 1995]

    • Inspired by the logistics domain, but about an order of magnitude larger

    • Several different kinds of packages, vehicles, and procedures for handling the packages

      • e.g., hazardous materials need special handling

    • Several dozen primitive operators

    • Several dozen methods

    • Typical problems: dozens of vehicles, dozens of packages

  • SHOP versus UMCP

    • UMCP [Erol, 1994] is our “classical” HTN planner

  • Couldn’t test the other planners

    • Difficult to translate this domain into an action-based format

      • Will say more about this later


Um translog continued l.jpg
UM Translog (Continued)

Time

  • 100 randomlygenerated problems

  • Same machineas before

  • UMCP did muchworse than SHOP

Number of actions in plan


Digression translating htn problems into action based planning problems l.jpg
Digression: Translating HTN Problems into Action-Based Planning Problems

  • Can we compare these results with those of action-based planners (IPP, Blackbox, etc.)?

  • Problem:

    • HTN planning is strictly more expressive then STRIPS-style planning (Erol et al. 1994)

    • HTN problems from domains that include unbounded recursion among their methods cannot be expressed in STRIPS

  • However:

    • UM-Translog does not include recursive methods at all

    • For such cases, Amnon Lotem [Lotem & Nau, 2000] has defined an algorithm that translates an HTN domain into a STRIPS domain

m1

m1

m1

...


Htn to strips algorithm l.jpg
HTN-to-STRIPS Algorithm Planning Problems

HTN Operator

STRIPS Operator

Preconditions

Add Effects

Preconditions

Add Effects

p1

p1

Load

e1

Load

e1

p2

p2

Load-completed

Artificial predicate


Htn to strips algorithm38 l.jpg
HTN-to-STRIPS Algorithm Planning Problems

HTN Method

STRIPS Operator

Preconditions

Add Effects

Door-open-completed

(?t)

Load-top

(?p, ?t, ?o)

Artificial operator

Load-top-completed

(?p, ?t, ?o)

m

op-m

Load-completed

(?p, ?t, ?o)

Door-open

(?t)

Load

(?p, ?t, ?o)

Door-closed

(?t)

Door-closed-completed

(?t)


Translating um translog into strips l.jpg
Translating UM-Translog into STRIPS Planning Problems

  • Lotem used the algorithm to translate a subset of the UM-Translog domain into a STRIPS-style representation

  • There were several problems with that approach:

    • Poor readability of the resulting domain(artificial operators and predicates)

    • The artificial operators can be filtered out from the final solution, but we cannot guarantee minimal parallel length of the reported plan

    • A huge number of instantiated actions. Only very simplified versions of the test problems could be solved using Blackbox and IPP.


Manual encoding of um translog l.jpg
Manual Encoding of UM-Translog Planning Problems

Specs

  • Guidelines:

    • Do not create artificial operators

    • Keep the domain compact (smaller number of instantiated actions)

  • Findings:

    • It was difficult to express such a spec by using only operators.

    • Many operators became context-specific to preserve order constraints

    • Domain was still large, although more compact then the previous one

      • Could run IPP on some simple UM Translog problems, but not Blackbox

Manual

HTN Encoding

STRIPS-Style Encoding

Translation Algorithm

operators

methods + operators


Aips 2000 planning competition l.jpg
AIPS-2000 Planning Competition Planning Problems

  • Two tracks:

    • Track 1: STRIPS and PDDL planners

    • Track 2: “hand tailored” planners

      • many more problems, much harder problems

  • We entered SHOP in Track 2

  • We didn’t do much preparation for the competition

    • We felt very confident that SHOP would perform best

  • We were wrong!

    • SHOP ran much faster than the Track-1 planners, but it wasn’t the best planner in Track 2

      • In two domains, we got incorrect results on a few problems

      • In the other problem domains, a new planner called TALplanner was faster


Aips 2000 planning competition continued l.jpg
AIPS-2000 Planning Competition (Continued) Planning Problems

  • Why we got the errors

    • We had to translate from PDDL to SHOP by hand

      • In two domains, we didn’t do the translation correctly

      • The errors were minor, but caused incorrect results

    • For next time, we are writing an PDDL-to-SHOP translator

  • Why TALplanner was faster (we think)

    • Like TLplan, TALplanner does forward search guided by pruning rules written in modal logic

      • many of the same advantages as the SHOP algorithm

    • TALplanner uses highly optimized data structures

    • For next time, we intend to do the same for SHOP

      • Example: by making a simple modification to SHOP’s state representation, we made SHOP more than an order of magnitude faster


Related publications l.jpg
Related Publications Planning Problems

[Andrews et al., 1995] Andrews, Kettler, Erol, and Hendler. UM Translog: A Planning Domain for the Development and Benchmarking of Planning Systems. Tech. Report CS-TR-3487, Dept. of Computer Science, U. of MD.

[Bacchus et al. 2000] Bacchus and Kabanza. Using Temporal Logics to Express Search Control Knowledge for Planning. Artificial Intelligence, 116(1-2):123-191.

[Erol et al., 1994] Erol, Hendler, and Nau. UMCP: A Sound and Complete Procedure for Hierarchical Task-Network Planning. AIPS-94, 249-254.

[Lotem & Nau, 2000] A. Lotem and D. Nau. New Advances in GraphHTN: Identifying Independent Subproblems in Large HTN Domains. In Proc. Fifth International Conference on Artificial Intelligence Planning and Scheduling (AIPS-2000), April 14-17, 2000, pages 206-215. Breckenridge, CO.<http://www.cs.umd.edu/~nau/papers/AIPS-2000.pdf>

[Nau et al., 1999] D. Nau, Y. Cao, A. Lotem, and H. Munoz-Avila. SHOP: Simple Hierarchical Ordered Planner. IJCAI-99, August 1999, pp. 968-973.<http://www.cs.umd.edu/~nau/papers/shop-ijcai99.pdf>

[Nau et al., 2000] D. S. Nau, Y. Cao, A. Lotem, and H. Muñoz-Avila. SHOP and M-SHOP: Planning with Ordered Task Decomposition. Tech. Report CS TR 4157, University of Maryland: College Park, MD, 2000. <http://www.cs.umd.edu/~nau/papers/shop-ijcai99.pdf>


6 evacuation planning l.jpg
6. Evacuation Planning Planning Problems

  • Joint work with David Aha, Leonard Breslow, and Héctor Muñoz-Avila

Theory

1. Principles ofHTN planning

4. Ordered Task

Decomposition

5. SHOP

2. Computerbridge

3. Electronic Designand Manufacturing

6. Evacuationplanning

Applications


Noncombatant evacuation operations neos l.jpg
Noncombatant Planning ProblemsEvacuation Operations (NEOs)

  • Goal:

    • Assist the US Dept. of State to evacuate people whose lives are in danger

      • noncombatants, nonessential military personnel, host-nation citizens, third-country nationals

  • Characteristics:

    • Joint task force - geographically distributed, often multi-national

    • Uncertainty

    • Complexity (200+ tasks)

    • US Ambassador is senior authority

  • More than ten NEOs were conducted within the past decade


Hicap h ierarchical i nteractive c ase based a rchitecture for p lanning l.jpg
HICAP: Planning ProblemsHierarchical Interactive Case-based Architecturefor Planning

  • Motivation

    • Interactive decision support tool - user in control

    • Guided by military doctrine

    • Provide access to previous experiences

      • Plan elicitation by reusing cases

      • Plan revision by reusing lessons learned

    • Inferencing on standard procedures

    • Perform bookkeeping

      • Reduce the chances of error

      • Help secure accountability

U

S

E

R

IDS

Requests

Elicited plan

Plan

Scenario

HICAP


Why htn planning l.jpg

Hierarchical planning is natural for military organizations Planning Problems

Strategic

National

JCS / NCA

CINC

Strategic

Theater

JTF

Operational

Tactical

Why HTN Planning?


Hicap h ierarchical i nteractive c ase based a rchitecture for p lanning48 l.jpg

Lessons Planning Problems

Deliverer

HICAP:Hierarchical Interactive Case-based Architecturefor Planning

U

S

E

R

IDS

Requests

Elicited plan

Plan

Scenario

HICAP

Hierarchical

Task Editor

(HTE)

NaCoDAE/HTN

CCBR Tool

SHOP

Generative

Planner

DecTS

Decision

Tracker

Mixed-initiative planner

  • Interactive case retrieval: Select among alternative task decompositions

  • Generative planning: Automated task component

  • Resource conflict identification and resolution

    Input: Doctrine & resources, cases, methods, lessons

  • HTN representation

    Output: Elicited plan


Hierarchical task editor l.jpg

HTE Planning Problems(i.e., manual)

1. Apply Doctrine

2. Manual Edits

NaCoDAE/HTN

3. Apply Cases

SHOP

4. Apply Methods

Task Decomposition

Hierarchical Task Editor

U

S

E

R

Task


Example shop methods l.jpg
Example SHOP Methods Planning Problems

  • Select Helicopter Launching Base

    • Select possible area (A)

    • Transport sec. force (F,A,H)

      • Embark sec. force (F,H)

      • Fly(H,A)

      • Disembark (F,H,A)

    • Position security force (F,A)

    • Transport fuel to (A)

      • ...

Select Helicopter Launching Base

alternative

methods

Launch from

Carrier Battle

Group

Establish Base within Flying Distance

Transport helicopters

available (H)

Transport helicopters

available (H)

  • Decompose tasks into (more tactical) subtasks

  • Consider restrictions (e.g., transport helicopters available)

  • Resolve interactions (e.g., deploy security force first)

  • If necessary, backtrack and try other methods

Security force

available (F)

Helicopters have air

refuel. capability (H)


Nacodae htn navy conversational decision aids environment l.jpg

User Planning Problems

<Q,A>

process

Alternative decompositions

(cases) for the task ranked according to the user’s answers

selects case

System’s

Situation

Knowledge

NaCoDAE/HTN: Navy Conversational Decision Aids Environment

- NaCoDAE/HTN implements Conversational Case Based Reasoning

  • NaCoDAE/HTN allows interactive elicitation of situations from the user


Methods versus cases l.jpg

NaCoDAE/HTN Planning Problems

Cases denote concrete task decompositions (taken from previous plans) and preferences for selecting those decompositions:

Task: travel(From,To)

Task: travelC(Penn ST.,Downtn NYC)

Decomposition:

travelC(From, Station1)

travelIC(Station1,Station2)

travelC(Station2, To)

Decomposition:

take(taxi, Penn St., Downtn NYC)

Questions:

Is it raining hard in NYC? No

Is the passenger carrying

luggage? No

Conditions:

in(To,City1)

in(To,City2)

trainStation(Station1,City1)

trainStation(Station2,City2)

Methods Versus Cases

SHOP

Methods denote generic task decompositions and conditions for selecting those decompositions:


Using nacodae htn l.jpg

Planning tasks Planning Problems

World State

Using NaCoDAE/HTN


Sin shop integrated with nacodae htn l.jpg

Planning Problems

NaCoDAE/HTN

SHOP

SiN:SHOP integrated with NaCoDAE/HTN

In a mixed-initiative manner either SHOP or NaCoDAE/HTN has control over

the decomposition process and cedes control to the other if it cannot proceed

In control

System’s

Situation

Knowledge

SHOP


Sin algorithm l.jpg
SiN: Algorithm Planning Problems

  • Let t be the task currently being decomposed

  • If t is primitive return a success

  • Else if SHOP is in control

    • SHOP decomposes t if possible. If SHOP cannot decompose t but NaCoDAE/HTN can, then cede control to NaCoDAE/HTN.

  • Else if NaCoDAE/HTN is in control

    • NaCoDAE/HTN decomposes t if possible. If NaCODAE/HTN cannot decompose t but SHOP can, then cede control to SHOP.

  • Else if neither SHOP nor NaCoDAE/HTN can decompose t

    • Backtrack if possible. If it is not possible, then return a failure.


Sin example mixed initiative l.jpg

NaCoDAE/HTN Planning Problems

Cases denote concrete task decompositions and preferences for selecting those decompositions:

Task: travel(From,To)

Task: travelC(Penn ST.,Downtn NYC)

Decomposition:

travelC(From, Station1)

travelIC(Station1,Station2)

travelC(Station2, To)

Decomposition:

take(taxi, Penn St., Downtn NYC)

Questions:

Is it raining hard in NYC? No

Is the passenger carrying

luggage? No

Conditions:

in(To,City1)

in(To,City2)

trainStation(Station1,City1)

trainStation(Station2,City2)

SiN: Example – Mixed Initiative

SHOP

Methods denote generic task decompositions and conditions for selecting those decompositions:


Sin example mixed initiative57 l.jpg

Travel(Greenbelt,Union St.) Planning Problems

SHOP

Taxi(Greenbelt,GreenbeltM)

Metro(GreenbeltM,Union St.)

NaCoDAE/HTN

Train(Union St.,Penn St.)

Travel(Penn St.,Downtn NYC)

Taxi(Penn St.,Downtn NYC)

SiN: Example – Mixed Initiative

In control

Travel(Greenbelt, NYC)


Evaluating hicap l.jpg
Evaluating HICAP Planning Problems

  • Use HICAP to plan a NEO subtasks

    • compare performance with other approaches

  • How to evaluate? Can’t actually carry out a NEO

    • ModSAF - simulation program developed by the US Army

      • Simulates real-world military scenarios

      • Finite state simulation with modular components that represent individual entities and parts of entities

        • Example: simulated tank

          • Physical components (turret, etc.) and behavioral components (move, attack, target, react to fire, etc.)

      • Certain 3D aspects are also represented that can affect sensory and movement behavior

        • terrain elevation, trees, vegetation, rivers, oceans, atmospheric conditions, etc.

      • Realism is sufficient for training exercises



Evaluation empirical methodology l.jpg

Transport by Planning Problems

Land

Land

Air

Air

Escorted?

No

Yes (tanks)

No

Yes (attack helicopters)

Evaluation: Empirical Methodology

Blind study: HICAP user did not know the simulated scenario

  • NEO Subtask: Transport 64 evacuees from meeting site to embassy

    • Meeting site at forested crossroads outside of city

    • Terrain database from Camp Lejeune

  • Selection Method:

    • 1. HICAP

    • 2. Most frequently used plan

    • 3. Heuristic Choice (escort avg.)

    • 4. Random

  • We used the same performance measures used by the US armed forces:

    • Casualties (Evacuees, friendlies, hostiles)


Two scenarios and average results modsaf is non deterministic 10 runs l.jpg

1 2 Planning Problems

1 2

1 2

HICAP:

Most Frequent:

Heuristic:

Random:

Two Scenarios and Average Results(ModSAF is non-deterministic  10 Runs)

Evacuees Saved:

Friendly Casualties:

Hostile Casualties:

64

59

54

49

44

39

9

8

7

6

5

4

3

2

1

0

9

8

7

6

5

4

3

2

1

0

  • Scenarios: 82-person dismounted hostile teams:

    • 1. Anti-tank missiles, or

    • 2. Anti-aircraft missiles


Related work l.jpg

System Planning Problems

Generative

Case-based

Mixed-initiative

Interleaved

SHOP

X

CHEF

X

Prodigy/Analogy

X

X

SIPE II

X

X

NaCoDAE/HTN

X

X

MI-CBP

X

X

X

SiN

X

X

X

X

Related Work


Job announcement l.jpg
Job Announcement Planning Problems

  • We want to hire a full-time research scientist to work on extensions to HICAP

    • Research areas:

      • mixed-initiative planning, case-based reasoning, generative planning, knowledge management, and machine learning

    • The work will be joint between the University of Marylandand NRL's Intelligent Decision Aids Group

    • Ideal applicants will have some relevant research experience/interest, and Java software development expertise

      • Experience with simulators, military applications, and/or Smalltalk would also be welcome

    • The position is available now

  • If you’re interested, please let me know!


Related publications64 l.jpg
Related Publications Planning Problems

[Muñoz-Avila et al., 1999a]H. Muñoz-Avila, D. McFarlane, D. Aha, J. Ballas, L. Breslow and D. Nau. Using guidelines to constrain interactive case-based HTN planning. In Proceedings of the Third International Conference on Case-Based Reasoning (ICCBR-99), 1999. Finalist for the best paper award.<http://www.aic.nrl.navy.mil/papers/1999/AIC-99-004.ps.Z>

[Muñoz-Avila et al., 1999b]H. Muñoz-Avila, D. Aha, L. Breslow and D. Nau. HICAP: an interactive case-based planning architecture and its application to noncombatant evacuation operations. In IAAI-99, 1999, pages 870-875. <http://www.aic.nrl.navy.mil/papers/1999/AIC-99-002.ps.Z>

[Muñoz-Avila et al., 2000]H. Muñoz-Avila, D. W. Aha, L. A. Breslow, D. S. Nau and R. Weber. Integrating Conversational Case Retrieval with Generative Planning. In EWCBR-2000, 2000. Trento, Italy: Springer-Verlag.


Summary l.jpg

Theory Planning Problems

1. Principles ofHTN planning

4. Ordered Task

Decomposition

5. SHOP

2. Computerbridge

3. Electronic Designand Manufacturing

6. Evacuationplanning

Applications

Summary

  • Ordered task decomposition is an adaptation of HTN planning

    • Prolog-style left-to-right search; high degree of expressivity

  • Grew out of our work in two application domains:

    • manufacturing planning and the game of bridge

  • SHOP: domain-independent planning algorithm

    • Sound and complete over a wide class of problems

    • Powerful enough for use in complex applications

      • Evacuation planning


Conclusions l.jpg
Conclusions Planning Problems

  • For a long time, AI planning researchers thought that forward search was not a good way to generate plans

    • Recent results (SHOP, TLplan, FF) strongly suggest otherwise

  • AI planning is becoming capable enough to be used in real-world applications

  • Synergy between theory and applications

    • Understanding what works in practical planningsituations can produce better planning theories

    • This will lead to better real-world planners

Theory

Practice


Future work l.jpg
Future Work Planning Problems

  • Improvements to SHOP

    • optimize the data structures

    • PDDL-to-SHOP translator

  • Planning with incomplete information

    • Contingency plans, evaluation of alternatives

      • Somewhat like the game-tree search we did in Bridge Baron

  • Semi-automated knowledge acquisition

    • Case-based reasoning to synthesize HTN methods in HICAP, by observing what plans the human user creates in what situations

  • Multi-agent planning

    • Integrate SHOP with the IMPACT multi-agent environment


Acknowledgements and where to get more information l.jpg
Acknowledgements, and Planning ProblemsWhere to Get More Information

  • Sponsors

    • Government: NSF, NRL, ARL, DARPA

    • Industry: Great Game Products, Northrop Grumman

  • Where to get more information

    • Computer Bridge

      http://www.cs.umd.edu/~nau/bridge/bridge.html

    • EDAPS

      http://www.cs.umd.edu/~nau/projects/edaps/edaps.pdf

    • SHOP

      http://www.cs.umd.edu/projects/shop/

    • HICAP

      http://www.aic.nrl.navy.mil:80/hicap/


ad