Automated Planning
Introduction to Planning
Jonas Kvarnström
Automated Planning Group
Department of Computer and Information Science
Linköping University
jonas.kvarnstrom@liu.se – 2015
A deeper investigation of the definition…
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
Using knowledge about the world,
including possible actions and their results…

A modern context for planning:
 Autonomous
Unmanned Aerial Vehicles (UAVs)
5
jonkv@ida
Context: Unmanned Aerial Vehicles

6
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…
 Monitor traffic / find possible routes for emergency vehicles
Which actions to perform? How, when, …?
8
jonkv@ida
UAV Objective 1: Traffic Monitoring
 Patrol large areas searching for forest fires
Which actions to perform?
9
jonkv@ida
UAV Objective 2: Finding Forest Fires
 Assist in emergency situations
▪ Deliver packages of food, medicine, water
Which actions to perform?
jonkv@ida
UAV Objective 3: Emergency Services Logistics 10
Photograph buildings – generate realistic 3D models
Which actions to perform?
11
jonkv@ida
UAV Objective 4: Photogrammetry
…decide…before you actually start doing it…
We need a program – a solver / planner!

13
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

14
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

15
 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

16
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

17
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

18
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

19
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

20
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 last(order)
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!
21
jonkv@ida
Method 2: Think ahead – execution
22
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
24
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

25
But: Some domains are less straight-forward
 Writing an efficient solver from scratch is difficult

And 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.
26
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

27
To solve problems in other domains:
 Keep the planning algorithm
 Write a new high-level description of the problem domain

Generally lower performance, but much less effort 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!
28
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
29
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
30
jonkv@ida
Only One Solution?
31
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
32
*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"

Quite 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!
34
jonkv@ida
Classical Planning

Example: Shakey planned
using STRIPS
 Stanford Research Institute
Problem Solver
 Another early planner

Introduced some concepts
that are now associated with
classical planning
35
jonkv@ida
History: STRIPS

36
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