Automated Planning
Introduction to Planning
Jonas Kvarnström
Automated Planning Group
Department of Computer and Information Science
Linköping University
jonas.kvarnstrom@liu.se – 2016
One way of defining planning:
Using knowledge about the world,
including possible actions and their results,
to decide what to do and when
in order to achieve an objective,
before you actually start doing it
4
Some applications are simple, well-structured, almost toy problems
Simple structure
General Knowledge
Single agent acting
Specific Knowledge
 There are pegs and disks
 Three pegs, 7 disks
 A disk can be on a peg
 All disks currently on peg 2,
in order of increasing size
 One disk can be above another
 Actions:
Move topmost disk from x to y,
without placing larger disks
on smaller disks
Objective
 All disks on the third peg,
in order of increasing size
jonkv@ida
Towers of Hanoi
5
Some are larger, still well-structured

What you can do:
 Put package p in truck t
 Drive to location
 Deliver p from t

Objective: Deliver 20,000
packages (efficiently!)
 Which packages in which truck,
in which order?
 Which roads to use?
jonkv@ida
Logistics

Classical robot example:
Shakey (1969)
 Available actions:
▪ Moving to another location
▪ Turning light switches on and off
▪ Opening and closing doors
▪ Pushing movable objects around
▪ …
 Goals:
▪ Be in room 4 with objects A,B,C
▪ http://www.youtube.com/watch?v=qXdn6ynwpiI
6
jonkv@ida
Shakey

Tall buildings, multiple elevators
 How to serve people as efficiently as possible?

Schindler Miconic 10 system
 Enter destination before you board
 A plan is generated, determining
which elevator goes to which floor,
and in which order
 Saves time!
 Planning  3 elevators could serve as much traffic
as 5 elevators with earlier algorithms
7
jonkv@ida
Miconic 10 Elevators

Bending sheet metal
 Initially:
There is a flat sheet of metal
 Objective:
The sheet should be in specific shape
 Constraints: The piece must not collide with anything
when moved!
 An optimized plan for bending the sheet
saves a lot of time = money!
8
jonkv@ida
Bending Sheet Metal

Competition: autonomous cars drive 212 km off-road

Requires path planning
 Deciding how to get from one point to another, given:
▪ Speed limits
▪ Constraints on how you can move (turn radius, …)
▪ A map – that may not always be correct
▪ http://www.youtube.com/watch?v=M2AcMnfzpNg 2:00, 4:00
9
jonkv@ida
DARPA Grand Challenge 2005

SIADEX
 Decision support system for designing forest fire fighting plans
 Needs to consider allocation of limited resources
 Plans must be developed in cooperation with humans – people may die!
10
jonkv@ida
SIADEX

”Remote Agent” on Deep Space 1 spacecraft
 Controlled the spacecraft autonomously for 2 days
 Correctly handled simulated failures
 Rapid response to failures may be crucial to survival!
11
jonkv@ida
NASA Remote Agent

12
Rapid generation of activity plans for Mars Rovers
 Primary platform for creating daily activity plans for Spirit and Opportunity
 Mixed-initiative tool: Human in the loop
jonkv@ida
NASA Mapgen

And why should computers create plans?
 Manual planning can be boring and inefficient
 Automated planning may create higher quality plans
▪ Software can systematically optimize,
can investigate millions of alternatives
 Automated planning can be applied where the agent is
▪ Satellites cannot always communicate with ground operators
▪ Spacecraft or robots on other planets
may be hours away by radio
13
jonkv@ida
Why should Computers Plan?

A modern context for planning:
 Autonomous
Unmanned Aerial Vehicles (UAVs)
15
jonkv@ida
Context: Unmanned Aerial Vehicles
Using knowledge about the world,
including possible actions and their results…

17
Available actions, in this context:
 Take off
▪ Before: The UAV must be on the ground
▪ Result: The UAV is flying
 Fly to a point
▪ Before: Must have sufficient fuel
▪ Result: Will end up at the indicated point
 Land
Must define this
more formally

next lecture!
 Fly a trajectory curve
 Point camera
 Take picture
 Start/stop video recording
 Transmit information to operator
 …
Need other forms of
knowledge as well…

next lecture!
jonkv@ida
Actions for UAVs
…to decide what to do and when
in order to achieve an objective…
 Assist in emergency situations
▪ Deliver packages of food, medicine, water
Which actions to perform?
19
jonkv@ida
UAV Objective 1: Emergency Services Logistics
Photograph buildings – generate realistic 3D models
Which actions to perform?
20
jonkv@ida
UAV Objective 2: Photogrammetry
…decide…before you actually start doing it…
We need a program – a solver / planner!

22
For photogrammetry planning with a single UAV:
 Knowledge: Amount of fuel available
 Knowledge: Actions – fly, aim and take pictures (consuming fuel)
 Objective: To have pictures of certain buildings, in the specified directions!
 Decide:
What to do
jonkv@ida
Photogrammetry Planning

23
Exactly which class of problems should the algorithm solve?
Find a plan taking pictures of buildings A, B, C and D
in the LiU campus
Too specific!
Given as input a list of building coordinates,
find a plan taking pictures of the given buildings
Let's start here…
jonkv@ida
Solvers: Specific vs. General

24
 Solver should handle all instances of a problem domain
Photogrammetry
Problem Domain
Problem Instance(s)
There will be an initial fuel level
The actual positions and directions
There will be interesting positions/directions
The actual fuel level
The objective is to have pictures of those
Available actions: take off, fly, take picture, …
…
Write a solver based
on this general information…
…taking this specific information
as its input at runtime
jonkv@ida
Problem Specification

25
Method 0: Let’s be reactive (no planning) and stupid
 while (exists unvisited position) {
}
pos ← some random unvisited position
flyto(pos)
aim()
take-picture()
 Very fast algorithm
 Suboptimal…
…decide the next step to do…
…while you are doing it…
http://nfrac.org/felix/publications/tsp/
jonkv@ida
Method 0: Reactive + Stupid

26
Method 1: Let’s be reactive (no planning) and greedy
 while (exists unvisited position) {
pos ← the nearest unvisited position
flyto(pos)
aim()
take-picture()
Start here
}
 Greedy choice of action
 Better for this task, but not optimal
 For many other tasks: Still really bad
Often, not thinking ahead means
you can’t even solve the problem!
(Fly too far  run out of fuel;
crack an egg  can’t uncrack it;
…)
Run out of fuel here?
jonkv@ida
Method 1: Reactive + Greedy

27
Can be seen as search that immediately commits to choices
 Keeping track of [fuel left, visited positions, remaining positions]
 Not enough fuel left  give up (actions already executed  can't backtrack)
(100, [pos1], [pos2,…,pos20])
(96, [pos1,pos7],
[pos2,…,pos6,pos8,…,pos20])
(91, [pos1,pos7,pos8], …)
(82, [pos1,pos7,pos8,pos4], …)
jonkv@ida
Method 1, continued

28
Method 2: Let’s think ahead
 First create a complete plan, with backtracking
 Then execute
(100, [pos1], [pos2,…,pos20])
(96, [pos1,pos7],
[pos2,…,pos6,pos8,…,pos20])
(95, [pos1,pos8], …)
(91, [pos1,pos7,pos8], …)
(82, [pos1,pos7,pos8,pos4], …)
(81, [pos1,pos7,pos8,pos6], …)
jonkv@ida
Method 2: Think ahead

29
Method 2, step 1:
▪ call solve(100, [pos1], [pos2,…,pos20])
▪ solve(fuel-left, order, remaining) {
Have we already achieved the goal?
if (remaining == []) return order;
foreach position pos in remaining
First choice: As before (greedy heuristic)
in order of increasing
If not feasible: Try the next nearest pos
distance to current pos
Out of fuel ”in simulation”, not in reality
{
f2 = fuel-left – fuel-usage(last(order), pos);
if (f2 > 0) {
order2 = solve(f2, order+[pos], remaining–[pos])
if (order2 ≠ null) return order2;
}
}
Backtrack if there is no
return null;
feasible continuation
}
This is (one form of) planning!
jonkv@ida
Method 2: Think ahead – planning

Method 2: Let’s think ahead – second, execute the plan
▪ foreach (position pos in sequence of positions) {
flyto(pos)
aim()
take-picture()
}
Execution is separate!
30
jonkv@ida
Method 2: Think ahead – execution
31
Photogrammetry Without Planning – reactive
Generate one action (no lookahead)
Execute it
Repeat
Problem spec
Actions
Photogrammetry Planning
Problem spec
Planner generates
all actions
Plan
Execution
system
Actions
jonkv@ida
Reactive vs. Planning
33
Problem Instance Descr.
What we did:
Locations A, B, and C
Directions North, South, West,East
Helicopter H1
The goal is to have pictures
at location A in direction North,…
Domain-specific Planner
Written with domain knowledge:
There will be an initial fuel level
There will be interesting positions/directions
The objective is to have pictures of those
Available actions: take off, fly, take picture, …
Plan
Efficient code
Adapted to the
exact problem
Can even use
Traveling Salesman
algorithms…
jonkv@ida
Domain-Specific Planning

34
But: Some domains are less straight-forward
 Writing an efficient solver from scratch is difficult

Specialization means less flexibility! What if…
 you want to deliver a couple of crates at the same time?
▪ Need to modify
the code of the planner
 you have two UAVs and a UGV (ground vehicle)?
▪ Different
algorithm:
Multiple TSP
 you want to survey an area (send video feed of the ground)?
 you have dynamic no-fly-zones (”don’t fly there at 15:00-16:00”)?
PG +
Delivery
Planner
MultiTSP
planner
jonkv@ida
Domain-Specific Planning 2
High Level Domain Descr.
35
High Level Instance Descr.
There will be an initial fuel level
There will be interesting positions/directions
…
Easier to specify, easier to change!
In this particular problem we have:
Locations A, B, and C
Directions North, South, West,East
Helicopter H1
The goal is to have pictures
at location A in direction North,…
Domain-independent Planner
Written for generic planning problems
Difficult to create (but done once)
Improvements  all domains benefit
Plan
jonkv@ida
Domain-Independent Planning

36
To solve problems in other domains:
 Keep the planning algorithm
 Write a new high-level description of the problem domain

Performance can be lower,
but much less effort is needed
Mars Rover
problem instance
Mars
Rover
Domain
Domainindep.
Planner
Satellite
problem instance
Plan
Satellite
Domain
Domainindep.
Planner
Plan
jonkv@ida
Domain-Independent Planning
Problem Domain Descr.
There will be an initial fuel level
There will be interesting positions/directions
…
Easier to specify, easier to change!
37
Problem Instance Descr.
In this particular problem we have:
Locations A, B, and C
Directions North, South, West,East
Helicopter H1
The goal is to have pictures
at location A in direction North,…
Problem: Requires a very general planning formalism
to specify this kind of information!
Domain-independent Planner
Written for generic planning problems
Difficult to create (but done once)
Improvements  all domains benefit
jonkv@ida
Domain-Independent Planning
38
Which common language concepts
would be sufficient for all of these very different domains?
3D Geometry
Interaction
Path planning
Multiple agents
Opportunistic
goals
Simple…
Required
concurrency
Timing
jonkv@ida
Common Properties
Very difficult to create a well-defined semantics
for the combination of all of these requirements
Can we create a single unified
model + language
supporting all of these domains?
Can we create a single unified
planning algorithm
capable of generating plans in all of these domains?
Extremely difficult to find an algorithm
that works well in all cases
39
jonkv@ida
Only One Solution?
40
Increasing a planner's expressivity:

Can help ensure correctness
Decreasing a planner's expressivity:

 Can't model resources, fuel usage
 (By many orders of magnitude)
 create infeasible plans

 Allows different heuristics
Can help determine plan quality
 Allows different plan structures
 Which plan takes less time to
 Can exploit problem structure
execute? Requires a model of time!

 …
Can be necessary to handle:




Incomplete information
Non-determinism
Concurrency
...
Can improve performance
Simplifies development
 …

Conflicting desires – we need trade-offs!
Decide what "kind" of domains your planner should be able to accept
Write a planner for this expressivity
jonkv@ida
Different Requirements
41
*Except for standard
Turing-complete
programming
languages, which
don't count…
“Truly domain-independent”
Does not exist*
Partial order of
expressivity,
"coverage"…
…
…
Temporal planning
Classical planning
…
MDP
planning
…
Domain-specific
Can specialize the planner for very high performance
Must write an entire planner
Some classes
subsume others,
some are
simply different
jonkv@ida
Degrees of Expressivity

Many early planners made similar tradeoffs in terms of…
The expressivity of the modeling language
The underlying assumptions about the world

At the time this was simply "planning" or "problem solving"
 Later grouped together, called "classical planning"

Restricted, but a good place to start
 Forms the basis of most non-classical planners as well
Let's start here,
then explore more expressive alternatives!
43
jonkv@ida
Classical Planning

44
So exactly what is classical planning?
 Some disagreements…
▪ Inevitable: Just a group of similar techniques, formalisms
 Where to draw the line?
We'll use the book's definitions
Be aware:You can go outside those boundaries and still be "kind of classical"!
jonkv@ida
Classical Planning: Disagreements
45
A0: Finite number of states
Can't model continuous positions of containers
OK – we're only interested in some discrete alternatives:
in pile x, on truck y, carried by crane z, …
We want to affect a world
which is always in a given state
Another possible state
A6: Every action results in a discrete state transition
No concept of time
No concept of continuous change (crane swinging from A to B), only:
Before pickup, the container is on truck y;
after, the container is carried by crane z
Many planners do model some forms of time  "semi-classical"
jonkv@ida
Assumptions 1
46
A1: We can always detect the current state
Given A2, this only means that we know the initial state
Without A2, we can execute an action and then know where
we ended up
The world is always in
a given state
Another possible state
A2: Deterministic actions
If we know the current state and the action that is executed,
we know in advance exactly which state we will end up in
Some planners support non-determinism
Complicated due to explosion of possibilities!
jonkv@ida
Assumptions 2
A3: If we don't execute an action, we remain in the state
No random changes in the world
No other agents acting in the world
At least not in the part of the world we model!
The world is always in
a given state
47
jonkv@ida
Assumptions 3
other possible state
48
Another possible state
Another possible state
Goal states
Another possible state
Another possible state
The world is always in
a given state
Another possible state
A4: Restricted objectives
The objective is always to end up in a goal state,
a state having certain properties:
No constraint on cost, time requirements, states to avoid, …
Many planners support more complex objectives
jonkv@ida
Assumptions 4
 A5: Sequential plans
▪ A solution never executes two actions concurrently
▪ Many planners do allow concurrency  "semi-classical"
 A7: Offline planning
▪ No need to consider changes that may happen while generating plans.
We can define many other classes of planning problem
For now, we'll stay with classical problems
Next time: High-level languages for specifying classical planning problems
49
jonkv@ida
Assumptions 5