GraphPlan Alan Fern * * Based in part on slides by Daniel Weld and José Luis Ambite.

Slides:



Advertisements
Similar presentations
Informed search algorithms
Advertisements

Constraint Based Reasoning over Mutex Relations in Graphplan Algorithm Pavel Surynek Charles University, Prague Czech Republic.
CLASSICAL PLANNING What is planning ?  Planning is an AI approach to control  It is deliberation about actions  Key ideas  We have a model of the.
Dana Nau: Lecture slides for Automated Planning Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License:
Finding Search Heuristics Henry Kautz. if State[node] is not in closed OR g[node] < g[LookUp(State[node],closed)] then A* Graph Search for Any Admissible.
1 Graphplan José Luis Ambite * [* based in part on slides by Jim Blythe and Dan Weld]
Planning with Constraints Graphplan & SATplan Yongmei Shi.
Action Cook Prec: CleanHands Effects: Dinner Action Wrap Prec: Quiet Effects: Present Action Carry Prec: Effects: ~Garbage AND ~CleanHands Action Dolly.
Graph-based Planning Brian C. Williams Sept. 25 th & 30 th, J/6.834J.
1 Heuristic Search Chapter 4. 2 Outline Heuristic function Greedy Best-first search Admissible heuristic and A* Properties of A* Algorithm IDA*
Planning Graphs * Based on slides by Alan Fern, Berthe Choueiry and Sungwook Yoon.
For Monday Finish chapter 12 Homework: –Chapter 13, exercises 8 and 15.
AI – Week 5 Implementing your own AI Planner in Prolog – part II : HEURISTICS Lee McCluskey, room 2/09
Planning CSE 473 Chapters 10.3 and 11. © D. Weld, D. Fox 2 Planning Given a logical description of the initial situation, a logical description of the.
1 Classical STRIPS Planning Alan Fern * * Based in part on slides by Daniel Weld.
AI – Week AI Planning – Plan Generation Algorithms: GraphPlan Lee McCluskey, room 2/09
CPSC 322, Lecture 18Slide 1 Planning: Heuristics and CSP Planning Computer Science cpsc322, Lecture 18 (Textbook Chpt 8) February, 12, 2010.
OnT-A onT-B onT-C cl-A cl-C cl-B he Pick-A Pick-B Pick-C onT-A onT-B onT-C cl-A cl-C cl-B he h-A h-B h-C ~cl-A ~cl-B ~cl-C ~he st-A-B st-A-C st-B-A st-B-C.
Planning: Part 3 Planning Graphs COMP151 April 4, 2007.
CSE 5731 Lecture 21 State-Space Search vs. Constraint- Based Planning CSE 573 Artificial Intelligence I Henry Kautz Fall 2001.
Constraint Satisfaction Problems
Planning II CSE 473. © Daniel S. Weld 2 Logistics Tournament! PS3 – later today Non programming exercises Programming component: (mini project) SPAM detection.
1 Planning Chapters 11 and 12 Thanks: Professor Dan Weld, University of Washington.
Planning II CSE 573. © Daniel S. Weld 2 Logistics Reading for Wed Ch 18 thru 18.3 Office Hours No Office Hour Today.
Informed Search Idea: be smart about what paths to try.
An Introduction to Artificial Intelligence CE Chapter 11 – Planning Ramin Halavati In which we see how an agent can take.
Classical Planning Chapter 10.
For Wednesday Read chapter 12, sections 3-5 Program 2 progress due.
Dana Nau: Lecture slides for Automated Planning Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License:
Dana Nau: Lecture slides for Automated Planning Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License:
Homework 1 ( Written Portion )  Max : 75  Min : 38  Avg : 57.6  Median : 58 (77%)
Dana Nau: Lecture slides for Automated Planning Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License:
1 Planning as Satisfiability Alan Fern * * Based in part on slides by Stuart Russell and Dana Nau  Review of propositional logic (see chapter 7)  Planning.
P ROBLEM Write an algorithm that calculates the most efficient route between two points as quickly as possible.
Midterm Review Prateek Tandon, John Dickerson. Basic Uninformed Search (Summary) b = branching factor d = depth of shallowest goal state m = depth of.
For Monday Read chapter 12, sections 1-2 Homework: –Chapter 10, exercise 3.
Review: Tree search Initialize the frontier using the starting state While the frontier is not empty – Choose a frontier node to expand according to search.
Automated Planning Dr. Héctor Muñoz-Avila. What is Planning? Classical Definition Domain Independent: symbolic descriptions of the problems and the domain.
Introduction to Planning Dr. Shazzad Hosain Department of EECS North South Universtiy
AI Lecture 17 Planning Noémie Elhadad (substituting for Prof. McKeown)
Best-first search Idea: use an evaluation function f(n) for each node –estimate of "desirability"  Expand most desirable unexpanded node Implementation:
Intro to Planning Or, how to represent the planning problem in logic.
Classical Planning Chapter 10 Mausam / Andrey Kolobov (Based on slides of Dan Weld, Marie desJardins)
Graphplan.
© Daniel S. Weld 1 Logistics Travel Wed class led by Mausam Week’s reading R&N ch17 Project meetings.
Graphplan: Fast Planning through Planning Graph Analysis Avrim Blum Merrick Furst Carnegie Mellon University.
Automated Planning and Decision Making Prof. Ronen Brafman Automated Planning and Decision Making Graphplan Based on slides by: Ambite, Blyth and.
Graphplan CSE 574 April 4, 2003 Dan Weld. Schedule BASICS Intro Graphplan SATplan State-space Refinement SPEEDUP EBL & DDB Heuristic Gen TEMPORAL Partial-O.
1 GraphPlan, Satplan and Markov Decision Processes Sungwook Yoon* * Based in part on slides by Alan Fern.
By J. Hoffmann and B. Nebel
Dana Nau: Lecture slides for Automated Planning Licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License:
Heuristic Search Planners. 2 USC INFORMATION SCIENCES INSTITUTE Planning as heuristic search Use standard search techniques, e.g. A*, best-first, hill-climbing.
Chapter 3.5 Heuristic Search. Learning Objectives Heuristic search strategies –Best-first search –A* algorithm Heuristic functions.
1 Chapter 6 Planning-Graph Techniques. 2 Motivation A big source of inefficiency in search algorithms is the branching factor  the number of children.
An Introduction to Artificial Intelligence CE 40417
Planning as Satisfiability
Introduction Contents Sungwook Yoon, Postdoctoral Research Associate
Class #17 – Thursday, October 27
Planning José Luis Ambite.
Graph-based Planning Slides based on material from: Prof. Maria Fox
Graphplan/ SATPlan Chapter
Planning Problems On(C, A)‏ On(A, Table)‏ On(B, Table)‏ Clear(C)‏
Class #19 – Monday, November 3
Chapter 6 Planning-Graph Techniques
Graphplan/ SATPlan Chapter
Graphplan/ SATPlan Chapter
GraphPlan Jim Blythe.
An Introduction to Planning Graph
Graph-based Planning Slides based on material from: Prof. Maria Fox
[* based in part on slides by Jim Blythe and Dan Weld]
Presentation transcript:

GraphPlan Alan Fern * * Based in part on slides by Daniel Weld and José Luis Ambite

GraphPlan http://www.cs.cmu.edu/~avrim/graphplan.html Many planning systems use ideas from Graphplan: IPP, STAN, SGP, Blackbox, Medic, FF, FastDownward History Before GraphPlan appeared in 1995, most planning researchers were working under the framework of “plan-space search” (we will not cover this topic) GraphPlan outperformed those prior planners by orders of magnitude GraphPlan started researchers thinking about fundamentally different frameworks Recent planning algorithms are much more effective than GraphPlan However, many have been influenced by GraphPlan

Big Picture A big source of inefficiency in search algorithms is the large branching factor GraphPlan reduces the branching factor by searching in a special data structure Phase 1 – Create a Planning Graph built from initial state contains actions and propositions that are possibly reachable from initial state does not include unreachable actions or propositions Phase 2 - Solution Extraction Backward search for the solution in the planning graph backward from goal

Layered Plans Graphplan searches for layered plans (often called parallel plans) A layered plan is a sequence of sets of actions actions in the same set must be compatible a1 and a2 are compatible iff a1 does not delete preconditions or positive effects of a2 (and vice versa) all sequential orderings of compatible actions gives same result ? A C B D B D A C Layered Plan: (a two layer plan) move(A,B,TABLE) move(C,D,TABLE) ; move(B,TABLE,A) move(D,TABLE,C)

Executing a Layered Plans A set of actions is applicable in a state if all the actions are applicable. Executing an applicable set of actions yields a new state that results from executing each individual action (order does not matter) A C B D move(A,B,TABLE) move(C,D,TABLE) B B move(B,TABLE,A) move(D,TABLE,C) D D A C A C

Planning Graph A literal is just a positive or negative propositon A planning graph has a sequence of levels that correspond to time-steps in the plan: Each level contains a set of literals and a set of actions Literals are those that could possibly be true at the time step Actions are those that their preconditions could be satisfied at the time step. Idea: construct superset of literals that could be possibly achieved after an n-level layered plan Gives a compact (but approximate) representation of states that are reachable by n level plans

Planning Graph … s0 sn an Sn+1 propositions actions state-level 0: propositions true in s0 state-level n: literals that may possibly be true after some n level plan action-level n: actions that may possibly be applicable after some n level plan … s0 sn an Sn+1 propositions actions

Planning Graph … maintenance action (persistence actions) propositions represents what happens if no action affects the literal include action with precondition c and effect c, for each literal c … propositions actions

Graph expansion Initial proposition layer Action layer n Just the propositions in the initial state Action layer n If all of an action’s preconditions are in proposition layer n, then add action to layer n Proposition layer n+1 For each action at layer n (including persistence actions) Add all its effects (both positive and negative) at layer n+1 (Also allow propositions at layer n to persist to n+1) Propagate mutex information (we’ll talk about this in a moment)

Example stack(A,B) precondition: holding(A), clear(B) effect: ~holding(A), ~clear(B), on(A,B), clear(B), handempty s0 a0 s1 holding(A) holding(A) ~holding(A) handempty stack(A,B) ~clear(B) on(A,B) clear(B) clear(B)

Example stack(A,B) precondition: holding(A), clear(B) effect: ~holding(A), ~clear(B), on(A,B), clear(B), handempty s0 a0 s1 holding(A) holding(A) ~holding(A) handempty stack(A,B) ~clear(B) on(A,B) clear(B) clear(B) Notice that not all literals in s1 can be made true simultaneously after 1 level: e.g. holding(A), ~holding(A) and on(A,B), clear(B)

Mutual Exclusion (Mutex) Mutex between pairs of actions at layer n means no valid plan could contain both actions at layer n E.g., stack(a,b), unstack(a,b) Mutex between pairs of literals at layer n means no valid plan could produce both at layer n E.g., clear(a), ~clear(a) on(a,b), clear(b) GraphPlan checks pairs only mutex relationships can help rule out possibilities during search in phase 2 of Graphplan

Action Mutex: condition 1 Inconsistent effects an effect of one negates an effect of the other E.g., stack(a,b) & unstack(a,b) add handempty delete handempty (add ~handempty)

Action Mutex: condition 2 Interference : one deletes a precondition of the other E.g., stack(a,b) & putdown(a) deletes holdindg(a) needs holding(a)

Action Mutex: condition 3 Competing needs: they have mutually exclusive preconditions Their preconditions can’t be true at the same time

Literal Mutex: two conditions Inconsistent support : one is the negation of the other E.g., handempty and ~handempty or all ways of achieving them via actions are are pairwise mutex

Example – Dinner Date Suppose you want to prepare dinner as a surprise for your sweetheart (who is asleep) Initial State: {cleanHands, quiet, garbage} Goal: {dinner, present, ~garbage} Action Preconditions Effects cook cleanHands dinner wrap quiet present carry none ~garbage, ~cleanHands dolly none ~garbage, ~quiet Also have the “maintenance actions”

Example – Plan Graph Construction garbage cleanhands quiet carry dolly cook wrap Add the actions that can be executed in initial state

Example - continued s0 s1 a0 carry dolly cook wrap garbage cleanhands quiet garbage ~garbage cleanhands ~cleanhands quiet ~quiet dinner present carry dolly cook wrap Add the literals that can be achieved in first step

Example - continued s0 a0 s1 carry dolly cook wrap garbage ~garbage cleanhands ~cleanhands quiet ~quiet dinner present carry dolly cook wrap Carry, dolly is mutex with maintenance actions (inconsistent effects) ~quiet is mutex with present, ~cleanhands is mutex with dinner inconsistent support dolly is mutex with wrap Interference (about quiet) Cook is mutex with carry about cleanhands

Do we have a solution? carry dolly cook wrap The goal is: {dinner, present,~garbage} All are possible in layer s1 None are mutex with each other garbage ~garbage cleanhands ~cleanhands quiet ~quiet dinner present carry dolly cook wrap There is a chance that a plan exists Now try to find it – solution extraction

Solution Extraction: Backward Search Repeat until goal set is empty If goals are present & non-mutex: 1) Choose set of non-mutex actions to achieve each goal 2) Add preconditions to next goal set

Searching for a solution plan Backward chain on the planning graph Achieve goals level by level At level k, pick a subset of non-mutex actions to achieve current goals. Their preconditions become the goals for k-1 level. Build goal subset by picking each goal and choosing an action to add. Use one already selected if possible (backtrack if can’t pick non-mutex action) If we reach the initial proposition level and the current goals are in that level (i.e. they are true in the initial state) then we have found a successful layered plan

Possible Solutions Two possible sets of actions for the goals at layer s1: {wrap, cook, dolly} and {wrap, cook, carry} Neither set works -- both sets contain actions that are mutex garbage ~garbage cleanhands ~cleanhands quiet ~quiet dinner present carry dolly cook wrap

Add new layer… Adding a layer provided new ways to achieve propositions This may allow goals to be achieved with non-mutex actions

Do we have a solution? Several action sets look OK at layer 2 Here’s one of them We now need to satisfy their preconditions

Do we have a solution? The action set {cook, quite} at layer 1 supports preconditions Their preconditions are satisfied in initial state So we have found a solution: {cook} ; {carry, wrap}

Another solution: {cook,wrap} ; {carry}

GraphPlan algorithm Grow the planning graph (PG) to a level n such that all goals are reachable and not mutex necessary but insufficient condition for the existence of an n level plan that achieves the goals if PG levels off before non-mutex goals are achieved then fail Search the PG for a valid plan If none found, add a level to the PG and try again If the PG levels off and still no valid plan found, then return failure Termination is guaranteed by PG properties This termination condition does not guarantee completeness. Why? A more complex termination condition exists that does, but we won’t cover in class (see book material on termination)

Propositions monotonically increase (always carried forward by no-ops) Propery 1 p ¬q ¬r p q ¬q ¬r p q ¬q r ¬r p q ¬q r ¬r A A A B B Propositions monotonically increase (always carried forward by no-ops)

Property 2 Actions monotonically increase p ¬q ¬r p q ¬q ¬r p q ¬q r B B Actions monotonically increase

Properties 3 Proposition mutex relationships monotonically decrease q r … p q r … p q r … A Proposition mutex relationships monotonically decrease Specifically, if p and q are in layer n and are not mutex then they will not be mutex in future layers.

Properties 4 Action mutex relationships monotonically decrease A A A p q … p q r s … p q r s … p q r s … B B B C C C Action mutex relationships monotonically decrease

Properties 5 Planning Graph ‘levels off’. After some time k all levels are identical In terms of propositions, actions, mutexes This is because there are a finite number of propositions and actions, the set of literals never decreases and mutexes don’t reappear.

Important Ideas Plan graph construction is polynomial time Though construction can be expensive when there are many “objects” and hence many propositions The plan graph captures important properties of the planning problem Necessarily unreachable literals and actions Possibly reachable literals and actions Mutually exclusive literals and actions Significantly prunes search space compared to previously considered planners Plan graphs can also be used for deriving admissible (and good non-admissible) heuristics

Planning Graphs for Heuristic Search After GraphPlan was introduced, researchers found other uses for planning graphs. One use was to compute heuristic functions for guiding a search from the initial state to goal Sect. 10.3.1 of book discusses some approaches First lets review the basic idea behind heuristic search

Planning as heuristic search Use standard search techniques, e.g. A*, best-first, hill-climbing etc. Find a path from the initial state to a goal Performance depends very much on the quality of the “heuristic” state evaluator Attempt to extract heuristic state evaluator automatically from the Strips encoding of the domain The planning graph has inspired a number of such heuristics

Review: Heuristic Search A* search is a best-first search using node evaluation f(s) = g(s) + h(s) where g(s) = accumulated cost/number of actions h(s) = estimate of future cost/distance to goal h(s) is admissible if it does not overestimate the cost to goal For admissible h(s), A* returns optimal solutions

Simple Planning Graph Heuristics Given a state s, we want to compute a heuristic h(s). Approach 1: Build planning graph from s until all goal facts are present w/o mutexes between them Return the # of graph levels as h(s) Admissible. Why? Can sometimes grossly underestimate distance to goal Approach 2: Repeat above but for a “sequential planning graph” where only one action is allowed to be taken at any time Implement by including mutexes between all actions Still admissible, but more accurate.

Relaxed Plan Heuristics Computing those heuristics requires “only” polynomial time, but must be done many times during search (think millions) Mutex computation is quite expensive and adds up Limits how many states can be searched A very popular approach is to ignore mutexes Compute heuristics based on relaxed problem by assuming no delete effects Much more efficient computaiton This is the idea behind the very well-known planner FF (for FastForward) Many state-of-the-art planners derive from FF

Heuristic from Relaxed Problem Relaxed problem ignores delete lists on actions The length of optimal solution for the relaxed problem is admissible heuristic for original problem. Why? PutDown(A,B): PRE: { holding(A), clear(B) } ADD: { on(A,B), handEmpty, clear(A)} DEL: { holding(A), clear(B) } PutDown(B,A): PRE: { holding(B), clear(A) } ADD: { on(B,A), handEmpty, clear(B) } DEL: { holding(B), clear(A) } Problem Relaxation PutDown(A,B): PRE: { holding(A), clear(B) } ADD: { on(A,B), handEmpty, clear(A)} DEL: { } PutDown(B,A): PRE: { holding(B), clear(A) } ADD: { on(B,A), handEmpty, clear(B) } DEL: { }

Heuristic from Relaxed Problem BUT – still finding optimal solution to relaxed problem is NP-hard So we will approximate it …. and do so very quickly One way is to explicitly search for a relaxed plan Finding a relaxed plan can be done in polynomial time using a planning graph Take relaxed-plan length to be the heuristic value FF (for FastForward) uses this approach

FF Planner: finding relaxed plans Consider running Graphplan while ignoring the delete lists No mutexes (avoid computing these altogether) Implies no backtracking during solution extraction search! So we can find a relaxed solutions efficiently After running the “no-delete-list Graphplan” then the # of actions in layered plan is the heuristic value Different choices in solution extraction can lead to different heuristic values The planner FastForward (FF) uses this heuristic in forward state-space best-first search Also includes several improvements over this

Example: Finding Relaxed Plans Relaxed plan graph (no mutexes) The value returned depends on particular choices made in the backward extraction Heuristic value = 3 Heuristic value = 4

Summary Many of the state-of-the-art planners today are based on heuristic search Popularized by the planner FF, which computes relaxed plans with blazing speed Lots of work on make heuristics more accurate without increasing the computation time too much Trade-off between heuristic computation time vs. heuristic accuracy Most of these planners are not optimal The most effective optimal planners tend to use different frameworks (e.g. planning as satisfiability)

Endgame Logistics Final Project Presentations Final Project Reports Tuesday, March 19, 3-5, KEC2057 Powerpoint suggested (email to me before class) Can use your own laptop if necessary (e.g. demo) 10 minutes of presentation per project Not including questions Final Project Reports Due: Friday, March 22, 12 noon