wv19 9 planning - ist.tugraz.at

Gerald Steinbauer

Institute for Software Technology

1

Expert Systems

Gerald Steinbauer

Institut für Softwaretechnologie

Inffeldgasse 16b/2

A-8010 Graz

Austria

Expert Systems- Planning -

Gerald Steinbauer


2

Expert Systems

Shakey, the Robot

developed 1966-1972

at Stanford Research Institute (SRI)

move boxes in an office environment

Nils Nilsson

used STRIPS

~300k word program

Gerald Steinbauer


3

Expert Systems

Motivation

• planning is …• a very old problem

• a very important problem

• related to scheduling

• part of research on AI since ever

• part of every intelligent system

• annual conferences on planning; e.g. ICAPS

• annual competitions for planning

Gerald Steinbauer


4

Expert Systems

Applications of Planning

• Classical Action Planning, e.g., Robots

• Renormalization of Diagnosis Problems

• Software Testing

• Repair and Reconfiguration

• Exploration

• Logistics

• … and many more

Gerald Steinbauer


5

Expert Systems

Example: Logistics

s1 = {attached(p1,loc1), in(c1,p1), in(c3,p1), top(c3,p1), on(c3,c1), on(c1,pallet),

attached(p2,loc1), in(c2,p2), top(c2,p2), on(c2,palet), belong(crane1,loc1),

empty(crane1), adjacent(loc1,loc2), adjacent(loc2,loc1), at(r1,loc2), occupied(loc2,

unloaded(r1)}

Gerald Steinbauer


6

Expert Systems

Running Example• rigid propositions

•

•

•

• dynamic propositions•

•

•

•

•

•

•

•

•

.. location.. robot.. pile.. crane.. container

Gerald Steinbauer


7

Expert Systems

Running Example - Operators•

• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑎𝑡(𝑟, 𝑙), 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)

• effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,𝑒𝑚𝑝𝑡𝑦 𝑘 , ¬𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑 𝑟

•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), 𝑒𝑚𝑝𝑡𝑦(𝑘),

𝑎𝑡(𝑟, 𝑙), 𝑙𝑜𝑎𝑑𝑒𝑑(𝑟, 𝑐)

• effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), ¬𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,¬𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)

•• pre: 𝑎𝑑𝑗𝑎𝑐𝑒𝑛𝑡 𝑙 , 𝑙 , 𝑎𝑡 𝑟, 𝑙 ,

¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙

• effect:𝑎𝑡 𝑟, 𝑙 , ¬𝑎𝑡 𝑟, 𝑙 ,¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙 , 𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙

•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔 𝑘, 𝑙 , 𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 ,

𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑡𝑜𝑝(𝑐, 𝑝), 𝑜𝑛(𝑐, 𝑑)

• effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔 𝑘, 𝑐 , ¬𝑒𝑚𝑝𝑡𝑦(𝑘), ¬𝑖𝑛 𝑐, 𝑝 , ¬𝑡𝑜𝑝(𝑐, 𝑝), ¬𝑜𝑛(𝑐, 𝑑), 𝑡𝑜𝑝(𝑑, 𝑝)

•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙),

𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 , ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑡𝑜𝑝(𝑑, 𝑝)

• effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑒𝑚𝑝𝑡𝑦(𝑘), 𝑖𝑛(𝑐, 𝑝), 𝑡𝑜𝑝(𝑐, 𝑝), 𝑜𝑛(𝑐, 𝑑), ¬𝑡𝑜𝑝(𝑑, 𝑝)

Gerald Steinbauer


8

Expert Systems

Example: Dinner-Date

initial situation: one has clean hands and there is garbage in the kitchen. it is quiet in the house.

desired situation: a dinner is cooked, there is no garbage in the kitchen and we have a present.

what can we do?cook a dinner,wrap a present,carry the garbage out ordolly the garbage out

Gerald Steinbauer


9

Expert Systems

Planning is Problem Solving

• Classical Planning Problem (I,G,A)• I … a description of the initial state• G S … a description of the goal (S … state space)• A … a description of actions (domain theory)

• Plan=Solution• sequence of actions that when executed satisfy in the initial

state and will achieve the goal

• Descriptions• usually given in a formal language: e.g., first order predicate

calculus, propositional logic, situation calculus, STRIPS, …

Gerald Steinbauer


10

Expert Systems

Restrictive Assumptions• A0: Finite system:

• finitely many states, actions, events

• A1: Fully observable:• the controller always knows Σ’s

current state

• A2: Deterministic:• each action has only one outcome

• A3: Static (no exogenous events):• no changes but the controller’s actions

• A4: Restricted goals: • a set of goal states 𝑆

• A5: Sequential plans:• a plan is a linearly ordered sequence of actions (𝑎 , 𝑎 , … , 𝑎 )

• A6: Implicit time:• no time durations; linear sequence of instantaneous states

• A7: Off-line planning: • planner doesn’t know the execution status

Gerald Steinbauer


11

Expert Systems

Transition System

• a transition system is a 5-tupel T=<S,L,T,s0,S*>• S a finite set of states

• L is a finite set of (transition) labels

• TSLS is transition relation

• s0S is the initial state

• S*S is the set of goal states

• T has a transition <s,l,s’> if <s,l,s’> T

Gerald Steinbauer


12

Expert Systems

Transition System

D A

BC

FE

goal states

initial states

db

b

e

ca

d

a fb

dd

Gerald Steinbauer


13

Expert Systems

Set-Theoretic Representation

• it relies on a finite set of proposition symbols

• let L={p1,p2,…,pn} a finite set of proposition symbols then a set-theoretic planning domain is a restricted transition system =(S,A,)• S2L, each state is a subset of L, if p s then p holds in the

world represented by s

• each action aA is a triple of subsets of L a=(pre(a),effects+(a),effects-(a)), effects+(a) and effects-(a) are disjoint, a is applicable if pre(a)S

• if sS the state produced by an action is also in S

• transition function (s,a)=(s-effects-(a))effects+(a)

Gerald Steinbauer


14

Expert Systems

Classical Representation

• let L be a first-order language with finite many predicate and constant symbols

• a classical planning domain is a restricted transition system =(S,A,)• S2{all ground atoms of L}

• A are all ground operators in O, O is the set of all operators defended as triple (name(o) with n(x1,...,xn), pre(o), effects(o)), x1,…,xn are variables in pre(o) and effects(o), pre(o) and effects(o) are set of literals, a is applicable if pre+(a) s and pre-(a) s =

• (s,a)= (s-effects-(a))effects+(a) if a is applicable in s

• if sS the state produced by an action is also in S

Gerald Steinbauer


15

Expert Systems

Relevant Actions and Regression

• set-theoretic representation• an action a is relevant for a goal g if geffects+(a) and

geffects-(a)=• -1(g,a)=(g-effects+(a))pre(a)

• classical representation• an action a is relevant for a goal g if geffects(a) and

g+effects-(a)= and g-effects+(a)=• -1(g,a)=(g-effects(a))pre(a)

• goal g can be a set of literals

Gerald Steinbauer


16

Expert Systems

Types of Planning

• State-Space Planning• search in the space of states

• states are connected by state transitions (i.e., actions )

• find a state which satisfied the goal

• solution: a path from the initial state to the goal state

Gerald Steinbauer


17

Expert Systems

Forward Search

the most simple algorithmForward-Search(D,I,g)

s I

the empty plan

loop

if s satisfies g return applicable {a|a is a ground action of D and

precond(a) is true in s}

if applicable=Ø then return failure

non-deterministically choose an action a applicable

s (s,a)

.a

there exist also deterministic implementation

Gerald Steinbauer


18

Expert Systems

Backward SearchBackward-Search(D,I,g)

the empty plan

loop

if I satisfies g return relevant {a|a is a ground action of D and a is relevant for g}

if relevant=Ø then return failure

non-deterministically choose an action a relevant

a.g -1(g,a)

backward search is in general more focused as it includes the goal into the search

Gerald Steinbauer


19

Expert Systems

Types of Planning

• Plan-Space Planning• search in the space of partially defined plans• plans are connected by refinement actions, i.e., achieve a

new sub-goal or remove inconsistencies• search starts with an empty plan node• search for a final node containing a solution plan • uses the “least commitment” philosophy• a partial plan comprises a set of actions plus some ordering

and grounding constraints

Gerald Steinbauer


20

Expert Systems

Plan-Space Planning

• each node of the search space is a partial plan• a set of partially-instantiated actions

• a set of constraints

• make more and more refinements, until we have a solution

• types of constraints• precedence constraint: a must precede b

• binding constraints: inequality constraints, e.g., v1 ≠ v2 or v ≠ c; equality constraints (e.g., v1 = v2 or v = c) and/or substitutions

• causal link: use action a to establish the precondition p needed by action b

Gerald Steinbauer


21

Expert Systems

Solution to Plan-Space Planning

• a partial plan is a solution for plan problem if• its ordering constraints and binding constraints are consistent

• every sequence totally ordered and totally instantiated actions of satisfying and defines a path of from to with with initial state as effects and with goal state as precondition

• this is not a practical condition

Gerald Steinbauer


22

Expert Systems

Threat

• an action in a plan is a threat on a causal link

iff

• has an effect that is possibly inconsistent with , i.e and are unifiable

• the ordering constraints and are consistent with

• the binding constraints for the unification of and consistent with

Gerald Steinbauer


23

Expert Systems

Flaw

• a flaw in a plan is either:• a subgoal, i.e. a precondition of an action in without a causal link

or

• a threat, i.e. an action that may interfere with a causal link

• a partial plan is a solution to the planning problem if has no flaws and if the set of ordering constraints and binding constraints are consistent

Gerald Steinbauer


24

Expert Systems

The PSP Procedure

• PSP is both sound and complete• it returns a partially ordered solution plan

• any total ordering of this plan will achieve the goals• or could execute actions in parallel if the environment permits it

Gerald Steinbauer


25

Expert Systems

The PSP Procedure continued

•• finds all open goals in

• preconditions not supported by a causal link

• efficiently implemented using an agenda, a list of open preconditions

•

• finds every action that is a threat to a causal link ( )

• naively test all triples of actions in ,

• better us an incremental processing:• new action 𝑎: test all causal links not involving 𝑎, 𝑂(𝑛 )

• new causal link: test all actions not involved, 𝑂(𝑛)

Gerald Steinbauer


26

Expert Systems


•• finds all ways to resolve a flaw

• if is a subgoal for precondition of action

• a causal link (𝑎 → 𝑎 ) if there is already an action 𝑎 in 𝜋 whose effect can provide 𝑝; add causal link, ordering constraint (𝑎 ≺ 𝑎 ) if consistent with ≺ and binding constraints to unify 𝑝 with the effect of 𝑎

• a new action 𝑎 that can provide 𝑝, add action 𝑎, causal link including ordering and binding constraints including (𝑎 ≺ 𝑎 ≺ 𝑎 )

• if is a threat on a causal link ( ) by an action that has an effect und is unifiable with

• the constraint (𝑎 ≺ 𝑎 ), if consistent with ≺, i.e. ordering a before the causal link

• the constraint (𝑎 ≺ 𝑎 ), if consistent with ≺, i.e. ordering a after the causal link

• a binding constraint with 𝐵 that makes 𝑝 and 𝑞 nonunifiable

Gerald Steinbauer


27

Expert Systems


•• refines the partial plan with the elements in the resolver

• adding to • an ordering constraint,

• one or several binding constraints,

• a causal link, and/or

• a new action

• it has to maintain the set of subgoals and threats

• it performs query and update operations on the sets and • ordering constraints, 𝑂(𝑛 )

• binding constraints, related to CSP, 𝑁𝑃 − 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒

Gerald Steinbauer


28

Expert Systems

Extension to Classical Planning

• some problems are hard to model with “simple” descriptions

• therefore some extensions have been introduced

• quantifiers in formulas

• types

• conditional effects

• disjunctive preconditions

• axiomatic inference

• functions

Gerald Steinbauer


29

Expert Systems

Planning Domain Definition Language

• PDDL is a planning language

• standard encoding language for “classical” planning tasks

• planning tasks specified in PDDL are separated into two files• domain file for predicates and actions

• problem file for objects, initial state and goal specification

• several ready-to-go standalone planners available (e.g., SGPLAN6, fast downward)

• comment: PDDL is not a “hard” standard

Gerald Steinbauer


30

Expert Systems

PDDL Basics

• The Planning Domain Definition Language (PDDL)• variants used by most implemented planning systems

• supports a formalism comparable to what we have outlined above (including schematic operators and quantification)

• syntax inspired by the Lisp programming language: e.g., prefix notation for formulas

(and (or (on A B) (on A C))

(or (on B A) (on B C))

(or (on C A) (on A B)))

• the planner input is separated into a domain file (predicates, types, action schemas) and a problem file (objects, initial state, goal).

Gerald Steinbauer


31

Expert Systems

PDDL Domain File

• A PDDL domain file consists of:• (define (domain <name>)

• a requirements definition

• definitions of types (each object variable has a type)

• definitions of predicates

• definitions of action schemas

Gerald Steinbauer


32

Expert Systems

Domain File Types and Predicates: Example Blocksworld

(define (domain Blocksworld)

(:requirements :strips :typing)

(:types block - object

blueblock smallblock - block)

(:predicates (on ?x - smallblock ?y - block)

(ontable ?x - block)

(clear ?x - block))

Gerald Steinbauer


33

Expert Systems

Action Schema: Example Blocksworld

(:action fromtable

:parameters (?x - smallblock ?y - block)

:precondition (and (not (= ?x ?y))

(clear ?x)

(ontable ?x)

(clear ?y))

:effect

(and (not (ontable ?x))

(not (clear ?y))

(on ?x ?y)))

Gerald Steinbauer


34

Expert Systems

PDDL Grammar: Action Schema I

(:action <name>

List of parameters:

(?x - type1 ?y - type2 ?z - type3)

the precondition is a formula:

<predicate>

(and <formula> ... <formula>)

(or <formula> ... <formula>)

(not <formula>)

(forall (?x1 - type1 ... ?xn - typen) <formula>)

(exists (?x1 - type1 ... ?xn - typen) <formula>)

Gerald Steinbauer


35

Expert Systems

PDDL Grammar: Action Schema II

the effect is a combination of literals, conjunction, conditional effects, and quantification over effects:

<predicate>

(not <predicate>)

(and <effect> ... <effect>)

(when <formula> <effect>)

(forall (?x1 - type1 ... ?xn - typen) <effect>)

Gerald Steinbauer


36

Expert Systems

PDDL Problem Files

• a PDDL problem file consists of:• (define (problem <name>)

• (:domain <name>)– to which domain does this problem belong?

• definitions of objects belonging to each type

• definition of the initial state (list of ground predicates initially true)

• definition of the goal (a formula like action preconditions).

Gerald Steinbauer


37

Expert Systems

Problem File: Example Blocksworld

(define (problem example)

(:domain Blocksworld)

(:objects a b c - smallblock

d e – block

f - blueblock)

(:init (clear a) (clear b) (clear c)

(clear d) (clear e) (clear f)

(ontable a) (ontable b) (ontable c)

(ontable d) (ontable e) (ontable f))

(:goal (and (on a d) (on b e) (on c f)))

)

Gerald Steinbauer


38

Expert Systems

Dinner-Date: Domain(define (domain dinner-date)

(:requires :strips)

(:predicates (garbage) (cleanHands) (quiet) (dinner) (present))

(:action cook

:precondition (cleanHands)

:effect (dinner)

)

(:action wrap

:precondition (quiet)

:effect (present)

)

(:action carry

:effect (and (not (garbage)) (not(cleanHands)))

)

(:action dolly

:effect (and (not (garbage)) (not(quiet)))

)

)

Gerald Steinbauer


39

Expert Systems

Dinner-Date: Problem(define (problem dinner-date)

(:domain dinner-date)

(:requires :strips :negative-preconditions)

(:init (garbage) (cleanHands) (quiet))

(:goal (and (dinner) (present) (not (garbage))))

)

Gerald Steinbauer


40

Expert Systems

Example

http://editor.planning.domains

Gerald Steinbauer


41

Expert Systems

Graphplan

• basic idea, alternate between two phases• graph expansion: extends Graphplan forward in time

• solution extraction: performs backward-chaining to look for a plan that solved the planning problem

• fast algorithm - outperforms (most) others

• basic for encoding planning problems as SAT problems

• Graphplan uses a planning graph

Gerald Steinbauer


42

Expert Systems

Planning Graph

• two types of nodes• proposition nodes

• action nodes

• nodes are arranged in levels• even-numbered levels contain proposition nodes

• odd-numbered levels contain action nodes

• the zero level stores nodes of propositions true in the initialstate

• edges connect proposition nodes of the level i with action nodes of level i+1 and actions from level i+1 to propositions of level i+2

Gerald Steinbauer


43

Expert Systems

Planning Graph• an action is element of a level i iff all propositions

occurring in the precondition are in level i-1.• an edge between a proposition p at level i and action a

at level i+1 exists iff p is a precondition of a.• a proposition p is in level i>1 iff there exists an action a

in level i-1 where p is in the effect set. in this case there exists an edge between a and p.

• we assume the existence of identity actions for each proposition (aka maintenance actions).

• an action level represents (possible) parallel actions

Gerald Steinbauer


44

Expert Systems

Planning Graph0 i-1 i i+1

actions

propositions

Gerald Steinbauer


45

Expert Systems

Mutex Relations

• actions at the same level may not be executed at once, e.g., carry and cook

• binary mutual exclusion (mutex) between nodes

• two actions at level i are mutex if either• the effect of one action is the negation of the other’s effect

[inconsistent effect]

• one action deletes the precondition of the other [interference]

• the actions have preconditions, that are mutex at level i-1[competing needs]

Gerald Steinbauer


46

Expert Systems

Mutex Relations

--

• two propositions at level i are mutex if• all ways of achieving the proposition (actions at level i-1) are

pairwise mutex [inconsistent support]

Gerald Steinbauer


47

Expert Systems

Inconsistent Effect

A

not A

Gerald Steinbauer


48

Expert Systems

Inference

A

not A

Gerald Steinbauer


49

Expert Systems

Competing Needs

A

not A

Gerald Steinbauer


50

Expert Systems

Inconsistent Support

--

Gerald Steinbauer


51

Expert Systems

Graph Expansion• assume we built up the graph to the proposition level

i.• create a new action level i+1. for every action a,

where all preconditions are satisfied, create a new node for a.

• create a new proposition level i+2. for every effect in action a occurring in level i+1 create a proposition node in i+1.

• compute the mutex relations.

Gerald Steinbauer


52

Expert Systems

Dinner Example Level 2garbage

not garbage

cleanHands

not cleanHands

quiet

not quiet

dinner

present

garbage

cleanHands

quiet

wrap

dolly

cook

carry

0 21

Gerald Steinbauer


53

Expert Systems

Solution Extraction1. assume Graphplan has extended the graph up to a

level i, in which all goal propositions are present [necessary condition].

2. for each of the sub-goals at level i do:a) choose an action a from level i-1 that achieves the sub-goal.b) if this action is consistent, i.e., not mutex, with the previously

chosen actions, then take the next sub-goal.c) otherwise, backtrack to a previous choice.

Gerald Steinbauer


54

Expert Systems

Solution Extraction

3. after Graphplan has found a consistent set of actions for level i-1, it recursively tries to find a plan for the action’s precondition on level i-2.

4. if the zero level is reached a plan has been extracted.

5. if backtracking fails on all combinations (of actions for each goal) then Graphplan extends the graph (as described previously) and tries solution extraction again.

Gerald Steinbauer


55

Expert Systems

Dinner Example Level 2All goal propositions are included → solution extraction1.select not garbage2. select carry3. select dinner4. select cook5. cook mutex carry backtracking to 46. no action backtracking to 27. select dolly8. select dinner9. select cook10. select present11. select wrap 12. wrap mutex dolly backtracking to 1013. no action backtracking to 914. no action backtracking to 715. no action finish with no plan

Gerald Steinbauer


56

Expert Systems


not garbage

cleanHands

not cleanH.

quiet

not quiet

dinner

present

garbage

cleanHands

quiet

wrap

dolly

cook

carry

0 21

wrap

dolly

cook

carry

43

Gerald Steinbauer


57

Expert Systems


not garbage

cleanHands

not cleanH.

quiet

not quiet

dinner

present

garbage

cleanHands

quiet

wrap

dolly

cook

carry

0 21

wrap

dolly

cook

carry

43

quiet

dinner

possible plan:cook, wrap, carry

Gerald Steinbauer


58

Expert Systems

Some Observations

• from one level to another …

• propositions monotonically increase• actions have new effects

• always carried forward by no-ops

• actions monotonically increase• more preconditions are satisfied

• propositional mutex relations monotonically decrease• new paths for propositions emerge

• action mutex relations monotonically decrease• new ways to achieve the precondition emerge

Gerald Steinbauer


59

Expert Systems

Level Off

• plan graph levels off

• after some some levels k all levels are identical

• because of it’s finite state

• and the set of propositions never decrease

• and mutex do not reappear

Gerald Steinbauer


60

Expert Systems

Bibliography

• Daniel S. Weld. Recent advances in AI Planning. AI Magazine, pp 93-123, Summer 1999.

• Richard Fikes and Nils Nilsson. STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving. Artificial Intelligence, 2(3-4): 189-208, 1971.

• Avrim L. Blum and Merrick L. Furst. Fast Planning Through Planning Graph Analysis. Artificial Intelligence 90(1-2). 1995.

• Malik Ghallab, Dana Nau and Paolo Traverso. Automated Planning – Theory and Practice. Morgan Kaufman. 2005.

• @article{fox2003pddl2,

• Fox, Maria and Long, Derek. PDDL2. 1: An Extension to PDDL for Expressing Temporal Planning Domains. J. Artif. Intell. Res. (JAIR), 2003(20).

Gerald Steinbauer


61

Expert Systems--

Thank You!

wv19 9 planning - ist.tugraz.at

Documents