90
INSTITUTE OF THEORETICAL INFORMATICS Automated Planning and Scheduling Lecture 8: Hierarchical Planning Tom ´ s Balyo, Dominik Schreiber | December 13, 2018 KIT – University of the State of Baden-Wuerttemberg and National Laboratory of the Helmholtz Association www.kit.edu

Automated Planning and Scheduling - KIT

  • Upload
    others

  • View
    6

  • Download
    0

Embed Size (px)

Citation preview

INSTITUTE OF THEORETICAL INFORMATICS

Automated Planning and SchedulingLecture 8: Hierarchical Planning

Tomas Balyo, Dominik Schreiber | December 13, 2018

KIT – University of the State of Baden-Wuerttemberg and

National Laboratory of the Helmholtz Association

www.kit.edu

Outline

The idea behind hierarchical planningHTN planning

Definition, Expressiveness, Algorithms, Models

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 2/36

Motivation

Share your domain-specific knowledge with your planner.

Example: Cooking

Suppose we program a robot which cooks meals autonomouslyPlan the cooking using classical planning

Objects: All kinds of ingredients, tools, pans, . . .Actions: Put object from x to y , turn on stove, chop stuff, . . .Goal: Have a finished meal on the table

Get some plan fulfilling your problem modelUnstructured: Order of done tasks more or less arbitraryCan be sub-optimal w.r.t. actual real-world actions the robot doesFinding a plan can be very expensive

Better idea: Tell the planner what you know about cooking

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 3/36

Motivation

Share your domain-specific knowledge with your planner.

Example: Cooking

Suppose we program a robot which cooks meals autonomously

Plan the cooking using classical planningObjects: All kinds of ingredients, tools, pans, . . .Actions: Put object from x to y , turn on stove, chop stuff, . . .Goal: Have a finished meal on the table

Get some plan fulfilling your problem modelUnstructured: Order of done tasks more or less arbitraryCan be sub-optimal w.r.t. actual real-world actions the robot doesFinding a plan can be very expensive

Better idea: Tell the planner what you know about cooking

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 3/36

Motivation

Share your domain-specific knowledge with your planner.

Example: Cooking

Suppose we program a robot which cooks meals autonomouslyPlan the cooking using classical planning

Objects: All kinds of ingredients, tools, pans, . . .Actions: Put object from x to y , turn on stove, chop stuff, . . .Goal: Have a finished meal on the table

Get some plan fulfilling your problem modelUnstructured: Order of done tasks more or less arbitraryCan be sub-optimal w.r.t. actual real-world actions the robot doesFinding a plan can be very expensive

Better idea: Tell the planner what you know about cooking

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 3/36

Motivation

Share your domain-specific knowledge with your planner.

Example: Cooking

Suppose we program a robot which cooks meals autonomouslyPlan the cooking using classical planning

Objects: All kinds of ingredients, tools, pans, . . .Actions: Put object from x to y , turn on stove, chop stuff, . . .Goal: Have a finished meal on the table

Get some plan fulfilling your problem modelUnstructured: Order of done tasks more or less arbitraryCan be sub-optimal w.r.t. actual real-world actions the robot doesFinding a plan can be very expensive

Better idea: Tell the planner what you know about cooking

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 3/36

Motivation

Share your domain-specific knowledge with your planner.

Example: Cooking

Suppose we program a robot which cooks meals autonomouslyPlan the cooking using classical planning

Objects: All kinds of ingredients, tools, pans, . . .Actions: Put object from x to y , turn on stove, chop stuff, . . .Goal: Have a finished meal on the table

Get some plan fulfilling your problem modelUnstructured: Order of done tasks more or less arbitraryCan be sub-optimal w.r.t. actual real-world actions the robot doesFinding a plan can be very expensive

Better idea: Tell the planner what you know about cooking

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 3/36

Motivation: A Cooking Task Network (1)

cook_spaghetti

prepare_ingredients

cook_noodles

cook_sauce serve

fetch_ingredients chop_stuff

warm_water add_salt add_noodles drain_water

sear_onions add_tomatoes add_seasoning combine_food put(plate,table)

Ovals: non-primitive tasks (expand to sequences of subtasks)

Rectangles: primitive tasks (correspond to classical actions)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 4/36

Motivation: A Cooking Task Network (2)

prepare_ingredients

fetch_ingredients chop_stuff

put(noodles,cupboard,table)

put(tomatoes,fridge,table)

put(onions,can,table)

put(salt,cupboard,table)

grab(knife) chop(onions,table)

After expanding all tasks in the network exhaustively,. . . all leaves correspond to classical actions. . . traversing all leaves from left to right yields a plan

How does this structure differ from classical planning?Plan is structured in a natural way (intuitive subtasks can be identified)Search space of planner is drastically reduced

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 5/36

Motivation: A Cooking Task Network (2)

prepare_ingredients

fetch_ingredients chop_stuff

put(noodles,cupboard,table)

put(tomatoes,fridge,table)

put(onions,can,table)

put(salt,cupboard,table)

grab(knife) chop(onions,table)

After expanding all tasks in the network exhaustively,. . . all leaves correspond to classical actions. . . traversing all leaves from left to right yields a plan

How does this structure differ from classical planning?Plan is structured in a natural way (intuitive subtasks can be identified)Search space of planner is drastically reduced

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 5/36

Towards Hierarchical Task Networks

What do we keep from classical planning?

States: Consistent sets of atoms

Goal: Atoms which need to be achieved (now: optional)Actions: Only way to alter states

Will be “leaves” in our hierarchy

What is new?Tasks: What needs to be achieved

Not just in the end, but during the entire procedure

Methods: How a task may be achievedConstraints: What the application of some method enforces

on the world state before / during / after achieving the taskon the spawned subtasks

Top-level objective: Initial task network to achieve

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 6/36

Towards Hierarchical Task Networks

What do we keep from classical planning?

States: Consistent sets of atoms

Goal: Atoms which need to be achieved (now: optional)Actions: Only way to alter states

Will be “leaves” in our hierarchy

What is new?Tasks: What needs to be achieved

Not just in the end, but during the entire procedure

Methods: How a task may be achievedConstraints: What the application of some method enforces

on the world state before / during / after achieving the taskon the spawned subtasks

Top-level objective: Initial task network to achieve

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 6/36

Hierarchical Planning: Tasks

TaskA task is a syntactical expression which represents a certain operationalobjective of the problem at hand. A task is either primitive or compound.If it is primitive, it can be achieved by applying a certain action.If it is compound, it can be achieved by applying certain methods.

Examples:

Task put(plate, table):primitive, achieved by action put(plate, table)

(Primitive task and its action are interchangeable)

put(plate,table)

Task chop stuff():compound, achieved by multiple subtasks〈grab(knife), chop(onions, table)〉

chop_stuff

grab(knife) chop(onions,table)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 7/36

Hierarchical Planning: Tasks

TaskA task is a syntactical expression which represents a certain operationalobjective of the problem at hand. A task is either primitive or compound.If it is primitive, it can be achieved by applying a certain action.If it is compound, it can be achieved by applying certain methods.

Examples:

Task put(plate, table):primitive, achieved by action put(plate, table)

(Primitive task and its action are interchangeable)

put(plate,table)

Task chop stuff():compound, achieved by multiple subtasks〈grab(knife), chop(onions, table)〉

chop_stuff

grab(knife) chop(onions,table)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 7/36

Hierarchical Planning: Task Networks

Task NetworkA task network (T ,C) is a set of tasks T with a set of constraints C.A constraint has one of the following forms:

1 t1 ≺ t2: Ordering constraint; t1 must be achieved before t22 (p, t): “Before” constraint; atom p holds before t is achieved3 (t, p): “After” constraint; atom p holds after t is achieved4 (t1, p, t2): “Between” constraint; atom p holds between

achieving t1 and achieving t2

Example constraints in a task network for chop stuff:1 (grab(knife) ≺ chop(onions, table))2 (at(onions, table), chop(onions, table))3 (chop(onions, table), chopped(onions))4 (grab(knife), at(knife, hand), chop(onions, table))

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 8/36

Hierarchical Planning: Task Networks

Task NetworkA task network (T ,C) is a set of tasks T with a set of constraints C.A constraint has one of the following forms:

1 t1 ≺ t2: Ordering constraint; t1 must be achieved before t22 (p, t): “Before” constraint; atom p holds before t is achieved3 (t, p): “After” constraint; atom p holds after t is achieved4 (t1, p, t2): “Between” constraint; atom p holds between

achieving t1 and achieving t2

Example constraints in a task network for chop stuff:1 (grab(knife) ≺ chop(onions, table))2 (at(onions, table), chop(onions, table))3 (chop(onions, table), chopped(onions))4 (grab(knife), at(knife, hand), chop(onions, table))

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 8/36

Hierarchical Planning: Methods

MethodA method m is a “recipe” for how to achieve a certain compound task t .It contains a task network (subtasks(m), constraints(m)).

Method m for task t = chop stuff:subtasks(m) = {t1 : grab(knife), t2 : chop(onions, table)}constraints(m) = {(t1 ≺ t2), (at(onions, table), t2),(t2, chopped(onions)), (t1, at(knife, hand), t2)}Workings of methods in general:

One task can have multiple methods with different task networks(planner needs to pick one!)A method for a task t may feature t in its task network (recursion)Constraints of a task network may be emptyIf subtasks are totally ordered: Just write 〈. . .〉 instead of {. . .},keep needed ordering constraints implicit

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 9/36

Hierarchical Planning: Methods

MethodA method m is a “recipe” for how to achieve a certain compound task t .It contains a task network (subtasks(m), constraints(m)).

Method m for task t = chop stuff:subtasks(m) = {t1 : grab(knife), t2 : chop(onions, table)}constraints(m) = {(t1 ≺ t2), (at(onions, table), t2),(t2, chopped(onions)), (t1, at(knife, hand), t2)}

Workings of methods in general:One task can have multiple methods with different task networks(planner needs to pick one!)A method for a task t may feature t in its task network (recursion)Constraints of a task network may be emptyIf subtasks are totally ordered: Just write 〈. . .〉 instead of {. . .},keep needed ordering constraints implicit

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 9/36

Hierarchical Planning: Methods

MethodA method m is a “recipe” for how to achieve a certain compound task t .It contains a task network (subtasks(m), constraints(m)).

Method m for task t = chop stuff:subtasks(m) = {t1 : grab(knife), t2 : chop(onions, table)}constraints(m) = {(t1 ≺ t2), (at(onions, table), t2),(t2, chopped(onions)), (t1, at(knife, hand), t2)}Workings of methods in general:

One task can have multiple methods with different task networks(planner needs to pick one!)A method for a task t may feature t in its task network (recursion)Constraints of a task network may be emptyIf subtasks are totally ordered: Just write 〈. . .〉 instead of {. . .},keep needed ordering constraints implicit

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 9/36

Task Network Example: Navigation

Agent at some position x , walks on a map of waypoints

In classical planning: operator move(x, y),atoms at(x), road(x, y) and visited(x)

“Random” chaining of move actions until goal is reached

HTN: Define task navigate(x, z) with two different methods:Base case, and recursion

Method m1: subtasks(m1) = {t1 : nop()} (do nothing),constraints(m1) = {(at(x), t1), (x = z, t1)}Method m2: subtasks(m2) = {t1 : move(x,y), t2 : navigate(y,z)}(direct move + recursion),constraints(m2) = {(at(x), t1), (road(x,y), t1), (t1 ≺ t2),(t1, at(y), t2)}(Note we could add an after constraint at(z) to each of the methods)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 10/36

Task Network Example: Navigation

Agent at some position x , walks on a map of waypoints

In classical planning: operator move(x, y),atoms at(x), road(x, y) and visited(x)

“Random” chaining of move actions until goal is reached

HTN: Define task navigate(x, z) with two different methods:Base case, and recursion

Method m1: subtasks(m1) = {t1 : nop()} (do nothing),constraints(m1) = {(at(x), t1), (x = z, t1)}

Method m2: subtasks(m2) = {t1 : move(x,y), t2 : navigate(y,z)}(direct move + recursion),constraints(m2) = {(at(x), t1), (road(x,y), t1), (t1 ≺ t2),(t1, at(y), t2)}(Note we could add an after constraint at(z) to each of the methods)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 10/36

Task Network Example: Navigation

Agent at some position x , walks on a map of waypoints

In classical planning: operator move(x, y),atoms at(x), road(x, y) and visited(x)

“Random” chaining of move actions until goal is reached

HTN: Define task navigate(x, z) with two different methods:Base case, and recursion

Method m1: subtasks(m1) = {t1 : nop()} (do nothing),constraints(m1) = {(at(x), t1), (x = z, t1)}Method m2: subtasks(m2) = {t1 : move(x,y), t2 : navigate(y,z)}(direct move + recursion),constraints(m2) = {(at(x), t1), (road(x,y), t1), (t1 ≺ t2),(t1, at(y), t2)}(Note we could add an after constraint at(z) to each of the methods)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 10/36

Hierarchical Navigation: Example

Graph of waypoints:

1

2

3

4

5

Initial position 1,goal position 5

navigate(1,5)

navigate(2,5)move(1,2)

navigate(3,5)move(2,3)

navigate(4,5)move(3,4)

m2

m2

m2

navigate(5,5)move(4,5)

m2

nop()

m1

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 11/36

HTN Planning: Problems

HTN (Hierarchical Task Network) Planning Problem

An HTN planning problem P = (P,O,M, s0,T0) is a tuple where:

P, O, and M are the sets of atoms, operators, and methods;

s0 is the initial state; and

T0 is the initial task network.

What is a ground HTN planning problem in that sense?

Replace operators O with their actions A

Similarly, replace methods M with ground methods D(sometimes called reductions or decompositions)

Initial task network is always ground (just like initial state)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 12/36

HTN Planning: Problems

HTN (Hierarchical Task Network) Planning Problem

An HTN planning problem P = (P,O,M, s0,T0) is a tuple where:

P, O, and M are the sets of atoms, operators, and methods;

s0 is the initial state; and

T0 is the initial task network.

What is a ground HTN planning problem in that sense?

Replace operators O with their actions A

Similarly, replace methods M with ground methods D(sometimes called reductions or decompositions)

Initial task network is always ground (just like initial state)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 12/36

Formal definition of HTN solutions?

HTN planning is structurally complex:Completely formal definition of HTN solution plans usesoperational semantics

Idea of finding a plan to an HTN planning problem:Resolve initial task network step by step in chronological order(constraint t1 ≺ t2 ⇒ process t1 before t2)If a primitive task can be achieved regarding the current constraints,remove it, apply corresponding action and append it to the planIf a compound task can be achieved by some method, apply it andupdate task network with new subtasks and new constraintsIf all tasks have been achieved and all constraints have been satisfied,return the plan

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 13/36

Formal definition of HTN solutions?

HTN planning is structurally complex:Completely formal definition of HTN solution plans usesoperational semanticsIdea of finding a plan to an HTN planning problem:

Resolve initial task network step by step in chronological order(constraint t1 ≺ t2 ⇒ process t1 before t2)

If a primitive task can be achieved regarding the current constraints,remove it, apply corresponding action and append it to the planIf a compound task can be achieved by some method, apply it andupdate task network with new subtasks and new constraintsIf all tasks have been achieved and all constraints have been satisfied,return the plan

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 13/36

Formal definition of HTN solutions?

HTN planning is structurally complex:Completely formal definition of HTN solution plans usesoperational semanticsIdea of finding a plan to an HTN planning problem:

Resolve initial task network step by step in chronological order(constraint t1 ≺ t2 ⇒ process t1 before t2)If a primitive task can be achieved regarding the current constraints,remove it, apply corresponding action and append it to the plan

If a compound task can be achieved by some method, apply it andupdate task network with new subtasks and new constraintsIf all tasks have been achieved and all constraints have been satisfied,return the plan

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 13/36

Formal definition of HTN solutions?

HTN planning is structurally complex:Completely formal definition of HTN solution plans usesoperational semanticsIdea of finding a plan to an HTN planning problem:

Resolve initial task network step by step in chronological order(constraint t1 ≺ t2 ⇒ process t1 before t2)If a primitive task can be achieved regarding the current constraints,remove it, apply corresponding action and append it to the planIf a compound task can be achieved by some method, apply it andupdate task network with new subtasks and new constraints

If all tasks have been achieved and all constraints have been satisfied,return the plan

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 13/36

Formal definition of HTN solutions?

HTN planning is structurally complex:Completely formal definition of HTN solution plans usesoperational semanticsIdea of finding a plan to an HTN planning problem:

Resolve initial task network step by step in chronological order(constraint t1 ≺ t2 ⇒ process t1 before t2)If a primitive task can be achieved regarding the current constraints,remove it, apply corresponding action and append it to the planIf a compound task can be achieved by some method, apply it andupdate task network with new subtasks and new constraintsIf all tasks have been achieved and all constraints have been satisfied,return the plan

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 13/36

HTN planning: Solutions

HTN Solution Plan (semi-formal)A sequence of actions π = 〈a1, . . . , an〉 is a solution plan for a groundHTN planning problem P = (P,A,D, s0,T0), T0 = (T ,C), if one of thefollowing alternatives holds:

1 T is empty, and n = 0.2 Achieving a primitive task t ∈ T meets the constraints C in s0,

its corresponding action a1 is applicable in s0, andπ′ = 〈a2, . . . , an〉 is a solution plan forP ′ = (P,A,D, γ(s0, a1), (T \ {t},C)).

3 Applying a ground method m of a compound task t ∈ T meets theconstraints C in s0, and π is a solution plan forP ′ = (P,A,D, s0, (T \ {t} ∪ subtasks(m),C ∪ constraints(m)).

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 14/36

Back to Cooking

Example of deriving a plan in an HTN planning problem:

Task network T0 = ( {t1 : cook spaghetti},{ (t1, at(table,plate)) }), partial plan π = 〈〉

Reduce t1 (with some method):T0 = ({t1 : prepare ingredients, t2 : cook noodles,t3 : cook sauce, t4 : serve},{(t4, at(table,plate)), t1 ≺ t2, t2 ≺ t3, . . . }), π = 〈〉. . .

Finally: T0 = ∅, π = 〈 put(noodles,cupboard,table),put(tomatoes,fridge,table), put(onions,can,table),

. . . ,put(noodles,plate),put(sauce,plate),put(plate,table)〉.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 15/36

Back to Cooking

Example of deriving a plan in an HTN planning problem:

Task network T0 = ( {t1 : cook spaghetti},{ (t1, at(table,plate)) }), partial plan π = 〈〉Reduce t1 (with some method):T0 = ({t1 : prepare ingredients, t2 : cook noodles,

t3 : cook sauce, t4 : serve},{(t4, at(table,plate)), t1 ≺ t2, t2 ≺ t3, . . . }), π = 〈〉. . .

Finally: T0 = ∅, π = 〈 put(noodles,cupboard,table),put(tomatoes,fridge,table), put(onions,can,table),

. . . ,put(noodles,plate),put(sauce,plate),put(plate,table)〉.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 15/36

Back to Cooking

Example of deriving a plan in an HTN planning problem:

Task network T0 = ( {t1 : cook spaghetti},{ (t1, at(table,plate)) }), partial plan π = 〈〉Reduce t1 (with some method):T0 = ({t1 : prepare ingredients, t2 : cook noodles,

t3 : cook sauce, t4 : serve},{(t4, at(table,plate)), t1 ≺ t2, t2 ≺ t3, . . . }), π = 〈〉. . .

Finally: T0 = ∅, π = 〈 put(noodles,cupboard,table),put(tomatoes,fridge,table), put(onions,can,table),

. . . ,put(noodles,plate),put(sauce,plate),put(plate,table)〉.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 15/36

HTN Trucking

Trucking domain in HTN (any number of trucks, packages):

Task deliver-package(p, loc)

Method m: subtasks(m) = 〈 navigate(truck,x), load(truck,p),navigate(truck,loc), drop(truck,p) 〉,constraints(m) = {(at(p,x), t1), (empty(t), t1), . . .}Note: The truck to use is not part of the task definition!⇒ Implicit parameter of the method⇒ Truck is picked when planner picks a (ground) method

Task navigate(truck,x): Navigation procedure as described

Tasks load(t,p) and drop(t,p): primitive

Initial tasks deliver-package(p,loc) for each package p withdestination loc

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 16/36

HTN Trucking

Trucking domain in HTN (any number of trucks, packages):Task deliver-package(p, loc)

Method m: subtasks(m) = 〈 navigate(truck,x), load(truck,p),navigate(truck,loc), drop(truck,p) 〉,constraints(m) = {(at(p,x), t1), (empty(t), t1), . . .}

Note: The truck to use is not part of the task definition!⇒ Implicit parameter of the method⇒ Truck is picked when planner picks a (ground) method

Task navigate(truck,x): Navigation procedure as described

Tasks load(t,p) and drop(t,p): primitive

Initial tasks deliver-package(p,loc) for each package p withdestination loc

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 16/36

HTN Trucking

Trucking domain in HTN (any number of trucks, packages):Task deliver-package(p, loc)

Method m: subtasks(m) = 〈 navigate(truck,x), load(truck,p),navigate(truck,loc), drop(truck,p) 〉,constraints(m) = {(at(p,x), t1), (empty(t), t1), . . .}Note: The truck to use is not part of the task definition!⇒ Implicit parameter of the method⇒ Truck is picked when planner picks a (ground) method

Task navigate(truck,x): Navigation procedure as described

Tasks load(t,p) and drop(t,p): primitive

Initial tasks deliver-package(p,loc) for each package p withdestination loc

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 16/36

HTN Trucking

Trucking domain in HTN (any number of trucks, packages):Task deliver-package(p, loc)

Method m: subtasks(m) = 〈 navigate(truck,x), load(truck,p),navigate(truck,loc), drop(truck,p) 〉,constraints(m) = {(at(p,x), t1), (empty(t), t1), . . .}Note: The truck to use is not part of the task definition!⇒ Implicit parameter of the method⇒ Truck is picked when planner picks a (ground) method

Task navigate(truck,x): Navigation procedure as described

Tasks load(t,p) and drop(t,p): primitive

Initial tasks deliver-package(p,loc) for each package p withdestination loc

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 16/36

HTN Trucking

Trucking domain in HTN (any number of trucks, packages):Task deliver-package(p, loc)

Method m: subtasks(m) = 〈 navigate(truck,x), load(truck,p),navigate(truck,loc), drop(truck,p) 〉,constraints(m) = {(at(p,x), t1), (empty(t), t1), . . .}Note: The truck to use is not part of the task definition!⇒ Implicit parameter of the method⇒ Truck is picked when planner picks a (ground) method

Task navigate(truck,x): Navigation procedure as described

Tasks load(t,p) and drop(t,p): primitive

Initial tasks deliver-package(p,loc) for each package p withdestination loc

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 16/36

HTN vs. Classical Planning

How does HTN practically help model planning domains?

Express stepwise refinement of abstract tasks (very intuitive)

Supply methods with expressive constraints,focusing search of a planner

Is HTN planning theoretically more powerful than STRIPS planning?Can we simulate a classical planning problem with HTN?

Sure: See exercises

Can we simulate an HTN planning problem with classical planning?No!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 17/36

HTN vs. Classical Planning

How does HTN practically help model planning domains?

Express stepwise refinement of abstract tasks (very intuitive)

Supply methods with expressive constraints,focusing search of a planner

Is HTN planning theoretically more powerful than STRIPS planning?Can we simulate a classical planning problem with HTN?

Sure: See exercises

Can we simulate an HTN planning problem with classical planning?No!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 17/36

HTN vs. Classical Planning

How does HTN practically help model planning domains?

Express stepwise refinement of abstract tasks (very intuitive)

Supply methods with expressive constraints,focusing search of a planner

Is HTN planning theoretically more powerful than STRIPS planning?Can we simulate a classical planning problem with HTN?

Sure: See exercises

Can we simulate an HTN planning problem with classical planning?

No!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 17/36

HTN vs. Classical Planning

How does HTN practically help model planning domains?

Express stepwise refinement of abstract tasks (very intuitive)

Supply methods with expressive constraints,focusing search of a planner

Is HTN planning theoretically more powerful than STRIPS planning?Can we simulate a classical planning problem with HTN?

Sure: See exercises

Can we simulate an HTN planning problem with classical planning?No!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 17/36

Undecidability of HTN Planning

Theorem. [EHN94]Given an HTN planning problem P , it is generally undecidablewhether P is solvable (i.e. has a solution plan).

Consequence: Can only have semi-decidable planning proceduresIf a plan exists, it will eventually be foundIf no plan exists, you may never know

Proof: Model an undecidable problem as an HTN planning problem⇒ HTN planning cannot be decidable then!Possible candidates?

Halting problem: quite cumbersome and technicalUndecidable problems from formal languages: Much better suitedPost Correspondence Problem: Simpler, more intuitive

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 18/36

Undecidability of HTN Planning

Theorem. [EHN94]Given an HTN planning problem P , it is generally undecidablewhether P is solvable (i.e. has a solution plan).

Consequence: Can only have semi-decidable planning proceduresIf a plan exists, it will eventually be foundIf no plan exists, you may never know

Proof: Model an undecidable problem as an HTN planning problem⇒ HTN planning cannot be decidable then!Possible candidates?

Halting problem: quite cumbersome and technicalUndecidable problems from formal languages: Much better suitedPost Correspondence Problem: Simpler, more intuitive

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 18/36

Undecidability of HTN Planning

Theorem. [EHN94]Given an HTN planning problem P , it is generally undecidablewhether P is solvable (i.e. has a solution plan).

Consequence: Can only have semi-decidable planning proceduresIf a plan exists, it will eventually be foundIf no plan exists, you may never know

Proof: Model an undecidable problem as an HTN planning problem⇒ HTN planning cannot be decidable then!Possible candidates?

Halting problem: quite cumbersome and technical

Undecidable problems from formal languages: Much better suitedPost Correspondence Problem: Simpler, more intuitive

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 18/36

Undecidability of HTN Planning

Theorem. [EHN94]Given an HTN planning problem P , it is generally undecidablewhether P is solvable (i.e. has a solution plan).

Consequence: Can only have semi-decidable planning proceduresIf a plan exists, it will eventually be foundIf no plan exists, you may never know

Proof: Model an undecidable problem as an HTN planning problem⇒ HTN planning cannot be decidable then!Possible candidates?

Halting problem: quite cumbersome and technicalUndecidable problems from formal languages: Much better suitedPost Correspondence Problem: Simpler, more intuitive

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 18/36

Undecidability of HTN Planning (2)

The Post Correspondence Problem (PCP) [Pos46]Let Σ an alphabet with |Σ| ≥ 2, and A := 〈a1, . . . , ak〉 andB := 〈b1, . . . , bk〉 two sequences of words from Σ. (ai , bi ∈ Σ∗)Is there a sequence of indices 〈i1, i2, . . . , iN〉, N ≥ 1, such that

ai1ai2 . . . aiN = bi1bi2 . . . biN ,

i.e. the concatenations of chosen words from A and B perfectly match?

Objective: Model PCP as an HTN planning problem

Make the planner pick a sequence of indices

Symbol for symbol, match the resulting strings against each other

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 19/36

Undecidability of HTN Planning (2)

The Post Correspondence Problem (PCP) [Pos46]Let Σ an alphabet with |Σ| ≥ 2, and A := 〈a1, . . . , ak〉 andB := 〈b1, . . . , bk〉 two sequences of words from Σ. (ai , bi ∈ Σ∗)Is there a sequence of indices 〈i1, i2, . . . , iN〉, N ≥ 1, such that

ai1ai2 . . . aiN = bi1bi2 . . . biN ,

i.e. the concatenations of chosen words from A and B perfectly match?

Objective: Model PCP as an HTN planning problem

Make the planner pick a sequence of indices

Symbol for symbol, match the resulting strings against each other

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 19/36

An HTN planning domain for PCP (1)

Atoms: turnA and turnB (whose turn is it to add a symbol?),symbol(x) for all x ∈ Σ (which symbol is added?),picked(i) for all i ∈ 1, . . . ,N (what’s the “current” picked index i?)

All actions either (require turnA, delete turnA and add turnB),or (require turnB, delete turnB and add turnA)

Strict alternation between actions concerning Aand actions concerning BAction pickIndex(i) sets atom picked(i),action matchIndex(i) requires and deletes picked(i)Action print(x) sets atom symbol(x),action match(x) requires and deletes symbol(x)

Initial tasks: T0 = {startA(), startB()}

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 20/36

An HTN planning domain for PCP (1)

Atoms: turnA and turnB (whose turn is it to add a symbol?),symbol(x) for all x ∈ Σ (which symbol is added?),picked(i) for all i ∈ 1, . . . ,N (what’s the “current” picked index i?)

All actions either (require turnA, delete turnA and add turnB),or (require turnB, delete turnB and add turnA)

Strict alternation between actions concerning Aand actions concerning BAction pickIndex(i) sets atom picked(i),action matchIndex(i) requires and deletes picked(i)Action print(x) sets atom symbol(x),action match(x) requires and deletes symbol(x)

Initial tasks: T0 = {startA(), startB()}

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 20/36

An HTN planning domain for PCP (2)

Initial tasks: T0 = {startA(), startB()}For each word in A (B), add a method for startA (startB)Say, Σ := {0, 1}, A ⊇ a1 := 001 and B ⊇ b1 := 0

Add possible method for startA() with ordered subtasks〈pickIndex(1), startA(), print(0), print(0), print(1)〉Add possible method for startB() with ordered subtasks〈matchIndex(1), startB(), match(0)〉

Structure of derivable plans:1 First part: 〈 pickIndex(iN), matchIndex(iN), . . .pickIndex(i2),

matchIndex(i2), pickIndex(i1), matchIndex(i1) 〉2 Second part: 〈 print(x1), match(x1), print(x2), match(x2), . . . ,

print(xZ), match(xZ) 〉Such a plan can be derived from the HTN problem if and only ifthere is such a matching in the original PCP instance

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 21/36

An HTN planning domain for PCP (2)

Initial tasks: T0 = {startA(), startB()}For each word in A (B), add a method for startA (startB)Say, Σ := {0, 1}, A ⊇ a1 := 001 and B ⊇ b1 := 0

Add possible method for startA() with ordered subtasks〈pickIndex(1), startA(), print(0), print(0), print(1)〉Add possible method for startB() with ordered subtasks〈matchIndex(1), startB(), match(0)〉

Structure of derivable plans:1 First part: 〈 pickIndex(iN), matchIndex(iN), . . .pickIndex(i2),

matchIndex(i2), pickIndex(i1), matchIndex(i1) 〉2 Second part: 〈 print(x1), match(x1), print(x2), match(x2), . . . ,

print(xZ), match(xZ) 〉Such a plan can be derived from the HTN problem if and only ifthere is such a matching in the original PCP instance

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 21/36

HTN Undecidability: Remarks

As PCP is undecidable, HTN planning is undecidable as wellWhy can’t we model PCP in classical planning?

Needed sequence of indices may be arbitrarily longNeed to pick same indices for both A and B, but the correspondingwords may occur at very different times in the plan“Memory” of any given state bounded by 2|P| in classical planning

Direct consequence:

Expressiveness of HTN planningThere are planning problems which can be solved with HTN formalisms,but not with classical planning formalisms.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 22/36

HTN Undecidability: Remarks

As PCP is undecidable, HTN planning is undecidable as wellWhy can’t we model PCP in classical planning?

Needed sequence of indices may be arbitrarily longNeed to pick same indices for both A and B, but the correspondingwords may occur at very different times in the plan“Memory” of any given state bounded by 2|P| in classical planning

Direct consequence:

Expressiveness of HTN planningThere are planning problems which can be solved with HTN formalisms,but not with classical planning formalisms.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 22/36

HTN Undecidability: Remarks

As PCP is undecidable, HTN planning is undecidable as wellWhy can’t we model PCP in classical planning?

Needed sequence of indices may be arbitrarily longNeed to pick same indices for both A and B, but the correspondingwords may occur at very different times in the plan“Memory” of any given state bounded by 2|P| in classical planning

Direct consequence:

Expressiveness of HTN planningThere are planning problems which can be solved with HTN formalisms,but not with classical planning formalisms.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 22/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:

Task networks restricted to regular structureEach task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Expressiveness

Where does the power of HTN come from?

Hierarchical search states of arbitrary depth (Recursive tasks)

Interleaving of initial tasks(complex interaction between tasks possible)

Which features of HTN are (theoretically) unimportant?

Causal constraints (other than ordering)

(Partial order and interleaving) of non-initial tasks

Decidable subclasses:Task networks restricted to regular structure

Each task network is an ordered sequence 〈a, t〉 or 〈a〉Same expressive power as classical planning

Totally ordered tasks on all levelsDisallows interleaving⇒ no complex interactions between tasks

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 23/36

HTN Planning Approaches

Our definition of HTN solutions is already an abstract algorithmChronological processing of tasks and actionsMaintain a state during search (as in classical forward search)Non-deterministic choice of tasks and methods to use

Mainly three approaches:1 State space planning (“chonological”, as described above)2 Plan space planning (also “non-linear planning”)3 SAT-based HTN planning

Currently best / most well-established approach:State space planning

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 24/36

HTN Planning Approaches

Our definition of HTN solutions is already an abstract algorithmChronological processing of tasks and actionsMaintain a state during search (as in classical forward search)Non-deterministic choice of tasks and methods to use

Mainly three approaches:1 State space planning (“chonological”, as described above)2 Plan space planning (also “non-linear planning”)3 SAT-based HTN planning

Currently best / most well-established approach:State space planning

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 24/36

SHOP2 Planner

Algorithm 1 SHOP2 Planning procedure [NAI+03] (simplified, abstract)1: π = 〈〉; (T ,C) := initial task network2: while TRUE do3: if T = ∅ then return π // everything achieved4: T ′ := {t ∈ T : there is no t ′ such that t ′ ≺ t ∈ C}5: if T ′ = ∅ then return FAILURE // no valid tasks to pick from6: if ∃t ∈ T ′: t is primitive and its action a is applicable in s then7: T := T \ {t}; π := π ◦ a; s := γ(s, a)8: else if ∃t ∈ T ′: t is compound and one of its methods m is applicable in s then9: T := T \ {t} ∪ {subtasks(m)}

10: C := C ∪ {constraints(m)}11: else return FAILURE12: end if13: end while

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 25/36

SHOP2 Planner

Which simplifications are assumed in Alg. 1?

Check constraints of a method’s task network before its applicationProblem with general constraints (especially between, after )In SHOP2: Only before constraints for an entire method and orderingconstraints supportedAlternative: Add “markers” to check causal constraints later,even if parent task has been removed

Constraints involving removed tasks are not removed from CRemove concerned constraints, add updated ordering constraintsAlternative: Keep tasks in network as long as they are unfinished

Non-deterministic choice of tasks and methodsHeuristics needed!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 26/36

SHOP2 Planner

Which simplifications are assumed in Alg. 1?Check constraints of a method’s task network before its application

Problem with general constraints (especially between, after )In SHOP2: Only before constraints for an entire method and orderingconstraints supportedAlternative: Add “markers” to check causal constraints later,even if parent task has been removed

Constraints involving removed tasks are not removed from CRemove concerned constraints, add updated ordering constraintsAlternative: Keep tasks in network as long as they are unfinished

Non-deterministic choice of tasks and methodsHeuristics needed!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 26/36

SHOP2 Planner

Which simplifications are assumed in Alg. 1?Check constraints of a method’s task network before its application

Problem with general constraints (especially between, after )In SHOP2: Only before constraints for an entire method and orderingconstraints supportedAlternative: Add “markers” to check causal constraints later,even if parent task has been removed

Constraints involving removed tasks are not removed from CRemove concerned constraints, add updated ordering constraintsAlternative: Keep tasks in network as long as they are unfinished

Non-deterministic choice of tasks and methodsHeuristics needed!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 26/36

SHOP2 Planner

Which simplifications are assumed in Alg. 1?Check constraints of a method’s task network before its application

Problem with general constraints (especially between, after )In SHOP2: Only before constraints for an entire method and orderingconstraints supportedAlternative: Add “markers” to check causal constraints later,even if parent task has been removed

Constraints involving removed tasks are not removed from CRemove concerned constraints, add updated ordering constraintsAlternative: Keep tasks in network as long as they are unfinished

Non-deterministic choice of tasks and methodsHeuristics needed!

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 26/36

SHOP2 Planner: Remarks

Predecessor SHOP (Simple Hierarchical Ordered Planner)[NCLMA99] only for totally ordered subtasks

SHOP2 also features partial orders, axioms, numerical and temporalplanning, external procedure calls, . . .

Optional branch-and-bound optimization after finding initial solutionKeep searching for better plansIn general, no guarantees for optimal plans

SHOP and SHOP2 operate on lifted problem,instantiation and unification just as needed

Motivation for SHOP, SHOP2: Solving practical problemsfrom industry, other research domains [NAI+05]

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 27/36

SHOP2 Planner: Remarks

Predecessor SHOP (Simple Hierarchical Ordered Planner)[NCLMA99] only for totally ordered subtasks

SHOP2 also features partial orders, axioms, numerical and temporalplanning, external procedure calls, . . .Optional branch-and-bound optimization after finding initial solution

Keep searching for better plansIn general, no guarantees for optimal plans

SHOP and SHOP2 operate on lifted problem,instantiation and unification just as needed

Motivation for SHOP, SHOP2: Solving practical problemsfrom industry, other research domains [NAI+05]

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 27/36

SHOP2 Planner: Remarks

Predecessor SHOP (Simple Hierarchical Ordered Planner)[NCLMA99] only for totally ordered subtasks

SHOP2 also features partial orders, axioms, numerical and temporalplanning, external procedure calls, . . .Optional branch-and-bound optimization after finding initial solution

Keep searching for better plansIn general, no guarantees for optimal plans

SHOP and SHOP2 operate on lifted problem,instantiation and unification just as needed

Motivation for SHOP, SHOP2: Solving practical problemsfrom industry, other research domains [NAI+05]

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 27/36

SAT-based HTN Planning

Recent approaches to solve HTN planning problems with SAT:SMS: Stack Machine Simulation (totally ordered tasks) [SPFB19]

Encode a task stack of fixed size at each stepProcess tasks between stepsApply actions as in classical planningIncremental solving: increase encoding along number of steps

get_soil_data(w1)

bottom empty_store()

send_soil_data(w1)

sample_soil(w1)

bottom

push(4) move(w0,w1)

bottom

pop()

bottom

Execute action: Preconditions + effects

empty_store()

send_soil_data(w1)

sample_soil(w1)

move(w0,w1) empty_store()

send_soil_data(w1)

sample_soil(w1)

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 28/36

SAT-based HTN Planning

T-REX: Tree-like Reduction Exploration (total order) [Sch18]Encode problem’s hierarchy in a iterative deepening mannerIncrementally increase encoding along the hierarchy’s depth and thecorresponding maximum plan length, until satisfiabilityFeatures SAT-based plan length optimization

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 29/36

SAT-based HTN Planning

PANDA planner, e.g. [BHB19]Transform HTN problem into a sequence of STRIPS problemsGenerates a decomposition tree of growing depthAlso features partial orders

General remarks to SAT-based HTN planning:

Could easily incorporate general before / between / afterconstraints[citation needed]

Requires enumeration and encoding of all possible ground methodsHeuristic planners ideally just explore a very small subset of thatVolume of ground methods reduceable by exploiting incremental SAT?Is a SAT encoding of a lifted HTN problem possible?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 30/36

SAT-based HTN Planning

PANDA planner, e.g. [BHB19]Transform HTN problem into a sequence of STRIPS problemsGenerates a decomposition tree of growing depthAlso features partial orders

General remarks to SAT-based HTN planning:

Could easily incorporate general before / between / afterconstraints[citation needed]

Requires enumeration and encoding of all possible ground methodsHeuristic planners ideally just explore a very small subset of thatVolume of ground methods reduceable by exploiting incremental SAT?Is a SAT encoding of a lifted HTN problem possible?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 30/36

The Situation of HTN and PDDL

HTN planning with PDDL?

Methods commonly writtensimilar to operators

Initial task networkspecified in problem file

(:method (empty store ?s ?x)

(and (empty ?s))

(:ordered (drop ?x ?s)))

(:method (empty store ?s ?x)

(and (not (empty ?s)))

(:ordered ))

SHOP2 syntax

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 31/36

The Situation of HTN and PDDL

HTN planning with PDDL?

Methods commonly writtensimilar to operators

Initial task networkspecified in problem fileProblematic: Not standardized

Syntax varies among plannersHinders comparisons,evaluations / benchmarking

(:method (empty store ?s ?x)

(and (empty ?s))

(:ordered (drop ?x ?s)))

(:method (empty store ?s ?x)

(and (not (empty ?s)))

(:ordered ))

SHOP2 syntax

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 31/36

The Situation of HTN and PDDL

HTN planning with PDDL?

Methods commonly writtensimilar to operators

Initial task networkspecified in problem fileProblematic: Not standardized

Syntax varies among plannersHinders comparisons,evaluations / benchmarking

(:method empty store

:parameters (?s - store

?x - rover)

:expansion ((tag t1 (nop)))

:constraints (and (before

(empty ?s) t1)))

(:method empty store

:parameters (?s - store

?x - rover)

:expansion ((tag t1

(drop ?x ?s)))

:constraints (and (before

(not (empty ?s)) t1)))

PDDL4j syntax

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 31/36

The Situation of HTN and PDDL

HTN planning with PDDL?

Methods commonly writtensimilar to operators

Initial task networkspecified in problem fileProblematic: Not standardized

Syntax varies among plannersHinders comparisons,evaluations / benchmarking

(:task empty-store :parameters

(?s - store ?r - rover))

(:method m-empty-store-1

:parameters (?s - store

?r - rover)

:task (empty-store ?s ?r)

:precondition (empty ?s)

:subtasks ())

(:method m-empty-store-2

:parameters (?s - store

?r - rover)

:task (empty-store ?s ?r)

:precondition (not(empty ?s))

:subtasks (drop ?r ?s))

PANDA syntax

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 31/36

The Situation of HTN and PDDL

HTN planning with PDDL?

Methods commonly writtensimilar to operators

Initial task networkspecified in problem fileProblematic: Not standardized

Syntax varies among plannersHinders comparisons,evaluations / benchmarking

Good example for consequencesof missing standards(insert xkcd.com/927)

(:task empty-store :parameters

(?s - store ?r - rover))

(:method m-empty-store-1

:parameters (?s - store

?r - rover)

:task (empty-store ?s ?r)

:precondition (empty ?s)

:subtasks ())

(:method m-empty-store-2

:parameters (?s - store

?r - rover)

:task (empty-store ?s ?r)

:precondition (not(empty ?s))

:subtasks (drop ?r ?s))

PANDA syntax

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 31/36

Modeling HTN Domains: Some Notes

Find right balance of which method constraints to addState space HTN planners do not profit a lot from after constraintsMissing important method preconditions (before) can lead toterrible performanceSometimes, can propagate action preconditions up to method level

Total order of subtasks whenever it makes senseTakes away choices the planner would need to doAllowing interleaving of actions may just be a design decision

Make hierarchy as shallow as possibleEspecially for SAT-based planners: iterative deepening!Deep hierarchies imply many iterations

Branching factor of methods mattersHow many methods per task to pick from?What ratio of these methods actually leads to a plan?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 32/36

Modeling HTN Domains: Some Notes

Find right balance of which method constraints to addState space HTN planners do not profit a lot from after constraintsMissing important method preconditions (before) can lead toterrible performanceSometimes, can propagate action preconditions up to method level

Total order of subtasks whenever it makes senseTakes away choices the planner would need to doAllowing interleaving of actions may just be a design decision

Make hierarchy as shallow as possibleEspecially for SAT-based planners: iterative deepening!Deep hierarchies imply many iterations

Branching factor of methods mattersHow many methods per task to pick from?What ratio of these methods actually leads to a plan?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 32/36

Modeling HTN Domains: Some Notes

Find right balance of which method constraints to addState space HTN planners do not profit a lot from after constraintsMissing important method preconditions (before) can lead toterrible performanceSometimes, can propagate action preconditions up to method level

Total order of subtasks whenever it makes senseTakes away choices the planner would need to doAllowing interleaving of actions may just be a design decision

Make hierarchy as shallow as possibleEspecially for SAT-based planners: iterative deepening!Deep hierarchies imply many iterations

Branching factor of methods mattersHow many methods per task to pick from?What ratio of these methods actually leads to a plan?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 32/36

Modeling HTN Domains: Some Notes

Find right balance of which method constraints to addState space HTN planners do not profit a lot from after constraintsMissing important method preconditions (before) can lead toterrible performanceSometimes, can propagate action preconditions up to method level

Total order of subtasks whenever it makes senseTakes away choices the planner would need to doAllowing interleaving of actions may just be a design decision

Make hierarchy as shallow as possibleEspecially for SAT-based planners: iterative deepening!Deep hierarchies imply many iterations

Branching factor of methods mattersHow many methods per task to pick from?What ratio of these methods actually leads to a plan?

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 32/36

HTN Planning: Conclusion

Intuitive and powerful way of modeling planning domains

High quality domain-specific expert knowledge necessaryto get good performances

Commonly seen in industrial / real world applications

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 33/36

Stay tuned!

Next lecture: Plan improvement and parallel planning

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 34/36

References I

Gregor Behnke, Daniel Holler, and Susanne Biundo, Bringing order to chaos–acompact representation of partial order in SAT-based HTN planning.

Kutluhan Erol, James Hendler, and Dana S Nau, Htn planning: Complexity andexpressivity, AAAI, vol. 94, 1994, pp. 1123–1128.

Dana S Nau, Tsz-Chiu Au, Okhtay Ilghami, Ugur Kuter, J William Murdock, Dan Wu,and Fusun Yaman, Shop2: An htn planning system, Journal of artificial intelligenceresearch 20 (2003), 379–404.

Dana Nau, T-C Au, Okhtay Ilghami, Ugur Kuter, Dan Wu, Fusun Yaman, HectorMunoz-Avila, and J William Murdock, Applications of shop and shop2, IEEEIntelligent Systems 20 (2005), no. 2, 34–41.

Dana Nau, Yue Cao, Amnon Lotem, and Hector Munoz-Avila, Shop: Simplehierarchical ordered planner, Proceedings of the 16th international joint conferenceon Artificial intelligence-Volume 2, Morgan Kaufmann Publishers Inc., 1999,pp. 968–973.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 35/36

References II

Emil L Post, A variant of a recursively unsolvable problem, Bulletin of the AmericanMathematical Society 52 (1946), no. 4, 264–268.

Dominik Schreiber, Hierarchical task network planning using SAT techniques, Masterthesis, 2018.

Dominik Schreiber, Damien Pellier, Humbert Fiorino, and Tomas Balyo, Efficient SATencodings for hierarchical planning, To appear in: 11th Conference on Agents andArtificial Intelligence, 2019.

Tomas Balyo, Dominik Schreiber – Planning and Scheduling December 13, 2018 36/36