Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Temporal Planning - Automated Planning - Lecture Slides, Slides of Computer Science

These are the lecture Slides of Automated Planning which includes Domain-Independent Planners, Abstract Search Procedure, Planning Algorithms, Current Set of Solutions, Unpromising Members, Loop Detection, Constraint Violation etc. Key important points are: Temporal Planning, Explicit Representation, Sequence of Discrete Events, State Variables, Persistence Constraints, Time-Oriented View, Partially Specified Function, Temporal Assertions

Typology: Slides

2012/2013

Uploaded on 03/21/2013

dharmpaal
dharmpaal 🇮🇳

3.9

(10)

87 documents

1 / 26

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Chapter 14
Temporal Planning
Lecture slides for
Automated Planning: Theory and Practice
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a

Partial preview of the text

Download Temporal Planning - Automated Planning - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Chapter 14

Temporal Planning

Lecture slides for

Automated Planning: Theory and Practice

Temporal Planning

• Motivation: want to do planning in situations

where actions

– have nonzero duration

– may overlap in time

• Need an explicit representation of time

• In Chapter 10 we studied a “temporal” logic

– Its notion of time is too simple: a sequence of discrete

events

– Many real-world applications require continuous time

– How to get this?

The Time-Oriented View

  • We’ll concentrate on the “time-oriented view”: Sections 14.3.1–
  • It produces a simpler representation
  • State variables seem better suited for the task
  • States not defined explicitly
  • Instead, can compute a state for any time point, from the values

of the state variables at that time

State Variables

  • A state variable is a partially specified function telling what is true at some time t - cpos(c1) : time → containers U cranes U robots - Tells what c1 is on at time t - rloc(r1) : time → locations - Tells where r1 is at time t
  • Might not ever specify the entire function
  • cpos( c ) refers to a collection of state variables
    • But we’ll be sloppy and just call it a state variable

Temporal Assertions

  • Temporal assertion:
    • Event : an expression of the form x @ t : ( v 1 , v 2 )
      • At time t , x changes from v 1 to v 2 ≠ v 1
    • Persistence condition : x @[ t 1 , t 2 ) : v
      • x = v throughout the interval [ t 1 , t 2 )
    • where
      • t, t 1 , t 2 are constants or temporal variables
      • v , v 1 , v 2 are constants or object variables
  • Note that the time intervals are semi-open
    • Why?

Temporal Assertions

  • Temporal assertion:
    • Event : an expression of the form x @ t : ( v 1 , v 2 )
      • At time t , x changes from v 1 to v 2 ≠ v 1
    • Persistence condition : x @[ t 1 , t 2 ) : v
      • x = v throughout the interval [ t 1 , t 2 )
    • where
      • t, t 1 , t 2 are constants or temporal variables
      • v , v 1 , v 2 are constants or object variables
  • Note that the time intervals are semi-open
    • Why?
    • To prevent potential confusion about x ’s value at the endpoints

Example

• Timeline for rloc(r1):

Inconsistency in the book between Figure 14. and Example 14.

C-consistency

  • A timeline ( F,C ) is c-consistent (chronicle-consistent) if
    • C is consistent, and
    • Every pair of assertions in F are either disjoint or they refer to the same value and/or time points: - If F contains both x @[ t 1 ,t 2 ): v 1 and x @[ t 3 ,t 4 ): v 2 , then C must entail { t 2 ≤ t 3 }, { t 4 ≤ t 1 }, or { v 1 = v 2 } - If F contains both x @ t :( v 1 , v 2 ) and x @[ t 1 ,t 2 ): v , then C must entail { t < t 1 }, { t 2 < t }, { v = v 2 , t 1 = t }, or { t 2 = t , v = v 1 } - If F contains both x @ t :( v 1 , v 2 ) and x @ t' :( v' 1 , v' 2 ), then C must entail { tt' } or { v 1 = v' 1 , v 2 = v' 2 }
  • ( F,C ) is c-consistent iff every timeline in (F,C) is c-consistent
  • The book calls this consistency, not c-consistency
    • But it’s a stronger requirement than ordinary mathematical consistency
  • Mathematical consistency: C doesn’t contradict the separation constraints
  • c-consistency: C must actually entail the separation constraints
    • It’s sort of like saying that ( F,C ) contains no threats

Support and Enablers

  • Let α be either x @ t :( v,v' ) or x @[ t,t' ): v
    • Note that α requires x = v either at t or just before t
  • Intuitively, a chronicle Φ = ( F,C ) supports α if
    • F contains an assertion β that we can use to establish x = v at some time s < t ,
      • β is called the support for α
    • and if it’s consistent with Φ for v to persist over [ s,t ) and for α be true
  • Formally, Φ = ( F,C ) supports α if
    • F contains an assertion β of the form β = x @ s :( w',w ) or β = x @[ s',s ): w , and
    • ∃ separation constraints C' such that the following chronicle is c-consistent:
      • ( F ∪ { x@ [ s,t ): v , α}, CC' ∪ { w=v, s < t })
    • C' can either be absent from Φ or already in Φ
  • The chronicle δ = ({ x@ [ s,t ): v , α}, C' ∪ { w=v, s < t }) is an enabler for α
    • Analogous to a causal link in PSP
  • Just as there could be more than one possible causal link in PSP, there can be more than one possible enabler

Example

  • Let Φ be as shown
  • Then Φ supports α 1 = rloc(r1)@ t :(routes, loc3) in two different ways: - β 1 establishes rloc(r1) = routes at time t 2 - this can support α 1 if we constrain t 2 < t < t 3 - enabler is δ 1 = ({rloc(r1)@[ t 2 , t ):routes, α 1 }, { t 2 < t < t 3 } - β 2 establishes rloc(r1) = routes at time t 4 - this can support α 1 if we constrain t 4 < t < t 5 - enabler is δ 2 = ({rloc(r1)@[ t 4 , t ):routes, α 1 }, { t 4 < t < t 5 }
β 1 = rloc(r1)@ t 2 :(loc1, routes)
β 2 = rloc(r1)@ t 4 :(loc2, routes)

Example

  • Let Φ be as shown
  • Let α 1 be the same as before: α 1 = rloc(r1)@ t :(routes, loc3)
  • Let α 2 = rloc(r1)@[ t',t'' ):loc
  • Then Φ supports{α 1 , α 2 } in four different ways: - As before, for α 1 we can
use either β 1 and δ 1
or β 2 and δ 2
  • We can support α 2 with β 3 = rloc(r1)@ t 5 :(routes, l )
    • Enabler is δ 3 = ({rloc(r1)@[ t 5 , t' ):loc3, α 2 }, { l = loc3, t 5 < t' })
  • Or we can support α 2 with α 1
    • If we supported α 1 with β 1 and enabled it with δ 1 , the enabler for α 2 is δ 4 = ({rloc(r1)@[ t,t' ):loc3, α 2 }, { t < t' < t 3 })
    • If we supported α 1 with β 1 and enabled it with δ 2 , then replace t 3 with t 5 in δ 4

One Chronicle Supporting Another

  • Let Φ ' = ( F',C' ) be a chronicle, and suppose Φ = ( F,C ) supports F'.
  • Let δ 1 , …, δk be all the possible enablers of Φ '
    • For each δi , let δ'i = δ 1 ∪ C'
  • If there is a δ'i such that Φ ∪ δ'i is c-consistent,
    • Then Φ supports Φ ' , and δ'i is an enabler for Φ '
    • If δ'i ⊆ Φ, then Φ entails Φ '
  • The set of all enablers for Φ ' is θ(Φ/Φ ' ) = { δ'i : Φ ∪ δ'i is c-consistent}

Example: Operator for Moving a

Robot

move( t (^) s , t (^) e , t 1 , t 2 , r , l , l' ) =

Applying a Set of

Actions

  • Just like several temporal assertions can support each other, several actions can also support each other - Let π = { a 1 , …, a (^) k } be a set of actions - Let Φπ = ∪ i ( F ( a (^) i ), C ( ai )) - If Φ supports Φπ then π is applicable to Φ - Result is a set of chronicles
  • Example:
    • Suppose Φ asserts that at time t 0 , robots r1 and r2 are at adjacent locations loc1 and loc
    • Let a 1 and a 2 be as shown
    • Then Φ supports { a 1 , a 2 } with l 1 = loc1, l 2 = loc2, l' 1 = loc2, l' 2 = loc1, t 0 < t (^) s < t 1 < t' 2 , t 0 < t' (^) s < t' 1 < t 2

a 1

a 2