33
Planning CS 510: Intro to AI October 19 th 2017 By: Janith Weerasinghe ([email protected] ) Content based on slides from: Rachel Greenstadt & Chris Geib

Planning - College of Computing & Informaticsgreenie/cs510/Planning_CS510.pdfcity2 plane1 truck2 Hierarchical Planning •Notice that precondition based method decomposition eliminates

  • Upload
    hathuan

  • View
    215

  • Download
    1

Embed Size (px)

Citation preview

PlanningCS 510: Intro to AI

October 19th 2017

By: Janith Weerasinghe ([email protected])

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• 𝐴𝑡 𝑇𝑟𝑢𝑐𝑘1 , 𝑀𝑒𝑙𝑏𝑜𝑢𝑟𝑛𝑒 ∧ 𝐴𝑡 𝑇𝑟𝑢𝑐𝑘2, 𝑆𝑦𝑑𝑛𝑒𝑦 .• Closed world assumption: any fluents that are not mentioned are false.

• Action Schema:• Action name and parameter list 𝐷𝑟𝑖𝑣𝑒(𝑡𝑟𝑢𝑐𝑘, 𝑓𝑟𝑜𝑚, 𝑡𝑜)• 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: • 𝑂𝑛 𝐴, 𝑇𝑎𝑏𝑙𝑒 ∧ 𝑂𝑛(𝐵, 𝑇𝑎𝑏𝑙𝑒) ∧ 𝑂𝑛(𝐶, 𝐴) ∧ 𝐵𝑙𝑜𝑐𝑘(𝐴) ∧𝐵𝑙𝑜𝑐𝑘(𝐵) ∧ 𝐵𝑙𝑜𝑐𝑘(𝐶) ∧ 𝐶𝑙𝑒𝑎𝑟(𝐵) ∧ 𝐶𝑙𝑒𝑎𝑟(𝐶)

• Goal: • 𝑂𝑛 𝐴, 𝐵 ∧ 𝑂𝑛(𝐵, 𝐶)

• Actions:• 𝑴𝒐𝒗𝒆(𝒃, 𝒙, 𝒚)

Precondition: 𝑂𝑛 𝑏, 𝑥 ∧ 𝐶𝑙𝑒𝑎𝑟(𝑏) ∧ 𝐶𝑙𝑒𝑎𝑟(𝑦) ∧ 𝐵𝑙𝑜𝑐𝑘(𝑏) ∧ 𝐵𝑙𝑜𝑐𝑘(𝑦)Effect: 𝑂𝑛 𝑏, 𝑦 ∧ 𝐶𝑙𝑒𝑎𝑟 𝑥 ∧ ¬𝑂𝑛 𝑏, 𝑥 ∧ ¬𝐶𝑙𝑒𝑎𝑟(𝑦)

• 𝑴𝒐𝒗𝒆𝑻𝒐𝑻𝒂𝒃𝒍𝒆(𝒃, 𝒙)• Precondition: 𝑂𝑛 𝑏, 𝑥 ∧ 𝐶𝑙𝑒𝑎𝑟 𝑏 ∧ 𝐵𝑙𝑜𝑐𝑘 𝑏• Effect: 𝑂𝑛(𝑏, 𝑇𝑎𝑏𝑙𝑒) ∧ 𝐶𝑙𝑒𝑎𝑟(𝑥) ∧ ¬𝑂𝑛(𝑏, 𝑥)

Example: Logistics

• Initial state:• 𝑡𝑟𝑢𝑐𝑘 𝑡𝑟𝑢𝑐𝑘1 , 𝑡𝑟𝑢𝑐𝑘 𝑡𝑟𝑢𝑐𝑘2 , 𝑎𝑖𝑟𝑝𝑙𝑎𝑛𝑒 𝑝𝑙𝑎𝑛𝑒1𝑙𝑜𝑐 𝑙𝑜𝑐1, 𝑐𝑖𝑡𝑦1 , 𝑙𝑜𝑐 𝑎𝑝𝑡1, 𝑐𝑖𝑡𝑦1 , 𝑙𝑜𝑐 𝑎𝑝𝑡2, 𝑐𝑖𝑡𝑦2 , 𝑙𝑜𝑐 𝑙𝑜𝑐2, 𝑐𝑖𝑡𝑦2𝑎𝑡 𝑝, 𝑙𝑜𝑐1 , 𝑎𝑡 𝑡𝑟𝑢𝑐𝑘1, 𝑙𝑜𝑐1 , 𝑎𝑡 𝑝𝑙𝑎𝑛1, 𝑎𝑝𝑡1 , 𝑎𝑡(𝑡𝑟𝑢𝑐𝑘2, 𝑙𝑜𝑐2)

• Goal:• 𝑎𝑡(𝑝, 𝑙𝑜𝑐2)

p truck1

apt1loc1

city1

loc2apt2

city2

plane1truck2

Example: Logistics

• Actions:• 𝑙𝑜𝑎𝑑 𝑜, 𝑣, 𝑙 :

• Precondition: 𝑎𝑡 𝑣, 𝑙 , 𝑎𝑡(𝑜, 𝑙)

• Effect: ¬𝑎𝑡 𝑜, 𝑙 , 𝑖𝑛(𝑜, 𝑣)

• 𝑢𝑛𝑙𝑜𝑎𝑑 𝑜, 𝑣, 𝑙 :• Precondition: 𝑖𝑛 𝑜, 𝑣 , 𝑎𝑡 𝑣, 𝑙

• Effect: ¬𝑖𝑛 𝑜, 𝑣 , 𝑎𝑡 𝑜, 𝑙

p truck1

apt1loc1

city1

loc2apt2

city2

plane1truck2

• 𝑑𝑟𝑖𝑣𝑒 𝑡, 𝑙1, 𝑙2, 𝑐 :• Precondition: 𝑡𝑟𝑢𝑐𝑘 𝑡 , 𝑎𝑡 𝑡, 𝑙1 , 𝑙𝑜𝑐 𝑙1, 𝑐 , 𝑙𝑜𝑐(𝑙2, 𝑐)

• Effect: ¬𝑎𝑡 𝑡, 𝑙1 , 𝑎𝑡(𝑡, 𝑙2)

• fly 𝑝, 𝑙1, 𝑙2 :• Precondition: 𝑎𝑖𝑟𝑝𝑙𝑎𝑛𝑒 𝑝 , 𝑎𝑡 𝑝, 𝑙1

• Effect: ¬𝑎𝑡 𝑝, 𝑙1 , 𝑎𝑡 𝑝, 𝑙2

Exercise

• 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 ClimbDownfrom 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.

A

B

C

Exercise

• Initial state:𝐴𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝐴 ∧ 𝐴𝑡 𝐵𝑎𝑛𝑎𝑛𝑎𝑠, 𝐵 ∧ 𝐴𝑡 𝐵𝑜𝑥, 𝐶 ∧ 𝐻𝑒𝑖𝑔ℎ𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝐿𝑜𝑤 ∧ 𝐻𝑒𝑖𝑔ℎ𝑡 𝐵𝑜𝑥, 𝐿𝑜𝑤∧ 𝐻𝑒𝑖𝑔ℎ𝑡 𝐵𝑎𝑛𝑎𝑛𝑎𝑠, 𝐻𝑖𝑔ℎ ∧ 𝑃𝑢𝑠ℎ𝑎𝑏𝑙𝑒 𝐵𝑜𝑥 ∧ Climbable(𝐵𝑜𝑥)

• Actions:

A

B

C

• 𝑮𝒐(𝒙, 𝒚):

• 𝑷𝒖𝒔𝒉 𝒃, 𝒙, 𝒚 :

• 𝑪𝒍𝒊𝒎𝒃𝑼𝒑(𝒃):

• 𝑮𝒓𝒂𝒔𝒑(𝒐):

• 𝑪𝒍𝒊𝒎𝒃𝑫𝒐𝒘𝒏 𝒃 :

• 𝑼𝒏𝑮𝒓𝒂𝒔𝒑 𝒐 :

Precond: 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥Effect: 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑦 , ¬𝑎𝑡(𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥)

Precond: 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥 , 𝑎𝑡 𝑏, 𝑥 , 𝑃𝑢𝑠ℎ𝑎𝑏𝑙𝑒(𝑏)Effect: 𝑎𝑡 𝑏, 𝑦 , 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑦 , ¬𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥 , ¬𝑎𝑡(𝑏, 𝑥)

Precond: 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥 , 𝑎𝑡 𝑏, 𝑥 , 𝐶𝑙𝑖𝑚𝑏𝑎𝑏𝑙𝑒(𝑏)Effect: 𝑂𝑛 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑏 , ¬𝐻𝑒𝑖𝑔ℎ𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝐿𝑜𝑤 ,𝐻𝑒𝑖𝑔ℎ𝑡(𝑀𝑜𝑛𝑘𝑒𝑦,𝐻𝑖𝑔ℎ)

Precond: 𝐻𝑒𝑖𝑔ℎ𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, ℎ , 𝐻𝑒𝑖𝑔ℎ𝑡 𝑜, ℎ , 𝑎𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑥 , 𝑎𝑡(𝑜, 𝑥)Effect: 𝐻𝑎𝑣𝑒(𝑀𝑜𝑛𝑘𝑒𝑦, 𝑜)

Precond: 𝑂𝑛 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑏 , 𝐻𝑒𝑖𝑔ℎ𝑡(𝑀𝑜𝑛𝑘𝑒𝑦, 𝐻𝑖𝑔ℎ)Effect: ¬𝑂𝑛 𝑀𝑜𝑛𝑘𝑒𝑦, 𝑏 , ¬𝐻𝑒𝑖𝑔ℎ𝑡 𝑀𝑜𝑛𝑘𝑒𝑦, 𝐻𝑖𝑔ℎ ,𝐻𝑒𝑖𝑔ℎ𝑡(𝑀𝑜𝑛𝑘𝑒𝑦, 𝐿𝑜𝑤)

Precond:𝐻𝑎𝑣𝑒(𝑀𝑜𝑛𝑘𝑒𝑦, 𝑜)Effect: ¬𝐻𝑎𝑣𝑒(𝑀𝑜𝑛𝑘𝑒𝑦, 𝑜)

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 𝐾.

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 𝐾 + 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 𝐾 allows for 𝐾 action windows.

• Allows for the potential of multiple parallel actions.

𝑆0 𝐴1 𝑆1 𝐴2 𝑆3

Planning Graph: Mutex Actions

• Actions are marked as mutex if:• Inconsistent Effects: They have conflicting effects. 𝐴 and ¬𝐴

• 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. 𝐴 and ¬𝐴

• 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 garbage

• Cook: Pre: clean Effect: dinner

• Wrap: Pre: quiet Effect: present

• Carry: Pre: garb Effect: ¬ garb ∧ ¬ clean

• Dolly: Pre: garb Effect: ¬ garb ∧ ¬ quiet

• Initial State: clean ∧ garb ∧ quiet

• Goal: ¬ garb ∧ dinner ∧ present

clean

garb

quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

Initial State

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

Initial State

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

Candidate plans:{cook, wrap, carry}{cook, wrap, dolly}

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

clean

garb

quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

Action Precond Effect

Cook clean dinner

Wrap quiet present

Carry garb ¬garb∧ ¬clean

Dolly garb ¬garb∧ ¬quiet

cook

wrap

carry

dolly

clean

garb

quiet

dinner

present

¬clean

¬ garb

¬ quiet

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: [𝑙𝑜𝑎𝑑 𝑝, 𝑡, 𝑠𝑟𝑐 , 𝑑𝑟𝑖𝑣𝑒 𝑡, 𝑠𝑟𝑐, 𝑑𝑒𝑠𝑡, 𝑐𝑖𝑡𝑦 , 𝑢𝑛𝑙𝑜𝑎𝑑(𝑝, 𝑡, 𝑑𝑒𝑠𝑡)]

• 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

• Initial State: • 𝑡𝑟𝑢𝑐𝑘(𝑡𝑟𝑢𝑐𝑘1), 𝑡𝑟𝑢𝑐𝑘(𝑡𝑟𝑢𝑐𝑘2), 𝑎𝑖𝑟𝑝𝑙𝑎𝑛𝑒(𝑝𝑙𝑎𝑛𝑒1), 𝑙𝑜𝑐(𝑙𝑜𝑐1, 𝑐𝑖𝑡𝑦1), 𝑙𝑜𝑐(𝑎𝑝𝑡1, 𝑐𝑖𝑡𝑦1), …

• Goal: [𝐴𝑡(𝑝, 𝑙𝑜𝑐2)]

• Methods:• 𝐴𝑡(𝑝, 𝑙)

• Preconds: 𝑎𝑡 𝑝, 𝑠𝑟𝑐 , 𝑙𝑜𝑐 𝑠𝑟𝑐, 𝑐𝑖𝑡𝑦 , 𝑙𝑜𝑐(𝑙, 𝑐𝑖𝑡𝑦)• Subtasks: [𝑑𝑒𝑙𝑖𝑣𝑒𝑟_𝑏𝑦_𝑡𝑟𝑢𝑐𝑘(𝑝, 𝑙)]

• Preconds: 𝑎𝑡 𝑝, 𝑠𝑟𝑐 , 𝑙𝑜𝑐 𝑠𝑟𝑐, 𝑐𝑖𝑡𝑦1 , 𝑙𝑜𝑐 𝑙, 𝑐𝑖𝑡𝑦2 , 𝑑𝑖𝑓𝑓𝑒𝑟𝑒𝑛𝑡 𝑐𝑖𝑡𝑦1, 𝑐𝑖𝑡𝑦2 , …• Subtasks: [𝑑𝑒𝑙𝑖𝑣𝑒𝑟_𝑏𝑦_𝑡𝑟𝑢𝑐𝑘 𝑝, 𝑠𝑟𝑐, 𝑎𝑝𝑡1 ,𝑓𝑙𝑦(𝑝𝑙𝑎𝑛𝑒, 𝑎𝑝𝑡1, 𝑎𝑝𝑡2), 𝑑𝑒𝑙𝑖𝑣𝑒𝑟_𝑏𝑦_𝑡𝑟𝑢𝑐𝑘 𝑝, 𝑎𝑝𝑡2, 𝑙 ]

p truck1

apt1loc1

city1

loc2apt2

city2

plane1 truck2

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: 𝑂𝑛 𝐴, 𝐵 ∧ 𝑂𝑛(𝐵, 𝐶)

• Can a non-interleaved planner solve this?

• This is called the Sussman Anomaly