- 63 Views
- Uploaded on
- Presentation posted in: General

In the name of God

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

In the name of God

An Application of Planning

JSHOP

BY: M. Eftekhari and G. Yaghoobi

- SHOP and its successors are domain-independent implementations of Ordered Task Decomposition
- An AI planning technique that has been useful in several application domains (University of Maryland)

- As part of their HICAP for Noncombatant Evacuation Operations (NEOs).
- (HICAP) Hierarchical Interactive Case-based Architecture for Planning (An applet)

- Objective is to create a plan to perform a set of tasks (abstract representations of things that need to be done).
- HTN planning is done by problem reduction: the planner recursively decomposes tasks into subtasks, stopping when it reaches primitive tasks that can be performed directly by planning operators

- In order to tell the planner how to decompose nonprimitive tasks into subtasks. it needs to have a set of methods .
- where each method is a schema for decomposing a particular kind of task into a set of subtasks (provided that some set of preconditions is satisfied).

- Expressivity of languages
- A language L is as expressive as another language M iff any expression in L can be translated into an expression with the same meaning in M

- HTN planning is more expressive than state-based planning
- STRIPS-style planning is a special case of HTN planning

- No transformations, because HTN models have richer structure (because HTNs can represent harder problems than the STRIPS language)
- Solutions to STRIPS problems are regular sets
- Solutions to HTN problems can be arbitrary context-free sets
- Thus HTN’s are more expressive than STRIPS

- Is a special case of HTN planning in which the planning algorithm always builds plans forward from the initial state of the world
- ordered-task-decomposition: planner plans for tasks in the same order that the tasks will later be performed.
- the planner has already planned every action that will occur beforehand

- the preconditions of its methods and operators can include logical inferences, complex numeric computations, and calls to external programs.

subtask 1

subtask 2

subtask 3

subtask 4

task

method

- Ordered task decomposition
- Require the subtasks of each method to be totally ordered
- Decompose these tasks left-to-right
- The same order that they’ll later be executed
- Analogous to PROLOG’s search strategy

Theory:

Symbolic computations (STRIPS operators)

Single agent (the planner)

Perfect information

Unstack(x,y)

Pre:on(x,y), clear(x), handempty

Del:on(x,y), clear(x), handempty

Add:holding(x), clear(y)

- Practice:
- Complex numeric computations(geometry, images, probabilities)
- Multiple agents
- Imperfect information, external information sources

Theory

Applications

- Develop synergy between theory and applications

- Domain-independent algorithm forOrdered Task Decomposition
- Implementation
- Common-Lisp implementation available at
- http://www.cs.umd.edu/projects/shop

- Developing a Java implementation

- Common-Lisp implementation available at

- Input:
- State: a set of ground atoms
- Task List: a linear list of tasks
- Domain: methods, operators, axioms

- Output: one or more plans
- depending on what we tell SHOP to look for, it can return
- the first plan it finds
- all possible plans
- a least-cost plan
- all least-cost plans
- etc.

- depending on what we tell SHOP to look for, it can return

- Initial State: collection of ground atoms (in Lisp notation)
- ((at home) (have-cash 50.43) (distance home downtown 10))

- Task list: linear list of tasks to perform
- ((travel home downtown) (buy book))

- Each method: task, preconditions and decomposition
- Preconditions to be established using logical inference
- Decomposition is a task list

- Performs a primitive task

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,…)

- Initial task list:((travel home park))
- Initial state:((at home) (cash 20) (distance home park 8))
- Methods (task, preconditions, subtasks):
- (:method (travel ?x ?y)((at x) (walking-distance ?x ?y)) ((!walk ?x ?y)) 1)
- (:method (travel ?x ?y)((at ?x) (have-taxi-fare ?x ?y)) ((!call-taxi ?x) (!ride ?x ?y) (!pay-driver ?x ?y)) 1)

- Axioms:
- (:- (walking-dist ?x ?y) ((distance ?x ?y ?d) (call (<= ?d 5))))
- (:- (have-taxi-fare ?x ?y)((have-cash ?c) (distance ?x ?y ?d) (call (>= ?c (+ 1.50 ?d))))

- Primitive operators (task, precondition, delete list, add list)
- (:operator (!walk ?x ?y) () ((at ?x)) ((at ?y)))
- …

Optional cost;default is 1

Initial state:

(at home)(cash 20)

(distance home park 8)

(travel home park)

Precond:

Precond:

(at home)

(walking-distance

Home park)

(at home)

(have-taxi-fare home park)

Succeed

Succeed (we have $20,and the fare is only $9.50)

Succeed

Fail (distance > 5)

(!pay-driver home park)

(!call-taxi home)

(!ride home park)

(at park)(cash 10.50)

(distance home park 8)

(!walk home park)

Final state:

Final State

Using Methods

4

5

1

2

3

1

Initial state

Task1

Task2

Task3

Task4

Task5

How to do?

5

Only achieving goals

3

4

1

2

1

Final state

Book keeping Planning

Classical Planning

- 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)

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

- (: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)))

- (: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)))