Planning CS 510: Intro to AI October 19 th 2017 By: Janith Weerasinghe (bnw37@drexel.edu) Content based on slides from: Rachel Greenstadt & Chris Geib
My Background Using planning and plan recognition in assistive robots/agents. We used plan recognition: To identify what another agent is doing We used planning: To build plans to assist other agents Manage dialogues and interactions Simulated in a virtual environment
Overview Planning Representations Planning as Search GraphPlan Hierarchical Planning
Planning Is the reasoning side of acting. Search in the space of possible states of the world, looking for a sequences of actions that carries you from the initial state to the goal.
Planning Representations Need a compact representation PDDL Planning Domain Definition Language Derived from STRIPS (1970): Cool video of Shakey the robot on YouTube States: Conjunction of fluents that are ground, functionless atoms At Truck 1, Melbourne At Truck 2, Sydney. Closed world assumption: any fluents that are not mentioned are false. Action Schema: Action name and parameter list Drive(truck, from, to) Precondition - what must be true before action executed Effect - how state changes when action executed Goal: A conjunction of positive or negative ground fluents.
Example: Blocks Initial State: On A, Table On(B, Table) On(C, A) Block(A) Block(B) Block(C) Clear(B) Clear(C) Goal: On A, B On(B, C) Actions: Move(b, x, y) Precondition: On b, x Clear(b) Clear(y) Block(b) Block(y) Effect: On b, y Clear x On b, x Clear(y) MoveToTable(b, x) Precondition: On b, x Clear b Block b Effect: On(b, Table) Clear(x) On(b, x)
Example: Logistics p truck1 plane1 truck2 loc1 apt1 apt2 loc2 city1 city2 Initial state: truck truck1, truck truck2, airplane plane1 loc loc1, city1, loc apt1, city1, loc apt2, city2, loc loc2, city2 at p, loc1, at truck1, loc1, at plan1, apt1, at(truck2, loc2) Goal: at(p, loc2)
Example: Logistics p truck1 plane1 truck2 loc1 apt1 apt2 loc2 city1 city2 Actions: load o, v, l : Precondition: at v, l, at(o, l) Effect: at o, l, in(o, v) unload o, v, l : Precondition: in o, v, at v, l Effect: in o, v, at o, l drive t, l1, l2, c : Precondition: truck t, at t, l1, loc l1, c, loc(l2, c) Effect: at t, l1, at(t, l2) fly p, l1, l2 : Precondition: airplane p, at p, l1 Effect: at p, l1, at p, l2
B Exercise C A The monkey-and-bananas problem is faced by a monkey in a laboratory with the bananas hanging out of reach from the ceiling. A box is available that will enable the monkey to reach the bananas if he climbs on it. Initially, the monkey is at A, the bananas at B, and the box at C. The monkey and box have height Low, but if the monkey climbs onto the box he will have height High, the same as the bananas. The actions available to the monkey include Go from one place to another, Push an object from one place to another, ClimbUp onto or ClimbDown from an object, and Grasp or Ungrasp an object. Grasping results in holding the object if the monkey and object are in the same place at the same height.
B Exercise C A Initial state: At Monkey, A At Bananas, B At Box, C Height Monkey, Low Height Box, Low Height Bananas, High Pushable Box Climbable(Box) Actions: Go(x, y): Precond: at Monkey, x Effect: at Monkey, y, at(monkey, x) Push b, x, y : ClimbUp(b): Grasp(o): ClimbDown b : UnGrasp o : Precond: at Monkey, x, at b, x, Pushable(b) Effect: at b, y, at Monkey, y, at Monkey, x, at(b, x) Precond: at Monkey, x, at b, x, Climbable(b) Effect: On Monkey, b, Height Monkey, Low, Height(Monkey, High) Precond: Height Monkey, h, Height o, h, at Monkey, x, at(o, x) Effect: Have(Monkey, o) Precond: On Monkey, b, Height(Monkey, High) Effect: On Monkey, b, Height Monkey, High, Height(Monkey, Low) Precond:Have(Monkey, o) Effect: Have(Monkey, o)
Planning as a Search Consider the task get milk, bananas and a cordless drill. Forward search: Exploring irrelevant actions Huge branching factors Backward Search: Usually lower branching factor than forward search Search space is state sets harder to find heuristics A* Search? Heuristics? Ignore preconditions number of goals Ignore negative effects: no action will ever undo progress made by another action
Planning as a Search Plan Space Search: Partially ordered plans Search node: partial plan Find a flaw in the plan and add action to fix it Standard search algorithms fail miserably: Solutions: Solving relaxed versions of the problem - GraphPlan Add more domain knowledge Hierarchical Planning
GraphPlan 95 Propositional planner (very common now) Build a plan graph. Note: not a state graph. Alternate layers of action nodes and proposition nodes. Algorithm: 1. Build a plan graph of size K. 2. If plan graph doesn t rule out a plan at this length, look for the plan. If found return. 3. If not found build plan graph of depth K + 1 and repeat.
Planning Graph Alternating layers of propositions and actions Link from propositions to an action: preconditions Link from an action to propositions: action effects Initial layer is the initial state. Next layer is all of the actions that are possible. Next layer is the set of propositions that are made true/false. etc. Maintains lists of conditions that can t be true at the same time and actions that can t be executed at the same time
Planning Graph Plan graph at depth K allows for K action windows. Allows for the potential of multiple parallel actions. S 0 A 1 S 1 A 2 S 3
Planning Graph: Mutex Actions Actions are marked as mutex if: Inconsistent Effects: They have conflicting effects. A and A Interference: One deletes the precondition of the other. Competing Needs: They depend on predicates that are mutex at the previous layer.
Planning Graph: Mutex Propositions Propositions are mutex if: They are negations of each other. A and A Inconsistent Support: All actions that achieve them at the previous level are pairwise mutex.
Example: Dinner Date Problem Preparing a surprise date for one s sleeping sweetheart. Involves making dinner, wrapping a present and taking out age Cook: Pre: clean Wrap: Pre: Carry: Pre: Dolly: Pre: Effect: dinner Effect: present Effect: clean Effect: Initial State: clean Goal: dinner present
Initial State clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
Initial State clean cook wrap carry dolly clean dinner present Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly clean
clean cook wrap carry dolly clean dinner present Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly clean
clean cook wrap carry dolly clean dinner present Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly clean
clean cook wrap carry dolly clean dinner present Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly clean
clean clean cook wrap carry dolly dinner present Candidate plans: {cook, wrap, carry} {cook, wrap, dolly} clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
clean clean clean cook cook wrap wrap carry dolly dinner present carry dolly dinner present clean clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
clean clean clean cook cook wrap wrap carry dolly dinner present carry dolly dinner present clean clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
clean clean clean cook cook wrap wrap carry dolly dinner present carry dolly dinner present clean clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
clean clean clean cook cook wrap wrap carry dolly dinner present carry dolly dinner present clean clean Action Precond Effect Cook clean dinner Wrap present Carry clean Dolly
Limitations of GraphPlan Propositional Has been extended to deal with: conditional effects disjunctive preconditions. Universal qualified preconds and effects (sort of)
Hierarchical Planning Add information about how to accomplish tasks (ABSTRIPS 74, NONLIN 76). Method: <task-name, preconditions, partially ordered sequence of subtasks or actions> ex: Task name: Preconds: Subtasks: deliver_by_truck p, dest {truck t, loc src, city, at t, src, at(p, src)} [load p, t, src, drive t, src, dest, city, unload(p, t, dest)] Planner unifies unbound variables Preconditions have to be true for the method to be used. Elements of the decomposition can be basic actions or other method names. (recursive)
Hierarchical Planning Example p truck1 plane1 truck2 loc1 city1 apt1 Initial State: truck(truck1), truck(truck2), airplane(plane1), loc(loc1, city1), loc(apt1, city1), Goal: [At(p, loc2)] Methods: At(p, l) Preconds: at p, src, loc src, city, loc(l, city) Subtasks: [deliver_by_truck(p, l)] apt2 city2 loc2 Preconds: at p, src, loc src, city1, loc l, city2, different city1, city2, Subtasks: [deliver_by_truck p, src, apt1,fly(plane, apt1, apt2), deliver_by_truck p, apt2, l ]
Hierarchical Planning Notice that precondition based method decomposition eliminates searching the full plan tree. Huge number of real world applications use hierarchical planning. NASA space rovers and deep space probes Oil refineries Science experiment planning Modern hierarchical planner: SHOP2
Question Recall the blocks world example: Goal: On A, B On(B, C) Can a non-interleaved planner solve this? This is called the Sussman Anomaly