SHOP2. Modelling for and using a hierarchical planner. Ilche Georgievski Room: IAAS

Transcription

1 SHOP2 Modelling for and using a hierarchical planner Ilche Georgievski ilche.georgievski@iaas.uni-stuttgart.de Room: IAAS /2018 Spring

2 Why hierarchies? Easily understandable Different levels of abstractions Many real-world domains are intrinsically hierarchical Library classification DNS Star system

3 Hierarchies in planning (1) We may have an idea how to go about solving some problems Recipes why not use them? Instructions of how to do something Write actions and tasks that do fit the recipe Speed up planning Don t waste time to construct plans from individual actions Avoid exponential explosion

4 Hierarchies in planning (2) Reduce complexity Abstractions hide details Disadvantage Writing a planning domain is complicated (or more complicated than writing actions for classical planning) Abstractions hide conflicts too

5 Recap: HTN Planning Tasks Compound abstractions Primitive we know how to execute them directly Task network Tasks and their ordering Methods Ways to decompose compound tasks into subtasks (task network) Operators Achieve primitive tasks Actions in classical planning Initial state Predicates that are true Initial task network

6 Domain Modelling No standard language specification (yet) Hierarchical Planning Definition Language (HPDL) Attempt to standardize based on PDDL SIADEX and SH planners Each planner has ist own syntax SHOP2 specification syntax For the SHOP familiy of planners

7 SHOP2 planner Simple Hierarchical Ordered Planner Partial-order forward decomposition Domain configurable Turing-complete, sound and complete Won a distinguished award at the 3rd International Planning Competition

8 SHOP2 planner Input: tasks are partially ordered Output: totally ordered plan It knows the state at each planning step Make use of it to prune actions It is easy to call external programs, perform numeric operations, etc. Can be used to create efficient domainspecific planning algorithms

9 SHOP2 Syntax First-order logic Uses schematic encodings Lisp-like syntax More or less the same syntax for JSHOP2, the Java implementation of SHOP2

10 SHOP2 Components Predicates are properties of objects that can be true or false Operators describe ways of changing the state of the world Methods are ways of accomplishing our tasks (instructions) Initial state is the state of the world in which we start Initial task network contains the methods we want to perform and their ordering Axioms are statements not explicitly present in the planning state, but their logical value is inferred from the predicates in the state (Horn clauses)

11 Two parts of SHOP2 modelling Planner s input separated into two files Domain file for operators and methods Problem file for the initial state and initial task network SHOP2 files have a.lisp extension JSHOP2 files have no extension

12 SHOP2 Domain File Basic structure of domain files: (defdomain <domain-name> <SHOP2 code for operator schemas> <SHOP2 code for method schemas> ) <domain-name> is a string the identifies the application domain

13 SHOP2 Problem File Basic structure of problem files: (defproblem <problem-name> <domain-name> ) <SHOP2 code for the initial state> <SHOP2 code for the initial task network> <problem-name> is a string that identifies the planning problem <domain-name> must match the domain name in the corresponding domain file

14 TARS, the Gripper A gripping planning problem with four balls* TARS, a smart home robot, can move between boy s room and girl s room, and can pick up or drop balls with either of his two arms. Initially, all balls and TARS are in the boy s room. We want the balls to be in the girl s room. *As in the gripper planning domain found on Internet

15 TARS, the Gripper Instructions for how to move a ball to some destination What do we already now? Pick up a ball, move the robot, and drop the ball Pick up two balls, move the robot, drop the balls

16 TARS, the Gripper Predicates: Is ball x inside room y? Is TARS arm x empty? [ ] Operators: TARS can move between the rooms, pick up a ball or drop a ball. Tasks: move a ball, carry a ball, leave a ball Initial state: all balls and TARS are in the boy s room. Both TARS arms are empty. [ ] Initial task network: move all four balls.

17 TARS, the Gripper: Predicates Predicates: at-robot(x) at-ball(x, y) free(x) carry(x, y) true iff x is a room and TARS is in x true iff x is a ball, y is a room, and x is in y true iff x is an arm and x does not hold a ball true iff x is an arm, y is a ball, and x holds y SHOP2: predicates are not listed in the domain (in contrast to PDDL)

18 TARS, the Gripper: Movement Operator (1) Operator: Description: Precondition: Effect: TARS can move from x to y Empty. Knowledge transferred into the methods. at-robot(y) becomes true. at-robot(x) becomes false. Everything else does not change.

19 TARS, the Gripper: Movement Operator (2) SHOP2: Operators begin with! (:operator (!move?x?y) () ((at-robot?x)) ((at-robot?y)) ) Precondition Delete list Add list Effect

20 TARS, the Gripper: Pick-up Operator Operator: Description: Precondition: Effect: TARS can pick up x with y in z Empty. Knowledge transferred into the methods. carry(z, x) becomes true. at-ball(x, y) and free(z) become false. Everything else does not change. SHOP2: (:operator (!pick-up (?x?y?z) () ((at-ball?x?y) (free?z)) ((carry?z?x)) )

21 TARS, the Gripper: Drop Operator Operator: Description: TARS can drop x in y from z Preconditions and effects similar to the pick-up operator. SHOP2: (:operator (!drop (?x?y?z) () ((carry?z?x)) ((at-ball?x?y) (free?z)) )

22 TARS, the Gripper: Move a Ball Task (1) Task: Description: What needs to be done for TARS to move a ball x to y Method 1 Description: Precondition: Subtasks: If x is already at the destination, do not do anything. at-ball(x,y) is true. No subtasks. Method 2 Description: Precondition: Subtasks: If there is a ball x to be moved, make sure TARS is in the same room z, so that he can take x, move to y and leave x. at-ball(x,z) is true. move-robot(y,z), take(x,z), move-robot(z,y),leave(x,y).

23 TARS, the Gripper: Move a Ball Task (2) SHOP2: :method is used to define all possible ways of achieving a task (:method (move-ball?ball?to) ((at-ball?ball?to)) () Precondition Subtasks Method 1 ) ((at-ball?ball?from)) ((move-robot?to?from) (take?ball?from) (move-robot?from?to) (leave?ball?to)) Precondition Subtasks Method 2

24 TARS, the Gripper: Move the Robot Task (1) Task: Description: What needs to be done for TARS to move from x to y Description: Precondition: Subtasks: Method 1 If TARS is already at y, do not do anything. at-robot(y) is true. No subtasks. Method 2 Description: If TARS is at x, make him move to y. Precondition: at-robot(x) is true. Subtasks: move(x,y).

25 TARS, the Gripper: Move the Robot Task (2) SHOP2: (:method (move-robot?from?to) ((at-robot?to)) () ) ((at-robot?from)) ((!move?from?to))

26 TARS, the Gripper: Take a Ball Task Task: Description: What needs to be done for TARS to take a ball x at y Method 1 Description: Precondition: Subtasks: If TARS has a free arm and is in the same room as the ball, he can pick x up. free(z) and at-robot(y) are true. pick-up(x,y,z) SHOP2: (:method (take?ball?from) ) ((free?arm) (at-robot?from)) ((!pick-up?ball?from?arm))

27 TARS, the Gripper: Leave a Ball Task Task: Description: What needs to be done for TARS to leave a ball x at y. Method 1 Description: If TARS is carrying x and is at y, he can drop x. Precondition: Subtasks: carry(x,z) and at-robot(y) are true. drop(x,y,z). SHOP2: (:method (leave?ball?to) ) ((carry?ball?arm) (at-robot?to)) ((!drop?ball?to?arm))

28 TARS, the Gripper: Initial State (1) Initial state: free(left) and free(right) are true. at-robot(boyroom) is true. at-ball(blueball, boyroom),, at-ball(yellowball, boyroom) are true. Everything else is false.

29 TARS, the Gripper: Initial state (2) SHOP2: ( ) (free left) (free right) (at-robot boyroom) (at-ball blueball boyroom) (at-ball greenroom boyroom) (at-ball pinkball boyroom) (at-ball yellowball boyroom)

30 TARS, the Gripper: Initial Task Network Initial task network: move-ball(blueball, girlroom),, move-ball(yellowball, girlroom) must be performed and they can be performed in any order. Everything else is not important. SHOP2: (:unordered (move-ball blueball girlroom) (move-ball greenball girlroom) (move-ball pinkball girlroom) (move-ball yellowball girlroom) )

31 SHOP2 Written in Common Lisp Requirements Common Lisp installed (e.g., Allegro Common Lisp v8.2) Linux and Mac OS X Windows (under the assumption that ASDF system definitions are set properly) Download, installation and usage instructions here (github fork of the original SourceForce CSV repository)

32 JSHOP2 Java implementation of SHOP2 Download Documentation (JSHOP2.pdf) included in the.zip file Some syntax differences with SHOP2 Operator s preconditions cannot be omitted Smaller range of possible symbol names Keywords :task, :ordered and list are not supported Requirements JDK installed

33 JSHOP2 Installation Unzip the JSHOP2 zipped file Set the CLASSPATH environment variable to include On Windows: JSHOP2_DIRECTORY\bin\antlr.jar;JSHOP2_DIRECTORY\bi n\jshop2.jar;. On UNIX: JSHOP2_DIRECTORY/bin/antlr.jar:JSHOP2_DIRECTORY/bi n/jshop2.jar:. Replace JSHOP2_DIRECTORY with the directory where JSHOP2 is unzipped

34 JSHOP2 Compiling the source make or make c Running the planner For domains included in the.zip file: make <num>, where <num> is a number between 1 and 11 repesenting a domain from the included examples Your own domain java JSHOP2.InternalDomain <domain file> Choose: java JSHOP2.InternalDomain r <problem file> for a single plan, java JSHOP2.InternalDomain r<num> <problem file> for a <num> number of plans, or java JSHOP2.InternalDomain ra <problem file> for all possible plans javac <problem-name>.java java <problem-name> Programatically

35 TARS, the Gripper, JSHOP2 output (1)

36 TARS, the Gripper, JSHOP2 output (2)

37 References Ilghami, O. Documentation for JSHOP2, University of Maryland Nau, Dana S. Hierarchical Task Network Planning. Lecture slides for Automated Planning: Theory and Practice. University of Maryland

38 Report Submission Update your specification document Project title Project team members Update your sections as you see fit Include a Reflection section Did you implement everything you wanted? If not, why? What would you do differently with your project given the knowledge and experience you now have? Submit the report PDF document (no slides!) Deadline: Friday 20 th July 23:59. Where: marco.aiello@iaas.uni-stuttgart.de and ilche.georgievski@iaas.uni-stuttgart.de

39 Final Demo Date: Monday 23 rd July Room: 0.353, Universitätsstraße 38 Time: Group 1 9:30 Group 2 9:50 Group 11 10:10 Group 4 10:30 Group 5 10:50 Group 6 11:10 Group 7 11:30 Group 8 11:50 Group 10 12:10 Group 3 12:30