Características del producto

To deal with incomplete knowledge about the environment, GOLOGwas extended with sensing actions (Lakemeyer 1999; De Giacomo and Levesque 1999). These special actions allow an agent to query its sensors so as to gather information about the environment. This approach has, under certain circumstances, several drawbacks. When sensor values must be updated very frequently, acquiring world information through sensing actions is not feasible. The agent is busy with execut- ing sensing actions most of the time. Another problem occurs when off-line planning is interleaved with on-line execution. If the plan relies on the on-line information, the result of planning might be inconsistent due to wrong sensing results. It is generally not possible to plan ahead of sensing actions when deploying an active sensing approach. As we discussed in the previous section this is the main disadvantage of Soutchanski’s on-lineDTGOLOGapproach.

What is needed is a passive sensing approach which performs updates of the sensor values in the background. Proposals for passive sensing approaches are e.g. (Poole 1997; Grosskreutz and Lakemeyer 2001).

Our approach to passive sensing is based on (Grosskreutz and Lakemeyer 2001). They propose a system architecture where the high-level controller starts low-level processes via a so-called action register. (We already discussed this issue; nevertheless we recap their system architecture for a coherent presentation of the matter here). To initiate an action the high-level controller sends a command to the register. This command is passed through to the execution module which in turn takes care for executing of the action in the real world. From now on, the high-level controller is no longer concerned with monitoring the execution of the action. This is done asynchronously by the execution layer. When the execution of the action is finalized, the low-level control indicates this by sending a reply message to the high-level controller via the action register. The high- level controller can now react on this specific message. Between a send and a reply message the high-level controller is free for other tasks. The communication between high-level and low-level system is realized through a special fluent register and the two actions send and reply. The high- level controller invokes the low-level process with settling a send action, the low-level process answers with a reply message when the low-level process is finished (This becomes more evident in Chapter 4.4 when discussing the implementation ofsend and reply).

With this form of communication one has to distinguish between two modes: The on-line execution and the off-line projection task. During on-line execution the fluent register simply blocks until the low-level system has executed the command in the real world. Making use of prioritized concurrency the high-level controller can go on with its program. When projecting, a model of the low-level process is executed. The register fluent is also used to synchronize sensor updates in the background. With a special ccUpdate action an exogenous event is raised which does the sensor update. In the off-line mode the fluents are updated according to a low-level process of the currently executed action, during on-line execution the real sensor value is used.

When dealing with a large amount of world-model information like in robotic soccer the inte- gration of the update action takes longer than the decision cycle of the agent. Updating a complete world model in the simulated soccer domain, for example, takes more than100 ms which is longer than the decision cycle in the SIMULATIONLEAGUE(cf. Chapter 5.2). To deal with this problem we extended the system architecture proposed in (Grosskreutz and Lakemeyer 2001) by an explicit world model. To access the data stored in the world model we introduce a new fluent type, the so-called on-line fluent. The difference to ordinary fluents is that they are directly connected to the world model. They are initialized with the value undefined . With a special action exogfUpdate3

one can update the respective fluents. When the action exogfUpdate is executed a copy of the real sensor data at that specific moment in time is copied to the internal world model of the READY- LOGagent. In Figure 4.5 we present the extended system architecture. As in (Grosskreutz and Lakemeyer 2001) we use the special register fluent and the message passing between high-level and low-level control. The presence of an explicit world model extends the architecture. The special action exogfUpdate which is sent via the register initiates an update of the world model of the agent. The shaded arc “world” denotes the connection to the real world. One has to think of this as a rather complex layered system architecture which has access to the actuators and can gather data from the sensors.4 _{What is needed is that information taken from the real world can}

3_{The idea behind this action is very similar to the}

ccU pdate action proposed in (Grosskreutz and Lakemeyer 2001).

The difference is how this action is handled by the READYLOGinterpreter (see Chapter 4.4).

4.2. ON-LINE DT PLANNING WITH PASSIVE SENSING 79 send reply exogfUpdate low−level processes high−level controller reg(dstRm) reg(reached) . . . WORLD world model

Figure 4.5: The Extended Architecture

be updated asynchronously on demand.5_{The possibility to asynchronously update sensor values}

allows for on-line passive sensing. In the on-line execution mode of the interpreter, sensor updates arrive synchronously, or when they are explicitly triggered with an exogfUpdate action. Note that there are no mechanisms provided to check consistency of the world model information. In the domain implementation one has to check for consistency. In the off-line projection mode the last world state is taken and projected with the low-level processes. This simple method provides the interpreter with an efficient form of a passive sensing facility.

With this form of on-line passive sensing regression of on-line fluents is no longer possi- ble. Regression is the process of reducing a formula with a complex situation term to a formula mentioning onlyS0for sort situation. But with on-line fluents which are updated with each occur-

rence of the action exogfUpdate it is not possible to regress an action history over an occurrence of exogfUpdate. Consider the following example. Letf1(do(a, s)) = v ≡ a = a1∧ v =

f2(s) + 1 ∨ a 6= a1∧ v = f1(s) be the successor state axiom of the fluent f1withf1(S0) = 0,

and letf2be an on-line fluent which is updated by the exogfUpdate action to take the value1,

i.e. f2(do([exogfUpdate], s0)) = 1. Now suppose the action a1has been performed. Then,

f1(do([a1, exogfUpdate], s0)) = 2. If another update action changes the fluent value of f2to, say

0, the result of regressing the fluent value for f1should be be1 but in fact the value of f1is still2.

The reason is that not the whole world model is stored for each update action. It takes only the ref- erence to the last world model update. So, care has to be taken when using on-line fluents. When only on-line fluents are used the problem does not exist when fluents are not regressed further as the last update action. This yields a fast method to access values for on-line fluents, but in general correctness cannot be guaranteed. To solve this problem, we have to use progression instead. With progression a new initial database is computed. Progression is also indispensable for long-time operations of a READYLOGinterpreter and we discuss our approach to progression in Chapter 4.4. So why does progression solve our problem here? When a new initial database is calculated each time a world model update action is performed one can guarantee that no fluent refers to an old on-line fluent value. For off-line projections or decision-theoretic planning which makes use of regression to access fluent values this problem does not have an impact. The exogfUpdate action is an exogenous action which is ignored during projections anyway. This problem only occurs when executing programs or policies on-line. We will discuss how exogenous actions are integrated when introducing the implementation of the Readylog interpreter in Chapter 4.4.