3.2 Adding HTN Planning into the CAN BDI Language
3.2.3 Adding HTN Planning into CAN: the Plan Construct
In order to integrate HTN planning into the revised CAN language described in Section 3.2.1, we need to address several issues. First, we need to provide a model of actions. Second, we need to keep the full language as uniform as possible. Third, we need to give the BDI programmer control over when to perform HTN planning. Fourth, we need to determine what BDI domain knowledge
the HTN planner will use – we want the planner to re-use as much information as possible from the existing BDI domain. Finally, we need to determine how to execute a HTN solution from within the BDI execution cycle, while at the same time monitoring the execution if possible.
We address the last four issues by introducing a new program construct into the CAN language, namely, Plan(P), where P is a plan-body program. Intuitively, this construct means “execute
program P only if there is a complete hierarchical decomposition for P.” In this way, an agent
executing a program within thePlanconstruct performs a complete HTN look-ahead search before committing to even the first step in the program. Before providing an operational semantics to define the behaviour of thePlan construct, we first discuss our representation and semantics of actions.
Actions
In the BDI languages proposed by (Rao, 1996; Winikoff et al., 2002), actions are not modelled – an action is defined as any arbitrary operation that is always applicable, and one that always succeeds. In contrast, we consider actions to be the usual basic means of an agent to make changes to its environment. This view of actions is especially important in our work because we are interested in adding planning (HTN and classical) to BDI agents, and planners require an explicit representation of the preconditions and postconditions of actions.
In order to incorporate actions into CAN, we add to the definition of an agent a STRIPS-like
action-library Λ, containing rules of the form act : ψact ← Φ−act; Φ+act, one for each action type in the domain. Like CAN actions, the action name act can correspond to any arbitrary operation (e.g., a low-level function in C that activates a robot’s actuators). All that we are interested in capturing is the action’s precondition ψactand its postcondition, i.e., its add list of atoms Φ+act and delete list of atoms Φ−act. The language of the action-library is the same as that of the plan-library. Moreover, like the definition of a classical planning operator (Ghallab et al., 2004, p. 28), the following conditions hold for our action-rules: (i) free variables in ψact, Φ−act and Φ+act are also free in act; (ii) ψactis a conjunction of literals; and (iii) act is a symbol followed by a vector of distinct variables.
sented in the action-library Λ as follows:
move(x, y, z) : Free(z)∧ At(x, y) ←−
{Free(z), At(x, y)}; {Free(y), At(x, z)}.
An alternative, more involved approach for modelling actions would be to follow (Hindriks et al., 1999) and to assume that a partial function T , specifying the update semantics of basic
actions, is given. More precisely, if T (act, B) is defined, it yields the new updated belief base
B′; otherwise, the action’s precondition is not met inB. However, for simplicity, we stick to the
STRIPS-like action library described.
The rule that defines the behaviour of an action is shown next. This rule states that an action is executed by (i) selecting an applicable action-rule (if any) from the action-library Λ; (ii) adding the action to the sequence of actionsA; and (iii) updating belief base B with the add and delete lists of the action.
act′: ψ← Φ−; Φ+∈ Λ act′θ = act B |= ψθ hB, A, acti −→ h(B \ Φ−θ) ∪ Φ+
θ, A · act, nili act
Finally, we add another reasonable restriction to the definition of an action: we require the post- conditions of actions to be consistent. This restriction ensures, to a certain extent, that actions are written with appropriate care.
Definition 7. (Consistent Actions) Let Λ be an action-library and let act : ψ← Φ−; Φ+ ∈ Λ be
an action-rule. Then, act : ψ← Φ−; Φ+is consistent relative to Λ iff for all ground instances actθ of act and belief basesB, if B |= ψθ, then Φ+
θ ∪ {¬b | b ∈ Φ−θ} is consistent.
Plan construct
We now provide operational semantics to define the behaviour of thePlanconstruct. To do this, we first introduce two types of (labelled) transitions on basic configurations: bdi-type transitions andplan-type transitions. Intuitively,bdi-type transitions are used for the standard BDI execution cycle, andplan-type transitions are used for (internal) deliberation steps within a planning context. By distinguishing between these two types of transitions, we are able to disallow certain rules, such as those dealing with failure handling, from being used in a planning context. We write C−→ Ct ′
on a transition, both types apply.
Next, we show the main operational rule for thePlan construct. This rule, which is influ- enced by the Σ construct of (De Giacomo and Levesque, 1999), states that a basic configuration
hB, A,Plan(P)i can evolve into a configuration hB′, A′,Plan(P′)i if the following two conditions
are met: (i) configurationhB, A, Pi can evolve into configuration hB′, A′, P′i, and (ii) it is possible
to reach a final configuration fromhB′, A′, P′i in a finite number of planning steps.
hB, A, Pi−→ hBplan ′, A′, P′i hB′, A′, P′iplan−→ hB∗ ′′, A′′, nili hB, A,Plan(P)i−→ hBbdi ′, A′,Plan(P′)i
Plan
There are also two simpler rules associated with thePlanconstruct. These are shown below.
hB, A,Plan(nil)i −→ hB, A, nili Plant
hB, A, Pi−→ hBplan ′, A′, P′i
hB, A,Plan(P)i−→ hBplan ′, A′,Plan(P′)i
PlanP
RulePlant deals with the trivial case of planning on program nil, by simply removing thePlan construct from the program. RulePlanP handles thePlanconstruct within a planning context: if aPlan(P) program is encountered during an execution that is already within a planning context, rulePlanP, unlike rulePlan, avoids looking ahead on P, and performs instead a single (arbitrary)
plan-step on P. The reason for performing a single step on P is that it is not clear what it means to perform planning when already within a planning context. Therefore, any (nested)Planconstruct encountered from within a planning context is essentially ignored.
Certain transition rules only make sense in the context of BDI execution, in particular, the rules that deal with failure handling. As mentioned before, the concept of BDI-style failure handling, where on the failure of a step in some state an alternative is tried from that state, does not exist in HTN planning – HTN solutions do not include such failures. The rule that handles BDI-style failure is ⊲f from Section 3.2.1. We make this rule unavailable during planning by making it abdi- type transition, and we refer to the new version of the rule as ⊲bdif . In addition to this modification, we also need to modify slightly the agent level rules Astep and Aclean from Section 3.2.2, so that
they are defined in terms ofbdi-type transitions. The three updated rules are shown below: P1,nil hB, A, P1i 6 bdi −→ hB, A, (P1⊲ P2)i bdi −→ hB, A, P2i ⊲bdif P∈ Γ hB, A, Pi−→ hBbdi ′, A′, P′i hN, Λ, Π, B, A, Γi =⇒ hN, Λ, Π, B′, A′, (Γ \ {P}) ∪ {P′}i Astep P∈ Γ hB, A, Pi 6−→bdi
hN, Λ, Π, B, A, Γi =⇒ hN, Λ, Π, B, A, Γ \ {P}i Aclean
Observe that, with the alternative rule ⊲bdif , only the BDI execution cycle would be allowed to try alternative plans from ∆ for an event-goal upon the failure of some plan previously tried from
∆. Therefore, although a program of the form (?false ⊲ L∆M) has no transition within a planning
context, this program does have a transition within a BDI context – programL∆M will be tried.
Since the above rules are not available in the planning context, planning does not merely amount to looking ahead on the BDI execution cycle.
Let us explain how thePlanconstruct works with an example. Consider an agent with the following four plan-rules (where P2is some plan-body):
e0 : true←Plan(!e1) e1 : p← +u; !e2 e1 :¬u ← +r e2 : q← P2
Suppose the initial belief base of the agent is B0 = {p}. To understand how
programPlan(!e) works, let us first consider the execution of program !e1alone.
In the first execution step, rule Event is applied to obtain the set of relevant plans ∆ for event-goal e1:
∆ ={(p : +u; !e2), (¬u : +r)} hB0, A, !e1i −→ hB0, A, L∆Mi Event
execution. Since both plan-bodies in ∆ are applicable in this case, suppose the plan- body selected is +u; !e2:
(p : +u; !e2)∈ ∆ B0|= p
hB0, A, L∆Mi −→ hB0, A, (+u; !e2) ⊲ L{¬u : +r}Mi Sel
In the next step, the belief operation in program +u; !e2is performed; in partic-
ular, belief atom u is added to belief baseB0to obtain belief baseB1={p, u}:
hB0, A, +u; !e2i −→ hB1, A, nil; !e2i +b
hB0, A, (+u; !e2) ⊲ L{¬u : +r}Mi −→ hB1, A, nil; !e2⊲ L{¬u : +r}Mi ⊲
Two steps later, the set of relevant plans ∆ for event-goal !e2is obtained:
∆ ={q : P2}
hB1, A, !e2i −→ hB1, A, L∆Mi Event
hB1, A, !e2⊲ L{¬u : +r}Mi −→ hB1, A, L∆M ⊲ L{¬u : +r}Mi ⊲
Now, observe that the only plan in ∆ is not applicable for event-goal e2, because B1 6|= q. Consequently, a transition is not possible from configuration hB1, A, L∆Mi.
Moreover, the alternative plan-body +r inL{¬u : +r}M cannot be successfully exe- cuted either, because the belief base is B1 = {p, u} and the context condition of
plan-body +r requires¬u to hold. Consequently, the top-level event-goal program
!e fails.
Let us now consider the execution of programPlan(!e). In the first step of the execution, rulePlanwill be applicable, resulting in the set of relevant plans being selected as before: ∆ ={(p : +u; !e2), (¬u : +r)} hB0, A, !e1i plan −→ hB0, A, L∆Mi Event hB0, A,Plan(!e1)i bdi −→ hB0, A,Plan(L∆M)i Plan
In the next step, rulePlan will be applicable again. However, unlike before, from the relevant set of plans ∆, plan-body +u; !e2 will not be selected, because it
is not possible to successfully execute (decompose) this plan-body, for the reasons shown before. More specifically, condition hB0, A, (+u; !e2) ⊲ L{¬u : +r}Mi
plan∗ −→ hB′, A′, nili required by the antecedent of rulePlanis not met. However, condition
hB0, A, +r ⊲ L{p : +u; !e2}Mi plan∗
−→ hB′, A′, nili is indeed met, resulting in plan-body +r being selected for execution, and programPlan(!e) succeeding. It is important to note that, of course, the first execution step of programPlan(!e) would not have happened at all, if the successful execution of thePlan(!e) program were not possi- ble.
The full set of CANPlan rules is shown in Figure 3.3.