- One of the main tasks of the IndiGolog-OAA interface is to process
incoming OAA events while not giving the execution control to
the OAA library.
A special exogenous action get_event is defined as
part of the interface. It runs after every primitive action in
IndiGolog program (unless it is specifically disabled). get_event
first executes the procedures found in the main OAA event loop:
it gets the top priority OAA event form the communication library
and lets OAA process it. It repeats this part until there are
no more events waiting (until it receives 'timeout' event).
The reason why we need to let OAA process the events rather then
extract them manually is simple: in addition to events that result
from some agents requesting the services of our IndiGolog agent
there are other OAA events that we don't know how to handle. These
could be events that update a certain data solvable declared at
this particular agent, or these could be events that turn on the
system's tracing facility, and so on. We let the OAA library handle
these events since we want the combined IndiGolog OAA agent to
be compliant with OAA specifications to the maximum degree possible.
To achieve the task of separating OAA events that are calls to
user-defined solvables from other OAA events, we define and register
with OAA a default callback that is called every time some agent
requests the services of our IndiGolog OAA agent.
Registering the callback with OAA:
oaa_AppDoEvent(Goal, GoalParams) :-
callback(Goal, GoalParams).
This callback is given the goal (the problem that we have to solve)
and we add this goal to the queue that holds the OAA events to be
processed. The OAA library always sends the success message to the
caller. This is why other agents should only send non-blocking requests
for the services provided by the IndiGolog OAA agents. If some other
agent waits for the answer to its query, its oaa_Solve call will
return successfully, but the variables through which that agent
expects to get the answer will remain unbound.
- Defining the callback:
callback(Goal, Params):-
update_event_queue(Goal).
The process of extracting OAA events is completely transparent
for the programmer.
get_event procedure then processes the queue and
extracts the events from it. It adds the events to IndiGolog program
history, thus turning the newly received goals into actions that
appear to have been executed. This makes sense because IndiGolog
uses regression to evaluate the fluents, tracing back through
the history (possibly all the way through to the initial situation)
and checking whether the executed actions affected the value of
the fluents in question. Therefore, if the programmer wants the
IndiGolog program somehow react when the new goal arrives, he
will have to provide the corresponding successor-state axiom(s).
For example, suppose that we register the solvable:
movement_complete(Location)
This could be a notification from a certain mobile robot
that our IndiGolog agent controls. The following axiom specifies
one of the possible changes in the system caused by the arrival
of the goal movement_complete(Location):
causes_val(movement_complete(Loc),current_location,Loc,true).
This effectively says that the value of the fluent current_location
changes to wherever the robot has just finished moving.
|
