Projection Tests at Work

Using Lookahead within test conditions, a cc-Golog plan can check whether a possible behavior would lead to certain conditions, and thus deliberate over different possible subplans. In addition, the lookahead can be limited to a certain amount of time t, which seems very

useful in order to make quick decisions. A possible application of this test, illustrated by the following program, would be to check if the battery level is going to drop below 46V in the next 300 seconds if the robot comes close to the battery docking station:

proc(Πlookahead,

withPol(whenever(nearDockingStation,

if(Lookahead(lowBattLevel, start(now ) + 300, deliverMail, navProc), [grabWheels, chargeBatteries, releaseWheels])),

withCtrl(wheels, deliverMail))).

Here, we use lowBattLevel as an abbreviation for an expression that is true if and only if the value of battLevel is below 46V in the projected execution trace.

Let us now consider an on-line execution of Πlookahead, assuming that the robot’s initial

position is in Room 6213, that the battery docking station is in Room 6204, and that there are two letters to be delivered, one to Room 6205 and one to Room 6214, just as in the example illustrated in Figure 4.5 on page 78. This time however, the robot does not wait until the battery level drops below 46V before it reacts, but instead makes use of the lookahead construct. The resulting on-line execution trace is visualized in Figure 5.6. We remark that the behavior exhibited by the high-level plan making use of a projection test is superior to the behavior illustrated in Figure 4.5; in particular, the length of the overall trajectory is shorter. 2 4 3 1

Rm 6205

BattStation

Proj:

Rm 6214

Figure 5.6: Delivery with lookahead

Let us now take a closer look at the resulting on-line execution trace. Up to the node

marked “1”, the execution runs in a similar way as the previous examples. Let Slookahead refer

to the situation where nearDockingStation becomes true, that is to the situation where the

robot has just reached node “1”. Furthermore, let us assume that in Slookahead the battery

level is quite low (recall that the actual voltage level is provided by ccUpdate actions; see Section 5.1.1). At this point, the high-level controller running in on-line execution mode will evaluate Lookahead(lowBattLevel, start(now ) + 300, deliverMail, navProc), that is, it will project the effects of deliverMail. The projection test will look for a successor configuration

5.3. DISCUSSION 93 this configuration the battery level is below 46 V. Formally, this means that the projection test will verify:

Γ|= ∃σ∗_{, s}∗_.Trans∗_{(withPol(navProc, deliverMail), do(clipOnline, S}

lookahead), σ∗, s∗)∧

[∀σ∗∗, s∗∗.Trans∗(σ∗, s∗, σ∗∗, s∗∗)⊃ start(s∗∗) > start(Slookahead) + 300∨

Final(σ∗, s∗)]∧

start(s∗)≤ start(Slookahead) + 300∧

[battLevel≤ 46][s∗, start(Slookahead) + 300].

Assuming that the above holds, the high-level controller then interrupts deliverMail in Slookahead to first charge its batteries (node “2”). Thereafter, it completes the delivery.

Another possible application of the Lookahead construct arises in the context of multi-

robot control (cf. [ACF+98, AFH+98]). Suppose a user makes a request to have a letter

delivered by one of several courier robots. In order to determine which robot should deliver the letter, each robot might use projection to determine the cost that would arise if it were to carry out this job, and the task could then be assigned to the robot with a minimal cost estimate.

5.3

Discussion

In summary, we have extended cc-Golog so that it becomes suitable for both projections of plans and their on-line execution. To account for the fact that time advances differently in projections and during on-line execution, we explicitly distinguished between the two modes of operation. In particular, during on-line execution we make use of exogenous ccUpdate actions to frequently update the value of continuous fluents like robotLoc, and treat waitFor instructions simply as a special kind of test. Finally, we have shown how to interleave on-line execution and a form of time-bounded projection.

As mentioned before, the idea of interleaving projection and on-line execution was first explored by de Giacomo and Levesque [dGL99b]. However, they consider neither time nor the idea of low-level processes which interact with a high-level controller in complex ways. Most importantly, there is no distinction between the effects on fluents during projection and on-line execution, a distinction we feel is necessary when it comes to modeling essential features of

mobile robots such as their location at a given time. Lesp´erance and Ng [LN00] have extended

de Giacomo and Levesque’s ideas in a direction which bears some resemblances to ours. They propose that during projection one also needs to consider a simulated environment which, for example, produces exogenous actions to inform the high-level controller that the destination is reached. However, their notion of a simulated environment remains fairly simple since they are not able to model temporally extended processes, and they also do not distinguish between the effects on fluents during projection and on-line execution.

While the approach of [dGL99b] provides nondeterministic instructions, in cc-Golog de- liberation over different sub-plans is only possible by means of explicit projection tests. This scheme is certainly neither as elegant nor as expressive as the use of nondeterministic in- structions. However, the explicit use of constructs like Lookahead gives the user finer-grained control over the amount of projection involved in the execution of a plan, which is useful when dealing with limited resources. Finally, using projection tests it is possible to specify a program which first projects the successful execution of a program P , but then executes

where (potentially) every robot will project that it can carry out the next job, but only one robot will actually do so.

The idea to distinguish between the plan time effects and the run time effects of an action is also present in [BP98], where both the plan time effects and the run time effects of an action on the knowledge of an agent is modeled. As for the ccUpdate actions, we remark that they represent a kind of “passive” sensing, where sensory information continually becomes available without the need for an explicit request, as opposed to more classical approaches to sensing like [GW96, Lev96, WAS98]. This view of sensing is somewhat similar to that of Poole [Poo96, Poo98], and de Giacomo and Levesque [dGL99a], where sensing functions are used to represent on-board sensors that provide sensor readings at any time. However, while in [dGL99a] projection is defined in terms of histories, which intuitively consist of a situation and a formula representing the values of the sensors in each situation, we manage solely with a situation enriched with an arbitrary number of ccUpdate actions.

Chapter 6

pGOLOG - Dealing with

Probabilistic Uncertainty

In the previous chapters, we have assumed that all low-level processes have deterministic effects. In particular, there is no uncertainty about whether or not a low-level process achieves the desired results. However, an important feature of real robot environments is the inherent uncertainty in what the world is like and the outcome of many of a robot’s low-level processes, due to the fact that robot hard- and software is imperfect and error-prone. For example, if a robot tries to pickup a cup, many different outcomes are possible: the robot may completely miss the cup, the cup may drop on the floor, the robot may push adjacent objects or might even break the cup or an adjacent object. These outcomes typically occur with different probabilities. For example, the pickup may succeed perfectly about 80% of the time and may have some other outcomes with lower probability.

In this chapter, we will show how the GOLOG framework presented so far can be extended to allow the projection of high-level plans interacting with noisy low-level processes, based on a probabilistic characterization of the robot’s beliefs. In particular, we model low-level processes with uncertain outcome as probabilistic programs in a probabilistic extension of GOLOG which we call pGOLOG. The intuition is that the different probabilistic branches of the programs correspond to different outcomes of the processes. Given a faithful characterization of the low-level processes in terms of pGOLOG programs, we can then reason about the effects of their activation through simulation of the corresponding pGOLOG model. As a result of this probabilistic setting, projection now yields the probability of a plan to achieve a goal, which leads us to the notion of probabilistic projection.

To get a better feel for what we are aiming at, let us consider the following ship/reject- example, adapted from [DHW94]: We are given a manufacturing robot with the goal of having a widget painted (PA) and processed (PR). Processing widgets is accomplished by rejecting parts that are flawed (FL) or shipping parts that are not flawed. This can be done by means of the low-level processes ship and reject. The robot also has a low-level process paint that usually makes PA true. Initially, all widgets are flawed if and only if they are blemished (BL), and the probability of being flawed is 0.3.

Although the robot cannot tell directly if the widget is flawed, the low-level process inspect can be used to determine whether or not it is blemished. inspect reports OK (“not OK”) if the widget is blemished, and OK if not. The inspect process can be used to decide whether or not the widget is flawed because FL and BL are initially perfectly correlated. The use

of inspect is complicated by two things, however. (1) inspect is not perfect: if the widget is blemished, then 90% of the time it reports OK, but 10% of the time it erroneously reports OK. If the widget is not blemished, however, inspect always correctly reports OK. (2) Painting the widget removes a blemish but not a flaw, so executing inspect after the widget has been painted no longer conveys information about whether it is flawed. All low-level processes can always be activated, but may result in different effects. paint makes PA True (and BL False) with probability 0.95 if the widget was not already processed. Otherwise, it causes an execution error (ER). ship and reject always make PR True, ship makes ER true if FL holds, and reject makes ER True if FL does not hold. The goal of our manufacturing robot is to have the widget painted and processed with at least 90% probability.

In this scenario, an example projection task is the following: how probable is it that the plan “first inspect, then paint the widget; afterwards, if OK holds then ship else reject it” will falsely ship a flawed widget? In order to answer this kind of question, we have to represent the robot’s uncertainty about the initial state of the world, and must reason about low-level processes like paint which have uncertain outcomes. As mentioned above, we make use of probabilistic pGOLOG programs to model noisy low-level processes; for example, we model paint by a program which either causes PA to become true, or not. Besides, we have to deal with low-level processes like inspect which provide (noisy) information about the state of the world, i.e. we have to integrate sensing into our architecture. We call low-level processes like inspect “sensor processes.” Roughly, we deal with sensor processes as follows: during actual execution, we treat answers like OK as special exogenous actions. For the task of projection, on the other hand, we model the sensor processes by pGOLOG programs involving these special actions.

As for the representation of the uncertainty about the state of the world, we follow Bac- chus, Halpern and Levesque [BHL99] and characterize the robot’s epistemic state by a dis-

tribution over possible situations considered possible. While in general this probabilistic

representation of the robot’s beliefs would allow us to specify GOLOG-style plans whose tests and conditionals appeal to the robot’s real-valued beliefs, for means of simplicity in this chap- ter we do not allow plans involving conditionals like “if the robot’s belief that the widget is flawed is beyond 10%, then reject the widget.” Instead, we only consider plans whose actions are essentially conditioned on the answers provided by the sensor processes, like “OK” or “OK,” which we call directly observable. We will consider the issue of real-valued belief tests in the next chapter.

This chapter is organized as follows. In the next section, we define pGOLOG and show how low-level processes with uncertain outcome like paint can be modeled in pGOLOG. In Section 6.2, we extend the robot control architecture used in the previous chapters to account for uncertainty and sensing. Finally, in Section 6.3 we show how probabilistic projection works in pGOLOG, and briefly discuss the relation between probabilistic projection and the concept of expected utility.

6.1

pGOLOG: a Probabilistic GOLOG Dialect

As the above example illustrates, it is often convenient to model real-world processes as having different possible probabilistic outcomes. For example, the paint process might not be guaranteed to succeed, and this inaccuracy can naturally be modeled by assigning probabilities to different outcomes (e.g. success and failure). To take this into account, we introduce a new

6.1. PGOLOG: A PROBABILISTIC GOLOG DIALECT 97

sort probability ranging over the subset [0, 1] of the reals1 and extend cc-Golog with a new

probabilistic branching instruction: prob(p, σ1, σ2). Here, σ1 and σ2 are pGOLOG programs

and p is a probability which lies between 0 and 1, i.e. 0 < p < 1. The intended meaning of

prob(p, σ1, σ2) is to execute program σ1 with probability p, and σ2with probability 1− p. The

idea is to model noisy low-level processes through probabilistic programs, where the different probabilistic branches of the programs correspond to different outcomes of the processes. Altogether, the new language pGOLOG offers the following instructions:

α primitive action or waitFor

φ? wait/test action

[σ1, σ2] sequence

if(φ, σ1, σ2) conditional

while(φ, σ) loop

withCtrl(φ, σ) guarded execution

conc(σ1, σ2) prioritized execution

prob(p, σ1, σ2) probabilistic execution of either σ1 or σ2

{proc(P1( ~v1), β1); ...; proc(Pn( ~vn), βn); σ} procedures.

To illustrate the use of pGOLOG, we will now model the effects of the paint process by the pGOLOG program paintProc. Intuitively, if the widget is already processed, trying to paint it results in an error. Otherwise, paint will result in the widget being painted with probability 95%. There is also a 5% chance that although the widget is not processed, paint will remain effectless. In both probabilistic cases, a possible blemish is removed. To model the effects of paint, we make use of the fluents PA, FL, BL, PR and ER to represent the properties of our example domain, and assume successor state axioms that ensure that the truth value of PA is only affected by the primitive actions setPA and clipPA, whose effect is to make it True respectively False. Similarly for the other fluents. Here and in the remainder of this thesis, we use prob(p, σ) as a shorthand for prob(p, σ, nil).

paintProc= if(PR,setER, [clipBL, prob(0.95, setPA)]).

Given this characterization of the paint process, we can reason about the effects of its acti- vation through simulation of the pGOLOG model. We stress that pGOLOG programs like the above are not intended for actual execution. The purpose of pGOLOG programs like paintProc is to model the behavior of low-level processes as probabilistic programs, and thus to provide a faithful characterization of their effects on the world, similarly to the cc-Golog program navProc used in Section 4.3.2 as model of the navigation process.