Interleaving On-Line Execution and Projection

Next, we consider an example where interleaving projection and on-line execution is useful in specifying intelligent robot behavior. Again, our robot is to deliver letters. Additionally, it has to be back in Room 6204 by 15:30, where a practical course will start. In this scenario, a reasonable high-level behavior would be to deliver letters until the time is not sufficient for another delivery (but yet sufficient to travel to Room 6204), at which point the robot would start moving to Room 6204. Using a time-bound projection test telling us whether the robot will be able to deliver another letter and to travel to Room 6204 before 15:30, this behavior can (informally) be turned into the following high-level plan: “if projection indicates that there is enough time to deliver another letter, then do so; else, travel to Room 6204.”

Before we can turn to the formal specification of this plan, we first have to show how our cc-Golog implementation can be extended to account for time-bounded projection tests (cf. Section 5.2.2). In particular, we introduce the condition lookahead which implements the projection test Lookahead discussed in Section 5.2.2. lookahead(Phi,T,A,LL) is true if the projection of the plan A with time-bound T, using LL as model of the low-level processes, results in a situation where Phi holds. As it turns out, the evaluation of projection tests does not cause any difficulties in PROLOG. In fact, we only need to add a new holds/2 clause to those already listed in Section 8.1.4.

‘‘hello’’

Deliv1 Deliv2

Deliv3 Start

(a) Sufficient Battery Voltage

‘‘hello’’ Deliv1 Deliv2 Deliv3 Start battLvl!low chargeB.

(b) Low Battery Voltage

Figure 8.9: On-Line Execution Scenarios of introEx holds(lookahead(Phi,T,A,LL),S) :-

timeboundDo(withPol(LL,A),S,T,LL,SS), holds(Phi,SS).

Note that the low-level processes are taken into account during projection by concurrently simulating LL and A. To perform a time-bounded projection, the lookahead test makes use of the predicate timeboundDo/4. timeboundDo(A,S,T,S1) is defined similarly to do(A,S,S1) (cf. Section 8.1), but additionally verifies that the simulation ends if a situation S1 is reached whose successor has a starting time beyond T.

timeboundDo(A,S,T,S) :- final(A,S). timeboundDo(A,S,T,S1) :-

trans(A,S,R2,S2), start(S2,T2), (T2 > T, S1 = S;

T2 =< T, timeboundDo(R2,S2,T,S1)).

Now that we have implemented the projection test lookahead, we are settled for the specifica- tion of a plan realizing the behavior informally discussed at the beginning of this sub-section. We begin with a specification of the domain. To represent the letters to be delivered, we make use of the fluent letter(L,Origin,Destination), which is true if letter L is to be deliver from Origin to Destination. The fluent letter is only affected by the primitive action deliver(L), as specified by the following clauses:

holds(letter(L,Origin,Dest),s0) :-

[L,Origin,Dest] = [l1,r6213a,r6213]; [L,Origin,Dest] = [l2,r6214,r6212]; [L,Origin,Dest] = [l3,r6213,r6205]. holds(letter(L,Origin,Dest),do(A,S)) :-

8.2. RUNNING CC-GOLOG ON A REAL ROBOT 185 To deliver a letter l, the high-level controller can invoke the procedure deliverLetter with l as argument. deliverLetter makes use of the procedure gotoRoom(r) to travel to a room t, and of the functional fluents lOrig(l) and lDest(l), whose value is the origin respectively the destination of letter l.

proc(delivLetter,[l], [gotoRoom(lOrig(l)), pickup(l), gotoRoom(lDest(l)), deliver(l)]). isFF(nextLetter). isFF(lOrig(L)). isFF(lDest(L)).

hasValFF(lOrig(L),V,S) :- (holds(letter(L,V,_),S), ! ; V = nil). hasValFF(lDest(L),V,S) :- (holds(letter(L,_,V),S), ! ; V = nil).

Now that we have introduced the projection test lookahead and have specified the example domain, we can turn the informal specification “if projection indicates that there is enough time to deliver another letter, then do so; else, travel to Room 6204” into the cc-Golog plan deliverUntil. deliverUntil takes as argument the time t at which the robot has to be back in Room 6204. If there are no letters to be delivered, deliverUntil directly causes the robot to travel to Room 6204. If there still are letters to be delivered, deliverUntil determines – by means of a projection test – if it is possible to deliver the next letter and to be back in Room 6204 by time t. If so, it delivers the next letter and re-evaluates the new situation. Finally, if there is not enough time to deliver another letter, deliverUntil causes the robot to travel directly to Room 6204:

proc(delivUntil,[t],

if(not(exists(l,exists(o,exists(d,letter(l,o,d))))), gotoRoom(r6204), % Delivery Completed

if(lookahead(robotInRoom(r6204),t,

[deliverLetter(nextLetter),gotoRoom(r6204)], navProc),

% If enough time, then continue delivery [deliverLetter(nextLetter),delivUntil(t)], % Else stop delivery

gotoRoom(r6204)))).

Here, robotInRoom(R) is a macro, which is true if the robot’s position lies within room R, and nextLetter is a functional fluent (defined in terms of the fluent letter) whose value is the next letter to be delivered.

Figure 8.10 illustrates three different runs of deliverUntil. In the execution trace shown in the left sub-figure, CARL is only left 80 seconds to perform delivery, which only suffices to deliver one letter from Room 6213a to Room 6213. In the execution trace shown in the middle sub-figure, the robot can perform for 350 seconds before it has to be back in Room 6204, which allows it to deliver another letter from Room 6214 to Room 6212. Finally, the right sub-figure

Start Stop

deliv(l1) pickup(l1)

(a) 80 seconds remaining

Stop deliv(l1) pickup(l1) Start deliv(l2) pickup(l2) (b) 350 seconds remaining deliv(l1) pickup(l1) Stop Start deliv(l2) pickup(l2) deliv(l3) pickup(l3) (c) 950 seconds remaining

Figure 8.10: Time-Bound Delivery

shows an execution trace where the robot has enough time to deliver all letters. We remark that all limited projection tests involved in these examples were computed in less than 0.15 seconds, running on a Pentium III 500Mhz Linux Workstation.

Finally, we remark that in examples like the above, the reliability of the high-level con- troller heavily depends on the accuracy of the model of the navigation process used in the projection test. However, our execution scheme interleaving on-line execution and projection is still much more robust than the unreflected execution of a plan determined completely off-line, because each projection test takes into account the actual history encountered so far, thus adapting the robot’s behavior to previous delays.