From: AAAI Technical Report FS-98-02. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.
Reactivity
in a Logic-Based Robot ProgrammingFramework
Yves Lesp6rance,
Kenneth
Tam, and Michael
Jenkin
Dept. of ComputerScience, York University, Toronto, ONCanada, M3J1P3
{ lesperan,kenneth,jenkin} @cs.yorku.ca
Abstract
Synthesizingplans at run-time provides great flexibility,
but it is often computationally infeasible in complexdomains, especially when the agent does not have complete
knowledgeand there are exogenousevents (i.e. actions by
other agents or natural events). In (Levesqueet al. 1997),
it was argued that high-levelprogramexecution was a more
practical altemative. The idea, roughly, is that instead of
searching for a sequenceof actions that takes the robot from
an initial state to somegoal state, the task is to find a sequenceof actions that constitutes a legal execution of some
high-level program. By high-level program, we mean one
whoseprimitive instructions are domain-dependentactions
of the robot, whosetests involve domain-dependentpredicates that are affected by the actions, and whosecode may
contain nondeterministic choice points wherelookahead is
necessary to makea choice that leads to successful termination. As in planning, to find a sequencethat constitutes
a legal execution of a high-level program, one must reason
about the preconditionsand effects of the actions within thz
program. However, if the program happens to be almost
deterministic, very little searching is required; as moreand
more nondeterminismis included, the search task begins
to resemble traditional planning. Thus, in formulating a
high-level program,the user gets to control the search effort
required.
Arobotmustoften react to eventsin its environment
andexceptionalconditionsby suspendingor abandoning
its current
plan andselectinga newplan that is an appropriateresponse
to the event.Thispaperdescribeshowhigh-levelcontrollers
for robotsthat are reactivein this sensecanconveniently
be
implementedin ConGolog,a newlogic-based robot/agent
programming
language.Reactivityis achievedby exploiting
ConGolog’s
prioritized concurrentprocessesand interrupts
facilities. Thelanguagealso providesnondeterministic
constructs that supporta formof planning.Programexecution
relies on a declarativedomaintheory to modelthe state of
the robot andits environment.Theapproachis illustrated
witha maildeliveryapplication.
Introduction
Reactivity is usually understoodas having mainlyto do with
strict constraints on reaction time. As such, muchworkon
the design of reactive agents has involved non-deliberative
approaches where behavior is hardwired (Brooks 1986)
produced from compiled universal plans (Schoppers 1987;
Rosenschein &Kaelbling 1995). However,there is more to
reacting to environmentalevents or exceptional conditions
than reaction time. While some events/conditions can be
handled at a low level, e.g., a robot going downa hallway
can avoid collision with an oncomingperson by slowing
downand makinglocal adjustments in its trajectory, others require changes in high-level plans. For example, an
obstacle blocking the path of a robot attempting a delivery
maymeanthat the delivery must be rescheduled. Here as in
manyother cases, the issue is not real-time response. What
is required is reconsiderationof the robot’s plans in relation to its goals and the changedenvironmentalconditions.
Current plans mayneed to be suspended or terminated and
new plans devised to deal with the exceptional event or
condition.
To provide the range of responses required by environmental events and exceptional conditions, i.e. reactivity in
the wide sense, the best frameworkseemsto be a hierarchical architecture. Then, urgent conditions can be handled in
real-time by a low-level control module, while conditions
requiring replanning are handled by a high-level control
modulethat modelsthe environment and task, and manages
the generation, selection, and schedulingof plans.
In (Levesqueet al. 1997), Gologwas proposedas a suitable languagefor expressing high-level programsfor robots
and autonomousagents. Golog was used to design a highlevel robot control modulefor a mail delivery application
(Tam et al. 1997). This module was interfaced to systems providing path planning and low-level motioncontrol,
and successfully tested on several different robot platforms,
including a Nomad200, a RWIB21, and a RWIB12.
Alimitation of Gologfor this kind of applications is that
it provides limited support for writing reactive programs.In
(De Giacomo, Lespfrance, & Levesque 1997), GonGolog,
an extension of Gologthat provides concurrent processes
with possibly different priorities as well as interrupts was
introduced. In this paper, we try to showthat ConGologis
an effective tool for the designof high-level reactive control
modulesfor robotics applications. Weprovide an example
of such a modulefor a mail delivery application.
98
ConGolog
As mentioned, our high-level programs contain primitive
actions and tests of predicates that are domain-dependent.
Moreover, an interpreter for such programs must reason
about the preconditions and effects of the actions in the
programto find a legal terminating execution. Wespecify the required domaintheories in the situation calculus
(McCarthy&Hayes 1979), a language of predicate logic
for representing dynamicallychanging worlds. In this language, a possible world history, whichis simply a sequence
of actions, is representedby a first order term called a situation. Theconstant So is used to denote the initial situation
mthat in whichno actions (of interest) have yet occurred.
There is a distinguished binary function symboldo and the
term do(c~, s) denotes the situation resulting fromaction c~
being performedin situation s. Relations whosetruth values vary fromsituation to situation, called predicatefluents,
are denoted by predicate symbolstaking a situation term as
the last argument. For example, Holding(o, s) might mean
that the robot is holding object o in situation s. Similarly,
functions whosevalue varies with the situation,functional
fluents, are represented by function symbolsthat take a situation argument. The special predicate Poss(a, s) is used
to represent the fact that primitive action a is executablein
situation s. A domainof application will be specified by
theory that includes the following types of axioms:
¯ Axiomsdescribing the initial situation, So.
¯ Action precondition axioms, one for each primitive action
a, which characterizes Poss(cr, s).
¯ Successor state axioms, one for each fluent F, which
characterize the conditions under which F(£, do(a, s))
holds in terms of what holds in situation s; these axioms maybe compiled from effects axioms, but provide
a solution to the frame problem(Reiter 1991).
¯ Uniquenamesaxiomsfor the primitive actions.
¯ Somefoundational, domain independent axioms.
Thus, the declarative part of a ConGologprogram implementinga high-level controller for a robot will be such a
theory.
A ConGologprogram also includes a procedural part
whichspecifies the behaviorof the robot. This is specified
using the followingconstructs:
primitive action
a,
Iwait for a condition
~?,
sequence
(0-1;0-2),
nondeterministic
choice
between
actions
(0-1I 0-2),
nondeterministic choice of arguments
zr£ [o-],
o-*,
nondeterministic iteration
if q5 then o’1 else 0-2 endIf,
conditional
while ~b do 0- endWhile,
loop
concurrent
execution
(0-x[I0-2),
(0-1)~ o"2),
concurrencywith different priorities
1 Here,q5standsfor a situationcalculusformulawithall situation arguments
suppressed;qb(s) will denotethe formulaobtained
byrestoringsituationvariables to all fluentsappearing
in ~b.
crl,
concurrentiteration
< £" : ~b ~ 0- >,
interrupt
proc/3(aS) 0- endProc,
proceduredefinition
/~(i’),
procedurecall
noOp
do nothing
The nondeterministic constructs include (0-1 [ 0-2), which
nondeterministically choses betweenprograms0"1 and o’2,
r£[0-], whichnondeterministically picks a binding for the
variables £ and performs the program0- for this binding of
~, and o’% which meansperforming 0- zero or more times.
Concurrent processes are modeledas interleavings of the
primitive actions involved. A process maybecomeblocked
whenit reaches a primitive action whosepreconditions are
false or a wait action ~b?whosecondition ~b is false. Then,
execution of the program may continue provided another
process executes next. In (0"1)) 0"2), o’1 has higher priority than 0"2, and 0-2 mayonly execute when0"~ is done or
blocked. 0-1 is like nondeterministiciteration 0-*, but the
instances of 0- are executed concurrently rather than in sequence.Finally, an interrupt < £ : ~b --+ o- > has variables
:~, a trigger condition~b, and a body0-. If the interrupt gets
control fromhigher priority processesand the conditionq5 is
true for somebinding of the variables, the interrupt triggers
and the bodyis executedwith the variables taking these values. Oncethe bodycompletes execution, the interrupt may
trigger again. Withinterrupts, it is easy to write programs
that are reactive in that they will suspendwhatevertask they
are doing to handle given conditions as they arise. A more
detailed description of ConGologand a formal semantics
appear in (De Giacomo, Lesprrance, & Levesque 1997).
Wegive an example ConGologprogramin section 4.
A prototype ConGologinterpreter has been implemented
in Prolog. This implementation requires that the axioms
in the program’s domain theory be expressible as Prolog
clauses; note that this is a limitation of the implementation,
not the framework.
In applications areas such as robotics, we want to use
ConGolog to program an embedded system. The system
must sense conditions in its environmentand update its thetry appropriately as it is executing the ConGologcontrol
program.2 This requires adapting the high-level program
execution modelpresented earlier: the interpreter cannot
simplysearch all the wayto a final situation of the program.
An adapted model involving incremental high-level program execution is developed in (De Giacomo& Levesque
1998). Howeverin this paper, we sidestep these issues by
making two simplifying assumptions:
1. that the interpreter immediatelycommitsto and executes
any primitive action it reaches whenits preconditions are
satisfied, and
2. that there is a set of exogenousevents detectable by the
system’s sensors (e.g. a mall pick up request is received
or the robot has arrived at the current destination) and
2Here,the environment
is anythingoutside the ConGolog
control moduleabout whichinformationmustbe maintained;so the
sensingmightonly involvereadingmessagesfromanothermodule
througha communication
socket.
99
leave the robot’s state unchanged.This is specified in the
following successor state axiomfor the robotState fluent:
that the environmentis continuouslymonitoredfor these;
wheneversuch an exogenousevent is detected to have
occurred, it is immediatelyinserted in the execution.
robotState( do(a, s) ) =
3p a = startGoTo(p) A i = Moving
a = reachDest A i = Reached V
a = getStuek A i = Stuck V
a = resetRobot A i = Idle V
a = frezeRobot A i = Frozen V
i = robotState(s) A Vp a ~ startGoTo(p)
a ~ reachDest A a ~ getStuck A
a ~ resetRobot A a ~ frezeRobot
Wecan get away with this because our application programperforms very little search and the exogenousevents
involvedare easy to detect.
Interfacing
the High-Level Control Module
As mentionedearlier, we use a hierarchical architecture to
provide both real-time response as well as high-level plan
reconsideration whenappropriate. At the lowest level, we
have a reactive control systemthat performs time-critical
tasks such as collision avoidanceand straight line path execution. In a middle layer, we have a set of components
that support navigation through path planning, mapbuilding and/or maintenance,keeping track of the robot’s position, etc. and support path following by interacting with
the low-level control module.Ontop of this, there is the
ConGolog-basedcontrol module that supports high-level
plan execution to accomplishthe robot’s tasks; this level
treats navigation moreor less as a black box.
In this section, we describe howthe ConGolog-based
high-level control moduleis interfaced to rest of the architecture. The high-level control moduleneeds to run asynchronously with the rest of the architecture so that other
tasks can be attended to while the robot is navigating towardsa destination. To supportthis and allow for interaction
between the high-level control moduleand the navigation
module, we have defined the following simple model. With
respect to navigation, the robot is viewedby the high-level
control moduleas always being in one of the following set
of states:
RS = {Idle,
Wealso have precondition axiomsthat specify whenthese
primitive actions and exogenousevents are possible. For
example,the following says that the action of directing the
robot to start movingtoward a destination p is possible
wheneverthe robot is in Idle state:
Poss(startGoTo(p), s) = robotState(s)
: Idle
Weomit the other precondition axiomsas they are obvious
from the modeldescription.
Wealso use two additional functional fluents:
robotDestination(s)refers to the last destination the robot
was set in motiontowards, and robotPlace(s) refers to the
current location of robot as determined from the model.
Their successor state axiomsare:
robotDestinat ion( do(a, s) ) =
a -- startGoTo(p)
p = robotDestination(s) A Vp a ~ startGoTo(p)
robotPlace(do(a, s) ) =
3pI a = startGoTo(p I) A p = UnknownV
a = reachDest A p = robotDestination(s)
p = robotPlace(s)
Vp a ~ startGoTo(p) A a ~ reachDest
Moving, Reached, Stuck, Frozen}.
Thecurrent robot state is represented by the functional fluent robotState(s). The robot’s default state is Idle; when
in this state, the robot is not movingtowards a destination, but collision avoidanceis turned on and the robot may
movelocally to avoid oncoming bodies. With the robot
in Idle state, the high-level control modulemayexecute
the primitive action startGoTo(place); this changes the
robot’s state to Movingand causes the navigation module
to attempt to movethe robot to place. If and when the
robot reaches the destination, the navigation modulegenerates the exogenousevent reachDest, which changes the
robot’s state to Reached.If on the other hand the navigation
moduleencounters obstacles it cannot get around and finds
the destination unreachable,then it generates the exogenous
event getStuck, which changes the robot’s state to Stuck.
In any state, the high-level control modulemayexecute the
primitive action reset Robot, which aborts any navigation
that maybe under wayand returns the robot to Idle state.
Finally, there is the Frozenstate wherecollision avoidance
is disabled and the robot will not moveeven if something
approachesit; this is useful whenthe robot is picking up
or dropping off things; humansmayreach into the robot’s
carrying bins without it movingaway. All other actions
100
A Mail Delivery Example
To test our approach, we have implementeda simple mall
delivery application. The high-level control modulefor the
application must react to two kinds of exogenousevents:
¯ new shipment orders, whichare represented by the event
orderShipment( sender, recipient,priority),
and
¯ signals from the navigation module, namely the
reachDest event announcing that the destination has
been reached and the getStuck event announcing that
the robot has failed to reach its destination.
Thefirst kind is typical of the communication
interactions a
robot mayhave with its environment,while the second kind
is typical of the control interactions a task-level modulemay
have with the rest of the robot’s architecture. To require
more reactivity from the robot, we assume that shipment
orders comewith different priority levels and that the system
mustinterrupt service of a lowerpriority order whena higher
priority one comes in. Also, we want the robot to makea
certain numberof attempts to get to a customer’smailboxas
someof the obstacles it runs into maybe temporary, This is
handled by assigning a certain amountof credit to customers
initially and reducingtheir credit whenan attempt to go to
their mailboxfails. Whencustomersrun out of credit, they
are suspended and shipments sent to them are returned to
the sender whenpossible.
In addition to the navigation primitive actions and exogenousevents already described, the application uses the
following primitive actions:
The initial state of the domainmight be specified by the
following axioms:
Customer(Yves)
Customer(Ken)
Customer(Hector,)
Customer(Michael)
Customer(c) D cr,edit(c, So)
orderCtr,(So) =
orderState(n, So) = NonExistent
robotState(So) = Idle
r,obotPlace(So) = CentralO f fice
Let us nowspecify the behavior of our robot using a
ConGologprogram. Exogenous events are handled using
prioritized interrupts. The main control procedure concurrently executesfour interrupts at different priorities:
proe mainControl
( n : order’State(n) = Justin
--+ handleNewOrder,(n)
>>
( n : (orderState(n) = ToPickUp
A Suspended(sender(n)))
--+ cancelOrder(n)
ackOrder,(n) acknowledge reception of servable order
declineOrder(n)
decline an unservable order
pick UpSh ipment( n
pick up shipment n
dr,opO f f Shiprnent(n)
drop off shipment n
cancelOrder(n)
cancel an unservable order
r,educeCr,edit( c)
reduce customerc’s credit
noti f yStopSer,ving( c)
notify unreachable customer
Note that shipmentorders are identified by a numbern that
is assigned from a counter whenthe or,derShiprnent event
occurs. Wehave precondition axioms for these primitive
actions, for example:
P oss(pick UpSh ipment( n ) , s)
orderState(n, s) = ToPickUp
robot Place(s) = mailbox(sender(n,
The primitive fluents for the application are:
or,der,State(n, s) =
sender(n, s) =
recipient(n, s) =
or,der Pr,io(n, s) =
orderCtr,(s) =
credit(c, s) =
Suspended(c, s)
II
( n : (orderState(n) = ToPickUp
V orderState(n)
= OnBoard
V robotPlace ~ CentralOffiee)
robot M otionControl )
>>
( robotState = Moving ~ hoOp )
endProc
The top priority interrupt takes care of acknowledgingor
declining new shipmentorders. This ensures that customers
get fast feedbackwhenthey makean order. At the next level
of priority, we havetwoother interrupts, one that takes care
of cancelling orders whose senders have been suspended
service, and another that controls the robot’s motion.At the
lowest priority level, we have an interrupt with an empty
body that prevents the programfrom terminating whenthe
robot is in motionand all other threads are blocked.
The top priority interrupt deals with a newshipmentorder
n by executing the following procedure:
proc handleNewOrder(n)
if Suspended(sender(n)) V Suspended(recipient(n))
then declineOrder(n)
else
ackOr,der(n )
if robotState = Moving A
orderPrio(n) > eurOrderPrio then
%abort current service
resetRobot
endIf
endIf
endProc
This sends a rejection notice to customers makingan order whose sender or recipient is suspended; otherwise an
acknowledgementis sent. In addition, whenthe new shipmentorder has higher priority than the order currently being
served, the robot’s motionis aborted, causing a reevaluation
of which order to serve (curOrderPriois a defined fluent
whosedefinition appears below).
order n is in state i
sender of order n is c
recipient of order n is c
priority of order n is p
counter for orders arriving
customerc has credit k
service to customerc is suspended
Wehave successor state axiomsfor these fluents. For example, the state of an order starts out as NonExistent,
then changes to Justin when the orderShiprnent event
occurs, etc.; the following successor state axiomspecifies
this:
order,State(n, do(a, s)) =
3c, r, p a = orderShiprnent(c, r, p) A orderCtr =
A i = JustIn V
a = aekOr,der,(n) A i = ToPickUp
a = pickUpShiprnent(n) A i = OnBoard
a = dropOffShiprnent(n)
robotPlace(s)
= mailbox(recipient(n,
A i = Delivered V
a = dropOffShiprnent(n)
robotPlace(s) = rnailbox(sender(n,
A i = Returned V
a = dropOffShiprnent(n)
robotPlace(s) = Centr,alO f fice
A i = AtCentralOffice
V
a = cancelOr,der(n) A i = Cancelled
a = declineOrder(n) A i = Declined
i = orderState(n, s)
--~(3c, r, pa = orderShiprnent(c, r,p) A orderCtr =
A a 5£ ackOrder(n) A a ~ pickUpShiprnent(n)
a ¢ dropOffShiprnent(n) A a ¢ cancelOrder(n)
Weomit the rest of the successor state and action precondition axiomsfor space reasons.
101
OrderF orCustAt Prio( n, c, p, s) ~-f
orderState(n, s) = ToPickUp A sender(n, s) =
orderPrio(n, s) = p
orderState(n, s) = OnBoardA orderPrio(n, s) =
(recipient(n, s) =
sender(n, s) = c A Suspended(recipient(n, s),
The second interrupt in mainControl handles the cancellation of orders whenthe sender gets suspended;its body
executes the primitive action cancelOrder(n).
The third interrupt in mainControlhandles the robot’s
navigation, pick ups, and deliveries. Whenthe interrupt’s
conditionis satisfied, the followingprocedureis called:
proe robot M otionControl
if 3c CustToServe(c) then tryServeCustomer
else tryToWrapUp;
endIf
endProc
This tries to serve a customerwhenthere is one to be served
andtries to return to the central office and wrapup otherwise.
CustToServe(c, s) is a defined fluent:
mazCustPriority(s)
= e.f
p = 3c custPriority(c, s) =
A VcI custPriority(d, s) <_
maxCreditFor(p, s) = k
3c[custPriority(c, s) = p A credit(c, s) =
Vc’(custPriority(c’, s) = p D credit(d, s) k)
This essentially says that the best customers to serve are
those that have the highest credit amongthose having the
highest priority orders. Wecan nowalso define the priority
of the order currently being served as follows:
CustToServe(e, s)~3n[
(orderState(n, s) = ToPickUp A sender(n, s)
A ",Suspended(recipient(n, s), s))
(orderState(n, s) = OnBoardA (recipient(n, s)
V sender(n, s) = c A Suspended(recipient(n, s)))
A -,Suspended(c, s)
def
curOrderPrio(s) = p
Vc[robotState(s) = Moving
robotDestination(s) = rnailboz(c)
D p = custPriority(c, s)]
[-,(robotState(s)
= Moving
3c robotDestination(s) = mailboz(c)) D p = --1]
The handleServiceFailure procedure goes as follows:
proc handleServiceFailure(c)
reduce Credit (c);
if credit(c) = 0 then
noti f ySt opServing(p)
endff;
endProc
Whenthe robot gets stuck on the way to customer c’s mailbox, it first reducesc’s credit and then checkswhetherit has
reached zero and c has just becomeSuspended. If so, c is
notified that he/she will no longer be served.
The tryToWrapUp
procedure is similar to
tryServeCustorner:
proc tryToW rapU p
startGoTo(CentralO f fice);
(robotState ~£ Moving)?;
if robotState -- Reached then
freezeRobot;
dropO f fToCentralO f fice
resetRobot
else if robotState = Stuck then
resetRobot % abandon attempt
%else whenservice aborted nothingmoreto do
endIf
endProc
It starts the robot on its wayto the central office. Thethread
then waits until the robot halts. If the robot reaches the
central office, then all undeliverableshipmentson boardare
dropped off, and unless a new order comes in the program
terminates. If the robot gets stuck, then the robot is reset
and the procedure ends. If motion is aborted, the procedure ends immediately.In both cases control returns to the
mainControl procedure, which will serve a new order if
To try to serve a customer, we execute the following:
proc tryServeCustomer
rc c [BestCustToServe(c)?;
startGoTo(rnailboz(c)
(robotState # Moving)?;
if robotState = Reached then
freezeRobot;
dropO f f ShipmentsTo( c);
pickUpShiprnentsFrom(c);
resetRobot
else if robotState = Stuck then
resetRobot; % abandon attempt
handleService F ailure( c)
%else whenservice aborted nothingmoreto do
endIf ]
endProc
Thisfirst picks one of the best customersto serve, directs the
robot to start navigating towards the customer’s mailbox,
and waits until the robot halts. If the robot reaches the
customer’s mailbox, then shipments for the customer are
dropped off and shipments from him/her are picked up. If
on the other hand, the robot halts becauseit got stuck, the
handleServiceFailure procedure is executed. Finally,
if the robot halts because a higher priority order camein
and the top priority interrupt executed a resetRobot, then
there is nothing more to be done. BestCustToServe(c, s)
is a defined fluent that captures all of the robot’s order
schedulingcriteria:
BestCustToServe(c, s) "=f CustToServe(c, s)
custPriority(c,
s) = mazCustPriority(s)
credit(c, s) = rnaxCreditFor(rnaxCustPriority(s),
custPriority(c, s) p=~’f
3n Order F orCustAtPrio(n, c, p, s)
Vn’, p’(OrderForCustAtPrio(n’, c, p’, s) D p’ <_
102
point to point navigation in a previously mappedenvironmentand can use pre-positioned visual landmarksto correct
odometryerrors. It relies on sonar sensors to sense unmodeled obstacles.
The system’s architecture conformsto the general scheme
described earlier. It provides two levels of control. Anonboard low-level controller (Robinson &Jenkin 1994) performsall time-critical tasks such as collision avoidanceand
straight line path execution. The low-level controller assumesthat the robot is always in motion and communicates
with an offboard global path planner and user interface module knownas the Navigator. The Navigator takes as inputs
a metric/topological mapof the environmentin which the
robot is located and the coordinates (as defined in the map)
of the two end points, i.e., the source and the destination
of a path. By makinguse of somepredefined path-finding
algorithms such as breadth-first search or A*the Navigator
identifies a feasible path betweenthe source and the destination. To follow the path, the Navigator decomposesit
into segments(a segmentis a straight line betweentwo adjacent way-points) and then forwards the segments to the
low-level controller for execution. The Navigator supervises the low-level controller and identifies failures in the
low-level controller’s ability to execute a path segment.
The ConGolog-basedhigh-level control module interacts with the rest of the architecture by communicating with the Navigator through a socket interface. The
high-level controller, Navigator, and low-level controller
all run asynchronously. The primitive actions in the
ConGolog interface model are implemented using operations provided by the Navigator (currently, the mail
pickup and drop off actions are only simulated). For
example, the ConGologprimitive action startGoTo(p)
is implemented as [planPath(coordinatesOf(p))
;
followPath],
where planPath
and follow_path
are operations supplied by the Navigator.
Our experiments confirmed the system’s ability to deal
¯ with navigation failures and to interrupt the current task
whenan urgent shipment order is made. For more details
on the system, see (Tam1998).
Figure 1: Our robot facing an obstacle.
one has come in or make a new attempt to return to the
central office.
Procedure dropOffShipmentsTo(c) delivers to customer c all shipmentson board such that e is the shipment’s
recipient or c is the shipment’ssender and the recipient has
been suspended:
proc dropO f f ShipmentsTo( c)
while 3n (orderState(n) = OnBoard
(recipient(n) =
sender(n) = c/X Suspended(recipient(n))))
do
7r n [(orderState(n) = OnBoard
(recipient(n) =
sender(n) = c A Suspended(recipient(n))))?;
dropO f yShipment (n)]
endWhile
endProc
ProcedurepickUpShipmentsFrora(c) simplypicks up all
outgoing shipments from customer c’s mailbox. Procedure dropOffToCentralOffice drops off all shipments
whoserecipient and senders are both suspendedto the central office. These are similar to dropOffShipmentsTo(c)
and we omit their code.
Note that by handling the cancellation of pick ups in a
separate thread from that dealing with navigation and order
serving, we allow the robot to be productive while it is in
motion and waiting to reach its destination. This makesa
better use of resources.
To run the system, we execute rnainControl after placing a fewinitial orders:
Discussion
Wehave described how ConGologcan be used to implement high-level robot controllers that can cope with dynamic and unpredictable environments -- controllers that
are reactive and support high-level plan reconsideration in
response to exogenousevents and exceptional conditions.
Our work showshowa logic-based approach can be used to
build effective systemswhile retaining features such as clear
specifications, inferential power,and easy extensibility.
One limitation of the work accomplishedso far is that
the system developed is rather small. Weneed to experiment with morecomplexsystems to see whether the general
approachand the use of prioritized interrupts to provide reactivity scales up. Aswell, interrupts support the suspension
of the current plan but not its termination. Theaddition of a
conventional exception throwing and catching mechanism
that terminates the current plan is being investigated.
orderShipment(Yves, Ken, 0) II
orderShiprnent( K en, Hector, 1) >>
rnainControl
Experimentation
The high-level control modulefor the mail delivery application has been ported to an RWIB 12 mobile robot and tested
in experiments (see figure 1). The other software components for this were based on a system developed during
an earlier project concernedwith building an experimental
vehicle to conduct survey/inspection tasks in an industrial
environment (Jenkin et al. 1994). The system supports
103
Anotherlimitation concerns the lack of search/planning
in the current high-level program. However,the newmodel
of De Giacomo and Levesque (De Giacomo & Levesque
1998) provides a clean specification of incremental highlevel programexecution in the presence of sensing. This
will allow us to incorporate controlled search/planning in
our programswhile retaining a clean semantics. This might
be most useful for dealing with unexpectedplan failures.
A Golog-basedapproach to execution monitoring and plan
repair is developed in (De Giacomo,Reiter, &Soutchanski
1998). The use for Gologfor planning is investigated in
(Reiter 1998).
Another area under investigation is perceptual tasks.
Suchtasks often require sophisticated plan selection and
involve information acquisition. Weare currently working
on an application where packages must be delivered to the
recipient "in person" and wherethe robot must use sophisticated search strategies to locate the recipient, for example,
asking whether a co-worker has seen the recipient (Tam
1998).
The high-level programexecution modelof robot/agent
control that underlies our approach is related to work on
resource-boundeddeliberative architectures (Bratman, Israel, & Pollack 1988; Rao & Georgeff 1992) and agent
programminglanguages (Shoham1993). One difference
that in our approach,plan selection is codedin the program.
This makesfor a less declarative and in somecases more
complexspecification, but eliminates some overhead. On
the other hand, the robot’s world is modeledusing a domain
action theory and the world modelis updated automatically
using the successor state axioms;there is no needto perform
asserts and retracts. Moreover,the evaluation of a test may
involve arbitrary amountsof inference, although following
logic programmingphilosophy, we take the programmer
to be responsible for its efficiency/termination. Perhaps a
morecentral difference is that our robots/agents can be understood as executingprograms,albeit in a rather smart way;
they have a simple operational semantics. Modelingthe operation of an agent implementedusing a resource-bounded
deliberative architecture requires a muchmorecomplexaccount.
Brooks, R. 1986. A robust layered control system for a
mobile robot. IEEEJournal on Robotics and Automation
2(1): 14-23.
De Giacomo, G., and Levesque, H.J. 1998. An incremental interpreter for high-level programswith sensing.
In Working Notes of the 1998 AAAI Fall Synzposium on
Cognitive Robotics.
De Giacomo, G.; Lesprrance, Y.; and Levesque, H. J.
1997. Reasoningabout concurrent execution, prioritized
interrupts, and exogenousactions in the situation calculus. In Proceedingsof the Fifteenth International Joint
Conferenceon Artificial Intelligence, 1221-1226.
De Giacomo, G.; Reiter, R.; and Soutchanski, M. E.
1998. Execution monitoring of high-level robot programs.
In Principles of KnowledgeRepresentation and Reasoning: Proceedings of the Sixth International Conference
(KR’98),453---464.
Jenkin, M.; Bains, N.; Bruce, J.; Campbell, T.; Down,
B.; Jasiobedzki, E; Jepson, A.; Majarais, B.; Milios, E.;
Nickerson, B.; Service, J.; Terzopoulos,D.; Tsotsos, J.;
and Wilkes, D. 1994. ARK:Autonomousmobile robot for
an industrial environment. In Proc. IEEE/RSJIROS.
Levesque, H. J.; Reiter, R.; Lesprrance, Y.; Lin, E; and
Scherl, R. B. 1997. GOLOG:
A logic programming language for dynamic domains. Journal of Logic Programming 31 (59-84).
McCarthy, J., and Hayes, E 1979. Somephilosophical
problemsfromthe standpoint of artificial intelligence. In
Meltzer, B., and Michie, D., eds., MachineIntelligence,
volume 4. Edinburgh, UK: Edinburgh University Press.
463-502.
Rao, A., and Georgeff, M. 1992. An abstract architecture for rational agents. In Nebel, B.; Rich, C.; and
Swartout, W., eds., Principles of KnowledgeRepresentation and Reasoning: Proceedings of the Third International Conference, 439--449. Cambridge, MA:Morgan
KaufmannPublishing.
Reiter, R. 1991. The frame problem in the situation calculus: A simple solution (sometimes) and a completeness
result for goal regression. In Lifschitz, V., ed., Artificial
Intelligence and Mathematical Theory of Computation:
Papers in Honorof John McCarthy. San Diego, CA: Academic Press. 359-380.
Reiter,
R. 1998. Knowledge in action:
Logical foundations for describing and implementing dynamical systems.
Draft Monograph, available at
http://www. cs.toronto,
edu/-cogrobo.
Robinson, M., and Jenkin, M. 1994. Reactive low level
control of the ARK.In Proceedings, V~sionInterface ’94,
41-47.
Rosenschein,S. J., and Kaelbling, L. P. 1995. A situated
view of representation and control. Artificial Intelligence
73:149-173.
Schoppers,M. J. 1987. Universal plans for reactive robots
in unpredictable environments.In Proceedingsof the Tenth
Acknowledgements
This research received financial support from the Information Technology Research Center (Ontario, Canada) and
the Natural Science and Engineering Research Council
(Canada). Hector Levesquecame up with the idea of handling sensing through exogenous events. Wethank him
as well as Ray Reiter, Jeff Lloyd, Mikhail Soutchanski,
GiuseppeDe Giacomo,and Daniele Nardi for helpful discussions related to this work. Manyof our papers are available at http://www.
cs.yorku,ca/Nlesperan/.
References
Bratman,M.; Israel, D.; and Pollack, M. 1988. Plans and
ressource-bounded practical reasoning. ComputationalIntelligence 4:349-355.
104
hztenzational Joint Conferenceon Artificial hztelligence,
1039-1046.
Shoham,Y. 1993. Agent-oriented programming.Artificial
Intelligence 60( 1 ):51-92.
Tam,K.; LLoyd,J.; Lesp6rance, Y.; Levesque,H.; Lin, E;
Marcu, D.; Reiter, R.; and Jenkin, M. 1997. Controlling
autonomous robots with GOLOG.
In Proceedings of the
TenthAustralian Joint Conferenceon Artificial Intelligence
(AI-97), 1-12. Perth, Australia,
Tam, K. 1998. Experiments in high-level robot control using ConGolog-- reactivity, failure handling, and
knowledge-basedsearch. Master’s thesis, Dept. of Computer Science, YorkUniversity.
105