Lecture 6: Graphplan

# Artificial Intelligence: Planning

### Graphplan

---

# Project: Task 1

---

# Task 1

* I sent out the scores yesterday

* While many of you did really well, there were some reoccuring problems

* Let me talk about them a bit

---

# Class Hierarchy

The idea was to have **one class for each logical operator**

```
class And(Expression):
    def __init__(self, args):
        self.args = tuple(args)
    
    def isModeledBy(self, world):
        return all(map(lambda a: a.isModeledBy(world), self.args))
    
    def substitute(self, var, value):
        return And(map(lambda x: x.substitute(var,value), self.args))
    
    def get_change(self, world):
        delset = set()
        addset = set()
        for arg in self.args:
            d,a = arg.get_change(world)
            delset = delset.union(d)
            addset = addset.union(a)
        return (delset,addset)
```

---

# Atoms

```
class Atom(Expression):
    def __init__(self, name, args):
        self.name = name 
        self.args = tuple(args)
        
    def isModeledBy(self, world):
        return self in world.atoms
        
    def __eq__(self, other):
        return self.name == other.name and self.args == other.args
        
    def substitute(self, var, value):
        return Atom(self.name, 
            map(lambda x: value if x == var else x, self.args))
            
    def get_change(self, world):
        return (set(self), set())

```

---

# Make an Expression

```
def make_expression(ast):
    op = ast[0]
    if op == "and":
        return And(map(make_expression, ast[1:]))
        
    elif op == "or":
        return Or(map(make_expression, ast[1:]))
        
    elif op == "imply":
        return Imply(make_expression(ast[1]), 
                     make_expression(ast[2]))
    ...
    else:
        return Atom(ast[0], ast[1:])
```

---

# Pitfalls

* Effect expressions are conjunctions of positive and negative literals, when expressions and **forall** expressions

* A `forall` in `apply` needs to replace its child with all possible substitutions of the variable

* Substitute has to work for any arbitrary string variable and all formulas

* Please put your code in the **root folder** of the zip file!

---

# Graphplan

---

# Review: The Planning Problem

A planning problem consists of three parts:

* A definition of the current state of the world
  
  * A definition of a desired state of the world
  
  * A definition of the actions the agent can take

---

# Review: State-Space Planning

We defined a graph called the "state space":

* Each state is a logical state

* Each edge corresponds to an action

* In any state, we can take any action whose preconditions are satisfied to generate a new state

Using this definition, we can use A* on the state space graph to find a plan.

---

# Review: FastForward Heuristic

* Start with a "layer" consisting of the set of all atoms in the current state

* Apply *all* applicable relaxed actions, and add all their effects to the set of atoms generating the next layer

* Continue until all atoms in the goal can be found in a layer

* Then *backtrack* through the layers to build a relaxed plan

* The length of this plan is the value of the heuristic

---

# FastForward Heuristic

* How did you do on the homework problem?

* My description of FastForward was based on intuition rather than the full formal specification

* Since heuristic values are generally not accurate, it's fine if you came up with "some" value

* The heuristic is actually based on Graphplan, which we are going to look at in detail today

---

# Planning Graphs

---

# Planning Graphs: Motivation

* In many planning problems, the order of certain actions does not matter

* If two actions don't affect one another, they could even be executed in parallel

* Rather than looking at the planning problem as a sequence of actions, we will look at it as a sequence of time steps

* We will build a graphical representation of time from left to right

---

# Planning Graphs

* A planning graph consists of layers

* Layers alternate between literals and actions

* The first layer consists of all literals that form the initial state

* Note: **literals** (positive **and** negative), not atoms

* The second layer consists of all actions that can be applied using literals in the first layer

* The third layer consists of all effects of these actions, etc.

---

# No-Ops

* If we do exactly what I wrote on the previous slide, we will "lose" literals

* In state-space planning we assumed if an action didn't change something, that it would stay the same

* Let's add this assumption to our plan graph!

* Add one "action" for each literal that has that literal as its precondition and effect ("maintainance action")

---

# Planning Graph

---

# Planning Graph

* We construct this graph level by level

* In order to do actual planning with it, we need to do some more processing, though

* What does a planning graph "mean"?

---

# Mutexes

---

# Mutexes

* A planning graph of depth `k` consists of k timesteps

* Within each time step, there are many actions

* But just because two actions are within the same timestep does not necessarily mean that they can be executed in parallel

* We need to determine which actions are **mutually exclusive** ("mutex")

---

# Inconsistent Effects

One action's effect is the negation of the effect of another action

---

# Interference

One action's effect is the negation of the precondition of another action

---

# Competing Needs

One action's precondition is the negation of the precondition of another action

---

# Inconsistent Support

Any way to achieve two literals is mutually exclusive

Also: If a literal is the negation of another, they are mutually exclusive.

---

# Planning

* So, now we can generate a graph of depth k, and determine which actions and literals are mutex

* We want to use this graph for planning?

* How do we choose k?

* And how do we get a plan out of this mess?

---

# Graphplan

---

# Graphplan

* Graphplan constructs a planning graph one level at a time

* After generating a level, we check if the goal is present in the layer **and** not mutex

* Then we try to "extract" a solution

* If we can't extract a solution, we generate another layer

* If we run out of new layers to generate, the problem can't be solved

---

# Solution Extraction

* Once we have a layer in which all goal literals are present (and not mutex), we can try to extract a solution

* Pick a set of actions from the preceeding layer that achieves the goal

* Use the preconditions of these actions as the new goal and search backwards

* If any goal ever becomes mutex, backtrack and choose a new set of actions (if there is one)

---

# Properties

* Graphplan is sound and complete

* If there is no solution, Graphplan will terminate with "no solution"

* The planning graph is potentially huge, but in typical problems actions can often be executed "in parallel", requiring fewer layers

* Backtracking may require extra time

---

# Planning Graph Properties

* Because we maintain all literals, the number of literals in each new layer never decreases

* Likewise, the number of actions from one layer to the next never decreases

* Because of maintainance actions, the number of mutexes will decrease over time

* At some point, the planning graph will "level off", i.e. not change anymore

---

# Another Observation: Relaxed Graphplan

* When we don't have any negative preconditions and effects, we can ignore negative literals

* That means we won't have any mutexes

* The planning graph will grow over time

* That's exactly what the FastForward heuristic did

---

# Example

---

# Example: Dinner Date

---

# Example: Planning Graph of depth 1

---

# Example: Mutexes

---

# Example: Planning Graph of depth 2

---

# Example: Solution

---

# Homework

* [Homework 6](/PF-3335/assets/pdf/homework6.pdf) has been posted on the class website
  
* There are 4 problems where you will draw planning graphs

* It's only 4, because planning graphs are annoying to draw

* There is also also a bonus problem (another proof)

---

# References

* Dana Nau, [Planning-Graph Techniques](http://www.cs.umd.edu/~nau/planning/slides/chapter06.pdf)

* Nilufer Onder, [Planning Graphs and Graphplan](http://pages.mtu.edu/~nilufer/classes/cs5811/2005-fall/lecture-slides/cs5811-ch11b-graphplan.pdf)

* Tomás Lozano-Pérez, Leslie Kaelbling [Graph Plan](https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-825-techniques-in-artificial-intelligence-sma-5504-fall-2002/lecture-notes/Lecture12FinalPart1.pdf)