wv19 9 planning - ist.tugraz.at
Transcript of 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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
6
Expert Systems
Running Example• rigid propositions
•
•
•
• dynamic propositions•
•
•
•
•
•
•
•
•
.. location.. robot.. pile.. crane.. container
Gerald Steinbauer
Institute for Software Technology
7
Expert Systems
Running Example - Operators•
• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑎𝑡(𝑟, 𝑙), 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)
• effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,𝑒𝑚𝑝𝑡𝑦 𝑘 , ¬𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑 𝑟
•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙), 𝑒𝑚𝑝𝑡𝑦(𝑘),
𝑎𝑡(𝑟, 𝑙), 𝑙𝑜𝑎𝑑𝑒𝑑(𝑟, 𝑐)
• effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), ¬𝑙𝑜𝑎𝑑𝑒𝑑 𝑟, 𝑐 ,¬𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑢𝑛𝑙𝑜𝑎𝑑𝑒𝑑(𝑟)
•• pre: 𝑎𝑑𝑗𝑎𝑐𝑒𝑛𝑡 𝑙 , 𝑙 , 𝑎𝑡 𝑟, 𝑙 ,
¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙
• effect:𝑎𝑡 𝑟, 𝑙 , ¬𝑎𝑡 𝑟, 𝑙 ,¬𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙 , 𝑜𝑐𝑐𝑢𝑝𝑖𝑒𝑑 𝑙
•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔 𝑘, 𝑙 , 𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 ,
𝑒𝑚𝑝𝑡𝑦 𝑘 , 𝑡𝑜𝑝(𝑐, 𝑝), 𝑜𝑛(𝑐, 𝑑)
• effect: ℎ𝑜𝑙𝑑𝑖𝑛𝑔 𝑘, 𝑐 , ¬𝑒𝑚𝑝𝑡𝑦(𝑘), ¬𝑖𝑛 𝑐, 𝑝 , ¬𝑡𝑜𝑝(𝑐, 𝑝), ¬𝑜𝑛(𝑐, 𝑑), 𝑡𝑜𝑝(𝑑, 𝑝)
•• pre: 𝑏𝑒𝑙𝑜𝑛𝑔(𝑘, 𝑙),
𝑎𝑡𝑡𝑎𝑐ℎ𝑒𝑑 𝑝, 𝑙 , ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑡𝑜𝑝(𝑑, 𝑝)
• effect: ¬ℎ𝑜𝑙𝑑𝑖𝑛𝑔(𝑘, 𝑐), 𝑒𝑚𝑝𝑡𝑦(𝑘), 𝑖𝑛(𝑐, 𝑝), 𝑡𝑜𝑝(𝑐, 𝑝), 𝑜𝑛(𝑐, 𝑑), ¬𝑡𝑜𝑝(𝑑, 𝑝)
Gerald Steinbauer
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
12
Expert Systems
Transition System
D A
BC
FE
goal states
initial states
db
b
e
ca
d
a fb
dd
Gerald Steinbauer
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
26
Expert Systems
The PSP Procedure continued
•• 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
Institute for Software Technology
27
Expert Systems
The PSP Procedure continued
•• 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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
40
Expert Systems
Example
http://editor.planning.domains
Gerald Steinbauer
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
44
Expert Systems
Planning Graph0 i-1 i i+1
actions
propositions
Gerald Steinbauer
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
47
Expert Systems
Inconsistent Effect
A
not A
Gerald Steinbauer
Institute for Software Technology
48
Expert Systems
Inference
A
not A
Gerald Steinbauer
Institute for Software Technology
49
Expert Systems
Competing Needs
A
not A
Gerald Steinbauer
Institute for Software Technology
50
Expert Systems
Inconsistent Support
--
Gerald Steinbauer
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
56
Expert Systems
Dinner Example Level 2garbage
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
Institute for Software Technology
57
Expert Systems
Dinner Example Level 2garbage
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
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
Institute for Software Technology
61
Expert Systems--
Thank You!