Week 4: Introduction to AI Planning Lee McCluskey, room 2/07

Artform Research Group Overview Intelligent (virtual) Agents are defined as.. Software programs capable of autonomous behaviour in dynamic unpredictable environments THAT IS – THEY CAN  PLAN to solve goals  Execute and monitor plans  Communicate/co-operate  Sense/Observe/Gather information  Adapt and Learn

Artform Research Group Example Applications AUTOMATIC CONTROL: of industrial processes, traffic, industrial robots, spacecraft, underwater robots Eg NASA’s Remote Agent Experiment CRISIS MANAGEMENT: in military applications, accidents, evacuations, forest fire fighting USER SUPPORT: for project planning, web search, web service composition SIMULATION: games software AI Planning has to be cost effective - makes plans more quickly than people? more reliable plans? more efficient plans?

Artform Research Group r1 r3 r5 r7 r4 r2 bracelet locket ring +Sword +Cudgel Key-1 r6 p45 Key-2 troll orc p57 p25 p35 p24 p47 Sample Goal = Boromir kills Troll Aragorn acquiresThe Ring p56 Aragorn Boromir +Knife shield spell golem lock-2 lock-1 p67 p12 8: MOVE_INTO_ROOM P67 BOROMIR R6 R7 9: MOVE_TO_PASSAGE P67 BOROMIR R7 10: EXCHANGE BOROMIR R7 P67 LOCKET KEY1 11: MOVE_INTO_ROOM P67 BOROMIR R7 R6 12: MOVE_TO_PASSAGE P56 BOROMIR R6 13: MOVE_INTO_ROOM P56 BOROMIR R6 R5 14: UNLOCK_PASSAGE BOROMIR R5 P25 KEY1 15: MOVE_TO_PASSAGE P25 ARAGORN R5 16: MOVE_INTO_ROOM P25 ARAGORN R5 R2 17: FIGHT_AND_KILL_MONSTER ARAGORN R2 P12 SHIELD SWORD ORC 18: MOVE_TO_PASSAGE P12 ARAGORN R2 19: MOVE_INTO_ROOM P12 ARAGORN R2 R1 20: PICK_UP_TREASURE ARAGORN R1 RING 0: MOVE_TO_PASSAGE P67 BOROMIR R7 1: MOVE_TO_PASSAGE P45 ARAGORN R4 2: MOVE_INTO_ROOM P45 ARAGORN R4 R5 3: GET_PROTECTION ARAGORN R5 SHIELD 4: MOVE_INTO_ROOM P67 BOROMIR R7 R6 5: KILL_SLEEPING_MONSTER BOROMIR R6 P56 KNIFE TROLL 6: PICK_UP_TREASURE BOROMIR R6 LOCKET 7: MOVE_TO_PASSAGE P67 BOROMIR R6 PLAN generated by AI is shown opposite (its not optimal!)

Artform Research Group Automated (AI) Planning The scope of ‘AI Planning’ is the synthesis (generation) and execution of PLANS. That is, AI Planners reason with actions and generate plans. NECESSARY INPUT: A representation of ACTIONS, OBJECTS, GOALS, INITIAL STATE (possibly: resources, agents, constraints,..) OUTPUT FROM AI PLANNING: PLANS - (partial) orderings of actions guaranteed to achieve the goals when applied to the initial state

Artform Research Group Planning vs Scheduling Although these activities are similar, the difference is identified as follows: “Scheduling is the allocation of actions (processes) to resources (processors) whereas.. Planning involves deciding which particular actions to use and in which order to use them in”

Artform Research Group Usual (abstract) Architecture of Planners DOMAIN MODEL PLANNING ENGINE INTERFACE

Artform Research Group Simple Planning Domain Models Domain models typically contain 1. Types or classes of objects 2. Actions (represented by Operators) that change state of objects A TASK associated with a domain model is defined by: 1. An INITIAL STATE 2. GOAL(S)

Artform Research Group Environmental Assumptions In simple ‘applications’ we ASSUME: finite world (rather than infinite) deterministic actions (rather than non- deterministic) completely observable (rather than partially observable) instantaneous (rather than durative actions) unchanging, closed world (rather than open, dynamic world) infinite resources

Artform Research Group Environmental Assumptions The “FRAME PROBLEM” is a source of concern in AI planning – the logic of stating what is not affected by an action Often we assume an action satisfies the RULE of DEFAULT PERSISTENCE: If an action specification does not specify that a fact / object changes then it does not change.. things persist by default

Artform Research Group Languages for writing Domain Models… Literal Based: The “Planner Domain Definition Language” (PDDL) is the most commonly used language to communicate Planning Domain Models and associated Tash Descriptions Object-Centred: At Huddersfield we have pioneered the use of “object based” languages – the simple blocks world domain model is object centred.

Artform Research Group The Modelling of States A STATE represents a situation or snapshot of an application. This is sometimes called a WORLD STATE, STATES of a literal-based domain model are most simply defined as conjunctions of ground predicates (like a relational database for each state) In a object-centred domain model, as well as world states, dynamic OBJECTS have their own state also (sometimes called ‘substate’). A world state therefore conisists of a conjunction of the substates of each object.

Artform Research Group The Modelling of Actions This is CENTRAL to planning. In a literal based domain model, actions are modelled as PRE and POST conditions in the form of PRECONDITION SET ADD SET DELETE SET In an object-centred domain model, we use a more structured form: PREVAIL CONDITION NECESSARY OBJECT TRANSITIONS CONDITIONAL OBJECT TRANSITIONS

Artform Research Group Operator Schema - exs op(pick_up_off_table(X,G,T), [ ], [trans(X, [clear(X),on_table(X,T)],[lifted(X)]), trans(G, [empty(G)],[grips(G,X)]) ], [ ]). op(move(R,A,B), % prevail [condition(A,[can_fly(A,B)])], % necessary [ trans(R,[position(R,A), fuel_full(R)], [position(R,B), fuel_empty(R)] ) ], % conditional [ ]). Name+parameters Prevail Necessary Transitions Conditional Transitions

Artform Research Group Problems (aka Tasks) task1 :- start( [ condition(a,[on_table(a,t)]) ], [ state(g, [empty(g)]), state(a, [clear(a),on(a,b)]), state(b, [on_table(b,t)]), state(c,[clear(c), on_table(c,t)]) ] ). task1 :- start( [ condition(r2,[position(r2,paris)]) ], [ state(c1,[at(c1,london)]), state(c2,[at(c2,london)]), state(c3,[at(c3,london)]), state(c4,[at(c4,london)]), state(r1,[position(r1,london),fuel_full(r1)]), state(r2,[position(r2,london),fuel_full(r2)]), state(london, [can_fly(london,paris),can_fly(london,jfk)]), state(paris, [can_fly(paris,london),can_fly(paris,jfk)]), state(jfk, [can_fly(jfk,paris),can_fly(jfk,london)]) ] ). Goal Condition(s) Initial State

Artform Research Group PLANS Are what planners generate. They are orders of instantiated operator schemas. They should be: CORRECT - preconditions are satisfied COMPLETE - achieve the final goal OPTIMAL - no shorter or more efficient plan exists A simple task or planning problem is defined by: - An INITIAL STATE - A GOAL - A set of OPERATOR schema

Artform Research Group PLANS- examples [condition(a,[on_table(a,t2)]), condition(b,[on(b,c)]), condition(d,[lifted(d)])] achieved by sequence [pick_up_off_block(a,b,g,t1), put_down_on_table(a,g,t2), pick_up_off_table(b,g,t1), put_down_on_block(b,c,g,t), pick_up_off_table(d,g,t)] [condition(c1,[at(c1,jfk)]),condition(c2,[at(c2,paris)])] achieved by sequence [load(c1,r1,london),move(r1,london,jfk), load(c2,r2,london),move(r2,london,paris), unload(c2,r2,paris),unload(c1,r1,jfk)]

Artform Research Group Conclusions Plan domain model languages are logic-like formal specification languages for capturing the physics of a domain Traditionally planning domains contain things like objects, states, operators, constraints.

Artform Research Group Resource For one of the fastest and most used planners in the world (FF) google “FF planner homepage download”