In the name of God

1. In the name of God An Application of Planning JSHOP BY: M. Eftekhari and G. Yaghoobi

2. SHOP (Simple Hierarchical Ordered Planner) • 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)

3. JSHOPA Java implementation of SHOP • As part of their HICAP for Noncombatant Evacuation Operations (NEOs). • (HICAP) Hierarchical Interactive Case-based Architecture for Planning (An applet)

4. HTNHierarchical Task Network • 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

5. Continue • 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).

6. ContinueWhat is Expressivity? • 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

7. Continue • 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

8. Ordered Task Decomposition • 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

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

10. subtask 1 subtask 2 subtask 3 subtask 4 Search Strategy 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

11. Theory: Symbolic computations (STRIPS operators) Single agent (the planner) Perfect information AI Planning Is Different in PracticeThan it Was in Theory 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

12. Theory Applications Goal • Develop synergy between theory and applications

13. SHOP (Simple Hierarchical Ordered Planner) • Domain-independent algorithm forOrdered Task Decomposition • Implementation • Common-Lisp implementation available at • http://www.cs.umd.edu/projects/shop • Developing a Java implementation

14. Input and Output • 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.

15. Elements of the Input • 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 • Each axiom: Horn clause • Each primitive operator: task,precondition, delete list, add list • Performs a primitive task

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

17. Simple Example • 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

18. Simple Example (continued) 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:

19. Block worlds 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

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

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

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

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