Distributed Systems. Silvia Rossi 081. Intelligent

Transcription

1 Distributed Systems Silvia Rossi 081 Intelligent

2 30% for attending classes Grading 30% for presenting a research paper 40% for writing and discussing paper (design of a multi-robot system), pages.

3 E.D. Durfee, V.R. Lesser Next week paper Partial global planning: A coordination framework for distributed hypothesis formation. IEEE Trans. On Systems, Man, and Cybernetics, 21(5), Sept. 1991, p

4 Lynne E. Parker Next-next week paper Adaptive Heterogeneous Multi-Robot Teams Neurocomputing 28, 1998, pp.75-92

5 DISTRIBUTED CSP

6 Distributed CSP Each variable is owned by a different agent. The goal is still to find a global variable assignment that meets the constraints, but each agent decides on the value of his own variable with relative autonomy. While he does not have a global view, each agent can communicate with his neighbors in the constraint graph. 6

7 Distributed CSP A distributed algorithm for solving a CSP has each agent engage in some protocol that combines local computation with communication with his neighbors. A good algorithm ensures that such a process terminates with a legal solution (or with a realization that no legal solution exists) and does so quickly. 7

8 Asynchronous Backtracking Algorithm Assumptions: A total ordering on the agents. Each binary constraint is known to both the constrained agents and is checked in the algorithm by the agent with the lower priority between the two. A link in the constraint network is always directed from an agent with higher priority to an agent with lower priority. 8

9 Communication model Processes communicate by sending messages. A process can send messages to other processes iff the process knows the addresses/identifiers of other processes. The delay in delivering a message is finite, though random. F or the transmission between any pair of processes, messages are received in the order in which they were sent. 9

10 Asynchronous Backtracking Algorithm Agents instantiate their variables concurrently and send their assigned values to the agents that are connected to them by outgoing links. All agents wait for and respond to messages. After each update of his assignment, an agent sends his new assignment along all outgoing links. An agent who receives an assignment, tries to find an assignment for his variable that does not violate a constraint with the assignment he received. 10

11 Asynchronous Backtracking Algorithm ok? messages are messages carrying an agent s variable assignment. A i places the received assignment in a data structure called agent_view. A i checks if his current assignment is still consistent with his agent_view. If it is consistent, A i does nothing. If not, then A i searches his domain for a new consistent value. If he finds one, he assigns his variable that value and sends ok? messages to all lower-priority Otherwise, A i backtracks. 11

12 Asynchronous Backtracking Algorithm The backtrack operation is executed by sending a Nogood message. Nogood is an inconsistent partial assignment; The Nogood consists of A i s agent_view; The Nogood is sent to the agent with the lowest priority among the agents whose assignments are included in the inconsistent tuple. A i who sends a Nogood message to agent A j assumes that A j will change his assignment. Therefore, A i removes from his agent_view the assignment of A j ; A i makes an attempt to find an assignment for A j s variable that is consistent with the updated agent_view. 12

13 Asynchronous Backtracking Algorithm when received (Ok?, (Aj, dj )) do add (Aj, dj ) to agent_view check_agent_view when received (Nogood, nogood) do add nogood to Nogood list forall (Ak, dk) nogood, if Ak is not a neighbor of Ai do add (Ak, dk) to agent_view request Ak to add Ai as a neighbor add Ak as a neighbor check_agent_view 13

14 Asynchronous Backtracking Algorithm procedure check_agent_view when agent_view and current_value are inconsistent do if no value in Di is consistent with agent_view then backtrack else select d Di consistent with agent_view current_value d send (ok?, (Ai, d)) to lowerpriority neighbors 14

15 Asynchronous Backtracking Algorithm procedure backtrack nogood some inconsistent set, using hyperresolution or similar procedure if nogood is the empty set then broadcast to other agents that there is no solution terminate this algorithm else select (Aj, dj) nogood where Aj has the lowest priority in nogood send (Nogood, nogood) to Aj remove (Aj, dj) from agent_view check_agent_view 15

16 Asynchronous Backtracking Algorithm Complete 16

17 Asynchronous Backtracking Algorithm {red, blue} X 1 X 2 {red, blue} X 1 X 2 X 1 X 3 X 2 X 3 X 3 {red, blue}

18 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2, blue)} X 1 X 2 X 3 {cur_val,(x 3, blue)}

19 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} (ok?,(x1,blue)) {cur_val,(x 2, blue)} X 1 X 2 (ok?,(x1,blue)) (ok?,(x2,blue)) X 3 {cur_val,(x 3,blue)}

20 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,blue)} {loc_view,(x 1,blue)} X 1 X 2 X 3 {cur_val,(x 3,blue)} {loc_view,(x 1, blue),(x 2,blue)}

21 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,blue)} {loc_view,(x 1,blue)} X 1 X 2 check_agent_view X 3 {cur_val,(x 3,blue)} {loc_view,(x 1, blue),(x 2,blue)}

22 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,blue)} {loc_view,(x 1,blue)} X 1 X 2 X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,blue)}

23 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,red)} {loc_view,(x 1,blue)} X 1 X 2 (ok?,(x2,red)) X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,blue)}

24 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,red)} {loc_view,(x 1,blue)} X 1 X 2 X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

25 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,red)} {loc_view,(x 1,blue)} X 1 X 2 check_agent_view X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

26 Asynchronous Backtracking Algorithm {cur_val,(x 1, blue)} {cur_val,(x 2,red)} {loc_view,(x 1,blue)} X 1 X 2 (nogood, (X1,blue), (X2,red)) X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

27 Asynchronous Backtracking Algorithm {cur_val,(x {cur_val,(x 1, blue)} 2,red)} {loc_view,(x 1,blue)} {nogood,(x1,blue), (X2,red)} X 1 X 2 X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

28 Asynchronous Backtracking Algorithm {cur_val,(x {cur_val,(x 1, blue)} 2,red)} {loc_view,(x 1,blue)} (nogood, (X1,blue)) {nogood,(x1,blue), (X2,red)} X 1 X 2 X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

29 {cur_val,(x 1, blue)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm X 1 X 2 {cur_val,(x 2,red)} {loc_view,(x 1,blue)} {nogood,(x1,blue), (X2,red)} X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

30 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm (ok?,(x1,red)) X 1 X 2 {cur_val,(x 2,red)} {loc_view,(x 1,blue)} {nogood,(x1,blue), (X2,red)} (ok?,(x1,red)) X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

31 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm (ok?,(x1,red)) X 1 X 2 {cur_val,(x 2,red)} {loc_view,(x 1,blue)} {nogood,(x1,blue), (X2,red)} (ok?,(x1,red)) X 3 {cur_val,(x 3,red)} {loc_view,(x 1, blue),(x 2,red)}

32 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm X 1 X 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} X 3 {cur_val,(x 3,blue)} {loc_view,(x 1, red),(x 2,red)}

33 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm X 1 X 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} (ok?,(x2,blue)) X 3 {cur_val,(x 3,blue)} {loc_view,(x 1, red),(x 2,blue)}

34 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm X 1 X 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} (nogood, (X1,red), (X2,blue)) X 3 {cur_val,(x 3,blue)} {loc_view,(x 1, red),(x 2,blue)}

35 {cur_val,(x 1, red)} {nogood,(x1,blue)} Asynchronous Backtracking Algorithm X 1 X 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} {nogood,(x1,red), (X2,blue)} X 3 {cur_val,(x 3,red)} {loc_view,(x 1, red),(x 2,blue)}

36 Asynchronous Backtracking Algorithm {cur_val,(x 1, red)} {nogood,(x1,blue)} (nogood, (X1,red)) X 1 X 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} {nogood,(x1,red), (X2,blue)} X 3 {cur_val,(x 3,red)} {loc_view,(x 1, red),(x 2,blue)}

37 Asynchronous Backtracking Algorithm {cur_val,(x 1, red)} {nogood,(x1,blue)} {nogood,(x1,red)} X 1 X {nogood{}} 2 {cur_val,(x 2,blue)} {loc_view,(x 1,red)} {nogood,(x1,blue), (X2,red)} {nogood,(x1,red), (X2,blue)} X 3 {cur_val,(x 3,red)} {loc_view,(x 1, red),(x 2,blue)}

38 Asynchronous Backtracking Algorithm {cur_val,(x 1 =blue)} {cur_val,(x 2 =blue)} X 1 X 2 X 3 {cur_val,(x 3 =blue)}

39 39

40 40

41 41

42 The four queens problem 42

43 The four queens problem A1 = 1 A2 =1 A3 1 A4 sends a Nogood to A3 and removes the assignment of A3 from his Agent_View. Then, he assigns the value 2 43

44 The four queens problem A1 = 1 A2 3 44

45 The four queens problem A1 = 1 A2 = 4 A3 4 45

46 The four queens problem A1 = 1 A2 = 4 A3 2 46

47 The four queens problem 47

48 The four queens problem 48

49 The four queens problem 49

50 The four queens problem 50

51 PLANNING

52 Linear Planning Limitations Assumes goal independence and goals are dealt with linearly: it does not work on next goal until a plan for the current one is found. Incompleteness: there is a solution but the planner can t find it. Non-optimality: can t find optimal solution (Sussman s Anomaly).

53 State-space planning We initially have a space of situations (where you are, what you have, etc.) The plan is a solution found by searching through the situations to get to the goal A progression planner searches forward from initial state to goal state A regression planner searches backward from the goal Ideally this leads to reduced branching you are only considering things that are relevant to the goal

54 Plan-space planning An alternative is to search through the space of plans, rather than situations. Start from a partial plan which is expanded and refined until a complete plan that solves the problem is generated. Refinement operators add constraints to the partial plan and modification operators for other changes. We can still use STRIPS-style operators: Op(ACTION: RightShoe, PRECOND: RightSockOn, EFFECT: RightShoeOn) Op(ACTION: RightSock, EFFECT: RightSockOn) Op(ACTION: LeftShoe, PRECOND: LeftSockOn, EFFECT: LeftShoeOn) Op(ACTION: LeftSock, EFFECT: leftsockon) could result in a partial plan of [RightShoe, LeftShoe]

55 Partial-order planning A linear planner builds a plan as a totally ordered sequence of plan steps A non-linear planner (aka partial-order planner) builds up a plan as a set of steps with some temporal constraints constraints of the form S1<S2 if step S1 must comes before S2. One refines a partially ordered plan (POP) by either: adding a new plan step, or adding a new constraint to the steps already in the plan. A POP can be linearized (converted to a totally ordered plan) by topological sorting

56 Least commitment Non-linear planners embody the principle of least commitment only choose actions, orderings, and variable bindings that are absolutely necessary, leaving other decisions till later avoids early commitment to decisions that don t really matter A linear planner always chooses to add a plan step in a particular place in the sequence A non-linear planner chooses to add a step and possibly some temporal constraints

57 Non-linear plan A non-linear plan consists of (1) A set of steps {S 1, S 2, S 3, S 4 } Each step has an operator description, preconditions and post-conditions (2) A set of causal links { (S i,c,s j ) } Meaning a purpose of step S i is to achieve precondition C of step S j (3) A set of ordering constraints { S i <S j } if step S i must come before step S j

58 Causal Link: Action Ac (consumer) has precondition Q that is established in the plan by Ap(producer). 58

59 Step At threatens link (Ap, Q, Ac) if: 1. At has (not Q) as an effect, and 2. At could come between Ap and Ac, i.e. O u (Ap< At< Ac) is consistent 59

60 Soluzione Una soluzione è un piano completo e consistente In un piano completo ogni precondizione di un passo viene raggiunta da qualche altro passo. Un passo raggiunge una condizione se la condizione è uno degli effetti del passo e se nessun altro passo può eliminare la condizione. In un piano consistente non c è alcuna contraddizione nell ordinamento o nei vincoli sui legami

61 The initial plan Every plan starts the same way S1:Start Initial State Goal State S2:Finish

62 InitialPlan For uniformity, represent initial state and goal with two special actions: Start: no preconditions, initial state aseffects, must be the first step in the plan. Finish: no effects Goals as preconditions must be the last step in the plan.

63 Trivial example Operators: Op(ACTION: RightShoe, PRECOND: RightSockOn, EFFECT: RightShoeOn) Op(ACTION: RightSock, EFFECT: RightSockOn) Op(ACTION: LeftShoe, PRECOND: LeftSockOn, EFFECT: LeftShoeOn) Op(ACTION: LeftSock, EFFECT: leftsockon) S1:Start RightShoeOn ^ LeftShoeOn S2:Finish Steps: {S1:[Op(Action:Start)], S2:[Op(Action:Finish, Pre: RightShoeOn^LeftShoeOn)]} Links: {} Orderings: {S1<S2}

64 Solution Start Left Sock Right Sock Left Shoe Right Shoe Finish

65 Linearizzazioni

66 POP POP is sound and complete POP Plan is a solution if: All preconditions are supported (by causal links), i.e., no open conditions. No threats Consistent temporal ordering By construction, the POP algorithm reaches a solution plan 66

67 Example Op(ACTION: START, PRECONDITION: nil, EFFECT: AT(HOME) and SELLS(STORE,DRILL) and SELLS(SUPER,MILK) and SELLS(SUPER, BREAD)) Op(ACTION: FINISH, PRECONDITION: HAVE(DRILL) and HAVE(MILK) and HAVE(BREAD) and AT(HOME), EFFECT: nil) Op(ACTION: GO(x), PRECONDITION: AT(x), EFFECT: AT(y) and not AT(x)) Op(ACTION: BUY(x), PRECONDITION: AT(SHOP) and SELLS(SHOP,x), EFFECT: HAVE(x)) 67

68 InitialPlan 68

69 69

70 70

71 71

72 Corretto? 72

73 Piani con condizioni 73

74 Demotion 74

75 Promotion 75

76 76

77 77

78 Piano Totale 78

79 Heuristics Heuristics for selecting plans: Number of steps N Unsolved preconditions OP Often uses an algorithm A * with heuristics: f(p)=n(p) + OP(P) 79

80 Non-linear plan A non-linear plan consists of (1) A set of steps {S 1, S 2, S 3, S 4 } Each step has an operator description, preconditions and post-conditions (2) A set of causal links { (S i,c,s j ) } Meaning a purpose of step S i is to achieve precondition C of step S j (3) A set of ordering constraints { S i <S j } if step S i must come before step S j A non-linear plan is completeiff Every step mentioned in (2) and (3) is in (1) If S j has prerequisite C, then there exists a causal link in (2) of the form (S i,c,s j ) for some S i If (S i,c,s j ) is in (2) and step S k is in (1), and S k threatens (S i,c,s j ) (makes C false), then (3) contains either S k <S i or S j >S k

81 Consistent Plan Consistent plan: No cycles in the ordering constraint; No conflicts with the causal links. A consistent plan with no open precondition is a solution 81

82 1) The initial plan contains Start and Finish the ordering constraint Start < Finish, no causal links all the preconditions in Finish as open preconditions. 82

83 2) The successor function arbitrarily picks one open precondition p on an action B and generates a successor plan for every possible consistent way of choosing an action A that achieves p. Consistency is enforced as follows: 1. The causal link A ->p B and the ordering constraint A < B are added to the plan. Action A may be an existing action in the plan or a new one. If it is new, add it to the plan and also add Start < A and A < Finish. 83

84 2) The successor function arbitrarily picks one open precondition p on an action B and generates a successor plan for every possible consistent way of choosing an action A that achieves p. 2. Resolve conflicts between the new causal link and all existing actions. A conflict between A ->p B and C is resolved by making C occur at some time outside the protection interval B < C C < A We add successor states for either or both if they result in consistent plans 84

85 3) The goal test checks whether a plan is a solution to the original planning problem. Because only consistent plans are generated, the goal test just needs to check that there are no open preconditions. 85

86 POP 86

87 Nonlinear Planning P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY P: ON(B,A) ON(C,B) -: +:

88 Open preconditions The plan is incomplete P: HOLDING(B) CLEAR(A) -: CLEAR(A) HOLDING(B) +: ON(B,A) CLEAR(B) HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY P: ON(B,A) ON(C,B) -: +:

89 P: HOLDING(B) CLEAR(A) -: CLEAR(A) HOLDING(B) +: ON(B,A) CLEAR(B) HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) P: HOLDING(C) CLEAR(B) -: CLEAR(B) HOLDING(C) +: ON(C,B) CLEAR(C) HANDEMPTY P: ON(B,A) ON(C,B) -: +:

90 P: HOLDING(B) CLEAR(A) -: CLEAR(A) HOLDING(B) +: ON(B,A) CLEAR(B) HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) P: ON(B,A) ON(C,B) -: P: HOLDING(C) +: CLEAR(B) -: CLEAR(B) HOLDING(C) +: ON(C,B) CLEAR(C) HANDEMPTY Pickup(C)

91 Other possible achiever Pickup(B) Achievers Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Threat Stack(C,B) P: CLEAR(B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

92 Pickup(B) P: CLEAR(B) Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) P: CLEAR(B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

93 A consistent plan is one in which there is no cycle and no conflict between achievers and threats Pickup(B) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY A conflict can be eliminated by constraining the ordering among the actions or by adding new actions Note the similarity with constraint propagation Stack(B,A) Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

94 Pickup(B) P: HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

95 Pickup(B) P: HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) Pickup(C) P: HANDEMPTY P: ON(B,A) ON(C,B) -: +:

96 ~ Most-constrained-variable heuristic in CSP choose the unachieved precondition that can be satisfied in the fewest number of ways ON(C,TABLE) Pickup(B) P: HANDEMPTY CLEAR(B) ON(B,TABLE) Stack(B,A) P: HOLDING(B) CLEAR(A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Stack(C,B) P: HOLDING(C) CLEAR(B) Pickup(C) P: HANDEMPTY CLEAR(C) ON(C,TABLE) P: ON(B,A) ON(C,B) -: +:

97 Pickup(B) Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Putdown(C) Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

98 Pickup(B) Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Unstack(C,A) Putdown(C) Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

99 Pickup(B) P: HANDEMPTY Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Unstack(C,A) Putdown(C) Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

100 Pickup(B) Stack(B,A) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Unstack(C,A) Putdown(C) Stack(C,B) Pickup(C) P: ON(B,A) ON(C,B) -: +:

101 Pickup(B) P: -: +: ON(A,TABLE) ON(B,TABLE) ON(C,A) CLEAR(B) CLEAR(C) HANDEMPTY Unstack(C,A) Putdown(C) P: HOLDING(C) P: HANDEMPTY CLEAR(B) ON(B,TABLE) The plan is complete because every precondition of every step is added by some previous step, and no intermediate step deletes it P: HANDEMPTY CLEAR(C) ON(C,A) Stack(B,A) P: HOLDING(B) CLEAR(A) Stack(C,B) P: HOLDING(C) CLEAR(B) Pickup(C) P: HANDEMPTY CLEAR(C) ON(C,TABLE) P: ON(B,A) ON(C,B) -: +:

102 (R&N:11. ) FROM STRIPS TO PDDL 102

103 PDDL Planning Domain DefinitionLanguage The STRIPS language is very simple The language was extended, resulting into ADL, which incorporates among others: universal and existential quantification Conditional effects A common language to all planners is needed for problem and domain specification, and PDDL has been created There are many versions up to version PDDL 2.1 (there are successors), that allows among others: specification of execution cost for operators Variable types for operators Continuous change 103

104 PDDL - Predicates Predicate defines the property of an object, which can be TRUE of FALSE Example: Cloudy Big Yellow Use in PDDL Example: (Yellow T-Shirt) 104

105 Variables / Types PDDL?iterator int?bigstructure mystruct In PDDL data types are not predefined :types int mystruct 105

106 (and ( Yellow TShirt ) ( Big Shoes ) ) ( not ( Yellow Shoes ) ) ( and ( Yellow TShirt ) ( not ( Yellow Shoes ) ) ) PDDL not and or 106

107 PDDL - ForAll Let the all TShirts in this world be Yellow (:typestshirt) (:predicates (Yellow?things TShirt) ) ( forall (?things TShirt) (Yellow?things) ) This implies that the property Yellow should be true for all objects in the domain that are of type TShirt 107

108 PDDL - Exists If there exists even one Yellow shoe (:typesshoes) (:predicates (Yellow?things Shoes) ) ( exists (?things Shoes) (Yellow?things) ) This evaluates to TRUE if there exists one or more objects which has the property Yellow. 108

109 PDDL Domain Definition Requirements packages to be used Types user defined types Constants constant to be used in this domain Predicates definition of truth statements Action - operators Preconditions predicates that must be TRUE before this operator is applied Effects predicates that become true after this operator is applied 109

110 Logistic Domain (define (domain logistics) (:requirements :strips :typing) (:types truck airplane-vehicle package vehicle-physobj airport location -place city place physobj-object) (:predicates (in-city?loc -place?city -city) (at?obj-physobj?loc-place) (in?pkg -package?veh -vehicle))...) 110

111 Operators (:action load-truck...) (:action load-airplane...) (:action unload-truck...) (:action unload-airplane...) (:action drive-truck...) (:action fly-airplane :parameters (?p -airplane?s -airport?d -airport) :precondition (and (at?p?s) (not (=?s?d))) :effect (and (at?p?d) (not (at?p?s)))) 111

112 PDDL Problem Definition Define the problem to be solved Initial State define predicates which are true at the beginning of the problem Goal State - define predicates which are true at the end of the problem 112

113 Problem Definition (define (problem log1) (:domain logistics) (:objects (ob0 ob1 ob2 -package) (c2 c1 c0 -city) (po2 po1 po0 -location) (a2 a1 a0 -airport) (tr2 tr1 tr0 -truck) (pl1 pl2 -airplane)) (:init (in-city a2 c2) (in-city po2 c2) (at tr2 po2) (in-city a1 c1) (in-city po1 c1) (at tr1 po1) (in-city a0 c0) (in-city po0 c0) (at tr0 po0) (at ob1 a1) (in ob0 pl0) (in ob2 tr1) (at pl2 a1) (at pl1 a2)) (:goal (at-obj ob1 a2))) 113

114 RicherOperators (define (domain BriefcaseDomain) (:requirements :strips :equality :typing :conditional-effects) (:types location physicalobject) (constants (Briefcase physicalobject) (predicates (in?x -physicalobject?l -location) (into?x?y -physicalobject) ) (:action MoveBriefcase :parameters (?m?l location) :precondition (and (in Briefcase?m) (not (=?m?l))) :effect (and (in Briefcase?l) (not (en Briefcase?m)) (forall (?z) (when (and (into?z Briefcase ) (not (=?z Briefcase ))) (and (in?z?l) (not (in?z?m)))))) ) 114

115 (R&N:11.4,11.5,11.6) MORE ON GRAPHPLAN 115

116 Planning graph Directed, leveled graph with alternating layers of nodes Odd layers represent candidate propositions that might hold at time I Even layers represent candidate actions that we might possibly execute at time I, including maintain actions We can only execute one real action at any step, but the data structure keeps track of which actions are possibilities

117 Basic idea Construct a graph that encodes constraints on possible plans Use this planning graph to constrain search for a valid plan Planning graph can be built for each problem in relatively short time

118 Problem handled by GraphPlan STRIPS operators: conjunctive preconditions, no conditional or universal effects, no negations Finds shortest plans (by some definition) Sound, complete and will terminate with failure if there is no plan.

119 Planning graph Nodes divided into levels, arcs go from one level to the next For each time period, a state level and an action level Arcs represent preconditions, adds and deletes

120 What actions and what literals? Add an action in level Ai if all its preconditions are present in level Pi Add a precondition in level Pi if it is the effect of some action in level Ai-1 (including no-ops frame problem) Level P0 has all the literals from the initial state

121 Simple NASA domain Literals: at X L X is at location L fuel R rocket has fuel in X R X is in the rocket Actions: load X L load X onto rocket at location L (X and R must be at L) unload X L unload X from rocket at location L (R must be at L, X must be in L) move L L move rocket from L to L (R must be at L and have fuel; moving uses up the fuel) Graph representation: Solid black lines: preconditions/effects Dotted red lines: negated preconditions/effects

122 Example planning graph at A L load A L at A L load A L at A L at B L load B L at B L load B L at B L at R L move L P at R L move L P at R L fuel R fuel R fuel R unload A P at A P in A R in B R move P L in A R in B R unload B P at B P at R P at R P Props Time 1 Actions Time 1 Props Time 2 Actions Time 2 Props Time 3 Actions Time 3 Goals

123 Exclusion relations (mutexes) Two actions (or literals) are mutually exclusive at some stage if no valid plan could contain both. Can quickly find and mark some mutexes: Inconsistent Effects: one action negates an effect of the other Interference: One of the effects of one action is the negation of the precondition of the other Competing needs: If some precond of one action is mutex with a precond of the other action Inconsistent support: Two propositions are mutex if all ways of creating them both are mutex

124 Example planning graph at A L at B L at R L fuel R load A L at A L nop load B L at B L nop move L P at R L nop fuel R Inconsistent nop effects in A R in B R load A L nop load B L nop move L P nop nop nop move P L nop at A L at B L at R L fuel R in A R in B R unload A P unload B P at A P at B P at R P nop at R P Props Time 1 Actions Time 1 Props Time 2 Actions Time 2 Props Time 3 Actions Time 3 Goals

125 Example planning graph at A L at B L at R L fuel R load A L nop load B L nop move L P nop nop at A L at B L at R L fuel R in A R in B R load A L nop load B L nop move L P nop nop nop move P L nop at A L at B L at R L fuel R in A R in B R unload A P unload B P at A P at B P at R P nop at R P Props Time 1 Actions Time 1 Props Time 2 Actions Time 2 Props Time 3 Actions Time 3 Goals

126 A slightly different planning graph at A L at B P at R L fuel R Interference load A L nop nop move L P nop nop at A L at B P at R L fuel R in A R load A L nop load B P nop move L P nop nop nop move P L nop at A L at B L at R L Competing needs fuel R unload A P in A R unload B P in B R at A P at B P Inconsistent support at R P nop at R P Props Time 1 Actions Time 1 Props Time 2 Actions Time 2 Props Time 3 Actions Time 3 Goals

127 Mutex: Summary Actions A,B are mutex at level i if no valid plan could possibly contain both at i: inconsistent effects: A s effects negate one of B s effects interference: A s effects delete one of B s preconditions, or vice-versa competing needs: A & B have mutex preconditions Propositions P,Q are mutex at level i if no valid plan could possibly contain both at i inconsistent support: If at i, all ways to achieve P exclude all ways to achieve Q

128 GraphPlan algorithm (without termination) Grow the planning graph (PG) until all goals are reachable and not mutex. (If PG levels off first, fail) Search the PG for a valid plan If none found, add a level to the PG and try again

129 Valid plans A valid plan is a planning graph where: Actions at the same level don t interfere (delete each other s preconditions or add effects) Each action s preconditions are made true by the plan Goals are satisfied

130 Extending the planning graph Action level: For each possible instantiation of each operator (including no-ops), add if all of its preconditions are in the previous level and no two are mutex. Proposition level: Add all effects of actions in previous level (including no-ops). Mark pairs of propositions mutex if all ways to create one are mutex of all ways to create the other

131 Creating the planning graph is usually Theorem 1: fast The size of the t-level PG and the time to create it are polynomial in t, n (= number of objects), m (= number of operators) and p (= propositions in the initial state)

132 Searching for a plan Backward chain on the planning graph Complete all goals at one level before going back: At each level, pick a subset of actions to achieve the goals that are not mutex. Their preconditions become the goals at the earlier level. Build subset by picking each goal and choosing an action to add. Use one already selected if possible. Do forward checking on remaining goals.

133 SATplan Formulate the planning problem as a CSP Assume that the plan has k actions Create a binary variable for each possible action a: Action(a,i) (TRUE if action a is used at step i) Create variables for each proposition that can hold at different points in time: Proposition(p,i) (TRUE if proposition p holds at step i)

134 Constraints Only one action can be executed at each time step (XOR constraints) Constraints describing effects of actions Persistence: if an action does not change a proposition p, then p s value remains unchanged A proposition is true at step i only if some action (possibly a maintain action) made it true Constraints for initial state and goal state

135 Planning as CSP Constraint-satisfaction problem (CSP) Given: set of discrete variables, domains of the variables, and constraints on the specific values a set of variables can take in combination, Find an assignment of values to all the variables which respects all constraints Compile the planning problem as a constraintsatisfaction problem (CSP) Use the planning graph to define a CSP

136 Representing the Planning Graph as a CSP

137 Summary: classical planning Representations in planning Representation of action: preconditions + effects Approaches: State-space search Plan-space search Constraint-based search