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 Too

Init(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 graph

GRAPHPLAN(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