Planning

PSU CS441/541 Lecture 7
November 6, 2000

• Finally, Applications
  • Next 3 weeks
    • planning
    • machine learning
    • natural language
  • Concurrently, project
    • Lines Of Action
    • will be substantial in-class time
    • code requirements
    • tournament offline: *not* graded
• Planning and Action
  • 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)
      • 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
      • tractability: tp slow
      • 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
• 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)
  • Declarativity of STRIPS
    • ``nondeclarative''?? p. 282

      Because the planning process is procedural, it is reasonable to think of the STRIPS description as nondeclarative.

    • difficult to integrate with declarative databases, yes
    • actions not as expressive
  • 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
    • POCL
      • means-end analysis
      • causal links
      • partial-ordered plans
      • complexity of linearization: NP hard
• 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