arXiv:cs/0003032v1 [cs.AI] 8 Mar 2000 endvlpdfrti ups.A neape con- example, an As following purpose. the this sider for pro- developed been special Several in as such world time. languages over the gramming fashion change continuous and a concurrently processes operate specify typically which controllers robot High-level rap eairo oierbtdpoe naraitcenviron- (Thrun time realistic of a period in proce- extended deployed an robot the for mobile ment to a of call behavior a by indicate merely dure we which hl rsrigasmnial elfuddprojection mechanism. well-founded semantically a preserving languages while control non-logic-based to compared siveness sbsdo h xeddstaincluu.Oeben- One calculus. situation of extended efit the on based is oeb rtetnigtestaincluu osup- and to behavior presenting over- event-driven calculus then and be situation change can the continuous problems extending port these first In how by show come behavior. we event-driven However, paper, expressing this latter. problems the has for well-suited it is logic- calculus, a evolves uation hand, like other world language the the control On based how pro- executed. way, to are actions conspicuous comes when it a when in poorly jecting, fare express they to non-logic- suited scenarios, well While such are low”. languages is control batter- level robot voltage the based the “charge as in execu- soon as as the event-driven ies is where actions and concurrently, of continuously, tion operate world which typi- the processes change domains with realistic deal in cally controllers robot High-level ogl,terbtsmi aki odlvrmail, deliver to is task main robot’s the Roughly, 1 rpl DELIVER-MAIL Fry18) or 1987), (Firby cc-Golog WITH-POLICY a eetybe sdscesul ocnrlthe control to successfully used been recently has cc-Golog WITH-POLICY DELIVER-MAIL iue1 ffiedlvr plan delivery Office 1: Figure cc-Golog sta tnrostegpi expres- in gap the narrows it that is oad oeRaitcLgcBsdRbtControllers Robot Logic-Based Realistic More Towards : hl xctn hspoeue the procedure, this executing While . Introduction rpl WHENEVER WHENEVER CHARGE-BATTERIES SAY(“hello”) Abstract colbert -program: ain of variant a , ConGolog erkGosruzadGradLakemeyer Gerhard and Grosskreutz Henrik Batt-Level rpl NEAR-DOOR(RmA-118) Knlg 97 have 1997) (Konolige MDrot1992), (McDermott ae ntesit- the on based , ≤ { ConGolog grosskreutz,gerhard 46 eateto optrSineV Science Computer of Department ahnUiest fTechnology of University Aachen tal. et 25 ahn Germany Aachen, 52056 which 1999). 1 } @cs.rwth-aachen.de htpoetosrl nusing on rely projections that im hc ak omlsmnisadwihmakes which and semantics formal a lacks which nism, tion. r efre,amto hc lole ttehatof heart the at lies also which ques- planning. method such a answering performed, are to to approach ac- is of principled tions courses A both different among to choose tion. important to want yet robot may the by, intended and who come development the program to during satisfy designer easy the will not it are whether goals program and a executable whether like is questions to answers programs, block should battery the activity. other of other the charging all On actual continue. the should hand, be delivery mail must level, priority changing tery high as with of non-blocking and thought concurrently best execute such are Conditions level (3) continuously voltage determined. after the is immediately as level charged voltage low are a batteries the example, true. lems. xfrm srahn eti or otrbtcnrllan- construct control special robot the Most using feature waitFor this door. realize certain execution guages such a true the reaching becoming occurs, conditions as certain action on ac- an depends of time when timing stating The plicitly (1) largely is controllers: tions robot high-level moment. of this at doing is in- it batteries battery else its the whatever recharges should it terrupting door and, low, the “hello” dangerously passes says drop level it it A-118 in- whenever Room an priority: to with of following, level the creasing does also concurrently robot agae like languages construct. ntecs of case the In robot concurrent of complexity inherent the Given vnti ipepormehbt motn features important exhibits program simple this Even 2 3 nteexample, the In sfra eko,ohrnnlgcbsdrbtcontrol robot non-logic-based other know, we as far As 2 3 xss(cemt 92 94,bti a prob- has it but 1994), 1992; (McDermott exists 2 cin r executed are Actions (2) ehp h otsrosdfiinyof deficiency serious most the Perhaps ( φ ,wihssed ciiyuntil activity suspends which ), project o xml,wiewiigfralwbat- low a for waiting while example, For . rap vrtm.()Prso rgaswhich programs of Parts (4) time. over event-driven or rpl o h ol vle hnactions when evolves world the how waitFor colbert rjcinmcaimcalled mechanism projection a , shde ihntewhenever- the within hidden is hti,rte hnex- than rather is, that , ontee osdrprojec- consider even not do rpl sso spossible as soon as seeuinmecha- execution ’s φ becomes xfrm For . is predictions implementation dependent. Preferably one functional fluents and are denoted analogously; finally, would like a language which is as powerful as rpl yet al- there is a special predicate Poss(a,s) used to state that lows for projections based on a perspicuous, declarative action a is executable in situation s. semantics. Within this language, we can formulate theories The recently proposed language ConGolog (de Gia- which describe how the world changes as the result of como, Lesperance, & Levesque 1997) fulfills some of the available actions. One possibility is a basic action these desiderata as it offers many of the features of rpl theory of the following form (Levesque, Pirri, & Reiter such as concurrency, priorities etc. and, at the same 1998): time, supports rigorous projections of plans4 because it is entirely based on the situation calculus(McCarthy • Axioms describing the initial situation, S0. 1963; Levesque, Pirri, & Reiter 1998). • Action precondition axioms, one for each primitive It turns out, however, that despite many similari- action a, characterizing Poss(a,s). ties, ConGolog in its current form is not suitable to F represent robot controllers such as the example above. • Successor state axioms, one for each fluent , stat- F ~x, a,s The main problem is that the existing temporal ex- ing under what conditions ( do( )) holds as a s. tensions of the situation calculus such as (Pinto 1997; function of what holds in situation These take the Reiter 1996) require that the execution time of an ac- place of the so-called effect axioms, but also provide tion is supplied explicitly, which seems incompatible a solution to the frame problem (Levesque, Pirri, & with event-driven specifications. To solve this prob- Reiter 1998). lem we proceed in two steps. First we present a new • Domain closure and unique name axioms for the ac- extension of the situation calculus which, besides deal- tions. ing with continuous change, allows us to model actions • Foundational, domain independent ax- which are event-driven by including waitFor as a spe- ioms (Levesque, Pirri, & Reiter 1998). cial action in the logic. We then turn to a new variant of ConGolog called cc-Golog, which is based on the ex- 1. ∀P.P (S0) ∧ [∀s∀a.(P (s) ⊃ P (do(a,s)))] ⊃ ∀sP (s); tended situation calculus. We study issues arising from 2. do(a,s)= do(a′,s′) ⊃ a = a′ ∧ s = s′;5 the interaction of waitFor-actions and concurrency and 3. ¬(s ❁ S0); show how the example-program can be specified quite ❁ ′ ′ ′ naturally in cc-Golog with the additional benefit of sup- 4. s do(a,s ) ≡ s ⊑ s , where s ⊑ s stands for ❁ ′ ′ porting projections firmly grounded in logic. (s s ) ∨ (s = s ). The rest of the paper is organized as follows. In the 5. s ≺ s′ ≡ s ❁ s′ ∧ ∀a,s∗.s ❁ do(a,s∗) ⊑ s′ ⊃ next section, we briefly review the basic situation cal- Poss(a,s∗) culus. Then we show how to extend it to include con- The first is a second-order induction axiom ensuring tinuous change and time. After a very brief summary that the only situations are those obtained from apply- of ConGolog, we present cc-Golog, which takes into ac- ing do to S0. The second is a unique names axiom for count the extended situation calculus. This is followed situations. ⊑ defines an ordering relation over situa- by a note on experimental results and conclusions. tions. Intuitively, s ⊑ s′ holds if s′ can be obtained from s by performing a finite number of actions. Fi- The Situation Calculus nally, s ≺ s′ holds when there is a legal sequence of One increasingly popular language for representing and actions leading from s to s′, where legal means that reasoning about the preconditions and effects of actions each action is possible. is the situation calculus (McCarthy 1963). We will not go over the language in detail except to note the follow- Continuous Change and Time ing features: all terms in the language are one of three sorts, ordinary objects, actions or situations; there is Actions in the situation calculus cause discrete changes a special constant S0 used to denote the initial situa- and, in its basic form, there is no notion of time. In tion, namely that situation in which no actions have yet robotics applications, however, we are faced with pro- occurred; there is a distinguished binary function sym- cesses such as navigation which cause properties like the bol do where do(a,s) denotes the successor situation robot’s location and orientation to change continuously to s resulting from performing the action a; relations over time. In order to model such processes in the situa- whose truth values vary from situation to situation are tion calculus in a natural way, we add continous change called relational fluents, and are denoted by predicate and time directly to its ontology. symbols taking a situation term as their last argument; As demonstrated by Pinto and Reiter (Pinto 1997; similarly, functions varying across situations are called Reiter 1996), adding time is a simple matter. We add a new sort real ranging over the real numbers and, for 4In this paper we will use the terms program and plan mnemonic reasons, another sort time ranging over the interchangeably, following McDermott (McDermott 1992) who takes plans to be programs whose execution can be 5We use the convention that all free variables are implic- reasoned about by the agent who executes the program. itly universally quantified. reals as well.6 In order to connect situations and time, the introduction, motivated by the treatment of time in we add a special unary functional fluent start to the robot control languages like rpl, rap, or colbert, we language with the understanding that start(s) denotes introduce a new type of primitive action waitFor(φ). the time when situation s begins. We will see later The intuituion is as follows. Normally, every action how start obtains its values and, in particular, how the happens immediately, that is, the starting time of the passage of time is modeled. situation after doing a in s is the same as the starting A fundamental assumption of the situation calculus time of s. The only exception is waitFor(φ): whenever is that fluents have a fixed value at every given situa- this action occurs, the starting time of the resulting tion. In order to see that this assumption still allows us situation is advanced to the earliest time in the future to model continuous change, let us consider the exam- when φ becomes true. Note that this has the effect ple of a mobile robot moving along a straight line in a that actions always happen as soon as possible. One 1-dimensional world, that is, the robot’s location at any may object that requiring that two actions other than given time is simply a real number. There are two types waitFor must happen at the same time is unrealistic. of actions the robot can perform, startGo(v), which ini- However, in robotics applications, actions often involve tiates moving the robot with speed v, and endGo which little more than sending messages in order to initiate or stops the movement of the robot. Let us denote the terminate processes so that the actual duration of such robot’s location by the fluent robotLoc. What should actions is negligible. Moreover, if two actions cannot the value of robotLoc be after executing startGo(v) in happen at the same time, they can always be separated situation s? Certainly it cannot be a fixed real value, explicitly using waitFor. since the position should change over time as long as the For the purposes of this paper, we restrict the argu- robot moves. In fact, the location of the robot at any ment of waitFor to what we call a t-form, which is a time after startGo(v) (and before the robot changes its Boolean combination of closed atomic formulas of the velocity) can be characterized (in a somewhat idealized form (F op r), where F is a continuous fluent with the 7 fashion) by the function x + v × (t − t0), where x is the situation argument suppressed, op ∈ {<, =}, and r is starting position and t0 the starting time. The solution a term of type real (not mentioning val). An example is then to take this function of time to be the value of is φ = (robotLoc ≥ 1000). To evaluate a t-form at a robotLoc. We call functional fluents whose values are situation s and time t, we write φ[s,t] which results continuous functions continuous fluents. in a formula which is like φ except that every contin- The idea of continuous fluents, which are often called uous fluent F is replaced by val(F (s),t). For instance, parameters, is not new. Sandewall (Sandewall 1989) (robotLoc ≥ 1000)[s,t] becomes (val(robotLoc(s),t) ≥ proposed it when integrating the differential equations 1000). For reasons of space we completely gloss over into logic, Galton (Galton 1990) investigated similar the details of reifying t-forms within the language8 ex- issues within a temporal logic, and Shanahan consid- cept to note that we introduce t-forms as a new sort ers continuous change in the event calculus (Shana- and that φ[s,t] is short for Holds(φ,s,t), where Holds han 1990). Finally, Miller and Pinto (Miller 1996; is appropriately axiomatized. Pinto 1997) formulate continuous change in the situ- To see how actions are forced to happen as soon as ation calculus. Here we essentially follow Pinto, in a possible, let ltp(φ,s,t) be an abbreviation for the for- somewhat simplified form. mula We begin by introducing a new sort t-function, whose φ[s,t] ∧ t ≥ start(s) ∧ ∀t′.start(s) ≤ t′ as well. val(linear(x, v,t0),t)= x + v × (t − t0). 8See, for example, (Giacomo, Lesperance, & Levesque 1999) for details how this can be done. Let us now turn to the issue of modeling the pas- 9 sage of time during a course of actions. As indicated in This is not unlike Reiter’s definition of a least nat- ural time point in the context of natural actions (Reiter 6For simplicity, the reals are not axiomatized and we as- 1996). Similar ideas occur in the context of delaying pro- sume their standard interpretations together with the usual cesses in real-time programming languages like Ada (Burns operations and ordering relations. & Wellings 1991). case it advances to the earliest time in the future when ConGolog φ holds. ConGolog (Giacomo, Lesperance, & Levesque 1999), an Poss(a,s) ⊃ [start(do(a,s)) = t ≡ extension of GOLOG (Levesque et al. 1997), is a for- ∃φ.a = waitFor(φ) ∧ ltp(φ,s,t)∨ malism for specifying complex actions and how these [∀φ.a 6= waitFor(φ) ∧ t = start(s)]]. are mapped to sequences of atomic actions assuming Let AX be the set of foundational axioms of the previ- a description of the initial state of the world, action ous section together with the domain closure and unique precondition axioms and successor state axioms for names axioms for t-functions, the axioms required for each fluent. Complex actions are defined using control t-form’s, the precondition axiom for waitFor, and the structures familiar from conventional programming lan- successor state axiom for start. Then the following for- guage such as sequence, while-loops and recursive pro- mulas are logical consequences of AX. cedures. In addition, parallel actions are introduced with a conventional interleaving semantics. Here we Proposition 1: confine ourselves to the deterministic fragment of Con- 1. The starting time of legal action sequences is mono- Golog. (While nondeterministic actions raise interesting tonically nondecreasing: issues, we ignore them for reasons of space. Also note ∀s,s′.s ≺ s′ ⊃ start(s) ≤ start(s′). that nondeterminism plays little if any role in languages 2. Actions happen as soon as possible: like rpl.) [∀a, s.start(do(a,s)) = start(s)] ∨ [∃φ.a = α primitive action waitFor(φ) ∧ ltp(φ, s, start(do(a,s)))] φ? testaction11 To illustrate the approach, let us go back to the robot seq(σ1, σ2) sequence example. First, we can formulate a successor state ax- if(φ, σ1, σ2) conditional iom for robotLoc: while(φ, σ) loop Poss(a,s) ⊃ [robotLoc(do(a,s)) = y ≡ par(σ1, σ2) concurrent execution ∃t0, v, x.x = val(robotLoc(s),t0) ∧ t0 = start(s)∧ prio(σ1, σ2) prioritized execution [a = startGo(v) ∧ y = linear(x, v,t0) proc β(x)σ procedure definition ∨a = endGo ∧ y = constant(x) ∨ y = robotLoc(s)∧ The semantics of ConGolog is defined using the so- ¬∃v.(a = startGo(v) ∨ a = endGo)]] called transition semantics, which defines single steps In other words, when an action is performed robotLoc of computation. There is a relation, denoted by the ′ is assigned either the function linear(x, v,t0), if the predicate Trans(σ,s,δ,s ), that associates with a given robot starts moving with velocity v and x is the location program σ and situation s a new situation s′ that results of the robot at situation s, or it is assigned constant(x) from executing a primitive action in s, and a new pro- if the robot stops, or it remains the same as in s.10 gram δ that represents what remains of σ after having Let Σ be AX together with the axioms for val, performed that action. Furthermore, we need to de- the successor state axiom for robotLoc, precondition fine which configurations (σ, s) are final, meaning that axioms stating that startGo and endGo are always the computation can be considered completed when a S0 final configuration is reached. This is denoted by the possible, and the fact (robotLoc( ) = constant(0)), 12 that is, the robot initially rests at position 0. Let predicate Final(σ, s). . We do not consider the axiomatization concerning us assume the robot starts moving at speed 50 13 (cm/s) and then waits until it reaches location 1000 the proc instruction, which is more subtle to handle. (cm), at which point it stops. The resulting sit- Note that the semantics is defined for the non-temporal uation is s1 = do(endGo, do(waitFor(robotLoc = situation calculus. Adapting the semantics to the tem- 1000), do(startGo(50),S0))). Then poral situation calculus of the previous section will be the subject of the next section. Σ |= start(s1)=20 ∧ robotLoc(s1)= constant(1000). In other words, the robot moves for 20 seconds and Final(α, s) ≡ false , where α is a primitive action stops at location 1000, as one would expect. Final(nil,s) ≡ true, where nil is the empty program In summary, to model continuous change and time Final(φ?,s) ≡ false in the situation calculus, we have added four new sorts: real, time, t-function (functions of time), and t-form 11Here, φ stands for a situation calculus formula (temporal formulas). In addition, we introduced a spe- with all situation arguments suppressed, for example cial function val to evaluate t-functions, a new kind hasMail(gerhard). φ[s] will denote the formula obtained of primitive action waitFor together with a domain- by restoring situation variable s to all fluents appearing in φ. independent precondition axiom, and a new fluent start 12 (the starting time of a situation) together with a suc- Again, we gloss over the issue of reifying formulas and cessor state axiom. programs in the logical language and refer to (Giacomo, Lesperance, & Levesque 1999) for details. 10 13 Note that val(robotLoc(s),t0) is well-defined since every Indeed, it necessitates a second order axiomatization t-function has a name (constant or linear) with correspond- of Trans; see (Giacomo, Lesperance, & Levesque 1999) for ing axioms for val as given above. details. Final(seq(σ1, σ2),s) ≡ Final(σ1,s) ∧ Final(σ2,s) cc-Golog: a Continuous, Concurrent Final(if(φ, σ1, σ2),s) ≡ Golog φ[s] ∧ Final(σ1,s) ∨ ¬φ[s] ∧ Final(σ2,s) Let us now turn to cc-Golog, which is a variant of de- Final(while(φ, σ),s) ≡ ¬φ[s] ∨ Final(σ, s) terministic ConGolog and which is founded on our new extension of the situation calculus. Final(par(σ1, σ2),s) ≡ Final(σ1,s) ∧ Final(σ2,s) First, for reasons discussed below we slightly change Final(prio(σ1, σ2),s) ≡ Final(σ1,s) ∧ Final(σ2,s) the language by replacing the instructions par and prio ′ by the constructs tryAll and withPol, respectively. In- Trans(α,s,δ,s ) ≡ 1 2 1 ′ tuitively, tryAll(σ , σ ) starts executing both σ and Poss(α, s) ∧ δ = nil ∧ s = do(α, s) σ2; but unlike par, which requires both σ1 and σ2 to Trans(nil,s,δ,s′) ≡ false reach a final state, the parallel execution of tryAll stops as soon as one of them reaches a final state. As for Trans(φ?,s,δ,s′) ≡ φ[s] ∧ δ = nil ∧ s′ = s withPol(σ1, σ2), the idea is that a low priority plan σ2 ′ Trans(seq(σ1, σ2),s,δ,s ) ≡ is executed, which is interrupted whenever the program ′ Final(σ1,s) ∧ Trans(σ2,s,δ,s )∨ σ1, which is called a policy, is able to execute. The ex- ′ ′ ′ ′ ∃δ .T rans(σ1,s,δ ,s ) ∧ δ = seq(δ , σ2) ecution of the whole withPol construct ends as soon ′ Trans(if(φ, σ1, σ2),s,δ,s ) ≡ as σ2 ends. (Note that prio is just like withPol except ′ φ[s] ∧ Trans(σ1,s,δ,s )∨ that for prio to end both σ1 and σ2 need to have ended.) ′ ¬φ[s] ∧ Trans(σ2,s,δ,s ) tryAll and withPol are inspired by similar instruc- tions in rpl where they have been found very useful Trans while φ, σ ,s,δ,s′ ( ( ) ) ≡ in specifying complex concurrent behavior. In particu- γ.δ seq γ,while φ, σ φ s ∃ = ( ( )) ∧ [ ]∧ lar, withPol is useful to specify the execution of a plan Trans σ,s,γ,s′ ( ) while guarding certain constraints. As we will see later, ′ Trans(par(σ1, σ2),s,δ,s ) ≡ it is quite straightforward to define par and prio us- ′ ∃γ.δ = par(γ, σ2) ∧ Trans(σ1,s,γ,s )∨ ing the new instructions. On the other hand, defining ′ ∃γ.δ = par(σ1,γ) ∧ Trans(σ2,s,γ,s ) tryAll and withPol in terms of par and prio appears ′ par Trans(prio(σ1, σ2),s,δ,s ) ≡ to be more complicated. Hence we decided to trade ′ prio ∃γ.δ = prio(γ, σ2) ∧ Trans(σ1,s,γ,s )∨ and for their siblings. ′ ∃γ.δ = prio(σ1,γ) ∧ Trans(σ2,s,γ,s )∧ Let us now turn to the semantics of cc-Golog, which ′ ′′ ′ ′′ 6 ∃γ ,s .T rans(σ1,s,γ ,s ) means finding appropriate definitions for Final and Trans. To start with, the semantics remains exactly Intuitively, a program cannot be in its final state if the same for all those constructs inherited from deter- there is still a primitive action to be done. Similarly, ministic ConGolog. Note that this is also true for the new waitFor(φ), which is treated like any other primi- a concurrent execution of two programs is in its final 14 state if both are. As for Trans, let us just look at par: tive action. Hence we are left to deal with tryAll and a transition of two programs working in parallel means withPol. that one action of one of the programs is performed. It is straightforward to give Final its intended A final situation s′ reachable after a finite number of meaning, that is, tryAll ends if one of the two pro- transitions from a starting situation is identified with grams ends and withPol ends if the second program the situation resulting from a possible execution trace ends: of program σ, starting in situation s; this is captured Final(tryAll(σ1, σ2,s)) ≡ Final(σ1,s)∨Final(σ2,s) by the predicate Do(σ,s,s′), which is defined in terms Final(withPol(σ1, σ2),s) ≡ Final(σ2,s) of Trans∗, the transitive closure of Trans: When considering the transition of concurrent pro- ′ ′ ∗ ′ ′ ′ ′ grams, care must be taken in order to avoid conflicts Do(δ,s,s ) ≡ ∃δ .T rans (δ,s,δ ,s ) ∧ Final(δ ,s ) with the assumption that actions should happen as soon Trans∗(δ,s,δ′,s′) ≡ ∀T [... ⊃ T (δ,s,δ′,s′)] as possible, which underlies our new version of the situ- ation calculus. To see why let us consider the following where the ellipsis stands for the conjuction of the example, where we want to instruct our robot to run a following formulas: backup at time 8 or 20, whichever comes first. Let us assume we have a continuous fluent clock representing T (δ,s,δ,s) the time15 and let runBackup be always possible. Given Trans(δ,s,δ′′,s′′) ∧ T (δ′′,s′′,δ′,s′) ⊃ T (δ,s,δ′,s′) 14The reader familiar with ConGolog may wonder whether Given a program δ, proving that δ is executable a test action φ? is the same as waitFor(φ). This is not so. in the initial situation then amounts to proving Σ |= Roughly, the main difference is that tests have no effect on ∃sDo(δ, S0,s), where Σ consists of the above axioms the world while waitFor advances the time. for ConGolog together with a basic action theory in the 15This can be modeled using a simple linear function, but situation calculus. we ignore the details here. ′ our intuitive reading of tryAll, we may want to use the Trans(withPol(σ1, σ2),s,δ,s ) ≡ ¬Final(σ2,s)∧ ′ following program: ∃δ1.T rans(σ1,s,δ1,s ) ∧ δ = withPol(δ1, σ2)∧ ′ ∀δ2,s2.T rans(σ2,s,δ2,s2) ⊃ start(s ) ≤ start(s2)] seq tryAll , , ′ ( (waitFor(clock = 8) waitFor(clock = 20)) ∨ ∃δ2.T rans(σ2,s,δ2,s ) ∧ δ = withPol(σ1,δ2)∧ ′ runBackup) ∀δ1,s1.T rans(σ1,s,δ1,s1) ⊃ start(s ) < start(s1)] If we start the program at time 0 we would expect to This then ends the discussion of the semantics of see Trans in cc-Golog. Trans∗ and Do(δ,s,s′) are defined the same way as in ConGolog. [waitFor(clock=8),runBackup] One issue left open is to show how a policy can run in as the only execution trace, since time 8 is reached blocking mode. This can be arranged using the macro first. (Recall that tryAll finishes as soon as one of its withCtrl(φ, σ), which stands for σ with every primitive arguments finishes.) However, this is not necessarily action or test α replaced by if(φ, α, false?).17 guaranteed. In fact, the obvious adaptation of Con- Intuitively withCtrl(φ, σ) executes σ as long as φ is 16 Golog’s Trans-definition of par to the case of tryAll true, but gets blocked otherwise. As the following ex- also yields the trace ample shows, the effect of a policy in blocking mode is [waitFor(clock=20),runBackup]. obtained by having the truth value of φ be controlled by the policy and using the withCtrl(φ, σ)-construct in This is because there simply is no preference enforced the low priority program. between the two waitFor-actions. As the following defi- This leads us, finally, to the specification of our nition shows, it is not hard to require that actions which initial example in cc-Golog. In the following we can be executed earlier are always preferred, restoring assume a fluent wheels, which is initially true, the original idea that actions should happen as early as set false by grabWhls, and reset by the action possible. releaseWhls. We also use whenever(φ, σ) as short- ′ Trans(tryAll(σ1, σ2),s,δ,s ) ≡ hand for while(true, seq(waitFor(φ), σ)). ¬Final(σ1,s) ∧ ¬Final(σ2,s)∧ ′ ∃δ1.T rans(σ1,s,δ1,s ) ∧ δ = tryAll(δ1, σ2)∧ withPol(whenever(battLevel ≤ 46, ′ ∀δ2,s2.T rans(σ2,s,δ2,s2) ⊃ start(s ) ≤ start(s2)] seq(grabW hls, chargeBatteries,releaseWhls)18), ′ ∨ ∃δ2.T rans(σ2,s,δ2,s ) ∧ δ = tryAll(σ1,δ2)∧ withPol(whenever(nearDoorA-118, ′ ∀δ1,s1.T rans(σ1,s,δ1,s1) ⊃ start(s ) ≤ start(s1)] seq(say(hello), waitFor(¬nearDoorA-118))) We are left with defining Trans for withPol. To see withCtrl(wheels, deliverMail))) what is involved, let us consider the following example withPol(watchB, deliverMail), where Figure 2: The introductory example as cc-Golog plan. watchB = seq(waitFor(battLevel ≤ 46), chargeBatt). The idea is to deliver mail and, with higher priority, In this program, the outermost policy is waiting un- watch for a low battery level, at which point the bat- til the battery level drops to 46. At this point, a teries are charged. In the discussion of a similar sce- grabWheels is immediately executed, which blocks the nario written in rpl, we already pointed out that the execution of the program deliverMail. It is only after waitFor-action should not block the mail delivery even the complete execution of chargeBatteries that wheels though it belongs to the high priority policy. On the gets released so that deliverMail may resume execution other hand, once the routine for charging the batteries (if, while driving to the batterie docking station, the starts, it should not be interrupted, that is, it should robot passes by RmA − 118, it would still say “hello”). Note that the cc-Golog-program is in a form very close run in blocking mode, which should also hold for possi- rpl ble waitFor-actions it may contain such as waiting for to the original -program we started out with. Hence arrival at the docking station. It turns out that it suf- we feel that cc-Golog is a step in the right direction fices to arrange in the semantics of Trans that occur- towards modeling more realistic domains which so far rences of waitFor within a policy are considered non- could only be dealt with in non-logic-based approaches. blocking. As we will see below, the effect of a policy Moreover, with their rigorous logical foundation, it is running in blocking mode is definable by other means. now possible to make provable predictions about how Interestingly, the resulting axiom is almost identical the world evolves when executing cc-Golog-programs. to that of tryAll: the main difference is that ≤ is re- (See also the next section on experimental results.) 17 placed by < in the last line. This ensures that σ1 takes We remark that if(φ, α, false?) can only lead to a tran- precedence if both σi are about to execute an action at sition if φ is true in the current situation at which point the same time. α is executed immediately. This is essentially due to the fact that false? is neither F inal nor can it ever lead to a 16 Roughly, replace par by tryAll and add ¬F inal(σ1,s) transition (see (Giacomo, Lesperance, & Levesque 1999)). 18 and ¬F inal(σ2,s) as additional conjuncts on the definition’s seq(σ1,σ2,σ3) is a shorthand for seq(σ1,seq(σ2,σ3)). R.H.S. We will also use a similar shorthand for tryAll. Finally, let us briefly consider how par and prio which we dropped in favor of tryAll and withPol Library are definable within cc-Golog. Let us assume fluents A-110 A-112 flgi which are initially false and set true by setFlgi. A-111 A-114 Then we can achieve what amounts to par(σ1, σ2) by A-113 tryAll(seq(σ1,setFlg1,flg2?),seq(σ2,setFlg2,flg1?)). Note that the testing of the flags at the end Hallway of each program forces that both σi need Classroom to finish. Similarly, prio can be defined as A-120 A-119 A-117 withPol(seq(σ1,setFlg),seq(σ2,flg?)). A-121 We end this section with some remarks on Re- A-118 iter’s proposal for a temporal version of GOLOG (Re- iter 1998),19 which makes use of a different tempo- ral extension of the situation calculus (Pinto 1997; Reiter 1996). Roughly, the idea is that every primi- Figure 3: The robot environment tive action has as an extra argument its execution time. E.g., we would write endGo(20) to indicate that endGo is executed at time 20. It turns out that this explicit • The introductory example (Fig. 2). We assumed that mention of time is highly problematic when it comes there are two letters to be delivered and that the to formulating programs such as the above. Consider delivery is once interrupted by low battery voltage. the part about saying “hello” whenever the robot is • The (slightly modified) example of (Beetz & near Room A-118. In Reiter’s approach, the program- Grosskreutz 1998). Again, the robot is to deliver let- mer would have to supply a temporal expression as an ters. But at the same time, it has to monitor the state argument of the say-action. However, it is far from of the environment, that is it has to check wether obvious what this expression would look like since it in- doors are open. As soon as it realizes that the door volves analyzing the mail delivery subprogram as well to A-113 is open, it has to interrupt its actual de- as considering the odd chance of a battery recharge. In livery in order to deliver an urgent letter to A-113. a nutshell, while Reiter’s approach forces the user to This is specified as a policy that leads the robot in- figure out when to act, we let cc-Golog do the work. side A-113 as soon as the opportunity is recognizes. — As a final aside, we remark that waitFor-actions al- Note that in the implementation, we used PROLOG low us to easily emulate Reiter’s approach within our lists ([a1,a2,...]) instead of seq(a1,a2, ...). framework. withPol(whenever(inHallway, Experimental Results [say(enterHW), tryAll([whenever(nearDoor(a-110), Although the definition of cc-Golog requires second- [checkDoor(a-110+121),false?])], order logic, it is easy to implement a PROLOG in- [whenever(nearDoor(a-111), terpreter for cc-Golog, just as in the case of the orig- [checkDoor(a-111+120),false?])], inal ConGolog.20 In order to deal with the constraints [whenever(nearDoor(a-112), implied by the waitFor instruction, we have made [checkDoor(a-112+119),false?])], [whenever(nearDoor(a-113), use of the ECRC Common Logic Programming Sys- [checkDoor(a-113+118),false?])], tem Eclipse 4.2 and its built-in constraint solver library [whenever(nearDoor(a-114), clpr to implement a cc-Golog interpreter (similar to [checkDoor(a-114+117),false?])], Reiter (Reiter 1998)). [waitFor(leftHallway), We used three example plans to compare the per- say(leftHW)])]), formance of our cc-Golog interpreter with earlier work withPol([useOpp?, on the projection of continuous change (Beetz & gotoRoom(a-113),deliverUrgentMail], Grosskreutz 1998) within the xfrm (McDermott 1992; [gotoRoom(a-118),giveMail(gerhard)]))). 1994) framework. As an example environment, we use the one of (Beetz & Grosskreutz 1998), depicted in Fig- The outer policy is activated whenever the robot en- ure 3. We approximated the robot’s trajectory by poly- ters the hallway. It concurrently monitors whether lines, consisting of the starting location, the goal loca- the robot reaches a location near a door, whereat is tion and a point in front of and behind every passed checks whether the door is open or not. If A-113 doorway (similar to (Beetz & Grosskreutz 1998)): is detected to be open, the fluent useOpp is set true 19 (by procudure checkDoor). The policy is deactivated While the paper is about sequential GOLOG, the exten- sion to ConGolog is straightforward. when the robot leaves the hallway. 20The subtle differences between the second order axiom- The inner policy is activated as soon as useOpp gets atization of ConGolog and a PROLOG implementation are true. It’s purpose is to use the opportunity to enter discussed in (Giacomo, Lesperance, & Levesque 1999). A-113 as soon as possible. Figure 3 illustrates the projected trajectory, assuming that the door to A- due to Pinto and a novel approach to modeling the pas- 113 is open. sage of time using a special waitFor-action. We then cc-Golog ConGolog • A longer trajectory through all rooms. considered , a deterministic variant of which is based on the extended situation calculus. A withPol(whenever(inHallway, key feature of the new language is the ability to have [say(enterHW), part of a program wait for an event like the battery [say(enterHW), voltage dropping dangerously low while other parts of tryAll([whenever(nearDoor(a-110), the program run in parallel. Such mechanisms allow [checkDoor(a-110+121),false?])], very natural formulations of robot controllers, in par- ...]), ticular, because there is no need to state explicitly in [gotoRoom(a-114),say(a-114), gotoRoom(a-113),say(a-113), the program when actions should occur. In addition to gotoRoom(a-112),say(a-112), the sound theoretical foundations on which cc-Golog is gotoRoom(a-111),say(a-111), built, experimental results have shown a superior per- gotoRoom(a-110),say(a-110), formance in computing projections when compared to gotoRoom(a-117),say(a-117), the projection mechanism of the plan language rpl, gotoRoom(a-118),say(a-118), whose expressive power has largely motivated the de- gotoRoom(a-119),say(a-119), velopment of cc-Golog. gotoRoom(a-120),say(a-120), However, much remains to be done. For one, sens- gotoRoom(a-121),say(a-121) ing actions need to be properly integrated into this ]))))) approach. Here we hope to benefit from existing ap- proaches in GOLOG and ConGolog (Lakemeyer 1999; Figure 4 shows the time it took to generate a projec- de Giacomo & Levesque 1998). Also, uncertainty plays tion of the example plans using cc-Golog resp. xfrm, a central role in the robotics domain which should as well as the number of actions resp. events occur- be reflected in a plan language as well. Based on ing in the projection. Both cc-Golog and xfrm run foundational work within the situation calculus (Bac- on the same machine (a Linux Pentium III Worksta- chus, Halpern, & Levesque 1995) first preliminary re- tion), under Allegro Common Lisp Trial Edition 5.0 sults have been obtained regarding an integration into resp. Eclipse 4.2. As it turns out, cc-Golog appears ConGolog (Grosskreutz 1999; Grosskreutz & Lakemeyer to be faster by an order of magnitude than xfrm. We 2000). believe that cc-Golog owes this somewhat surprising ad- Finally, a few words are in order regarding the use of vantage to the fact that it lends itself to a simple imple- projections in cc-Golog. They should be understood as mentation with little overhead, while xfrm relies on the a way of assessing whether a program is executable in rather complex rpl-interpreter involving many thou- principle. The resulting execution trace of a projection sand lines of Lisp code. is not intended as input to the execution mechanism of the robot. This is because the time point of a waitFor- condition like a low battery level is computed based Problem: cc-Golog xfrm on a model of the world which includes a model of the Intro. Ex. 0.4 s / 115 acts - robot’s energy consumption. In reality, of course, the AIPS-98. Ex. 0.5 s / 73 acts 3.6 s / 106 evs robot should react to the actual battery level by period- Long Traj. 3 s / 355 evs 22.7 / 486 evs ically reading its voltage meter. In the runtime system of rpl for an actual robot (Thrun et al. 1999) this link Figure 4: Runtime in seconds between waitFor-actions and basic sensors which are immediately accessible to the robot has been realized. One possibility to actually execute cc-Golog-programs cc-Golog It also seems noteworthy that contents it- on a robot would be to combine this idea of execut- self with significantly less predicted relevant events (i.e. xfrm ing waitFor’s with an incremental interpreter along the atomic actions) than . This results from the fact lines of (de Giacomo & Levesque 1999). We leave this cc-Golog that only predicts an action if an action is actu- to future work. ally executed (unlike xfrm, which also projects events whose only purpose is to test if actual changes occur, References like the “reschedule” events; see (Beetz & Grosskreutz 1998)). Finally, and maybe most importantly, the cc- Bacchus, F.; Halpern, J.; and Levesque, H. 1995. Rea- Golog implementation is firmly based on a logical speci- soning about noisy sensors in the situation calculus. In fication, while xfrm relies on the procedural semantics IJCAI’95. of the rpl interpreter. Beetz, M., and Grosskreutz, H. 1998. Causal models of mobile service robot behavior. In AIPS’98. Conclusions Burns, A., and Wellings, A. 1991. Real-time systems In this paper we proposed an extension of the situation and their programming languages. Addison-Wesley. calculus which includes a model of continuous change de Giacomo, G., and Levesque, H. 1998. An incremental interpreter for high-level programs Pinto, J. 1997. Integrating discrete and continuous with sensing. Technical Report 861, Depart- change in a logical framework. Computational Intelli- ment of Computer Science, Univ. of Toronto, gence, 14(1). http://www.cs.toronto.edu/cogrobo/. Reiter, R. 1996. Natural actions, concurrency and de Giacomo, G., and Levesque, H. 1999. An incremen- continuous time in the situation calculus. In Proc. tal interpreter for high-level programs with sensing. In KR’96, 2–13. Levesque, H., and Pirri, F., eds., Logical Foundations Reiter, R. 1998. Sequential, temporal golog. In Proc. for Cognitive Agents. Springer. 86–102. KR’98. de Giacomo, G.; Lesperance, Y.; and Levesque, H. J. Sandewall, E. 1989. Combining logic and differential 1997. Reasoning about concurrent execution, priori- equations for describing real-world systems. In KR’89. tized interrupts, and exogeneous actions in the situa- Shanahan, M. 1990. Representing continuous change tion calculus. In IJCAI’97. in the event calculus. In ECAI’90. Firby, J. 1987. An investigation into reactive planning Thrun, S.; Bennewitz, M.; Burgard, W.; Dellaert, F.; in complex domains. In Proc. of AAAI-87, 202–206. Fox, D.; Haehnel, D.; Rosenberg, C.; Roy, N.; Schulte, Galton, A. 1990. A critical examination of allen’s the- J.; and Schulz, D. 1999. Minerva: A second-generation ory of action and time. Artificial Intelligence 42:159– museum tour-guide robot. In ICRA’99. 188. Giacomo, G. D.; Lesperance, Y.; and Levesque, H. J. 1999. Congolog, a concurrent program- ming language based on the situation calculus: foun- dations. Technical report, University of Toronto, http://www.cs.toronto.edu/cogrobo/. Grosskreutz, H., and Lakemeyer, G. 2000. Turning high-level plans into robot programs in uncertain do- mains. In Submitted. Grosskreutz, H. 1999. Probabilistic temporal projec- tions in congolog. In Proc. of the IJCAI’99 Workshop on Robot Action Planning. Konolige, K. 1997. Colbert: A language for reactive control in sapphira. In KI’97, volume 1303 of LNAI. Lakemeyer, G. 1999. On sensing and off-line inter- preting in golog. In Levesque, H., and Pirri, F., eds., Logical Foundations for Cognitive Agents. Springer. Levesque, H. J.; Reiter, R.; Lesprance, Y.; Lin, F.; and Scherl, R. 1997. Golog: A logic programming language for dynamic domains. Journal of Logic Programming 31:59–84. Levesque, H.; Pirri, F.; and Reiter, R. 1998. Foundations for the situation calculus. Link¨oping Electronic Articles in Computer and Informa- tion Science Vol. 3(1998): nr 018. URL: http://www.ep.liu.se/ea/cis/1998/018/. McCarthy, J. 1963. Situations, actions and causal laws. Technical report, Stanford University. Reprinted 1968 in Semantic Information Processing (M.Minske ed.), MIT Press. McDermott, D. 1992. Robot planning. AI Magazine 13(2):55–79. McDermott, D. 1994. An algorithm for prob- abilistic, totally-ordered temporal projection. Re- search Report YALEU/DCS/RR-1014, Yale Univer- sity, www.cs.yale.edu/AI/Planning/xfrm.html. Miller, R. 1996. A case study in reasoning about actions and continuous change. In ECAI’96.