Introduction

Last day, we started learning about PDDL as a first-order logic for planning problems.
We showed how in PDDL we could express a problem that might be solvable by a problem solving agent
At the end of last day we gave an example of a cargo plane problem expressed in PDDL.
Today, we will resume with this example, show a couple other examples and then start talking about algorithms for planning.

Cargo Problem

An example, solution to this problem is the sequence:
`[Load(C_1, P_1, SFO), Fly(P_1, SFO, JFK), Unload(C_1, P_1, JFK),`
`\quad Load(C_2, P_2, JFK), Fly(P_2, JFK, SFO), Unload(C_2, P_2, SFO)]`
This problem illustrates one thing that we will have to be careful about when we talk about algorithms...
Consider the action `Fly(P_1, JFK, JFK)`. Intuitively, this should do nothing. However, the effect according to the fly rule is `At(P_1, JFK) ^^ neg At(P_1, JFK)`. Our rules for changing from one state say that we add `At(P_1, JFK)` (no change to the state set) then delete `At(P_1, JFK)`, causing the plane to vanish!
Typically, this problem is solved by adding inequality condiitons on the from and to airports.

Consider the problem of changing a flat tire. This can be expressed using the problem statement above from the book.
The goal is to have a good spare tire properly mounted onto the car's axle. The initial state has a flat tire on the axle and a good spare in the trunk.
A solution to the problem is the sequence:
`[Remove(Flat, Ax\l\e), Remove(Spare, Trunk), PutOn(Spare, Ax\l\e)]`

One of the most famous early AI planners was SHRDLU (1968-1970) which allowed a human to converse with a program about objects in block world. Using English the human could instruct the program to rearrange, stack blocks, etc, and the program would figure out the sequence of actions needed to accomplish this.
Above we give a simplified block world, state it as a planning domain, and give an initial and goal state.
Here `On(b,x)` indicates that block `b` is on `x`, where `x` is another block or the table. `Move(b,x,y)` moves block `b` from on top of `x` to on type of `y` provided that nothing is on top of `b`, `b` is on top of `x` and nothing is on top of `y`.
In order to allow the table to hold multiple blocks, we have a separate action for it. We also in the above interpret `Cl\e\a\r(x)` to be there is a clear space on `x` to hold a block.

Two common questions associated with planning are:
- PlanSat - given a planning problem, does there exist any plan that solves the problem?
- BoundedPlanSat - given a planning problem, does there exist any plan that solves the problem in `k` steps of less?
Both of these problems are known to be decidable for classical planning, that is, there is an algorithm (maybe inefficient) to find a plan if it exists.
Further (Ghallab 2004), show that both problems are in fact in PSPACE but are NP-hard.
They remain NP-hard if we disallow negative effects from our actions. However, PlanSat, for problems without negative preconditions is in polynomial time (P).
These are worst-case results. Many real-world problems are much easier than the worst case. But these results do show that there is an art to solving planning problems, and this art often means coming up with good heuristics.

In forward search, we start with our initial state and we apply each possible action rule and search forward hoping to find a goal state.
One problem with forward search is it is prone to considering irrelevant actions.
For example, suppose the goal is to buy a textbook and we have an action schema `Buy(isbn)` with effect `Own(isbn)`. ISBNs are ten digits, so this action schema has 10 billion ground actions. An uninformed forward-search would have to enumerate through each.
Planning problems often have large state spaces. Consider an air cargo problem with 10 airports, where each airport has 5 planes and 20 pieces of cargo. The goal is to move all the cargo at airport A to airport B. This could be done by load 20 pieces of cargo at airport A into one plane, fly the plane to B, and unload the cargo.
Finding the solution, however, might be hard because each of the 50 planes can fly to 9 other airports, and each of the 200 packages can be loaded or unloaded into any planes at its airport. The book estimates this problem might have as many as `2000^41` possible states.
For forward planning to work we need to have good domain-independent heuristics (which we will see we do).

In backward (regression) search, we start from the goal, and try to search backward until we reach a state implied by the initial state.
This kind of search is also called relevant-states search because we only consider actions that are relevant to the goal.
At each step, there will be a set of relevant states to consider, not just a single state.
For example, suppose the goal was `neg P\o\o\r ^^ Famous`. This describes those states in which Poor is false, Famous is true, and we don't care about the value of the other states.
If there are `n` ground fluents in a domain, then there are `2^n` ground states, but `3^n` descriptions of sets of goals: positive, negative, and not mentioned.
If a domain is expressed in PDDL, it is not too hard to do regression on it. Given a state `g`, action `a` (everything ground), the regression from `g` to `a` gives us a state `g'` defined by
`g' = (g - ADD(a))cup Precond(a)`
In addition to being able to handle ground states, we need to be able to handle partially un-instantiated actions and states.
For example, suppose the goal is to deliver a specific piece of cargo to SFO: `At(C_2, SFO)`. This suggests the action `Unload(C_2, p', SFO)`:
`Action(Unload(C_2, p', SFO)`,
`\quad Precond: In(C_2, p') ^^ At(p',SFO) ^^ Cargo(C_2) ^^ Pla\n\e(p') ^^ Airp\o\r\t(SFO)`,
`\quad Effect: At(C_2, SFO) ^^ neg In(C_2, p')).`