Forward-Looking Agents: Scheduling and Planning

PSU CS441/541 Lecture 8
November 15, 2001

• Scheduling
  • Task: thing to be done
  • Task properties
    • Label
    • Duration
    • Resource Use
  • Schedule: assign times to tasks, optimizing
    • Time
    • Resource consumption
  • Constraints
    • Precedence = task ordering (end-start, etc.)
    • Resource availability (capacity, consumable, etc.)
    • Release times and deadlines
  • Solution via search
    • Transformation to SAT
    • Direct Methods
      • Systematic search
      • Local search
  • MD4
    • Aircraft assembly problem: 575 tasks, 14 resources
    • Results
      • MS Project ``Leveller'': 80 days
      • State of art mid 90s: 40-50 days
      • CIRL best fully automatic: 30 days
      • Perhaps $1M/day!
• Planning
  • Action: situation -> situation
    • change of situation usually means timestep
      • not always: ring puzzle example
      • timestep vs. flow of real time
    • situation is some kind of theory (world state)
    • two special situations
      • initial situation: what you've got, where you are
      • goal situation: what you want, where you want to be
    • action is something changing situation
      • preconditions: in what situations can action be executed?
      • effects: how does action change situation?
  • Planning: finding sequence of actions taking initial situation to goal situation
    • planning is not execution: failure means different things in these stages
    • software compilation as planning
  • Where do plans come from?
    • no planning (= ``reactive planning''): just do what is ``known'' to be correct in each situation
      • pluses: fast, realistic
      • minuses: doesn't work, not obvious when it doesn't work
      • again, planning v. execution
    • programming: follow a canned plan, maybe with options
    • pathfinding search: find general-purpose optimal plan given always-executable action
    • monotonic, theorem proving in sitcalc: see below
    • nonmonotonic reasoning: default to persists (but beware the Yale Shooting Problem again)
    • STRIPS & friends: see below
    • hierarchy: plan (using above) at increasing levels of detail
      • macros
      • repair
  • Situation calculus and theorem proving
    • situation calculus (from Ginsberg, c.f. Nilsson)
      • take statement about action:
        move(b,l) -> loc(b,l)
      • repair to include situation:
        move(b,l,s) -> loc(b,l,next(s))
      • connect extra function to action:
        loc(b, l, result(move(b, l), s)) [*]
      • add preconditions:
        clear(b,s) and clear(l,s) -> *
      • alternatively, lift s (reify): holds(clear(b),s) and holds(clear(l),s) ->
        holds(loc(b,l),result(move(b,l),s))
      • Note can quantify over sentences in FOL:
        exists s . forall f . not holds(f, s)
    • basic tp planner
      • write problem in sitcalc (FOL)
      • resolve to proof problem is solvable
      • this yields plan
    • problems with tp planning
      • frame problem: must axiomatize persistence
      • qualification problem: must axiomatize all preconditions
        • domain axioms: forall b s . not holds(loc(b, b), s)
        • scoping: potato in tailpipe
      • ramification problem: must axiomatize all effects
        • briefcase problem
        • spraygun problem
      • tractability: tp impossibly slow
  • STRIPS and the Blocks World
    • STRIPS formulation
      • situation: set of fluents (logical statements that may hold)
      • initial situation: what fluents hold initially
      • goal situation: fluents that must hold (not hold) finally
      • action
        • precondition: fluents that must hold (not hold) to execute
        • effects:
          • fluents ``added'' (made to hold) by execution
          • fluents ``deleted'' (made to not hold) by execution
          • other fluents persist
    • Power of STRIPS
      • directly attacks frame problem
      • not too relevant to qualification, ramification
      • tractability: PSPACE-complete (Towers of Hanoi)
    • STRIPS folklore
      • The ``blocks world''
        • formal setting
          • predicate logic
          • objects: table T, blocks A, B, C,...
          • fluents: on(x,y), clear(x)
          • actions (2!):
            • move(x,y): clear(x), clear(y), on(x,z) -> add on(x,y), add clear(z), del on(x,z), del clear(y)
            • drop(x): clear(x), on(x,z) -> del on(x,z), add on(x,T), add clear(z)
          • initial situation: clear(T), stacks...
          • goal situation: total? partial?
        • the Sussman Anomaly
          
          • problem

            		A
                C     to    B
                A B         C
            	      

          • cannot solve either A on B or B on C first!
          • (XXX can solve C on table first)
        • tractability
          • satisfying: easy via unstack-stack (but most planners do not do this!)
          • optimal (shortest plan): NP-complete! (Gupta and Nau)
    • STRIPS planning algorithms
      • forward/backward state space (e.g. GPS)
      • POCL
        • means-end analysis
        • causal links
        • partial-ordered plans
        • complexity of linearization: NP hard
    • Macro Planning
      • Hierarchical Planning
      • Plan Learning
  • Bart's Dissertation
    • Observation 1: POCL is effectively backward planning
    • Observation 2: literature says backward planning is better
    • Result 1: any STRIPS problem S can be converted into a STRIPS problem S' such that a forward step in S is a backward step in S' (and vice versa)
    • Observation 3: result 1 says obs 2 is hooey
    • Result 2: artificial STRIPS problems can be constructed which are trivial to search forward and NP-hard to search backward (and vice versa)
    • Result 3: result 2 was used to show that obs 1 is (roughly) correct
    • Observation 4: result 2 says obs 2 is hooey
    • Conclusions:
      • STRIPS is ``too expressive''
      • state space planning is fast = good
      • smart people are still confused about planning