Computer Networks and ISDN Systems 23 (1995) 209-219
`
`Beyond the Web: manipulating the real world
`
`Ken Goldberg a° * ,Michael Mascha b, Steven Gentner a, Jurgen Rossman ~,
`Nick Rothenberg d, Carl Sutter e, Jeff Wiegley a
`a Department of Computer Science, Uniuersiry of Southern California, Los Angeles, CA 90089, USA
`e Department ofAnthropology, University of Soulhem California, Los Angeles, CA 90089, USA
`University of Dortmund, Dortmund Germany
`d Department ojVrsual Anthropology, University of Southern Cafifomia, Los Angeles, CA 90089, USA
`Center for Scholarly Technology, University of Southern California, Los Angeles, CA 90089, ITSA
`
`Abstract
`
`This paper describes a WWW site that allows users to "leave the Web" and interact with the real world. An
`interdisciplinary team of anthropologists, computer scientists and electrical engineers collaborated on the project,
`desigining a system which consists of a robot arm fitted with a CCD camera and a pneumatic system. By clicking on
`an ISMAP control panel image, the operator of the robot directs the camera to move vertically or horizontally in
`order to obtain a desired position and image. The robot is located over adry-earth surface allowing users to direct
`short bursts of compressed air onto the surface using the pneumatic system. Thus robot operators can "excavate"
`regions within the environment by positioning the arm, delivering a burst of air, and viewing the image of the newly
`cleared region. This paper describes the system in detail, addressing critical issues such as robot interface, security
`measures, user authentication, and interface design. We see this project as a feasibility study for a broad range of
`WWW applications.
`
`Keywords: Robot; Remote control; Mercury Project; USC; Random token; Telerobotics
`
`1. Goals of the project
`
`The WWW provides amulti-media interface
`that spans all major platforms. Thousands of sites
`have been set up in the past year. Our goal with
`this project was to provide public access to a
`teleoperated robot, thus allowing users to reach
`beyond the digital boundaries of the VVWW,
`
`' Corresponding author. E-mail: goldberg@ieor.berkeley.
`edu.http://www.usc.edu/users/goldberg. This work was
`supported in part by .NSF Awards IRI-9123747 and IRI-
`9457523.
`
`Such a system should be robust as it must'
`operate 24 hours a day and it should be low in
`cost (we had an eactremely limited budget). It is
`worth noting that the manufacturing industry uses
`the same criteria to evaluate robots for produc-
`tion. Thus our e~cperience with RISC robotics
`(see below) proved helpful
`Our secondary goal was to create an evolving
`WWW site that would encourage repeat visits by
`users to collectively solve a puzzle. This paper
`focuses on the details of the unplementation. The
`Mercury Project is arctii~ed with supporting ex-
`amples and statistics at:
`http: //www.usc.edu/dept/raiders
`
`0169-7552/95/$09.50 OO 1995 Published by Elsevier Science B.V. All rights reserved
`SSDI 0169-7552(95)00094-1
`
`Petitioners - Exhibit 1007 Page 1
`
`

`
`210
`
`K Goldberg er al. /Computer Networks and ISDN Systems 28 (1995) 209-219
`
`2. Related work
`
`3. User interface and environment design
`
`The first "teleoperated robots" were devel-
`oped over 40 years ago. The basic objective has
`always been to develop systems capable of work-
`ing in inhospitable environments (such as radia-
`tion sites). Teleoperation began with very simple
`mock-ups in nuclear power plants [6], progressing
`to more versatile setups for teleoperation of
`robots in space [?J. Over the last 20 years, the
`development of intuitively operable teleoperation
`tools has continued to play an important role in
`the development of robotics in general. The basic
`objectives have remained the same, even though
`.the methods and technical limitations have
`changed. See also [4].
`Today, sophisticated "Telerobot Operator
`Control Stations" [3] are equipped with stereoim-
`age-displays, "force reflecting hand controllers"
`and comprehensive video graphics support. The
`development of teleoperation stations is currently
`being pushed further with the help of latest
`graphics workstations to provide so-called "tele-
`presence". Modern telepresence systems, consid-
`ered to be pushing the frontier of research in this
`field, are defined as follows [l]: "At the worksite,
`the manipulator has the de~tteriry to allow the
`operator to perform normal human functions. At
`the control station, the operator receives suffi-
`cient quantity and quality of sensory feedback to
`provide a feeling of actual presence at thework-
`SItC".
`The Mercury Project does not achieve this
`level of telepresence but provides a lunited level
`of teleoperation. One of our goals was to provide
`"teleoperation for the masses". Instead of devel-
`oping ahighly sophisticated, multi-million-dollar
`testbed, we opted for a simple and reliable end-
`effector on a commercial robot. Combined with
`an intuitively operable man-machine-interface,
`the system gives all WWW users access to teleop-
`eration. In the Discussion section, we describe a
`number of other WWW sites that offer interac-
`tive capabilities.
`
`The interface design for the system was chal-
`lenging due to the limitations of the
`HTML/HTTP environment, as well as network
`traffic considerations. An effective system was
`created within such limitations by carefully de-
`signing the physical environment for the robot,
`and by fine-tuning the user-machine interface.
`For example, the initial idea of a live video feed
`from the camera was dropped in order to main-
`tain compatibility with all visual clients on the
`Web. (Although we could have implemented some
`custom clients 1, we decided to stay within the
`limits of H'I'ML/FTITP to reach as large a user
`base as possible, making this a truly global sys-
`tem.) In addition, initial simulations using a robot
`fitted with grippers (simulated in VIRTUS
`WALKTHROUGH) revealed a high degree of
`
`I There are two possble fixes to this protilem, One is to
`release specially modified clients that set up a two-way com-
`munication, the second is to use some other software to
`display the current system on the user's client workstation.
`Since many clients are used to view the WWW, making
`modifications would be difficult, especially since they are
`being updated all the time. Even if source code could be
`obtained for every major client, changes would have to made
`to every release of all these be on each release of these
`applications, The second possibility is to write a separate
`program to run on the clients' workstation. The problem here
`is to write a robots client that can be released for enough
`platforms to be useful, -Since this would be an esoteric piece
`of the system, it is not likely that other sites would customize
`the software for different systems like is done for the major
`systems. One technique is to use the X windows protocol to
`display a client application on the users workstation running
`an X server (weather, movies). We felt that this would be a
`limited audience, however, It also may compromise security.
`from the user's point of view, Both these approaches may be
`attempted in version 2.0 of the system to allow more en-
`hanced use of the system for some users. The HTTPD proto-
`col could be extended to allow these sort of connections,
`though—maybe we need a new protocol for passing media
`only back that doesn't have all the hooks into system calls like
`X Windows and Display PostScript.
`
`Petitioners - Exhibit 1007 Page 2
`
`

`
`i
`
`i
`
`K Goldberg et al. /Computes Networks and lSDN Systems 28 (1995) 209-219
`
`211
`
``.
`
`Fig. 1, The control panel.
`
`~,
`~) ~° ii
`
`comple~uty in control functions z, not suitable for
`the anticipated 5-10 seconds per frame page
`loading time, a 2D Mosaic window and a
`naive/untrained user.
`The team chose instead to use a simple envi-
`ronment which would allow relatively easy con-
`trol of the robot. Here the analogy taken from
`real world archaeology—using adry-earth envi-
`ronment 'and compressed air bursts—allowed us
`to simplify the robot control dramatically. Thus
`users could be quickly trained in the operation of
`the system, through a simple "Operator's Orien-
`tation" and a "Level 1 Clearance Test".
`Even with a simplified system (see Fig. 1),
`users are still able to choose between fine and
`gross movements of the arm. Fine pitch move-
`ments are executed by clicking in the camera
`image, with the robot moving to center the arm
`over the X,Y-coordinates of the click-point. Crude
`navigation is provided by clicking on a schematic
`picture of the robot and it's workspace, with the
`robot moving to center the arm over the click-
`point. Two buttons allow navigation in the Z-a~cis
`(between "up" and "down" positions), with a
`button to blow air only active when at the Z = O
`(i.e., "down") position.
`
`Other features of the system were designed to
`balance functionality with user needs. All H'I'ML
`documents sent to the clients are carefully de-
`signed to minimize network traffic in order to get
`a high refresh rate. For example, control panel
`functions are clearly distinguished from text-based
`information documents. The "Operator's log" was
`implemented to create a forum for collaborative
`efforts to solve the puzzle/problem regarding the
`underlying logic which links the artifacts. (The
`"Operator's log" is readable throughout the sys-
`tem but only writeable after completing an oper-
`ating session.) A second entry path 3 was also
`created to the system, which provides a "back-
`story" explaining the project while also hinting at
`possible "real world" uses of the system,
`
`4. Access to the robot
`
`Most of the HTML documents seen by the
`user on our site are generated by a script running
`on the WVJW server. Using a random token
`scheme described below, the system tracks' each
`user as he or she proceeds through the interface
`and generates appropriate HT'ML documents.
`This allows. the system to discriminate between
`
``3D control of a robot needs: 3 dimensions of spatial
`movement, 3 dimensions of orientation and 1 to 3 dimensions
`of gripper control
`
`http://www.usc.edu/dept/raiders/story/mercury-
`story.html
`
`Petitioners - Exhibit 1007 Page 3
`
`

`
`212
`
`K Goldberg et al. /Computer Networks and ISDN Systems 28 (1995) 209-219
`
`"observers" and "operators" so that it presents
`only accessible options to each.
`To operate the robot, the user must read the
`information on how to use the control panel, and
`then complete alevel-1 clearance test to get a
`password. Since only one person can operate the
`robot at a time, the system maintains a queue of
`pending operators. A typical user will enter
`his/her password, and then add him/herself to
`the queue. Each time the update button is clicked,
`the system updates the queue and returns a cur-
`rent status page. When the user's turn arrives,
`the screen returned is the live operators' control
`screen.
`
`5. System architecture
`
`Fig. 2 shows a block diagram for the system.
`We start with an overview that necessarily glosses
`over many interesting details.
`At one..end are WWW_clients_from_around the
`__
`_, _ _ :.
`world; at-the-other end is a robot arm combined
`with-a=camera: The robot and camera provide an
`updated image of the environment, which is com-
`bined with a schematic of the robot arm/works-
`pace and control buttons to produce the final
`GIF image that is send to users.
`At any given time there may be dozens of
`clients interacting with the system, Since there
`
`can only be one operator at a time, one challenge
`is to keep track of which client is the operator.
`The ,Mercury system is comprised of `three
`communicating `sewers. The first, call it A, is a
`standard Mosaic server (NCSA httpd v.1,3, cur-
`rently running on a Sun SPARCserver 1000, with
`SunOS Release 5.3. When ,the Site is requested
`by an observer, the most recent_ image, which. is
`stored on server A, is simply returned:
`The database of registered users is handled by
`another server, tail it B. In our case, server B
`runs on the same machine as server A. The
`database server is custom programmed for this
`project, but performs fairly -standard database
`functions.
`- - -
`When aclient request comes in, server A
`communicates with server B. If that- client ss an
`j' operator, server A must then communicate with
`a third server,-call it C, that controls the robot.
`Server- C runs on a Pentium-based PC and tom-
`municates with. servers A and. B_ via the Internet.
`Server A decodes the ISMAP X and Y mouse
`coordinates, and sends them to server C.
`On server C, a custom program decodes these
`coordinates into a robot command and verifies
`that t_he_ command is legal e.g., within the robot
`workspace. If it is, this ~ command is then con-
`verted-into a robot command format which is sent
`to the robot over a serial line, Once the robot
`move is completed server C uses the CCD cam-
`
`~`,`~ H~T7P SERVER
`
`'~i;.~
`
`~ ;<~_ ~
`
`.
`
`~ ~ Dynamic DoCt~m~3nts S~ripi~
`L_1 J
`,.
`~'' ~ ~(~ta Sarver H
`L_iJ
`__ —
`F--.
`-
`
`_ _
`E _ ! ~
`
`__
`
`_.
`
`Ethamot Gard
`
`7CW i~
`S~rF:~d Code
`
`~. VidC-o
`p~ Di~itiring
`
`--a--~•
`
`',;tI:r,
`
`~~;~ Seridt Port _,{..~-
`
`, _
`
`System Block Diagrazn
`
`Fig. 2. System block diagram.
`
`Petitioners - Exhibit 1007 Page 4
`
`

`
`C\
`
`t
`
`~..
`
`C a 1:.
`
`~
`
`''~
`c
`
`~
`
`1
`
`U'
`
`fr
`
`~ ~
`i,
`
`K Goldberg et al. /Computer Networks and ISDN Systems 28 (1995) 209-219
`
`era to capture a stable 8 bit 192 x 165 image of
`the workspace.
`Using a simple set of equations for inverse
`kinematics server C then generates a schematic
`view of the robot in its new configuration. This
`schematic is combined with the camera image,
`and the up, down, and air control buttons to form
`a new composite image. Server C then. com-
`presses this unage into GIF format and returns it
`to server A, which updates the most recent image
`and returns it to the operator client.
`
`-
`
`6. Subsystems
`
`6.1. Random tokens for cache avoidance and user
`tracking
`
`Following some complex and unwieldy .tests,
`we implemented a random token scheme for
`tracking users as they use the system. Each time a
`~ LTRL is returned, a large random number is added
``
`~ ~ , , i ~,.! - to the path (which the NCSA HTTPD 1.3 server
`~,
`~
`splits into the PATH_INFO environment vari-
`able), This "token" serves two purposes;
`The first is to prevent ttte WWW client from
`caching the robot view. When a document is
`requested a second time during a session, it is
`much faster to swap in a local copy of the docu-
`ment rather than going back over the net to
`retrieve it a second tune. Most unplementations
`of Mosaic support such caching at various mem-
`ory levels: However in our case we want to re-
`peatedly retrieve the URL containing the robot
`image because it is updated continuously. In brief,
`we don't want users to cache this URL. The
`random token makes each request look different
`and tricks the client into retrieving a fresh version
`of the document.
`The second use for the token is to identify
`operators. When an operator logs in with a cor-
`rectpassword, the system begins tracking him/her
`as he/she moves from viewing the robot to being
`on .the.-.operators' queue to operating the robot.
`Since the same script is used for all views, the
`token allows the system to customize the result
`for every user depending on his/her position in
`the system.
`
`1 `,
`
`6.2. Scripts
`
`The robot view screen is controlled for the
`most part by one script at the HTTPD server.
`Each call to the main script has a token attached
`to the URL. The token is decoded by the WWW
`server, and placed in the PATH INFO environ-
`ment variable, The main script then checks the
`token with the database server to determine the
`status of the user. Each check of the database
`generates a sgstem update to keep the queue
`moving. The user's status is used to generate the
`custom system status page.
`The robot image itself is only changed by the ~
`operator when he or she makes a move, Each
`image is date and time stamped, so WWW clients
`that cache the image will only retrieve the image
`when it changes (since its filename will be differ-
`ent, due to a different tune stamp).
`Due to the client-server architecture of the
`World Wide Web HTTPD protocol, the robot
`system (server) has no way to contact the client
`except at the client's prompting. From the user's
`point of view, once he or she gets the robot view
`screen, there is no way for the server to keep
`sending updates automatically as the robot is
`moved by the operator. The screen updates must
`be driven by the user. Since the user must trigger
`each update, we wanted to provide a button for
`doing so, since each web client handles reloading
`the page differently. Some sites have a "reload"
`hypertext Link to the same page, buf this doesn't
`work for any client that caches pages. If a page is
`being viewed, hitting reload will just re-display
`the page from the cache, thus not obtaining a
`new view from the system. Asking the user to
`disable his/her cache is also problematic, since
`not all clients allow this option.
`One attempt was made to use amini-form,
`since the submit button always calls a script and
`is not cached. That scheme was eventually
`dropped, since passing registered user identifica-
`tion information to the server via hidden fields
`only worked on some clients. Using the random
`token allows for an elegant interface,
`Since the robot can only be controlled by one
`person at_ a time, a registration scheme was im-
`plemented to allow the server to track operators
`
`Petitioners - Exhibit 1007 Page 5
`
`

`
`214
`
`K Goldberg et al. /Computer Nehvorks and ISDN Systems 28 (1995) 209-219
`
`as they move on to the waiting queue and progress
`to controlling the robot. Since the server only
`knows the IP address of each user, some user
`information had to be incorporated into the
`HTML robot view document itself for re-trans-
`mission to the system when the user hits "reload".
`There are various techniques used. by many so-
`phisticated web systems to accomplish user iden-
`tification between document requests, but we
`found some problems in many of the standard
`solutions. In the end, the random token served
`excellently as a means of identifying registered
`users.
`A preliminary attempt was made to use a small
`form to identify the user. Hidden fields could
`hold the user id, but once again, many clients do
`not implement the hidden field attributes so the
`interface is cluttered by unnecessary fields.
`Putting the user's id information into the AC-
`TION field of the form tag is also client depen-
`dent. Unfortunately, some clients strip that data
`before adding the encoded field information.
`Since random tokens were already being passed
`with each update, the system was extended to
`track the tokens of each registered user. Each
`time the script is called, the token is exchanged
`for a new one, and the database is updated with
`the new token for registered users. One side
`effect is that the user cannot use the client re-load
`button, since this will not use the new URL (it is
`embedded in the update HREF).
`
`6.3. The data server
`
`The data server (B) is a custom Perl script that
`handles all of the database work for the project.
`It continuously runs as a TCP/IP listener, wait-
`ing for database transactions from the other sys-
`tem scripts. The data server runs as a single
`process, handling requests serially to maintain
`internal data integrity. Typically, transactions are
`very short, since the data is kept in main memory.
`The data server could be replaced by an off-the-
`shelf transaction based DB system in the future.
`A time-out is set to close the connection if there
`is too much time elapsed between commands_.;
`This was implemented because some WWW
`clients would crash in the middle, of a document
`
`request, leaving the system waiting for the con-
`nection to be closed.
`
`6.4. Internal network interface
`
`The networking functionality required by the
`project was defined by two factors. On one hand,
`the camera that we purchased required a PC-
`based platform running an Microsoft DOS or
`compatible operating system to run on server C.
`On the other hand, the expected load of client
`requests required a machine capable of more
`heavy networking duties such as a Sun worksta-
`tion (server A). Currently server A is located
`across campus from server C.
`These servers are connected via Ethernet. Each
`machine has its own IP address and resides in the
`usc.edu domain. Communication is achieved us-
`ing asocket connection between the two ma-
`chines. The implementation on server A was
`done using the standard BSD socket functions
`provided with the SunOS 4.1 operating system
`and Perl. On server C we used a publicly avail-
`able socket package called Waterloo TCP and
`Borland C. The Waterloo TCP package was ob-
`tained from the ftp site dorm.rutgers.edu in the
`file /pub/msdos/wattcp/wattcp.zip.
`With this software server A can request a
`socket connection to server C to establish a con-
`nection. The first step in obtaining a new image is
`for server A to write a command consisting of
`thirty bytes which encodes the (XY) coordinates
`of the ISIv1AP event. After server C completes
`the moves and generates the new image, it writes
`the size of the new image to server A so that
`server A knows exactly how many bytes to expect.
`Server C then proceeds to write the entire image
`to the socket and waits for the socket to close to
`insure deliver of the. data. Once server A has
`read alI the specified bytes it closes the socket.
`Server C is now ready and waiting for another
`socket connection. Server A is free to continue
`processing the Mosaic actions of the current users.
`Current throughput is approximately 20
`Kbytes/second, which is poor compared to the
`0.5 megabyte per second rate that can be achieved
`between two Sun workstations in close pro~mity
`on the campus network. At this time we feel that
`
`Petitioners - Exhibit 1007 Page 6
`
`

`
`!C Goldberg et al. /Computer Networks and ISDN Systems 28 (1995) 209-219
`
`215
`
`the delays are being imposed by the MS-DOS
`operating system because of its inability to sup-
`port networking operations and its lack of multi=
`tasking abilities, which necessitates busy waiting
`cycles in the PC software to obtain concurrence
`between the robotic/camera operations and the
`networking duties.
`Our low data rate is somewhat tolerable be-
`cause the tune for communication between servers
`A and C is small compared with Internet delays
`,,, between clients and server A. One way to speed
`communication would be to use different meth-
`ods of image compression such as JPEG to re-
`duce the size of the image. However this may
`introduce latency due to encoding.
`
`6.5. The IBM robot and server C
`
`The robot we're. using is an IBM SR5427
`SCARA arm, built around 1980. SCARA stands
`for "Selective Compliance Assembly Robot Arm".
`Robots with SCARA kinematics are common in
`industrial assembly for "pick-and-place" opera-
`tions because they are fast, accurate and have a
`large 2.SD workspace. However, the SCARA arm
`can only rotate its gripper about the vertical (Z)
`aacis. We selected this robot over other robots in
`our lab due to its excellent durability, large
`workspace, and because it was gathering dust in
`the Robot Education Lab.
`The IBM SCARA robot is controlled through
`a 4800 baud serial port by a custom written C
`library constructed with reference from IBM's
`BASIC library distributed along with the robot.
`The commands sent by the library are simple
`instructions consisting of instruction id, length,
`data and checksum. The data length and content
`varies depending on instruction id. The IEEE
`floating point format is used to represent the
`necessary data. This command string is then sent
`over the serial line to the robot to issue the
`command.
`Unfortunately IBM no longer supports this
`robot and we were forced to read two antiquated
`BASIC programs and monitor their serial line
`transmissions to decipher the protocols needed
`for serial control of the robot. The robot accepts
`XYZ and Theta commands using IEEE format
`
`and checksums. Server C now runs on a Pentium
`based PC with all custom code written in Borland
`C.
`
`The first step was implementing a local graphi-
`cal user interface to control robot movements
`and monitor subsequent functions such as net-
`work flow. We chose two views of the workspaces
`a global schematic view for coarse motions, and a
`local camera view for fine motions. Note that a
`click on the camera image requires a different
`relative move if the camera is in the up or down
`position. To handle it, we implemented an empir-
`ical calibration program.
`The major difficulty in implementing server C
`was to schedule response to the network, the
`local mouse, and the image capture board. At
`first we discussed amulti-tasking environment
`but, upon further study, we realized we could
`achieve this cooperation within a single DOS
`task. Another problem, inherent to DOS-based
`applications, is memory management. This com-
`plication was solved by careful usage of memory
`and by utilizing the screen itself as a memory
`buffer. This careful usage of memory enabled the
`custom written GIF encoder to use more memory
`which, combined with an appropriate hash func-
`tion, sped the GIF encoding process up to a few
`microseconds.
`In future versions of Mercury, we plan to
`incorporate a more sophisticated PC-based robot
`simulation system based on COSIMIR [8] from
`the University of Dortmund.
`
`6.6. Camera
`
`We are using an EDC 1000 digital CCD _cam-
`era from Electrim Inc, This camera was chosen
`based on size and cost. Image data is sent from
`the camera back through a serial line intoavideo
`capture card. The picture captured is always 192
`X'165 pixels with 256 shades of gray. The image
`size and gray shades are fixed. Focus and contrast
`are manually adjusted. Exposure time can be
`changed by software to range between 1/200th to
`1/64th of a second. 1/150th exposure was used
`to reduced light streaking that the camera is
`prone to.
`
`Petitioners - Exhibit 1007 Page 7
`
`

`
`216
`
`K Goldberg et al. /Computer Networks and ISDN Systems 28 (1995) 209-219
`
`Although the robot's control system quickly
`dampens oscillation about the destination point,
`dynamic effects can cause image blur. Two solu-
`tions were implemented. First the robot was
`slowed down enough as to reduce some of the
`vibration but not to hinder the robot access speed
`considerably. Second, once the robot responds
`positively to an issued command, the camera cap-
`tures two_: pictures= each-`at 1/64th of a second.
`These two images are compared to determine a
`factor of similarity. If this factor is below some
`set value the image is presumed to be stable,
`otherwise subsequent pictures are taken until the
`image pair is determined to be stable. More than
`5 trials results in a time-out in which case the
`most current image is used and the program
`continues. This image comparison procedure re-
`duces movement streaks seen in pictures of mov-
`ing objects.
`Lighting the workspace has been problematic.
`The work space is primarily luminated by stan-
`dard florescent ceiling fixtures and augmented by
`two additional florescent lamps to reduce shad-
`ows and raise the overall ambient light levels. We
`tested a contrast enhancement routine to normal-
`ize the lighting of each image captured from the
`camera. This increased the visual aesthetics of
`the image but subjected it to drastic light and
`dark changes as the robot moved onto different
`objects with different Iight reflecting qualities. In
`response, a global lighting adjustment was imple-
`mented but found to reduce certain areas to
`unacceptable darkness. Certainly a better lighting
`system is required.
`Due to the manual focus adjustment of the
`camera, the focus adjustment could not be
`changed between the up and down position of the
`camera. This resulted in a compromise focus ad-
`justment that is not perfect for the up or down
`position of the robot arm, buf accepatable in both
`positions.
`To decrease compressed image size and thus
`increase network transfer rate the image is re-
`duced from 256 to 64 gray scales since most
`systems available can only display 256 colors or
`64 shades of gray. Thus the gray scale reduction
`did not reduce image quality but reduced com-
`pressed image size by about lOK.
`
`6.7. Robustness and soft resets
`
`All robot motions are monitored by server C.
`Each command sent to the robot is verified to be
`within the robot's workspace. Acknowledginents
`from the robot are monitored to detect errors,
`When an error is detected, server C automati-
`cally resets the robot controller, recalibrates, and
`returns the robot to its previous position.
`
`7. Performance
`
`7.Y. History and statistics
`
`Daily statistics are available and may be corre-
`lated with project milestones 4. The site received
`over 2 million hits from over 50 000 unique sites
`during its active period from September 1994 to
`March 1995.
`
`7.2. Refresh rates uia ethernet
`
`System response time seems to be mostly de-
`pendent on network link speeds. Locally, we get
`screen refreshes at rates of 5-10 seconds per
`page. Similar response times have been reported
`from Europe. Obviously, a slow local link or SLIP
`connection will drastically affect the update
`speed, since the robot control image is essential
`to the system. Updates are also strongly affected
`by the speed of the WWW client application.
`
`7.3. Uptime
`
`The system is designed for 24 hour use. The
`WWW server scripts are generally modified,
`tested and then loaded into the running system.
`Background programs monitor the system and
`notify the team members if there are problems.
`
`7.4. Operators' logs
`
`When an operator has finished driving, he or
`she is prompted to make a textual entry into an
`"Operator's log". T'he Operator's log 5 provides
`
`http://www.usc.edu/dept/raiders/
`5 http://www.usc,edu/dept/raiders/
`
`Petitioners - Exhibit 1007 Page 8
`
`

`
`K Goldberg et al. /Computer Networks and lSDN Systems 28 (1995) Z09-219
`
`217
`
`an ongoing forum for discussion of the system
`and record of artifacts discovered in the sand.
`For example, several skeptics have claimed
`that the system is an elaborate how where all
`images are taken from a prestored library (much
`like the celebrated Apollo Moonwalk hoax of 25
`years ago). We have had encouraging comments
`from the robotics community, including several
`researchers at NASA.
`
`8. Discussion and fi►ture applications:
`
`This project is an initial step in an ongoing
`educational and research project at the Univer-
`sity of Southern California. It brings together
`faculty and students of different backgrounds to
`collaborate in the design and implementation of a
`networked system that combines robotics with
`archaeology and interactive art.
`This system exemplifies RISC Robotics, which
`advocates Reduced Intricacy in Sensing and Con-
`trol. The SCARA-type robot requires only 4 axes,
`is relatively inexpensive and robust, and it is easy
`to avoid singularities. The end effector we've
`used here is also about the minimum. For more
`on RISC as applied to industrial robotics, please
`see [2].
`We see the project leading in several direc-
`tions. For-Mosaic and ;;the WWVJ, the required
`interface design prompted new developments re-
`lated to several_ssues, including user authentica-
`tion, user queuing and :interface security (as dis-
``cussed above).
`For this project we chose a very simple appli-
`cation. The server can be extended to a variety of
`platforms that permit remote inspection and ma-
`nipulation of objects—for example, providing
`unique and unedited access and views of priceless
`and otherwise inaccessible resources (a Grecian
`urn, a Gutenberg Bible, etc.), thus providing an
`alternative to pre-stored libraries which are lim-
`ited in terms of perspective, depth of resolution,
`etc. For example, see http://vive,cs.berkeley.
`edu/capeK/
`Further extensions for this project might in-
`clude: the robot could be placed out in the field,
`in a remote anthropological site or on the moon;
`
`the camera could be replaced with a scanning
`electron microscope; or the remote operator could
`be a doctor examining a patient or a specialist
`performing remote inspection or manufacturing.
`All of these areas also have significant implica-
`tions for education, as they present the opportu-
`nity for virtual=-`-`field=trips" to a-live site while
`permitting remote.. manipulation_ from the_ class-,
`room;
`Anthropologists have conventionally recorded
`the diverse cultural heritage of humankind by
`means of varied media: written text, graphics,
`film, sound and still images. The advantage of a
`system like the one described in this paper lies in
`the fact that you do not' have to `7ely on prere-
`corded_media.-It enables the user to_.view_and
`possibly record. her or his _own_"slice of-reality".
`We see the Web as a perfect medium for updat-
`ing pre-recorded media as described in [5]. Fur-
`thermore, we now have the possibility to combine
`updateable ,prerecorded media of''all sorts with
`live recordings and live remote interactions. The
`possibilites of a system that combines global ac-
`ce