4.2 Creating Abstract Planning Operators
4.2.3 Algorithms
For use in the algorithms that follow, we define a summary information of a program as follows.
Definition 13. (Summary Information) A summary information of a program P (relative to a plan-
library and an action-library) is a tuplehP, φ, Lmt, Lmni, where φ is a precondition of P if P is an event-goal program, and φ = ǫ otherwise; Lmt is a set of must literals of P; and Lmnis a set of
mentioned literals of P.
In order to compute the must literals of a program, we need to take into account the possibility of literals brought about by the program’s execution conflicting with other literals brought about by the execution. More specifically, we need to take into account situations in which literals are
definitely undone (or must undone) and possibly undone (or may undone) within a program. Since,
unlike the work of (Clement et al., 2007), we do allow variables in literals, event-goals and actions, finding such conflicts involves reasoning about values assigned at runtime to variables in literals.
For example, take the following plan-body:
. . . ;
+Colour(Block1, Blue);
?(Block(b)∧ Colour(b, Blue));
−Colour(b, Blue); +Colour(b, Red).
This plan adds a belief that Block1 is blue, then binds the variable b to some blue block (possibly Block1), removes the belief that b is blue and adds the belief that b is red. The literals Colour(Block1, Blue) and Colour(b, Red) are both asserted in the body of this plan. However, only Colour(b, Red) can be considered a definite effect, as Colour(Block1, Blue) will be true only if b is not bound to Block1. Therefore,
Colour(Block1, Blue) is only a possible effect.
We say that a literal l is must undone in some program P if the negation of the literal is a must literal of some atomic program mentioned in P. Note that, although l can be any literal and P can be any program (i.e., sequence of atomic programs), we will only need to use this definition to determine whether a literal belonging to some atomic program P′in a plan-body is must undone in the sequence of atomic programs after P′. Formally, given a program P and the set ∆ of summary information of all atomic programs mentioned in P, a literal l is must undone in P relative to ∆, denotedMust-Undone(l, P, ∆), if there exists an atomic program P′ mentioned in P and a literal
l′ ∈ Lmt, withhP′, φ, Lmt, Lmn
i ∈ ∆, such that l = l′, i.e., l is the complement of l′.5 Similarly,
we say that a literal l is may undone in a program P if there is a literal l′ that is a mentioned (or must) literal of some atomic program in P such that l′ may become the negation of l due to variable substitutions at runtime. More precisely, given a program P and the set ∆ of summary information of all atomic programs mentioned in P, a literal l is may undone in P relative to ∆, denotedMay-Undone(l, P, ∆), if there exists an atomic program P′mentioned in P, substitutions
θ, θ′, and a literal l′ ∈ Lmn, with
hP′, φ, Lmt, Lmn
i ∈ ∆, such that lθ = l′θ′.
Next, we move on to the main algorithms for computing the summary information of pro- grams, that is, algorithms 4.1, 4.2 and 4.3. We will use Figure 4.4 and Table 4.1 as a running example.
Algorithm 4.1: Given a plan-library and an action-library, Algorithm 4.1 computes the sum-
mary information of each event-goal mentioned in the plan-library. In a nutshell, the algorithm works bottom up, by summarising first the leaf-level entities of the plan-library, that is, primi- tive programs (line 1), and then repetitively summarising plan-bodies using Algorithm 4.2, and event-goals using Algorithm 4.3, in increasing order of their levels of abstraction (lines 3-8). The algorithm terminates after all top level event-goals (i.e., those with the highest rank) have been
Algorithm 4.1Summarise(Π, Λ)
Input: Plan-library Π and action-library Λ, where a ranking exists for Π. Output: Set ∆ of summary information of event types mentioned in Π.
1: ∆⇐ {hP, ǫ, post(P, Λ), post(P, Λ)i | P is a primitive program mentioned in Π}
//Summarising primitive programs; recallpost(P, Λ)is a set of literals
2: E⇐ {e(~x) | e is an event-goal mentioned in Π} //Construct the set of event types inΠ
3: for i⇐ min({RΠ(e)| e ∈ E}) to max({RΠ(e)| e ∈ E}) do //RecallRΠ(e)is the rank ofe
4: for each e∈ E such that RΠ(e) = i do
5: ∆⇐ ∆ ∪ {Summarise-Plan-Body(P, Π, Λ, ∆)| e′: ψ← P ∈ Π, e′= eθ}
//Summary information of event-goals mentioned inPis available due to ranking
6: ∆⇐ ∆ ∪ {Summarise-Event(e, Π, ∆)}
7: end for
8: end for
9: return ∆\ {u | u ∈ ∆, u is not the summary information of an event-goal}
summarised.
In lines 2-8, all event-goal types mentioned in the plan-library are obtained and then sum- marised in increasing order of their rank. This way, there is a guarantee that whenever the summary information of an event-goal or plan-body needs to be computed, all the summary information of associated less abstract entities has already been computed. Finally, before returning the computed set ∆ in line 9, we remove all the summary information tuples of entities other than event-goals, since we are only interested in the summary information of event-goals.
Observe that, although according to Definition 12 (Must Literal), any literal that holds at the end of all successful executions of a program is considered a must literal of the program (i.e., even if a literal holds at the end of such an execution only due to preconditions that require it to hold), the algorithm only classifies as must literals those that are actually brought about during the program’s execution, i.e., literals in postconditions of primitive programs. This is because our aim is to create operators from event-goals, and consequently, literals that are required to hold due to preconditions do not need to be added to postconditions of operators.
For example, consider an event-goal e that is handled by one plan-rule e : p ←
act, where the operator associated with action act does not mention proposition p.
Observe that p is a must literal of e because it holds at the end of all successful executions of e. However, since p is not actually brought about by the execution of e — i.e., p is only required by some precondition — we do not include p in the postcondition of the operator corresponding to e.
Algorithm 4.2Summarise-Plan-Body(P, Π, Λ, ∆in)
Input: Plan-body P; plan-library Π, where a ranking exists for Π; action-library Λ; and the set ∆in of summary information of (i) primitive programs mentioned in P, and (ii) event types mentioned in P.
Output: The summary information of P.
1: ∆⇐ ∆in∪ {h!e(~x), φ, Lmt, Lmniθ | !e(~t) occurs in P, he(~x), φ, Lmt, Lmni ∈ ∆in, e(~t) = e(~x)θ}
//Variables inLmnmust be renamed appropriately
2: Suppose P = P1; P2; . . . ; Pn 3: LmtP ⇐ {l | l ∈ Lmt, hP i, φ, Lmt, Lmni ∈ ∆, i ∈ {1, . . . , n}, ¬May-Undone(l, Pi+1; . . . ; Pn, ∆)} 4: LmnP ⇐ {l | l ∈ Lmt∪ Lmn, hPi, φ, Lmt, Lmni ∈ ∆, i ∈ {1, . . . , n}, ¬Must-Undone(l, Pi+1; . . . ; Pn, ∆)} 5: return hP, ǫ, Lmt P, LmnP i
Algorithm 4.2: This algorithm summarises the given plan-body with respect to the given plan-
library, action-library, and set ∆in of summary information. The algorithm first obtains the sum- mary information of each event-goal program mentioned in the plan-body, from the already avail- able summary information in ∆inof the corresponding event-goal types (line 1). Next, the algor- ithm computes the set of must literals (LmtP) and the set of mentioned literals (LmnP ) of the given plan-body P, by determining, from the must and mentioned literals of atomic programs mentioned in P, which literals will definitely be met and which literals will possibly be met on the successful executions of P (lines 3 and 4). More specifically, a must literal l of an atomic program Pi men- tioned in P = P1; . . . ; Pnis considered a must literal of P only if l is not may (or must) undone in
Pi+1; . . . ; Pn(line 3). If this is not the case, then l is considered a mentioned literal of P, provided
l is not must undone in Pi+1; . . . ; Pn (line 4). The reason we do not summarise mentioned literals that are must undone is to avoid losing completeness. This is shown in the following example.
Suppose the algorithm does summarise mentioned literals that are must undone. Next, consider the plan-library below. Observe the following: the postcondition of
a0and a2is p; the postcondition of a1is¬p; and the postcondition of a3is q. e0 R0 → a0 p e1 OR R1 → a1 ¬p a2 p R2 a3 q
Furthermore, observe that:
1. p is a must literal of R1;
2. q is a must literal of R2;
3. e1 has no must literals—there are no literals that are guaranteed to hold irre-
spective of the plan-rule selected to achieve e1;
4. ¬p (brought about by a1) is a mentioned literal of R1; and
5. ¬p is also mentioned literal of e1.
Observe, further, that, according to the algorithm, the literal p brought about by a0
is not a must literal of R0 because it may be undone by mentioned literal ¬p of e1. However, in reality, although R1 does bring about literal ¬p, action a2 of R1
later adds p. This means that p is indeed a must literal of R0. The algorithm will
recognise this (i.e., it will be more complete) if (i) the algorithm recognises that mentioned literal¬p is must undone in R1, and (ii) the algorithm excludes¬p from
the set of mentioned literals of R1.
Then, the literals added to set LmnP by the algorithm are not just mentioned literals, but what we call may literals, that is, mentioned literals of atomic programs occurring in the given plan-body that are not must undone later in the plan-body. It is important to note, however, that our may literals are still a weaker notion than the corresponding notion of a may summary condition in (Clement et al., 2007), because it is still possible that our may literals are never asserted, due to interactions which ensure that the particular plan-body which asserts a may literal can never be applied.
To illustrate how Algorithm 4.2 works, consider Figure 4.4 and Table 4.1. Ob- serve that literals HaveMoistureContent(dst) and HaveParticleSize(dst) are must literals of plan-body P5 because (i) they are must literals of primitive actions GetMoistureContent(dst) and GetSoilParticleSize(dst), and (ii) they are neither must
undone nor may undone in P5.
Next, consider plan-body P4. Observe that, although literal HaveSoilSample(dst) is a must literal of primitive action PickSoilSample(dst),
Therefore, HaveSoilSample(dst) is neither a may nor must literal of the plan-body. Literal ¬HaveSoilSample(dst) is a must literal of P4, along with the must literals HaveMoistureContent(dst) and HaveParticleSize(dst) belonging to event-goal AnalyseSoilSample(dst).
Finally, consider plan-body P0. Observe that literal Calibrated is a may literal
of the plan-body because the literal is a may literal of event-goal Navigate(src, dst), and the literal is not must undone in PerformSoilExperiment(dst). On the other hand, observe that although literal At(dst) (respectively ¬At(src)) is a
must literal of event-goal Navigate(src, dst), this literal is only a may literal of P0, because ¬At(dst) (respectively At(ldr)) is a may literal of event-goal PerformSoilExperiment(dst), and consequently, At(dst) (respectively ¬At(src)) is
ExploreSoilLocation(src, dst) R0 −→ Navigate(src, dst) OR R1 −→ CalibrateViaGPS Move(src, dst) R2 Move(src, dst) PerformSoilExperiment(dst) R3 −→ ObtainSoilResults(dst) R4 −→ PickSoilSample(dst) AnalyseSoilSample(dst) R5 −→ GetMoistureContent(dst) GetSoilParticleSize(dst) DropSoilSample(dst) TransmitSoilResults(dst) OR R6 −→
EstablishConnection SendResults(dst) BreakConnection
R7 −→ Navigate(dst, ldr) UploadResults(dst) event-goal plan-rule action
Figure 4.4: A slightly modified and extended version of the Mars Rover agent of Figure 4.2. This version has options for navigating and transmitting results, and if the lander is not within range, transmitting involves navigating to the lander and uploading results.
Program Must Literals May Literals
CalibrateViaGPS CA -
Move(src, dst) ¬At(src), At(dst) -
PickSoilSample(dst) HSS(dst) - DropSoilSample(dst) ¬HSS(dst) - GetMoistureContent(dst) HMC(dst) - GetSoilParticleSize(dst) HPS(dst) - EstablishConnection CE - SendResults(dst) RT(dst) - BreakConnection ¬CE - UploadResults(dst) RT(dst) - P1 ¬At(src), At(dst), CA - P2 ¬At(src), At(dst) - P5 HMC(dst), HPS(dst) - P4 HMC(dst), HPS(dst),¬HSS(dst) - P6 RT(dst),¬CE - P7 ¬At(dst), At(ldr), RT(dst) CA P3 RT(dst), HMC(dst), HPS(dst), ¬CE, ¬At(dst), ¬HSS(dst) At(ldr), CA
P0 RT(dst), HMC(dst), HPS(dst), ¬CE, At(dst), ¬At(dst),
¬HSS(dst) At(ldr), CA,¬At(src)
Navigate(src, dst) ¬At(src), At(dst) CA
AnalyseSoilSample(dst) Same as P5 -
ObtainSoilResults(dst) Same as P4 -
TransmitSoilResults(dst) RT(dst) ¬CE, ¬At(dst)
At(ldr), CA
PerformSoilExperiment(dst) Same as P3 Same as P3
ExploreSoilLocation(src, dst) Same as P0 Same as P0
Table 4.1: Must literals and may literals of atomic programs and plan-bodies of Figure 4.4. Note that the rightmost column only shows the may literals that are not also must literals. Abbreviations used in the table are as follows: CA = Calibrated, HSS = HaveSoilSample,
HMC = HaveMoistureContent, HPS = HaveParticleSize, CE = ConnectionEstablished , and RT = ResultsTransmitted. Each Piis the plan-body corresponding to plan-rule Riin the figure.
Algorithm 4.3: This algorithm summarises the given event-goal with respect to the given plan-
library and set ∆ of summary information. In a nutshell, in lines 3-8, the algorithm computes the mentioned literals of the event-goal, and the algorithm obtains the precondition of the event-goal as the disjunction of the context conditions of all associated plan-rules. Next, the algorithm obtains the must and may literals of the event-goal by respectively taking the intersection of the must literals of associated plan-rules (lines 6 and 10), and the union of the may literals of associated plan-rules (line 7).
More specifically, in line 5, the current plan-rule’s context condition is added as a disjunction to the current value of the event-goal’s precondition, after performing the appropriate variable renamings. In line 10, the must literals of the event-goal are taken as the must literals that are common across the plan-bodies of all plan-rules handling the event-goal, since such literals are guaranteed to be true after any successful execution of the event-goal, irrespective of the plan-rule chosen to achieve it.
Algorithm 4.3Summarise-Event(e(~x), Π, ∆)
Input: Event-goal type e(~x); plan-library Π, where a ranking exists for Π; and the set ∆ of sum-
mary information of plan-bodies of plan-rules e′ : ψ← P ∈ Π such that e′= e(~x)θ. Output: The summary information of e(~x).
1: φ ⇐ false
2: Lmt, Lmn, S ⇐ ∅ //Lmt, Lmnare sets of literals andS is a set of sets of literals
3: for each e(~y) : ψ← P ∈ Π such that e(~x) = e(~y)θ do
4: //Variables inψand tuplehP, ǫ, Lmt P, L
mn
P i ∈ ∆need to be renamed appropriately
5: φ ⇐ φ ∨ ψθ 6: S ⇐ S ∪ {Lmt P θ}, where hP, ǫ, LmtP , LmnP i ∈ ∆ 7: Lmn⇐ Lmn∪ Lmn P θ 8: end for
9: if S ,∅ then //Obtain the must literals ofe(~x)
10: Lmt ⇐TS
11: Lmt ⇐ {l | l ∈ Lmt, variables occurring in l also occur in e(~x)}
12: end if
13: return he(~x), φ, Lmt, Lmni
For example, consider Figure 4.4 and Table 4.1. Observe that the only must lit- eral in common between plan-bodies P6 and P7 is RT(dst). This literal is also
a must literal of event-goal TransmitSoilResults(dst), because there is a guarantee that a ground instance of this literal will be true on the successful execution of
event-goal. Observe that all other (must or may) literals of the two plan-bodies are may literals of the event-goal.