Week 9: Advanced Planning and Problem Decomposition
Last week's planners assumed one robot arm, producing strictly sequential plans. This week opens three new directions. First, multi-armed robots that can act in parallel, shrinking plan makespan. Second, Graphplan, which constructs a planning graph capturing all possible solutions before searching inside it. Third, problem decomposition via AND-OR trees and the AO* algorithm, which breaks goals into sub-goals and solves them optimally. The thread connecting all three: moving from linear to non-linear, from state-space to graph-structured, from sequential to decomposed reasoning.
Multi-armed Robots [Lecture 1]
A one-armed robot can only do one thing at a time, forcing linear plans. With two (or more) arms, actions can happen in parallel, reducing the makespan (number of time steps) of a plan.
Modifying STRIPS operators for two arms
Each arm gets its own predicates: , , , (arm empty). Each original operator is duplicated per arm:
| One-arm version | Two-arm versions |
|---|---|
| Unstack(x, y) | Unstack(x, y), Unstack(x, y) |
| Pickup(x) | Pickup(x), Pickup(x) |
| Putdown(x) | Putdown(x), Putdown(x) |
| Stack(x, y) | Stack(x, y), Stack(x, y) |
The generic arm number can parameterize the operators: , .
To delete or not to delete Clear(x)?
In the one-arm domain, when you pickup or unstack block , should you delete from the state?
- One-arm robot: It doesn't matter. After picking up , the only options are putdown or stack, both of which make true again.
- Multi-arm robot: It matters. If arm 1 unstacks from and arm 2 unstacks from in parallel, the question is: after unstacking, is true? If we delete on unstack, then is only restored when another action adds it (e.g., stacking onto makes true). This creates a causal dependency that forces ordering constraints.
Worked example: two arms
Start: D on A, C on B. Goal: , .
With one arm: 6 steps (unstack D, putdown D, unstack C, stack C on A, pickup D, stack D on C).
With two arms (deleting Clear):
Makespan = 3 instead of 6. The two unstack actions happen in parallel. Stack(D,C) must wait for Stack(C,A) because Clear(C) is only true after C is placed on A. This causal link is only captured when we delete Clear on unstack.
If we don't delete Clear, both unstacked blocks remain "clear," allowing Stack(D,C) and Stack(C,A) in parallel, potentially yielding a makespan of 2. But this is incorrect for the domain: after unstacking C from B, C cannot have something stacked onto it until it is placed somewhere. The delete-Clear version correctly captures the constraint.
Means-Ends Analysis [Lecture 2]
Proposed by Newell and Simon in their General Problem Solver (GPS), means-ends analysis is a heuristic strategy for problem solving that mirrors how humans plan.
The strategy
- Compare the current state with the desired goal
- List the differences between them
- Evaluate differences by magnitude
- Reduce the largest difference first using the operator-difference table
- Recursively achieve the preconditions of the chosen operator
- Apply the operator, then recursively achieve the remaining goal from the new state
The AND structure
Means-ends analysis produces an AND-OR tree:
Both branches must succeed (AND node): first reduce the largest difference, then achieve the rest of the goal from the new state. This is different from OR trees (where any one branch suffices).
Operator-difference table (travel example)
| Distance | Operators |
|---|---|
| > 5000 km | Airplane |
| 100-5000 km | Airplane, Train, Car |
| 1-100 km | Train, Car, Taxi, Bus |
| < 2 km | Walk, Bus, Taxi |
To get from IIT Madras to Parashar Lake (Himachal Pradesh):
- Largest difference: ~2500 km → take a flight (Chennai → Delhi)
- Remaining: IIT → Chennai airport (taxi), Delhi airport → Mandi (bus)
- Smallest: Mandi → Parashar Lake (walk/taxi)
The key insight: means-ends analysis selects an action in the middle of the plan first (the flight), then recursively fills in the prefix and suffix. This is fundamentally different from forward or backward state-space planning, which commit to an ordering direction.
Hierarchical planning (brief mention)
A related approach: define high-level operators (e.g., "plan a holiday") with abstract preconditions, then refine them into detailed plans. This is hierarchical planning, and we don't cover it in detail here.
Algorithm Graphplan [Lecture 3]
Graphplan (Blum & Furst, 1995) takes a radically different approach: two-stage planning. First, construct a planning graph that compactly represents all possible plans. Then, search inside that graph for a valid solution.
This paradigm shift increased the plan lengths that could be found from ~15 steps to ~200 steps.
Related two-stage planners
| Planner | Stage 1 | Stage 2 |
|---|---|---|
| Graphplan | Build planning graph | Extract solution from graph |
| SATplan | Convert to SAT problem | Use SAT solver |
| CPlan | Convert to CSP | Use CSP solver |
| HSP / FF | Compute domain-independent heuristic | Heuristic state-space search |
Planning graph structure
A planning graph is a layered graph with alternating layers:
- = the start state (set of propositions)
- = all applicable actions in
- = union of all effects of actions in
No-op actions
Every proposition in layer has a corresponding no-op action: precondition = , positive effect = . This ensures all propositions carry forward to subsequent layers. No-op actions are always assumed present but not drawn in diagrams.
Edges in the planning graph
Three kinds of edges from action layers to proposition layers:
- Precondition links: action → propositions in the previous layer it depends on
- Positive effect links: action → propositions it adds in the next layer
- Negative effect links (red, with circle): action → propositions it deletes in the next layer
Mutual exclusion (mutex)
Two actions in the same layer are mutex if any of these hold:
| Condition | Meaning |
|---|---|
| Competing needs | They have precondition propositions that are mutex |
| Inconsistent effects | One adds , the other deletes |
| Interference | One deletes a precondition of the other |
| Consuming same resource | Both need and delete the same proposition (e.g., both need ArmEmpty) |
Two propositions in the same layer are mutex if all pairs of actions that produce them are mutex.
Monotonicity and leveling off
- Proposition layers grow monotonically (new propositions are only added, never removed)
- Action layers grow monotonically
- Mutex relations first increase, then gradually decrease as more actions become available in later layers
- If two consecutive layers have the same propositions and the same mutex relations, the graph has leveled off. No further changes are possible. If goal propositions are absent, the problem has no solution.
Termination and solution extraction
Grow the graph until:
- All goal propositions appear in and none are mutex with each other → attempt to extract a solution
- The graph levels off without the goal being present → no solution exists
Solution extraction searches backward from the goal propositions in , selecting non-mutex actions whose preconditions are present and non-mutex in earlier layers. If extraction fails, grow the graph by one more layer and try again. The first successful extraction yields the minimum makespan plan.
Problem Decomposition and AND-OR Trees [Lecture 4]
Motivation: planning an evening out
Suppose you need to choose: an activity, a movie, and a restaurant. With depth-first search, you fix Activity, then Movie, then Restaurant, and backtrack chronologically if the combination fails.
The problem: if "visit mall" is the culprit (no plan with mall is accepted), depth-first search wastes effort trying all movie/restaurant combinations with mall before finally switching to "beach." Dependency-directed backtracking would jump straight to the culprit, but ordinary DFS can't do this.
AND-OR trees
The alternative representation: break the goal into independent sub-goals. The solution is a subtree, not a path.
- AND arc: all children must be solved (activity AND movie AND dinner)
- OR arc: any one child suffices (beach OR mall)
Solution = subtree
For OR trees (standard search), the solution is a path. For AND-OR trees, the solution is a subtree whose leaves are all solved (primitive problems needing no further refinement). Internal nodes labeled live need further refinement.
Symbolic integration example
AND-OR trees arise naturally in symbolic integration:
- Transform the integral by substitution ()
- Decompose the transformed integral into simpler parts (integration by parts, sum rule)
- Each part either reduces to a primitive (known integral = solved node) or needs further decomposition
The process can cycle (e.g., converting to and back), so the algorithm must detect and avoid loops.
Solving Goal Trees with AO* [Lecture 5]
AO* (Martelli & Montanari, 1978) is the AND-OR tree analog of A*. The star denotes admissibility: under certain conditions, it finds the least-cost solution subtree.
Comparison: A* vs AO*
| Aspect | A* | AO* | |---|---| | Graph type | OR graph | AND-OR graph | | Solution | Path from start to goal | Subtree rooted at start | | Node expansion | Expand the lowest -cost open node | Follow marked paths, expand a live node | | Cost backup | | Cost = sum of best child costs + edge costs | | Termination | Goal dequeued from OPEN | Root labeled solved |
The AO* algorithm
Forward phase:
- Start at the root. Trace the marked (best-looking) paths down to a set of live (unsolved, unexpanded) nodes .
- Pick a node from and refine it (generate its successors).
- Check for loops and remove any child that would create one.
Backward phase:
-
Let = set of newly modified nodes.
-
For each node in (deepest first):
- Compute the best cost from 's children
- Mark the best option at
- If all AND-successors along the marked path are labeled solved, label as solved
- If 's cost or solved label changed, add all parents of to
-
Continue until the root is labeled solved (success) or no solution exists.
Admissibility
AO* is admissible (finds the optimal solution) when the heuristic function underestimates the true cost, just like A*. The reasoning is analogous: as long as underestimates hold, no unexplored partial solution can be cheaper than the one being refined, so the algorithm won't miss the optimum.
Key insight: backed-up cost, not heuristic value
When choosing which node to expand next, the decision is based on the backed-up cost of the entire solution path, not the heuristic value of the individual node. A node with low -value may be part of an expensive solution branch.
AO*: An Example [Lecture 6]
Consider an AND-OR graph with heuristic values assigned to unexpanded nodes. Solved nodes (double boxes) have cost 0.
Case 1: Edge cost = 1 (heuristic values are overestimates)
With unit edge costs, the heuristic values (e.g., 10 for a node whose actual cost is 1) tend to overestimate.
Step 1: Expand root. Two options: left branch (cost 6 + 7 + 2 = 15) vs right branch (cost 4 + 5 + 2 = 11). Mark right branch.
Step 2: Expand node with . It has one AND-choice leading to two solved nodes (cost 0 each). Its real cost = 0 + 0 + 1 + 1 = 2. Root cost drops from 11 → 8.
Step 3: Expand node with . Two options: AND-choice (cost 3 + 4 + 2 = 9) vs OR-choice (cost 7 + 1 = 8). Mark OR-choice. Cost goes up from 4 → 8.
Step 4: The right branch cost has risen, but it's still cheaper than the left. Continue refining.
Characteristic of overestimation: costs keep coming down as nodes are refined. The first promising branch always stays the best, so the algorithm never switches. It terminates quickly but may not find the optimal solution.
Case 2: Edge cost = 10 (heuristic values are underestimates)
With edge cost 10, the same heuristic values now underestimate the true cost.
Step 1: Right branch: 4 + 5 + 20 = 29. Left branch: 6 + 7 + 20 = 33. Mark right.
Step 2: Expand node. Its real cost = 0 + 0 + 10 + 10 = 20. Right branch cost jumps from 29 → 44. Left branch is now cheaper (33). Marker switches to left.
Step 3: Expand node. It has an AND-choice with cost 3 + 4 + 20 = 27. Left branch cost becomes 27 + 6 + 20 = 53. Right branch (44) is now cheaper again. Marker switches back.
Characteristic of underestimation: costs tend to go up as nodes are refined. The algorithm keeps switching between branches as better estimates emerge, exploring more thoroughly. It is slower but guaranteed to find the optimal solution.
This directly parallels weighted A*: overestimating is like using a large weight (faster but suboptimal), while underestimating is like (slower but admissible).
Goal Trees and Deduction in Logic [Lecture 7]
AND-OR trees appear not just in planning but in logical deduction. The connection: searching for a proof is searching for a solution in an AND-OR graph.
Entailment and proof
Given a knowledge base (a set of sentences assumed true) and a query sentence , we ask: is entailed by ? That is, if everything in is true, must also be true?
- Entailment () is a semantic notion about truth
- Provability () is a syntactic notion about deriving via inference rules
- Soundness: if then (every provable statement is true)
- Completeness: if then (every true statement is provable)
The Socratic syllogism
- All men are mortal:
- Socrates is a man:
- Therefore:
The form is valid regardless of content (replace Man with City, Mortal with Congested, Socrates with Chennai).
Forward chaining vs backward chaining
Forward chaining (natural deduction): start from , apply inference rules (e.g., modus ponens: from and , derive ), add new sentences, repeat until is derived or no new sentences can be added.
Backward chaining (deductive retrieval): start from the goal , look for rules whose consequent matches , reduce to proving the antecedents. This produces an AND-OR tree.
Backward chaining with variables
The goal can contain variables (existential quantifier): "Is there someone who is mortal?" → .
The process:
- Match goal against the rule
- Unify: substitute , producing sub-goal
- Match against facts in : try , , etc.
- Each successful substitution gives a witness for the existential query
Conjunctive antecedents: AND nodes
Consider the rule: .
To prove , you must prove both and . This is an AND node. When multiple rules can prove the same consequent (e.g., "red with square base" also makes a nice toy), those are OR alternatives.
Nice toy example
Rules:
- Rule 1:
- Rule 2:
Facts: Green(A), Green(B), Circular(C), Red(C), Red(D), Square(D), Circular(E)
Backward chaining from :
- Via Rule 1: needs Green(A) ✓ and Circular(A)? No fact. needs Green(C)? No fact. No solution via Rule 1 with current KB.
- Via Rule 2: needs Red(D) ✓ and Square(D) ✓. Solution found: D is a nice toy.
The search through this AND-OR tree is exactly what AO* does: it explores the marked (cheapest-looking) branches, refines live nodes, and backs up revised cost estimates.
Week 9 Summary
| Topic | Key idea | Planning paradigm |
|---|---|---|
| Multi-arm robots | Parallel actions, makespan, delete-Clear choice | Plan-space with parallel actions |
| Means-ends analysis | Reduce largest difference first, operator-difference table | Recursive AND-OR decomposition |
| Graphplan | Build planning graph, then extract solution | Two-stage: graph construction + search |
| AND-OR trees | Solution is a subtree, not a path | Goal decomposition |
| AO* | Follow marked paths, expand live node, back up costs | Best-first AND-OR search |
| Under/overestimation | Underestimate → optimal but slow; overestimate → fast but maybe suboptimal | Directly parallels weighted A* |
| Logic & deduction | Backward chaining through rules = AND-OR search | Unification + modus ponens as search |
The grand arc of this week: from extending STRIPS to parallel agents, to a two-stage planning architecture, to treating planning as search in AND-OR graphs. Each step generalizes the notion of what a "plan" is, from a linear sequence to a partially ordered set to a decomposed subgraph.