Introduction to Automated Task Planning Jonas Kvarnström Automated Planning and Diagnosis Group Artificial Intelligence and Integrated Computer Systems (AIICS) / IDA 3 jonkv@ida What is Planning? Planning is thinking ahead Not just reacting to what happens! Thinking about possible actions and their effects, formulating a complete plan that describes what to do and when, in order to achieve a goal …so when do we want computers to do that? 4 jonkv@ida Shakey Classical example: Shakey Used the STRIPS planner ▪ Stanford Research Institute Problem Solver ▪ One of the first planners (1969)
30
Embed
Introduction to Automated Task PlanningTDDC17/info/slides/2011/TDDC17_Fo8_9_plan_4sl.pdf · Miconic 10 Elevators 5 jonkv@ida Schindler Miconic 10 elevators People enter their destination
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Introduction to
Automated Task
PlanningJonas Kvarnström
Automated Planning and Diagnosis Group
Artificial Intelligence and Integrated Computer Systems (AIICS) / IDA
3
jonk
v@ida
What is Planning?
Planning is thinking ahead
Not just reacting to what happens!
Thinking about possible actions and their effects,
formulating a complete plan that describes what to do and when,
in order to achieve a goal
…so when do we want computers to do that?
4
jonk
v@ida
Shakey
� Classical example: Shakey� Used the STRIPS planner
▪ Stanford Research InstituteProblem Solver
▪ One of the first planners (1969)
5
jonk
v@ida
Miconic 10 Elevators
� Schindler Miconic 10 elevators� People enter their destination
before they board an elevator
� Many elevators, many floors
� The goal: For everyone to be at their destination
� The plan tells us:Which elevators should go to whichfloors, in which order?
� The gain: Less time to wait for an elevator!
6
jonk
v@ida
Sheet Metal Bending
� Robots bending sheet metal� Goal: Bend a flat sheet to a specific shape
� Constraints: The piece must not collide with anything when moved!(Geometric reasoning required)
� Optimized operation saves a lot of time = money!
7
jonk
v@ida
NASA Earth Observing-1 Mission
� Earth Observing-1 Mission � Satellite in low earth orbit
▪ Can only communicate 8 x 10 minutes/day
▪ Operates for long periods without supervision
� CASPER software:Continuous Activity Scheduling, Planning, Execution and Replanning
� Dramatically increases science returns
▪ Interesting events are analyzed(volcanic eruptions, …)
▪ Targets to view are planneddepending on previous observations
▪ Plans downlink activities:Limited bandwidth
� http://ase.jpl.nasa.gov/
8
jonk
v@ida
Unmanned Aerial Vehicles
� Unmanned aerial vehicles� Multiple agents to coordinate
� Actions executed concurrently
9
jonk
v@ida
UAV 1: Photogrammetry
� Photograph buildings, to generate 3D models
10
jonk
v@ida
UAV 2: Traffic Monitoring
� Monitor traffic / find possible routes for emergency vehicles
11
jonk
v@ida
UAV 3: Finding Forest Fires
� Patrol large areas searching for forest fires, day after day after day…
12
jonk
v@ida
UAV 4: Emergency Services Logistics
� Assist in emergency situations
▪ Deliver packages of food, medicine, water
13
jonk
v@ida
Why Planning?
� Can’t we just solve these problems ourselves?
� Manual planning can be boring and inefficient
▪ Who wants to spend all day guiding elevators?
� 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
Domain-Specific vs.
Domain-Independent Planning
15
jonk
v@ida
Introduction
� Let’s say we are interested in the photogrammetry domain� Multiple UAVs available
� Goal: To take pictures of buildings
� How do you create a photogrammetry plan?
16
jonk
v@ida
Domain-Specific Planning
� Domain-specific planner: Created for a particular domain� Input: A map containing buildings
▪ Everything else is implicit,since the planner already knowswhat actions are available, etc (hardcoded!)
� Implementation:
▪ Calculate suitable UAV positions
▪ Call a Travelling Salesman Problem solver
▪ Generate flight commands
PG Problem PG-specificPlanner
PG Plan
Sounds simple, and can be very efficient! But…
17
jonk
v@ida
Domain-Specific Planning
� Specialization means less flexibility! What if…� you want to deliver a couple of crates at the same time?
▪ Generalize input…
� you have to consider refueling?
▪ Different algorithm!
� you have two UAVs and a UGV (ground vehicle)?
▪ Differentalgorithm!
� you want to survey an area (send a video feed of the ground)?
� you have dynamic no-fly-zones (”don’t fly there at 15:00-16:00”)?
PG +DeliveryPlanner
PGPlannerw/ fuel
Multi-TSP
planner
18
jonk
v@ida
Domain-Independent Planning
� We want a generic planning system!� Capable of taking a high-level description of any problem domain
and then solving problems within the domain!
� A single planner
▪ Improvements to the planner � all domains benefit
� High-level domain and problem definitions
▪ Easier to specify these than to write specialized algorithms
▪ Easier to change than a hard-coded optimized implementation
▪ Also useful for rapid prototyping
Satellite
DomainGeneralPlanner
Satellite
problem instance
PlanUAV
DomainGeneralPlanner
Photogrammetry
problem instance
Plan
19
jonk
v@ida
What is Common?
What is common to all of these problems?
20
jonk
v@ida
This is Common!
� The world contains various types of objects� Buildings, cards, aircraft, switches, people, …
� We are generally interested in properties of these objects� Location of a card, whether we have a picture of a building or not, …
� Goals can be described as desired properties� We should have a picture of each building
� Actions modify properties (simplified!)� takeoff(uav) � now the UAV is in the air
� photograph(uav, building) � now we have a picture of the building
� Can only be executed if we can see the building
21
jonk
v@ida
Example 1
� In the Emergency Services Logistics domain:� 1. What objects exist?
▪ Let’s generalize:Both helicopters and boxesare objects as well.
22
jonk
v@ida
Example 2
� 2. What properties can different types of objects have?(Defined using state variables)
▪ An object is or isn’t at a certain location: at(object, loc)A helicopter is or isn’t at a certain location: at(heli, loc)A helicopter is or isn’t carrying a certain box: carrying(heli, box)
23
jonk
v@ida
Example 3
� 3. What properties do the objects of the current problem have now?
▪ Every box is at a certain location:at(box1, depot1), at(box2, depot1), …
▪ Every helicopter is at a certain location:at(surv1, basestation), at(surv2, person1), …
▪ Some helicopters are carrying boxes:carrying(cargo1, box4)
� 4. What properties should they have?This is our goal!
▪ at(box1, person1), at(box2, person2), …
Situationwe want to
achieve
Situationright now
24
jonk
v@ida
Example 4
� 4. What can we do about it? Actions!� Example: fly(heli, loc1, loc2)
▪ Preconditions:at(heli, loc1)loc2 is free – no other helicopter therefuel(heli) > dist(loc1, loc2) * fuelUsage(heli)
▪ Effects:at(heli, loc1) is no longer trueat(heli, loc2) is true insteadfuel(heli) decreases by dist(loc1, loc2) * fuelUsage(heli)
▪ Time requirements:distance(loc1, loc2) / speed(heli)
� Take off / land
� Hover at the current location
� Position the camera at angle θ
� Take a visual picture / Take an infrared picture
� Lift a package using a winch / Deliver a package using winch
L1 L2
25
jonk
v@ida
Domain-Independent Planning
Input 1: Planning domain
Input 2: Problem instance
Object Types: There are UAVs, boxes …
Properties: Every UAV has a maxSpeed, …
Actions: Definition of fly, pickup, …
Objects: Current UAVs are {UAV1,UAV2}
Initial State: Box locations, …
Goal: Box b1 at location l1, …
But what language should we use?
27
jonk
v@ida
Desirable Properties
� Desirable properties of a domain-independent planner:� Should be as general as possible
▪ Handle a wide variety of domains
� Should be as efficient as possible
▪ Generate plans quickly
� Should generate plans of the highest quality
▪ Fewer actions, lower cost, faster to execute, …
� Should support the user as much as possible
▪ Provide useful high-level structures such as actionsthat a user can easily specify
Many of these properties are in direct conflict!
28
jonk
v@ida
Classical Planning
� For efficiency, planners generally exploit domain structure� This implies constraining the expressivity of the planner
and its input language!
� Classical planning uses a common set of constraints…� Sometimes called "STRIPS planning"
� Demonstrated using a simple domain: The Blocks World
� Also introduces PDDL, the Planning Domain Definition Language
▪ General language
▪ Subsets are supported by most modern planners
29
jonk
v@ida
Blocks World
� What you can do:� Pick up a block
▪ unless something is on top of it
� Put a block that you’re holding…
▪ on the table (space for all blocks)
▪ on another block,unless something is on top of it
� Which actions will achieve your goals?
Your greatest desireWhat you knowYou
C B
A
C
B
A
30
jonk
v@ida
PDDL: Domain and Problem Definition
� PDDL: Lisp-like language, expressions in parentheses� Every domain is named,
associated with explicit list of expressivity requirements
▪ (define (domain blocksworld)(:requirements
:adl ;; Conditional effects, quantification, …:equality ;; Use of “=”…)
;; Remaining domain information goes here!)
� Problem instance has a name, belongs to a domain
� Three different statesin the Blocks World� Can be described graphically
� Can be described in text(the following 3 slides!)
C
B
A
C B
A
C B
A
34
jonk
v@ida
3: Complete Initial Information
� We assume complete information about the initial state� All state variables are given values in the problem instance
▪ BW: on(A,B), on(B,Table), on(C,Table)… etc.
C B
A
35
jonk
v@ida
3b: Initial State in PDDL
� How do we completely specify the initial BW state?▪ (and
(not (on A A)) (not (on A B)) (on A C) (not (on A Table)(not (on B A)) (not (on B B)) (not (on B C)) (on B Table)(not (on C A)) (not (on C B)) (not (on C C)) (on C Table)(not (on Table A)) (not (on Table B))(not (on Table C)) (not (on Table Table))(not (istable A)) (not (istable B)) (not (istable C))(istable Table))
� Observation: Given complete info, most facts are false!
▪ A block can only be on one other block:Given any ?x, at most one instance of (on ?x ?y) is true(Given 1000 blocks, ?x is on 1, not on 999)
C B
A
36
jonk
v@ida
3c: Conventions for Initial States
� Convention: Only specify what is true in the initial state
▪ (define (problem MyThreeBlockProblem)(:domain blocksworld)(:objects A B C)(:init (on A C) (on C Table) (on B Table) (istable Table))
…)
� This is a shorthand notation, and is only used in :init.
▪ PDDL is for planners that cannot handle unknown initial information,so for convenience,an atom that is not mentioned is by definition false
C B
A
37
jonk
v@ida
4: Operators and Actions
� A set of single-step operators defines what you can do� Part of the domain description
� Many ways of modeling any domain! One example:
▪ “put” should take a block from where it is, and put it on another block
� Each operator has parameters: put(x,y)
▪ Instantiated into actions: put(A,B), put(A,C), …
� Each operator has a precondition
▪ “There must be no other block on top of x”, …
� Each operator has effects
▪ Afterwards, x will be on top of y
���� put(A,B) ����
C B
A
C B
A
38
jonk
v@ida
4b: Operators and Actions
� Each action is executed as a single step� If the precondition holds in the current state:
▪ The action can be executed
▪ A single new state results, where the effects hold.
� UAV domain:
▪ Flying from (100,100) to (300,300)is basically modeled as “teleporting”in a single step
▪ We don’t model the factthat the UAV moves throughintervening locations
▪ Sufficient for sequential plans���� put(A,B) ����
C B
A
C B
A
39
jonk
v@ida
4c: Operator Preconditions
� Precondition: Must hold for an action to be applicable
▪ Classical planning: We must know what an action requires!
▪ (define (domain blocksworld) …(:action put
:parameters (?moved ?dest):precondition (and
;; Don't put the table on top of something(not (istable ?moved)) ;; Don't put a block on top of itself(not (= ?moved ?dest));; There is nothing on top of the block we move(not (exists (?other) (on ?other ?moved))) ;; Either the destination is the table,;; or there is nothing on top of it(or (istable ?dest) (not (exists (?other) (on ?other ?dest))))
)
Connectives:(and …)(or …)(imply …)(not …)
Quantifiers:(exists (?v) …)(forall (?v) …)
Operators are called actions in PDDL…
40
jonk
v@ida
4d: Effects
� Effects: What changes if you perform an action?
▪ Classical planning: We must know all effects!
▪ Can’t state that an action may fail: (on x y) or (on x Table)
▪ Can’t model outcome probabilities: 95% (on x y), 5% (on x Table)
▪ Instead, complete information: Only (and …) is possible!
▪ Include atoms that become true: (on ?moved ?dest)
▪ Include negated atoms that become false: (not (on ?moved ?other))
:effect (and;; ?moved is now on ?dest.(on ?moved ?dest);; If ?moved was on some ?other, it no longer is.(forall (?other)
(when (on ?moved ?other) (not (on ?moved ?other))))
Uses quantified and conditional effects (ADL):(when (condition-in-invocation-state)
(effects-in-result-state))
41
jonk
v@ida
5: No Other Agents
� Classical planning assumes the state of the world can only be modifiedby actions generated by the planner
▪ No agents are moving blocks aroundunless we say so in the plan!
▪ � When considering different potential plans,the planner can predict the exact end result of every action in the planwithout worrying about someone "disturbing" its execution
42
jonk
v@ida
6: Goals
� Goals only constrain the final state of a plan� Specify the end result, not how you get there
� Specified in the problem instance
� Goal for our example instance� One possibility:
▪ (define (problem ABC)(:domain blocksworld)…(:goal (and (on A B) (on B C) (on C Table))))
C
B
A
43
jonk
v@ida
6b: Goals
� A complete goal specification is generally not required� Some predicates can "follow from others"
▪ (define (problem ABC)(:domain blocksworld)…(:goal (and (on A B) (on B C) (on C Table))))
� Here we don't specify that (on A C) must be false
▪ This just follows from the fact thata block can't be on two different blocks at the same time
C
B
A
44
jonk
v@ida
6c: Goals
� A goal specification can usually correspond to many states� An arbitrary conjunction is allowed
� We do not assume that predicates left out must be false!
▪ (define (problem ABC)(:domain blocksworld)…(:goal (and (on B C) (on C Table))))
▪ We don't say whether (on A B) is true,so either of the two following states would be considered goal states!
� Sometimes disjunctions may be allowed as well
C
B
A
C
B
A
Using Object TypesSame Expressivity, More Convenient
46
jonk
v@ida
Example Domain: Logistics
� The "traditional" logistics domain� Unlike the blocks world, many object types
▪ We have a number of packages at given locations
▪ Move packages within a city using trucks
▪ Move packages between cities using airplanes
▪ Airplanes can only move between certain airport locations
▪ Goal: Packages should be at their destinations
47
jonk
v@ida
Logistics Domain in PDDL
� First attempt at a logistics domain:� (define (domain logistics)
70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 plans – but computers are fast…
Assume 1020 (100 billion billion) plans per second: 20000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 years – but we have multiple cores…
Suppose every particle in the universe is a computer:2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 years
63
jonk
v@ida
Hopeless?
� Is there still hope for planning?� Of course there is!