On-Line Execution and On-line Execution Traces

To start with, similar to Chapter 5 we modify pGOLOG’s semantics regarding waitFor actions to account for both projection and on-line execution. As in Section 5.1.3, we make use of the fluent online(s) to distinguish between both modes of operation, and simply treat waitFor actions as tests during on-line execution. Formally, we replace the assertion for primitive actions in the first-order definition of transPr by a new axiom. As before, for readability

we specify the new axiom for transPr in the if - then - else notation introduced in

7.1. ON-LINE EXECUTION AND BELIEF UPDATE 135 transPr(α, s, δ, s0) =

if [¬online(s) ∨ ∀τ.α 6= waitFor(τ )] ∧ P oss(α[s], s) ∧ δ = nil ∧ s0 = do(α[s], s) then 1

else if online(s)∧ ∃τ.α = waitFor(τ ) ∧ τ [s, start(s)] ∧ δ = nil ∧ s = s0 _{then 1 else 0.}

As in cc-Golog, the semantics of transPr is as before if we are in projection mode: in situation s, there is a transition with probability 1 from the primitive or waitFor action α to a successor configurationhδ, s0_{i if α is possible, s}0 _{= do(α[s], s) and δ = nil, and there is no other transition}

with positive weight. The same holds if we are in on-line execution mode and a is not a waitFor action. However, if we are in on-line execution mode and a is a waitFor(τ ) action, then a is treated as test, meaning that there is a transition with positive weight if and only if the t-form τ is true at the beginning of the actual situation, that is if τ [s, start(s)] holds. If this is true, there is exactly one transition with positive weight, and the weight of this transition

is 1. Furthermore, in the new configuration s = s0 and δ = nil.

Similarly, the second order definition of transPr is obtained by replacing the implication

for primitive actions in ΦtransPr by the following two implications:

Poss(α[s], s)∧ [¬online(s) ∨ ∀τ.α 6= waitFor(τ )] ⊃ t(α, s, nil, do(α[s], s)) = 1

online(s)∧ τ [s, start(s)] ⊃ t(waitFor(τ ), s, nil, s) = 1.

We remark that all propositions of the previous chapter regarding the properties of transPr

and transPr∗ continue to hold with respect to the new definition of transPr. The only differ-

ence is that in the proofs an additional base case has to be considered.

On-Line Execution Traces Now that we have adapted pGOLOG’s semantics to account

for on-line execution, let us consider the situations which can result from an actual on-line execution of a bGOLOG plan. As in Section 5.1 where we considered the on-line execution of cc-Golog plans, we assume that the execution system of the robot periodically provides the high-level controller with ccUpdates that set the value of the continuous fluents to the latest estimates of the low-level processes. Besides updating continuous fluents, these actions also provide the correct current time; thus, we use the same successor state axiom for start as in Section 5.1.2. Finally, the low-level processes can execute reply actions to provide the high-level controller the answers of sensor processes. The following definition is completely analogous to the definition of on-line execution in cc-Golog (cf. Section 5.1.4).

Definition 19 Let AXpOnline be the foundational axioms of the epistemic situation calculus

together with the precondition axioms for waitFor and ccUpdate, the successor state axioms

for start and online from Section 5.1.2, the (second-order) definitions of Final and transPr∗

from the previous chapter, the axioms needed for the encoding of programs as first-order terms,

the axioms required for t-form’s, the set of axioms AXarch from Section 4.3.1, and the new

second-order definition of transPr. Furthermore, let AX be AXpOnlinetogether with a situation

calculus axiomatization of an application domain. Then an on-line execution with respect to AX of a program σ0 in a situation s0 is a sequence σ0, s0, ..., σn, sn such that for i = 0, ...n−1:

1. AX|= transPr(σi, si, σi+1, si+1) > 0; or

2. ∃a, i, n. a = reply(i, n) ∧ σi+1= σi∧ si+1= do(a, si); or

3. ∃a, ~x, t. a = ccUpdate(~x, t) ∧ [∀σ0_{, s}0_{. transPr(σ}

i, si, σ0, s0) > 0⊃ t ≤ start(s0)]∧ σi+1=

We call an on-line execution completed if AX|= Final(σn, sn). Besides, we say that there

is an on-line execution of σ0 in s0 that results in (σn, sn) if and only if there is an on-line

execution σ0, s0, ..., σn, sn of σ0 in s0. Finally, we say that a situation sn is a legal on-line

execution trace of σ0 in s0 if and only if there is a program σn such that there is an on-line

execution of σ0 in s0 that results in (σn, sn).

The only difference between this definition and the definition of an on-line execution of a

cc-Golog plans is that Trans(σ, s, δ, s0) is replaced by transPr(σ, s, δ, s0) > 0. Note that as

bGOLOG plans do not include prob instructions, a bGOLOG plan can always execute at most one action at any time (cf. Proposition 13).

As an example, let us reconsider the plan Πrobby4 from Section 6.3.2:

Πrobby4= [send(fork, inspect), Bel(reg(inspect). 6= nil) = 1?,

send(fork, paint), Bel(reg(painted) =>) = 1?, if(Bel(reg(inspect) = OK) = 1,

[send(fork, ship), Bel(reg(processed) =>) = 1?] [send(fork, reject), Bel(reg(processed) =_{>) = 1?])].}

Let Γ be the set of axioms AXpOnlinetogether with an axiomatization of the ship/reject domain

(cf. Section 6.3.2). The following situation is a legal on-line execution trace of Πrobby4 in S0

with respect to Γ, assuming that the execution system provides a ccUpdate action every 0.25 seconds (we only write the last argument (time) of ccUpdate):

S1 = do([send(fork, inspect),.

reply(fork, nil), ccUpdate(0.25), ..., ccUpdate(10.0), reply(inspect, OK),

send(fork, paint),

reply(fork, nil), ccUpdate(10.25), ..., ccUpdate(40.0), reply(painted,>) send(fork, reject),

reply(fork, nil), ccUpdate(40.25), ..., ccUpdate(50.0), reply(processed,>)], S0).

Proof: (Outline) A send action is always possible, so Πrobby4 can execute send(fork, inspect).

The low-level execution system answers by executing reply(fork, nil). Thereafter, the remain-

ing plan is blocked, waiting for Bel(reg(inspect)6= nil) = 1, that is for a reply(inspect,OK) or

reply(inspect,OK) action. So the low-level execution system can execute exogenous ccUpdate actions which cause time to advance (cf. the third condition in Definition 19). Then, the inspect process executes a reply(inspect,OK) action, which unblocks the high-level plan. As

a result, the plan activates the paint process and waits for Bel(reg(painted) = >) = 1 to

become true. Again, the low-level system replies by reply(fork, nil), and executes a sequence

of ccUpdate actions. Finally, the paint process signals completion by reply(painted,>). This

reactivates the plan, which evaluates the conditional. The value of register inspect is OK because of the reply(inspect,OK) answer of the inspect process, so the plan activates reject.

Thereafter, it waits until the reject process executes reply(processed,>) and ends. 2

Another example of an on-line execution trace is the following situation SUCwhich results

from the execution of the plan [send(fork, paint), Bel(reg(painted) = >) = 1?]. Note that in

the following situation SUC the execution of the high-level plan is not completed:

SUC= do([send(fork, paint),.

7.1. ON-LINE EXECUTION AND BELIEF UPDATE 137 We remark that our definition of an on-line execution does not ensure that an execution trace actually includes all the reply actions predicted by the pGOLOG model of the low-level processes. Nevertheless, the framework for belief update presented in this chapter relies on their occurrence; in particular, we assume that only such reply actions occur during on-line execution which are considered in the pGOLOG model of the low-level processes. So in a sense the definition of on-line execution is under-constrained. The argument is that pGOLOG programs like kernelProc are designed by the user as a faithful model of the actual low-level processes. That is, the user has to take care that if during on-line execution a particular reply action can occur, then there is a probabilistic branch in the pGOLOG model of the low-level processes involving this reply action.

Similarly, we assume that the difference ∆ = ti+1− ti between two subsequent updates

ccUpdate(~x, ti) and ccUpdate(~x, ti+1) is smaller than the minimal delay between the execution

time of any two actions of the pGOLOG models which have different execution time. Further- more, we assume that if a reply is modeled to happen at time t, then during on-line execution the high-level controller’s run-time system will generate a ccUpdate action causing start to advance to t before the actual reply action happens.