Belief

Based on p, BHL define Bel(φ, s), the agent’s degree of belief that φ holds in situation s. As usual, φ stands for a situation calculus formula where now may be used to refer to the current situation. Formally, they define Bel(φ, s) = p as an abbreviation for the following term expressible in second-order logic:

X

s0:φ[s0]

p(s0, s)/X

s0

p(s0, s) = p.

Intuitively, Bel(φ, s) is the (normalized) sum of the degree of likelihood of all situations s0

considered possible in s that fulfill φ. Note that we are restricting ourselves to discrete

probability distributions, where the probability of a set can be computed as the sum of the probabilities of the elements of the set.

As an example, let us describe the initial belief state of a robot whose confidence to be

in room R1 is 90%, and which believes to be in room R2 else. In this situation, the world is

initially in one of two states, s1 and s2, which occur with probability 0.9 and 0.1, respectively. In this simple scenario, these are the only possibilities, all other situations have likelihood 0. The following axiom makes this precise together with what holds and does not hold in each of the two states:

∃s1, s2.∀s.s 6= s1∧ s 6= s2⊃ p(s, S0) = 0 ∧

p(s1, S0) = 9∧ p(s2, S0) = 1∧

robotLoc(s1) = R1∧ robotLoc(s2) = R2.

Chapter 4

cc-Golog – Dealing with Continuous

Change

Figure 4.1: Robot environment In real-world applications, high-level controllers typically

operate low-level processes which change the world in a

continuous fashion over time. Although it may some-

times seem reasonable to abstract away from the contin- uous change involved, for example to represent a pickup as causing discrete qualitative change, abstracting away from the actual continuous movement of the gripper, this is not always appropriate. For example, consider a robot operating in the north floor of the Computer Science De- partment V at Aachen University of Technology, illustrated in Figure 4.1. Here, dealing with event-driven actions like “say hello if you come near Door 6213” is both problematic and un-natural without taking into account the continuous trajectory caused by the navigation process.

In order to deal with continuously changing properties in a natural way, the non-logic- based robot programming languages RPL, RAP, PRS-Lite and Colbert introduced in Section 2.3 all offer a special wait-for instruction, which suspends activity until a condition appealing to continuously changing properties becomes true. As an example, consider the following RPL program: (with-policy (loop wait-for Batt-Level≤ 46 charge-batteries) (with-policy (loop wait-for near-door(Rm 6213) say(“hello”) wait-for¬near-door(Rm 6313)) deliver-mail))

Figure 4.2: Office delivery plan

Roughly, the robot’s main task is to deliver mail, which we merely indicate by a call to 55

the procedure deliver-mail. While executing this procedure, the robot concurrently also does the following, with an increasing level of priority: whenever it passes the door to Room 6213 it says “hello” and, should the battery level drop dangerously low, it recharges its batteries interrupting whatever else it is doing at this moment. Even this simple program exhibits important features of high-level robot controllers:

• The timing of actions is largely event-driven, that is, rather than explicitly stating when an action occurs, the execution time depends on certain conditions becoming true such as reaching a certain door. In this example, the specification of reactive behavior is realized using the wait-for construct.

• Actions are executed as soon as possible, that is, immediately after their precondition becoming true. For example, the batteries are charged immediately after a low voltage level is determined.

• Conditions such as the voltage level are best thought of as changing continuously over time.

• Parts of programs which execute with high priority must allow the execution of con- current sub-programs with lower priority, other parts must interdict the execution of concurrent sub-programs with lower priority. For example, while waiting for a low bat- tery level, mail delivery should continue. On the other hand, the actual charging of the battery should block the mail delivery. We will refer to high-priority sub-programs that interdict the execution of concurrent programs as blocking policies. In RPL, blocking policies are handled by having the different procedures (for example deliver-mail and charge-batteries) compete for a valve (cf. the discussion on page 34).

Given the inherent complexity of concurrent robot programs, answers to questions like whether a program is executable and whether it will satisfy the intended goals are not easy to come by, yet important to both the designer during program development and the robot who may want to choose among different courses of action. A principled approach to answering such questions is to project how the world evolves when actions are performed. Although the

xfrmsystem [McD92a, McD94] allows the projection of RPL plans like the above [BG98], it

relies on RPL’s run-time system, which lacks a formal semantics and which makes predictions implementation dependent. Preferably one would like a language which is as powerful as RPL yet allows for projections based on a perspicuous, declarative semantics. As for other non-logic-based robot control languages discussed in Section 2.3, they either model complex programs as primitive actions (like RAP), or do not consider projection at all.

Although ConGolog offers features such as concurrency and priorities, it turns out that in its current form it is not suitable to represent robot controllers such as the example above. The problem is that in its current form, the situation calculus on which it is based is only able to represent discrete change, and lacks the capability to express that a property like the robot’s position changes continuously over time. On the other hand, the existing temporal extension of GOLOG [Rei98] requires that the execution time of an action is supplied explicitly, which seems incompatible with event-driven specifications. Finally, it is not clear how to handle both blocking and non-blocking prioritized execution in ConGolog. In particular, ConGolog’s

(σ1ii σ2) construct simply blocks the execution of of σ2whenever σ1can execute (cf. page 43).

In this chapter, we will present an extension of GOLOG and the situation calculus which will allow the specification and projection of plans which react to continuously changing

4.1. CONTINUOUS CHANGE AND TIME 57 properties, similarly to the example of Figure 4.2. We proceed in three steps. First we present a new extension of the situation calculus which, besides dealing with continuous change, allows us to model actions which are event-driven by including a special action waitFor in the logic. We then turn to a new variant of ConGolog called cc-Golog, which is based on the extended situation calculus. In particular, cc-Golog comes with a new semantics for concurrent execution, which ensures that actions which can be executed earlier are always preferred. Unlike ConGolog, cc-Golog only provides deterministic instructions, which is due to anomalies which arise from the interaction of waitFor-actions, concurrency and nondeterminism.

Finally, we show how a robot control architecture where a high-level controller commu- nicates with low-level processes via messages (like the layered robot control architectures discussed in Section 2.3) can be modeled directly in cc-Golog. Thereby, we model complex low-level processes like the navigation process as cc-Golog programs. This allows a very fine- grained characterization of the effects of the low-level processes at a level of detail involving many atomic actions, in particular taking into account the temporal extent of low-level pro- cesses like the navigation process. Given a faithful characterization of the low-level processes in terms of cc-Golog programs, we can then reason about the effects of their activation through simulation of the corresponding cc-Golog model. The main advantage of having an explicit model of the robot control architecture is that there is a clear separation of the actions of the high-level controller from those of low-level processes. We remark that in this chapter, we are only concerned with how to project a cc-Golog plan. Actual (on-line) execution of cc-Golog plans will be the topic of the next chapter.

The rest of this chapter is organized as follows. In the next section, we show how to extend the basic situation calculus to include continuous change and time. Thereafter, we present cc-Golog which takes into account the extended situation calculus, in particular its notion of time and temporal precedence. Finally, we show how to model a layered robot control architecture, develop a cc-Golog model of a low-level navigation process, and show how the example-program can be specified quite naturally in cc-Golog with the additional benefit of supporting projections firmly grounded in logic.

4.1

Continuous Change and Time

Actions in the situation calculus cause discrete changes and, in its basic form, there is no notion of time. In robotics applications, however, we are faced with processes such as naviga- tion which cause properties like the robot’s location and orientation to change continuously over time. In order to model such processes in the situation calculus in a natural way, we add continuous change and time directly to its ontology.