Homework 1 (Written Portion) Max: 75 Min: 38 Avg: 57.6 Median: 58
(77%)
Planning Graph A planning graph consists in a sequence
of levels that correspond to time steps Level 0 is the initial state
Each level contains a set of literals that could be true at this time step
Each level contains a set of actions that could be applied at this time step
Have Cake and Eat it TooInit(Have(Cake))Goal(Have(Cake) ∧ Eaten(Cake))Action(Eat(Cake)
PRECOND: Have(Cake)EFFECT: ¬ Have(Cake) ∧ Eaten(Cake))
Action(Bake(Cake)PRECOND: ¬ Have(Cake)EFFECT: Have(Cake))
Planning Graph Level A0 contains all the actions that could occur in
state S0. Persistence actions (small boxes) represent the fact that
one literal is not modified. Mutual exclusions (mutexes, gray lines) represent
conflicts between actions. To go from level 0 to the level 1, you pick a set of non
exclusives actions (for instance, action Eat(Cake))
Level S1 contains all the literals that could result from picking any subset of actions in A0.
Mutexes represent conflicts between literals.
How to build the planning graph
Mutexes A mutex between two actions indicates
that it is impossible to perform these actions in parallel.
A mutex between two literals indicates that it is impossible to have these both literals true at this stage.
How to compute mutexes Actions
Inconsistent effects: two actions that lead to inconsistent effects
Interference: an effect of the first action negates the precondition of the other action
Competing needs: a precondition of the first action is mutually exclusive with a precondition of the second action.
Literals one literal is the negation of the other one Inconsistency support: each pair of action achieving
the two literals are mutually exclusive.
Inconsistent effects: Eat(Cake) & noop of Have(Cake) disagree on effect Have(Cake)
Interference: Eat(Cake) negates precondition of the noop of Have(Cake)
Competing needs: Bake(Cake) & Eat(Cake): compete on Have(Cake) precondition
In S1, Have(Cake) & Eaten(Cake) are mutex In S2, they are not because Bake(Cake) & the noop of
Eaten(Cake) are not mutex
Plan Graph Summary Continue until two consecutive levels are
identical. Graph indicates which actions are not
executable in parallel Construction polynomial No choice which action to take, only
indicate which are forbidden to occur in parallel
Planning graph for heuristic search Using the planning graph to estimate the
number of actions to reach a goal
If a literal does not appear in the final level of the planning graph, then there is no plan that achieve this literal! h = ∞
Heuristics max-level: take the maximum level where any literal
of the goal first appears admissible
level-sum: take the sum of the levels where any literal of the goal first appears not admissible, but generally efficient (specially for
independent subplans)
set-level: take the minimum level where all the literals of the goal appear and are free of mutex admissible
Graphplan Algorithm Extracts a plan directly from the plan
graphGRAPHPLAN(problem) returns solution or failuregraph INITIALPLANNINGGRAPH(problem)goals GOALS[problem]loop do if goals all non-mutex in last level of graph then do solution EXTRACTSOLUTION(graph,goals,LENGTH(graph)) if solution failure then return solution else if NOSOLUTIONPOSSIBLE(graph) then return failure graph EXPANDGRAPH (graph,problem)
Questions?
Partially Ordered Plans Least Commitment Principle:
One should make choices only about things that you currently care about ,leaving the others to be worked out later.
Total Order Planner Planner in which plans consist of a simple lists of steps
(this is what we’ve seen so far) Partial Order Planner
A planner that can represent plans in which some steps are ordered (before or after) w.r.t each other and other steps are unordered.
Left Sock
Start
Finish
Right Shoe
Left Shoe
Right Sock
Start
Right Sock
Finish
LeftShoe
RightShoe
Left Sock
Start Start Start Start Start
Right Sock
Right Sock
Right Sock
Right Sock
Right Sock
Left Sock
Left Sock
Left Sock
Left Sock
Left Sock
Left Sock
RightShoe
RightShoe
RightShoe
RightShoe
RightShoe
LeftShoe
LeftShoe
LeftShoe
LeftShoe
Finish Finish Finish Finish Finish
Left Shoe onRight Shoe on
Left Sock on Right Sock on
Partial Order Plan: Total Order Plans:
Planning Languages STRIPS
Stanford Research Institute Problem Solver Historically important
ADL Action Description Languages See Table 11.1 for STRIPS versus ADL
PDDL Planning Domain Definition Language Revised & enhanced for the needs of the International
Planning Competition
PLANNING IN REAL WORLD
Planning in Ideal and Real Worlds Classical planners assume
Fully observable, static and deterministic domains Correct and complete action descriptions … allowing a “plan-first-then-act” planning approach
… but in the real world The world is dynamic, and time cannot be ignored Information on the world is incomplete and incorrect … the agent must be prepared for unexpected events
Plus - scaling up to real-world problem size!
Time, Schedules and Resources The PDDL language allows events (actions) and
ordering of events, but not time duration In real-life planning, we must take duration, delays,
etc. into account (not just ordering) Example: Job shop scheduling:
The problem is to complete a set of jobs Each job consists of a set of actions, with given duration
and resource requirements Determine a schedule that minimizes total time needed
while respecting resource constraints Must extend representation language to express
duration and resource constraints
Job-Shop Scheduling Problem
Scheduling – no resource constraints
1. Create a partially-ordered plan2. Use the critical-path method to determine the schedule.
Critical path = the path whose total duration is longest. This solution assumes no
resource constraints. Note that 2 engines are being added simultaneously.
Shortest duration schedule, given partial-order plan: 85 minutes
[earliest start, latest start]
Scheduling – with resource constraints
Takes longer, since same actions (on different cars) cannot overlap due to resource constraints (115 mins) Critical Path = AddEngine1, AddEngine2, AddWheels2,
Inspect2 Remaining actions have considerable slack time: they
can begin much later without affecting the total plan time.
Planning + Scheduling Serial: Plan, then Schedule. Interleaved: Mix planning and scheduling.
For example, include resource constraints during partial planning.
Note: We are still working in classic planning environments (i.e., observable, deterministic, static and discrete), but have added absolute start times and durations.
Complexity of Temporal Planning Finding critical path O(Nb)
N is number of actions, b is branching factor
Introducing resource constraints that restrict which actions can overlap turns this into an NP-hard problem! This is a really big area in AI right now. Recent work out of MIT, in collaboration with
Boeing and NASA, can perform human-robot teaming tasks of 15+ actions.
Hierarchical Planning Hierarchical Problem Decomposition - express actions at
one level as small sets of actions at the next lower level. Solve relatively small problems at each level of abstraction.
Hierarchical Task Network (HTN) Planning - begin with abstract plan and continue expanding each activity (i.e., replacing it with its lower-level realization) until plan consists of only low-level actions.
Most real-world planners use HTN variants
The formalism of HTN planning
Retain the basic environmental assumptions as for classical planning
What we previously simply called actions are now "primitive actions“
Add HLAs: High Level Actions (like Build House) each has 1 or more possible refinements
into sequences of actions
Example
What To Remember Basics of classical planning
State, action, preconditions, effects, goals Assumptions made by classical planning How forward and backward search works What a planning graph is and it tells us What a partially ordered plan is
Temporal planning Critical path is key to planning when actions have
durations Adding resource constraints makes planning really
hard Hierarchical Task Networks help to simplify all
types of planning