Flat Tire Example• init: {tire(flat),tire(spare),at(flat,axle),at(spare,trunk)}• goal: at(spare,axle)• operators:

– Remove(obj,loc)• precond: at(obj,loc)• effect: at(obj,loc),at(obj,ground)

– PutOn(t,axle)• precond: tire(t),at(t,ground),at(flat,axle)• effect: at(t,ground), at(flat,axle)

– LeaveOvernight• precond:• effect:

at(spare,ground), at(spare,trunk), at(spare,axle)at(flat,ground), at(flat,trunk), at(flat,axle)

SatPlan• propositionalization

– create separate literals for each ground instance of each fluent for each state index

• e.g. on_a_b_1 , on_a_b_2 , on_a_b_3, gripper_empty_1, gripper_empty_2...– create propositions for action taken at step t: pickup_a_b_1...

• convert axioms in FOL to propositional sentences (one copy for each time index)– possibility axioms: s,a Prec(s)Poss(a,s)

• gripper_empty_1clear_a_1 poss_pickup_a_1• gripper_empty_2clear_a_2 poss_pickup_a_2• gripper_empty_1clear_b_1 poss_pickup_b_1

– successor axioms: s Poss(a,s)Eff(result(a,s))• poss_pickup_a_1 pickup_a_1 holding_a_2gripper_empty_2

– frame axioms: s Flu(s)aCancelingActionsFlu(result(a,s))• on_b_c_1 poss_pickup_a_1 on_b_c_2

• use a satisfiability solved like DPLL or WalkSat– query: poss_on_a_b_1? poss_on_a_b_2? poss_on_a_b_3?– the truth values of action propositions in the model tell you the plan

• pickup_c_a_1=T, puton_c_table_2=T, pickup_b_table_3=T, puton_b_a_4=T

more complex planning domains

• Plan Abstraction– the idea: simplify problem by temporarily “dropping”

easy preconditions• defer solving them till later• make high-level plan, then fill in details

– system: ABSTRIPS– example:

• make a high-level plan for solving 8-puzzle where you assume you can move pieces without empty space

7 2 4

5 1 6

8 3

7 2 4

5 1 3

8 6

• Hierarchical Task Networks (HTNs)– plan library

• a list of standard operating procedures, written out in procedural syntax• ExecuteMissionWithHelicopters:

– preconds: haveHelicopters, knowTargetCoordinates– steps: {FlyFlightPlan,Engage,ReturnToBase}

– high-level operators vs. low-level operators– expansion, multiple choices of how to achieve subtask– still a problem of sub-goal interactions– system: STEAM

• plan monitoring and repair– what if action in step i might fail?– non-deterministic domains (most in real-world)– at each step, check pre-conditions– if expected conditions not satisfied, re-invoke planner

• costly to re-plan from scratch• search for modification of existing plan, e.g. re-do previous action or

insert steps to get back on track

• contingent planning: – a plan with a branch in it– include sensor actions to sense state– algorithm to create such plans to achieve goals

• goal regression? • universal planners: generate state-action tables, finite-state machines

{pickupA, senseHolding, while not holding do {pickupA,senseHolding}}{swingAx, senseTree, while TreeStanding do {swingAx,senseTree}}

enter room

sense light

off(light)? flip(switch)

next action

• plan optimization– use heuristics to search for a plan that minimizes cost

of operators, or time...– start by finding any plan that achieves goals, and then

apply incremental modifications

• related to scheduling– critical path method (CPM) – compute [ES,LS]

– resource constraints (e.g. 1 machine to add engine)

Robotics• basic approach:

– navigation in configuration space – find path from initial configuration to goal configuration

– # dimensions = degrees of freedom (parameters that can be controlled, e.g. joint angles)

– find path; avoid collisions with “obstacles”