A Remote Robotics Laboratory on the Internet

Y. U. Cao, T.-W. Chen, M. D. Harris, A. B. Kahng, M. A. Lewis and A. D. Stechert

Commotion Laboratory
UCLA CS Dept., Los Angeles, CA 90095-1596

Abstract resources. This technology will be enabling for such di-

This paper describes ongoing work toward a remote verse purposes as: remote scientic investigation, con-
robotics research site which allows repeatable remote tinued widespread availability and aordability of sci-
experimentation on multiple mobile robots. Our sys- entic equipment, development of more rigorous stan-
tem consists of ten small mobile robots hosting on- dards for scientic discourse in highly experimental en-
board Unix workstations. The robots provide facilities gineering disciplines, and Internet-based K-12 and un-
for sensing and moving obstacles, inter-robot position- dergraduate education. To help explain these visions
ing and communications, and user input. The Unix for the future we describe three core ideas: taskable
workstations allow the user to control the robots us- machines, colonies of taskable machines, and remote
ing common languages in a familiar environment, while science.
also providing an interface to mass-market peripherals 1.1 Taskable Machines
(secondary storage and vision), network access (telnet,
FTP, mail, and HTTP), and robust multi-tasking. We A taskable machine is an application-specic robot
believe that this work provides a foundation for future designed to achieve only a narrow range of tasks within
eorts toward new paradigms for remote research and a restricted domain. The concept of a taskable ma-
user interaction with taskable hardware (e.g., colonies chine is in direct contrast to that of a universal robot
of application-specic robots). We envision applica- that possesses a wide range of capabilities. Since a
tions in such domains as agriculture, environmental taskable machine need not be functional in all possible
monitoring, and deep-space exploration. environments and situations, the usual objectives of
universal intelligence, massive computation, and pow-
1 Motivations erful sensing can be deferred until necessary under-
lying technologies have matured. For robotics, the
The UCLA Commotion (Cooperative Motion) Lab- taskable machine concept is enabling: decades of ef-
oratory seeks new theories of cooperative task-solving, fort toward universal robots have met with disappoint-
grounded in the eld of robotics. One major goal of ment, while recent years have seen signicant successes
this research is to eld colonies of robots at remote in application-specic robotic technology (particularly
locations. These robots will be used to collect data, for defense [3], medicine [15, 32] and household appli-
perform experiments, etc. They will be used by a wide cations [9]). 1
variety of people including scientists, engineers, edu- Even though taskable machines are restricted in
cators, and students. their application, their control is non-trivial. When
We have identied several key problems that must a resource is constrained by its environment or its
be addressed. Among these are: communication be- use (e.g., an agricultural pump or the Hubble space
tween the experimenter and the remote colony, the re- telescope), users seem to require little more than a
mote tasking of robots, and the eective presentation scheduling interface. However, many scheduling prob-
of information to the user. lems are intractable, and the operation of remote hard-
To address these problems, we have put together a ware { particularly for sensing { entails challenging op-
robotic resource that will be made available to qual- timizations. 2 When mobility and unstructured envi-
ied users on the Internet within the next several ronments are involved (e.g., a rover on Mars or on the
months. Our resource consists of ten R3 research ocean oor), there are even more challenging issues of
robots from IS Robotics, Inc., with added network con- operator interface, resource allocation, real-time feed-
nections, and is not currently duplicated anywhere in back, and semi-autonomy. Software that acts as an
the world. We would enjoy sharing this infrastructure autonomous safety net might be required to maintain
resource with other researchers and educators. In re- system integrity when the network imposes communi-
turn, we expect to improve our understanding of how
such resources can be shared and tasked. 1 One analogy would be the contrast between application-
We feel that the existing information superhigh- specic integrated circuits (ASICs) such as controllers or DSP
way infrastructure provides an ideal backbone for this chips, and general-purpose microprocessors. While we view
project. While the information superhighway has taskable machinesas task-specic, other researcherssuch as Hor-
demonstrated its use in the interactive sharing of infor- swill [20] consider the notion of environment-specic robots.
mation, our plan will add new capability by allowing 2 As examples: (1) Power and bandwidth limitations to
control of and communication with physical, taskable telemetry may require intelligent image analysis before downlink
from the sensing hardware. (2) Time delays and uncertainty in
 This research was supported in part by NSF Young Inves- uplink of operator controls (e.g., to a deep-space probe via ra-
tigator award MIP-9257982 with matching support from High- dio, or to a mobile robot via an unreliable link in the Internet)
Level Design Systems. The UCLA Commotion Laboratory is may require intelligent partitioning of control between the task-
supported by NSF CDA-9303148 and matching funds from the able machine and its remote operator. Cf. [1] for an overview
UCLA School of Engineering and Applied Science. of intelligent scheduling.
cation delays. 3 ). mechanism that can enable widespread availabil-
1.2 Colonies of Taskable Machines ity and aordability of such equipment. Remote
science helps level the playing eld for researchers
Since each taskable machine has limited scope, constrained by location or budget.
achieving exibility and sophisticated capability re-
quires groups, or colonies, of taskable machines [2, 11].  Evolution of more rigorous standards for scien-
In other words, future task-solving robotic systems will tic discourse. Particularly in experimental engi-
be made up of colonies of taskable machines that col- neering disciplines such as robotics, descriptions
lectively achieve a wide range of tasks. Other motiva- of experimental protocols can be vague, leading to
tions for robot colonies include: irreproducibility of results. We believe that any
mechanism for remote science transparently en-
 Building and using several simple taskable ma- forces experiment reproducibility since the remote
chines can be easier, cheaper, more exible and researcher must completely specify his experiment
more fault-tolerant than building a single univer- prior to submitting it for remote execution.5
sal robot to accomplish all possible tasks.4
 Tasks may be inherently too complex for a single
 Improved access of K-12 and undergraduate ed-
robot to accomplish, or performance benets can ucators to leading-edge pedagogical material (cf.
be gained from using multiple robots. A popula- [26]). Again, an Internet-based remote science in-
tion of cooperating taskable machines is less lim- frastructure will provide the means to escape from
ited by spatial and temporal constraints: certain geographical and nancial constraints. User in-
problem classes are provably beyond the capabil- terfaces built using HTML or similar graphical
ity of a monolithic robot, essentially because a formats will facilitate access by casual or naive
single robot cannot be spatially distributed (that users.6
is, in two places at the same time).
2 Toward an Implementation
 Colonies of taskable robots are of independent re- The current state of our project, described in Sec-
search interest since their development may shed tion 3 below, makes ten mobile robots available for
light on elds spanning the social sciences (orga- experimentation over the Internet. This is of inter-
nization theory, economics), life sciences (theoret- est given recent levels of activity in cooperative mo-
ical biology, animal ethology) and cognitive sci- bile robotics [13]. We provide the remote researcher
ences (psychology, learning, articial intelligence). with (i) access to a colony of near-leading edge re-
Historically, implementationof robotic colonies may search robots, (ii) software and hardware extensions
have been viewed as strictly more dicult than im- to enable wireless networking and programmability in
plementation of a single robot. However, restricting high-level languages, and (iii) infrastructure for remote
robotic colonies to be composed of simpler application- experimentation. Thus, our project truly essays exper-
specic robots can compensate for the added complex- imental remote science.
ity of coordination. [16] gives example application do- For present lessons to be more applicable to future
mains. In recent years, works such as [31, 35] have es- eorts, and for relevance to \real science", we have cen-
tablished frameworks for task decomposition and con- tered on themes of mobility, autonomy, and remoteness
trol in multiple-robot systems. Several of these have in evaluating potential testbeds. Currently, we antici-
been implemented using real robots (see [13] for a de- pate two future project phases which lead to unstruc-
tailed survey). tured outdoor environments and applications such as
remote exploration, geological and botanical sampling,
1.3 Remote Science and ecosystem monitoring.7 The three project phases,
In the future, educators and experimental scientists and their relationships to each other, may be summa-
will be able to work with remote colonies of taskable rized below.
machines via a \remote science" paradigm that allows: Phase One (in progress) provides an indoor exper-
imental facility allowing users from cooperating insti-
 Spatial decoupling of experimenters and their ex- tutions to log in and control our robotic colony via a
periments. This allows: (i) multiple users in dif- World-Wide Web (WWW, or Web) interface. Here,
ferent locations to share collaboratively a single we believe users will focus on research issues in coop-
physical resource (cf. notions of virtual \collab- erative mobile robotics. Initial functionality includes
oratories" [41]), and (ii) enhanced productivity a full Unix development environment (X, gcc, Emacs,
through reduced travel time, enabling one exper- gdb, etc.), Web interface, simple scripting capability,
imenter to participate in multiple, geographically robot control via a shared-memory architecture, and
distributed experiments. full Internet connectivity (TCP/IP, SMTP, FTP, etc.).
 Sharing of expensive physical resources. In a cli- 5 Sensing, actuation, program and video traces which com-
mate of \big science" and constrained budgets, prise feedback to the remote experimenter will at the same time
shared operation of scientic hardware is the only provide back-annotation of the experimental protocol.
6 Public policy considerations must also be addressed, e..g.,
3 See [8], which describes a safety net for mobile robots based how should access to a space telescope be prioritized between
on potential elds, and uses the term \teleautonomy". Other a local researcher and a remote researcher, between a school
useful references are contained in the substantial literatures on assembly and a Ph.D. student's experiment, etc.?
teleoperation and telerobotics. 7 We are not as interested in a \remote undergraduate biol-
4 Note that: (1) A single robot translates to a single point ogy or chemistry laboratory" (cf. [28]). Requirements such as
of system failure. (2) Taskable machines by their nature do not manipulation, machine vision, safe operation in human environ-
require the riskier leading-edge technology needed by universal ments, etc., dominate such a concept; these are not so dominant
robots. (3) A system of multiple robots can provide graceful in the distributed sensing, monitoring, and exploration tasks
degradation under failures. that we envision for colonies of mobile taskable machines.
 Phase Two will introduce behaviors (i.e., task prim- or exploration), as well as for reconstruction and
itives, high-level tasks) into the colony via a layered analysis of the scientic experiment itself. For the
control approach. Of highest priority are behaviors former, on-board data storage is required along
which preserve the safety and integrity of the colony with possibly intelligent data/image processing
(see [29] as well as the discussion of requirements and prior to downlink in power- or bandwidth-limited
implementation issues in the remainder of this sec- scenarios. For the latter, low-level sensor and
tion). This \safety net" will provide protection against actuator traces, and perhaps (compressed, low-
errant or harmful user programs, against hardware sample rate) video and program traces should be
failures and power loss, etc. At the same time, the archived for eventual transmission to the remote
robot arena will be enhanced with hardware to allow experimenter.
manipulation of large obstacles, thus aording more
complex experimental environments and the removal  Real-time response is required since the robots
of failed robots. Given this increased exibility and are mobile in possibly hazardous environments.
programmability, the sophistication of experiment de- On-board requirements include a fast CPU and
sign will increase; we will provide more extensive data an approximation of real-time preemptive multi-
logging (sensing, actuation, variable-resolution or l- tasking. Remote user requirements include low-
tered on-board video), and experiment proles. Fi- resolution feedback of sensing and actuation (pos-
nally, the interface will improve, following the devel- sibly including some form of video feedback).
opment of HTML3 and other Web facilities. Since such feedback has multiple sources with
Phase Three will eld equipment in an outdoor set- varying bandwidth requirements, exibility in the
ting, using heterogeneous (legged or possibly aerial) spatial or temporal resolution of the feedback
robot platforms which are almost fully autonomous. streams must also be possible.
Experiments will last on the order of days to weeks,
and will be run remotely over the Internet. Science  Communication must be sucient for the
(e.g., botany, soil science, and atmospheric chemistry) agents in the robot colony to coordinate their ac-
will be performed, with task complexity hopefully on tions. There is a tradeo among communication
the order of that achievable by the JPL Pathnder bandwidth, sensing and processing, in that com-
Mars rover [23]. We believe that an important benet munication can be achieved implicitly by moni-
will be near-continuous, close-in monitoring for regions toring other robots, by sensing the eects of other
in which human access is too costly. robots' actions, or most directly through explicit
Throughout, our system will support rigorous sci- messages that are transmitted over some commu-
entic experimentation by enforcing well-dened ex- nication channel [13]. If robots are able to model
perimental protocols via its interface. Note also that other robots (i.e., beliefs, states, goals, etc.), then
our Phase Three does not entail teleoperation or telep- communication requirements will be correspond-
resence; such approaches are inappropriate for reasons ingly decreased. For our purposes, standard wire-
including network failure and the high cost of continu- less networking technologies provide the necessary
ous human operation. Rather, our goal is to extend the bandwidth and exibility in topology. Communi-
robots' sensing and manipulation capabilities to opti- cation must also enable telemetry (uplink of oper-
mize information gathering and delivery to the user. ator control and downlink of scientic data). As
The remainder of this section lists functional require- noted above, real-time downlink might include be-
ments for our system and contrasts them with capa- havioral state and low-level sensory data. If video
bilities aorded by existing eorts. feedback is desired, it will dominate the downlink
2.1 System Requirements requirement and bandwidth on the order of hun-
A taskable robotic system for remote experimenta- dreds of Kbps will be necessary.
tion has the following requirements for mobility, sens- The user interface must provide facilities for
ing, and data logging, real-time response, communica- 
user validation and acquisition of the taskable re-
tion, user interface, and programming support. source, program submission, experiment registra-
 Mobility implies the following technical prob- tion, experiment setup (i.e., to achieve repeat-
lems. (i) Energy. Mobile robots must carry their ably a prescribed initial conguration of robots
own energy sources or must derive their energy and obstacles), on-line control of the experiment,
from the environment using, e.g., solar cells. If viewing of near real-time feedback (e.g., the low-
the robots are dependent on an external source of resolution video and sensor traces noted above),
energy, then they must be able to navigate safely and receiving/viewing of the experimental data
to a refueling station when necessary. (ii) Loca- (e.g., in the form of a report). Additionally, tu-
tion. To exploit maps of the environment, or to torial facilities may be oered. For universal ac-
navigate to prescribed sites, robots must deter- cessibility, the interface should be graphical and
mine their positions; possibilities include dieren- Web-based.
tial Global Positioning System (absolute coordi-
nates), beacon system (relative coordinates), or  Programming support should be on at least
landmark-based navigation (in unstructured en- three levels: Level 1 allows interpreted, immedi-
vironments). Robots must also be able to deter- ate execution; Level 2 allows scripts of Level 1
mine locations of other objects relative to their instructions; and Level 3 aords high-level lan-
own frame of reference. (iii) Collision avoid- guage support and access to hardware via an ap-
ance. Robots must detect both static and moving plication programmer's interface (API). Simula-
objects in the environment and execute avoidance tion facilities can speed experiment design and
algorithms. programming, as well as o-load demands on the
actual robotic resource when the user commu-
 Data logging must be sucient for the scien- nity is large. Particularly, with sophisticated ex-
tic application at hand (e.g., remote monitoring periments that require Level 3 support, the API
 Figure 1: The UCLA/ISR R3+ robot.

should allow both scripting capability and low- With this in mind, even a minimal realization of our
level access to the robots.8 An ideal solution system must accomplish the following four steps: (i)
would be Unix-based with a standard mechatronic realize remote operation of taskable machines, (ii) add
interface [34] to low-level control of the robot. programmability, (iii) add multiplicity and autonomy,
Such an approach would leverage the mature and (iv) add collaborative remote experiment capabil-
Unix development environment, aording script- ity.
ing and rapid prototyping capabilities, while re- Regarding remote operation of taskable robots (our
taining low-level hooks into the hardware. step one), the eld of telerobotics has a 50-year history
[38] and is a form of resource sharing. When we add
2.2 Contrasts With Previous Work the goal of Web-accessibility, relevant previous works
Clearly, our goal of implementing Web-accessible include the following.11
autonomous mobile robots entails solving many prob-
lems. A brief digression into an operating systems  The Mercury project at USC [19, 21] consists
analogy points out transferable techniques and en- of a robot manipulator moving above a section
ables a more tractable picture of the system design. of earth known to contain artifacts. There is a
First, the shell provides a user interface through which downward-pointing camera attached to the distal
users submit commands and receive responses from end of the robot arm. By clicking on an image
the system. Basically, the shell provides user registra- or buttons on the Web page, users can make the
tion, user login, utilities such as job submission com- robot move along the X-Y axes and the camera
mands/languages, data logging commands/languages, along the Z axis. In real-time operation, GIF im-
commands \who" and \talk" to facilitate collabora- ages of the camera view are updated on the Web
tion. The shell also provides a programming environ- page, and a session is logged as an MPEG movie;
ment (compiler, simulator, and debugger). Second, the resource dened by a [computer] system" [39].
kernel schedules resources9 and implements the shell 11 Other Web applications include: (1) Net-frog [28] uses
commands. Thus, the kernel is responsible for such QuickTime movies to demonstrate dissections in the frog
system aspects as: (i) communication between entities, anatomy. Users use a mouse to practice dissection on still im-
(ii) sharing, scheduling and partitioning of resources, ages of frog; the program monitors and noties the users if, e.g.,
(iii) the safety net, (iv) maintaining information about they try to cut at the wrong place. (2) The Monterey BayNet
users (e.g., to enforce dierent levels of access), and (v) project [12] establishes the backbone for multiple educational
security10 . initiatives and research projects. ATM, Frame Relay, and ISDN
networks are interconnected, with the Multicast Backbone [40]
8 For example, [21] showed that by using a Web interface, it and World-Wide Web providing tools for complete connectiv-
is possible to make robotics applications widely accessible by ity to a wide variety of existing information sources. Ongoing
appropriately abstracting the interface. On the other hand, [18] projects include the live exploration of Monterey Canyon using
showed that low-level real-time control can also be achieved over a deep-sea remotely-operated vehicle, and a \virtual telescope"
the Internet. interface to astronomical data at The Monterey Institute for Re-
9 For users, resources include actuation, sensing, computation search in Astronomy (MIRA). (3) The NERO project [26] is an
and communication capabilities of the taskable hardware, which ongoing multiple-institution eort in Oregon to create a virtual
form the basis for the remote experiment. For the taskable hard- classroom, i.e., collaborative research and teaching among the
ware, resources include space, communications media, etc. and memberinstitutionsand with industrialsites. ATM provides the
engender many resource-con ict issues. basic network technology. Collaborative tools, distance learning
10 By \security", we mean \protection", i.e., \a mechanism and real-time control applications such as robotics and ight
for controlling the access of programs, processes or users to the simulators are some of the research areas.
 the only sensory data is the energy level. This sites, and a friendly user interface like Onika would
project has been decommissioned since March 31, be equally useful.14
1995. We know of no works that address the last two
steps { multiplicity, autonomy, and collaboration { of
 The Australia's Telerobot On The Web project our minimal system realization. Certainly, computer-
at the University of Western Australia [24] chal- supported collaborative design [41] and \Virtual Envi-
lenges users to control the parallel-jaw grippers of ronment" eorts15 are well-developed research elds,
a six-axis manipulator to pick up blocks on a ta- and it is possible that techniques from those elds
ble. Through a ll-out form, users can submit de- will allow collaborative remote experiment capability
sired (X,Y,Z) coordinates, and roll,pitch,yaw ac- to be built on top of realizations of the rst three steps
tions. A xed camera gives a side view of the above.
arena, and the image is updated when the user
command is submitted and executed. 3 Current System
 The Bradford Robotic Telescope [14, 25] allows The system is now in the early stages of implemen-
users to work either in batch mode12 or in real- tation and it is called the W3R3 Project. Ten R3
time mode. The user describes what he wishes robots have previously been acquired and an 8 meter
to observe and the telescope moves accordingly. x 7 meter arena has been set aside for remote exper-
One of the strong features of this project is the imentation. The following components are currently
good implementation of user access control: users in place: (i) IS Robotics R3 robots supplemented by
must register, login (passwords can be changed Unix workstations with Internet access, (ii) a Global
via e-mail), and submit jobs. Furthermore, jobs Positioning System, (iii) battery recharging support,
are prioritized; only those with highest priority and (iv) a Web-based user interface. These features
are allowed real-time control of the telescope. are described in the following subsections.
3.1 Robot Platform
All three of these projects aord remote manipula- Based on previous experience, we believe that the
tion of taskable hardware through a Web interface. In R3 is well suited to the project requirements outlined
this sense, they have demonstrated the feasibility of in section 2. However, two caveats apply: (i) they
certain basic aspects of our project plan. However, in have no interface to the Internet, and (ii) they have
each of these projects there is only one piece of taskable insucient GPS resolution (i.e., the measured spatial
hardware (the Mercury project uses an IBM manipula- resolution of the R3's original GPS subsystem was 10
tor, the UWA project uses an ASEA industrial robot, cm with a time resolution of 5 seconds).
and the Telescope project uses a telescope interfaced As initially congured, the R3 is a small, au-
to PCs); hence, issues of multiplicity and autonomy do tonomous mobile robot about 30 cm both in diameter
not arise. Furthermore, since there is no programma- and in height (see Figure 1). Computational require-
bility involved, neither programming environment nor ments are satised by 68332 and 68HC11 microcon-
data logging is an issue in these projects. trollers. The R3 runs the Venus operating system [27]
Regarding adding programmability (our step two), and runs user programs in 1MB of non-volatile RAM.
the most signicant work we know of is the Onika The sensor array of the robot includes infrared prox-
project at Carnegie-Mellon University [18], which sup- imity sensors, bump sensors, shaft encoders, power
posedly provides a \virtual laboratory / virtual fac- status indicators, and a user input panel. The robot
tory". moves using a dierential drive and can manipulate ob-
jects using a force-sensing gripper subsystem. Power is
 Onika is an interface to a real-time operating sys- supplied by rechargeable NiCad batteries. The robot
tem called Chimera which supports reusable real- has the capability to detect low power conditions and
time software. Through Chimera, reusable soft- recharge under software control when attached to an
ware modules downloaded from other sites can be external power source.
immediatelyassembled. Onika's contributions are
(i) an iconic interface for linking software modules
3.2 Computation Upgrade
(basically, like an object manager in an object- A key aspect of our design is the on-board support
oriented environment), (ii) the ability to follow of standard Internet protocols (e.g., TCP/IP, FTP,
hyperlinks to retrieve remote software modules13, etc.). We examined several ways of modifying the R3
to accept network connections including direct modi-
and (iii) display of video and other information at cation of Venus. An alternative was to add another
run time. In a demonstration, remote and local
software modules for controlling a Puma manip- 14 The Onika interface is built on top of X-windows; it is not
ulator were linked and executed using the Onika as simple to achieve an iconic interface and real-time video using
interface, with real-time video of the Puma shown existing Web facilities.
on the interface. 15 Various research works toward \Virtual Environments" and
"Virtual Reality" have already produced a number of software
packages, architectures, and operating systems. Two examples
For our purposes, something similar to the Chimera are as follows: (i) The VEOS (Virtual Environment Operating
operating system would be able to provide a good Shell) project [10], which is a management facility for gener-
software development environment for collaborating ation of, interaction with and maintenance of virtual environ-
ments. An early demonstration in a blocks world allowed four
12 I.e., submitting a job and receiving an image result { some- participants to independently navigate and manipulate movable
times days later. objects in a shared virtual space. (ii) The work of [30] allows in-
13 Because network delays are relatively long and unpre- formal collaboration by embedding an information retrieval tool
dictable, the remote software modules are rst downloaded au- (Gopher) to a \text-based virtual reality" environment; this is
tomatically by Onika, then the whole program executes on the an example of merging computer-mediated conferencing and on-
machine where all modules reside. line information retrieval.
processor capable of running Unix, which supports of 19.2 Kbps. Based on spread-spectrum technology,
network communications natively and to write soft- the radio bandwidth is multiplexed over seven radio
ware that interfaces the two. In addition to satisfying channels. Each modem can select one of the channels
our original requirements, choosing the latter option to transmit or receive data, but only four radio chan-
also allowed us to signicantly upgrade the computa- nels can be concurrently used in the same area. To
tional capability of the R3 and provide access to the support more radio connections, each radio channel
large base of Unix applications. can be further divided into 64K logical sub-channels.
Therefore, our robots have been augmented with a Contention for the sub-channels is handled at the MAC
compact 486DX2-66 Unix workstation, based on the (medium access control) layer by using the CSMA/CA
PC/104 bus standard, with 4MB of RAM and .5GB (carrier-sense multiple access with collision avoidance)
mass storage. The workstations run a variant of Unix protocol. However, due to the inherent delay caused
called Linux, for which source code is available, mak- by CSMA/CA, throughput degrades as the number of
ing kernel-level modications possible. This ability be- active sub-channels increases.
comes important when device drivers have to be writ- In our conguration, we have used the maximum of
ten for task-specic sensors or actuators. The entire four independent channels, statically assigning radio
workstation ts in a 12 cm cube that is secured to the modems to sub-channels to accommodate more than
top of the R3. four simultaneous connections. We are currently run-
The Unix workstation and the robot communicate ning PPP (Point-to-Point Protocol) on the wireless
via virtual shared memory. By this, we mean that links to provide TCP/IP functionality. The basesta-
no actual physical memory is shared; instead, we em- tion therefore can communicate with the Unix work-
ulate shared memory with software that drives RS- station on-board each R3 by using any of the facilities
232 hardware linking the two computational resources. of the TCP/IP protocol suite. At the same time, the
The shared memory is logically implemented as les on basestation has an Ethernet connection to the Inter-
the Unix workstation that store the current values of net, which provides high bandwidth connectivity to
the robot's sensors and the current set points of the other Internet hosts.
robot's actuators. The update frequency between the
workstation and the R3 is currently 32 Hz.
The advantage of this le-based shared memory ap-
proach is that closed loop control of the robot can be
implemented as a high priority Unix process that reads
the sensors le, computes new actuator set points, and
then updates the actuators le. Since virtually all lan-
guages support some kind of le access, this system
provides nearly universal access to programming lan-
guages.
3.3 Gobal Positioning System
The GPS consists of four overhead cameras with
slightly overlapping elds of view. The camera images
are digitized and processed to yield the position and
orientation of each robot and of obstacles in the en-
vironment, with updates occurring at 30 Hz with a
spatial resolution of about 3 cm. The system allows
queries of the robot's own position, of other robots'
positions, and of obstacles' positions. To provide this
information to processes running on the robots, sock-
ets are used to transfer data from the o-board vision
processing workstation to the robots local lesystems.
3.4 Recharging
Battery recharging support is accomplished by Figure 2: Part of the Web page.
\feeding trough" technology. When a robot needs
to recharge, it proceeds to a wall on one side of the
arena where two parallel horizontal plates maintain 3.6 User Interface
enough potential to drive the robot's recharging cir- On the basestation, an NCSA HTTP server runs
cuitry. Physically, the robot's grippers have contacts and provides a graphical user interface (GUI) to the
above and below that are positioned so that the ngers mobile robots.
can be inserted between the parallel plates to allow
recharging. This allows the current system to run in- In order for the users to interact eectively with the
denitely. With power-conscious safety net software, mobile robots in the lab, it is necessary that the GUI
robots can interrupt the current experiment under low must support the following capabilities: (i) submis-
power conditions and recharge before completing the sion of basic commands, e.g., Forward, RaiseGripper-
experiment. Lift, (ii) viewing of actuator and sensor states, and (iii)
submission of program les. In addition, the following
3.5 Communication are highly desirable: (iv) video of the lab overview,
The communication between basestation and each and (v) real-time animation of sensory readings.
R3 is discussed as follows in terms of OSI layers. We implement our GUI based on Web facilities
At the physical layer, a pair of Proxim radio (i.e. HTTP, HTTP server, Common Gateway Inter-
modems is dedicated as a wireless serial link between face, HTML, and Web browser). Web facilities are
each R3 and its basestation. The link can be viewed chosen as the implementation language since (i) Web
logically as a standard RS-232 cable, with a data rate facilities are widely available and therefore maximize
the accessibility of our system, and (ii) Web facilities [2] A. Agah, Sociorobotics: The Study of Robot Colonies From
are rapidly evolving so that in the near future we will Simulation to Hardware Realization, Ph.D. thesis, USC CS
be able to implement our entire GUI based only on Dept., 1994.
Web facilities. Figure 2 shows part of the current Web [3] ARPA, working notes of ARPA Taskable Machines Work-
page. shop, Feb. 15-16, 1995.
Since the current Web facilities cannot support all [4] T. J. Berners-Lee, R.T. Fielding, and H. F. Nielsen, \Hy-
the features needed for our interface,16 we use a hybrid perText Transfer Protocol { http1.0", Internet draft, Mar.
approach for now, and plan to replace non-Web-based 1995,
parts as Web facilities improve. http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-
The GUI can be divided into 3 parts: (i) registra- spec-00.txt.
tion/login, (ii) programming, and (iii) display. [5] T. J. Berners-Lee, R. Cailiau, J. F. Gro, and B. Poller-
The registration/login part is performed in a man- mann, \World-Wide Web: The Information Universe",
ner similar to the Bradford telescope project. We are Electronic Networking, Research, Applications and Policy,
adding new capabilities for users to schedule experi- No.2, 1992, pp.52-58.
ment time slots with our lab. [6] T. J. Berners-Lee and R. Cailliau, \World-Wide Web: Pro-
Programming is supported at dierent levels: posal for a Hypertext Project", 1990,
 At Level 1, users can set the state and value of
http://info.cern.ch/hypertext/WWW/Proposal.html.
actuators on a particular R3. [7] T.J. Berners-Lee and D.Connolly, \HyperText Markup
Language Specication - 2.0", Internet draft, Feb. 1995,
 At Level 2, users can program in a script lan- http://www.osn.de/htmlspec/HTMLSPEC.html.
guage to make an R3 to do simple tasks like mov- [8] J. Borenstein and Y. Koren, \Teleautonomous Guidance
ing in the gure of a square. A script is com- for Mobile Robots", IEEE Trans. on Systems, Man and
posed of lines with the format <command time- Cybernetics, 20(6), Nov.-Dec. 1990, pp. 1437-1443.
interval>. Commands currently implemented in- [9] A. Branch, personal communication, Oct. 1994.
clude Forward, Backward, FastForward, FastRe-
verse, TurnLeft, TurnRight, Pause, RaiseGripper- [10] W. Bricken and G. Coco, \The VEOS Project", Technical
Lift, and LowerGripperLift. Report, Tech Report R-93-3, Univ. of Washington, 1993.
 At Level 3, users can submit a program to the [11] R. A. Brooks and A. M. Flynn, \Fast, Cheap and Out of
basestation, and get possible error messages back Control: A Robot Invasion of the Solar System", Journal
on a Web page. Since there is no Web facility of the British Interplanetary Society, 42(10), Oct. 1989,
for uploading les to an HTTP server, users must pp. 478-485.
e-mail the program. Additionally, very trusted [12] D. Brutzman, \Networked Ocean Science Research and Ed-
users can simply telnet into the basestation. ucation, Monterey Bay California", Proc. INET'95, 1995.
[13] Y. U. Cao, A. S. Fukunaga, A. B. Kahng and F. Meng, \Co-
The display part of the GUI transmits video and operative Mobile Robotics: Antecedents and Directions",
sensory data in semi real-time. In the current setup, Proc. IEEE/RSJ Intl. Symp. on Intelligent Robotics and
we send video stream via a video conferencing tool Systems, Aug. 1995, to appear.
called nv (NetVideo) [17]. This requires that the client [14] M. J. Cox and J. E. F. Baruch, \Robotic Telescopes: An
has nv capability, and is therefore restrictive. Sensory Interactive Exhibit on the World-Wide Web", Proc. 2nd
data are plotted and displayed in primitive animation International World-Wide Web Conference, Oct. 1994.
using Netscape's server push method. Finally, the user
can request that the complete log of sensory readings [15] K. G. Engelhardt, personal communication (talk at Los
be sent to him/her via e-mail. Angeles Area Robotics and Automation Symposium), May
1995.
4 Summary [16] D. E. Franklin, A. B. Kahng and M. A. Lewis, \Distributed
We have described ongoing work toward a remote Sensing and Probing With Multiple Search Agents: To-
robotics research site which allows repeatable remote ward System-Level Landmine Detection Solutions", Proc.
experimentation on multiple mobile robots. Our sys- SPIE Aerosense-95: Detection Technologies for Mines and
tem consists of multiple mobile robots hosting on- Minelike Targets, Apr. 1995.
board Unix workstations, and approximates the Phase [17] R. Frederick, \Experiences with Real-Time Software Video
One functionality described in Section 2 above. As we Compress", Jul. 1994,
move toward the ability to conduct \real science" via ftp://parcftp.xerox.com/pub/net-research/nvpaper.ps.
networked, remote colonies of taskable robots, we en- [18] M. W. Gertz, D. B. Stewart, and P. K. Khosla, \A Human-
vision applications in such domains as agriculture, en- Machine Interface for Distributed Virtual Laboratories",
vironmental monitoring, and deep-space exploration. IEEE Robotics and Automation Magazine, Dec. 1994, pp.
References 5-13.
[19] K. Goldberg, M. Mascha, S. Gentner, N. Rothenberg, C.
[1] M. Aarup, M. Zweben and M. S. Fox, eds., Intelligent Sutter, and J. Wiegley, \Desktop Teleoperation via the
Scheduling, Morgan Kaufmann, 1994. World-Wide Web", Proc. IEEE Intl. Conf. on Robotics and
16 Currently widely used Web facilities are HTTP 1.0 [4], Automation, 1995.
HTML 2.0 [7], CGI 1.1 [22], and the most widely used browser [20] I. Horswill, Specialization of Perceptual Processes, Ph.D.
is Netscape (Version 1.1 as of mid-April 1995). However, the thesis, MIT EECS Dept., May 1993.
current Web facilities do not eectively support: (i) real-time
animation (although \poorman's animation" is achievable via, [21] http://cwis.usc.edu:80/dept/raiders.
e.g., Netscape 1.1's \server push" and \client pull"), and (ii) [22] http://hoohoo.ncsa.uiuc.edu/cgi/overview.html.
le upload capability. We note that adding le upload function [23] http://mpfwww.jpl.nasa.gov/ jwright/fact sheet
into HTML ll-out forms has been proposed [33, 36], and has /fact sheet.html.
been implemented experimentally by some browsers such as Hot
Java. [24] http://telerobot.mech.uwa.edu.au.
[25] http://www.eia.brad.ac.uk/rti.
[26] http://www.nero.net.
[27] IS Robotics,Venus Reference Manual, 1995.
[28] M. B. Kinzie, V. A. Larsen, J. B. Burch, and S. M. Boker,
\Net-frog: Using the WWW to Learn about Frog Dissec-
tion and Anatomy", Proc. INET'95, 1995.
[29] M. A. Lewis, A. H. Fagg, and G. A. Bekey, \The USC
Autonomous Flying Vehicle: An Experiment in Real-Time
Behavior Based Control", Proc. of IEEE Intl. Conf. on
Robotics and Automation, Vol. II, May 1993, pp. 422-439.
[30] L. Masinter and E. Ostrom, \CollaborativeInformationRe-
trieval: Gopher from MOO", Proc. INET'93, 1993.
[31] M. Mataric, Interaction and Intelligent Behavior, Ph.D.
thesis, available as Technical Report AI-TR-1495, MIT AI
Lab, Aug. 1994.
[32] B. L. Musits, W. L. Bargar and E. J. Carbone, \Image-
Driven Robot Assists Surgeons With Total Hip Replace-
ments", Industrial Robot 20(5), 1993, pp. 12-14.
[33] E. Nebel and L. Masinter, \Form-Based File Upload in
HTML", Internet draft, Apr. 1995,
ftp://ietf.cnri.reston.va.us/internet-drafts/draft-ietf-html-
leupload-02.txt.
[34] E. J. Nicolson, \Standardizing I/O for Mechatronic Sys-
tems (SIOMS) Using Real Time UNIX Device Drivers",
Proc. IEEE Intl. Conf. on Robotics and Automation, May
1994, pp. 3489-3494.
[35] L. E. Parker, Heterogeneous Multi-Robot Cooperation,
Ph.D. thesis, MIT EECS Dept., Feb. 1994.
[36] D. Raggett, \HyperText Markup Language Specication
Version 3.0", Internet draft, Apr. 1995,
http://www.hpl.hp.co.uk/people/dsr/html3/CoverPage.html.
[37] K. S. Roberts, \Robot Active Touch Exploration: Con-
straints and Strategies", Proc. IEEE Intl. Conf. on
Robotics and Automation, 1990, pp. 980-985.
[38] T. B. Sheridan, Telerobotics, Automation and Human Su-
pervisory Control, MIT Press, 1992.
[39] A. Silberschatz and P.B. Galvin, Operating System Con-
cepts, Addison-Wesley, 1994.
[40] A. Thyagarajan, S. Casner, and S. Deering, \Making the
MBone Real", Proc. INET'95, 1995.
[41] I. Tou, S. Berson, G. Estrin, Y. Eterovic, and E. Wu,
\Strong Sharing and Prototyping Group Applications",
IEEE Computer, 27(5), May 1994, pp.48-56.