Contrasts With Previous Work

Clearly, our goal of implementing Web-accessible autonomous mobile robots entails solving many problems. A brief digression into an operating systems analogy points out transferable techniques and enables a more tractable picture of the system design. First, the shell provides a user interface through which users submit commands and receive responses from the system. Basically, the shell provides user registration, user login, utilities such as job submission commands/languages, data logging commands/languages, commands ``who'' and ``talk'' to facilitate collaboration. The shell also provides a programming environment (compiler, simulator, and debugger). Second, the kernel schedules resources and implements the shell commands. Thus, the kernel is responsible for such system aspects as: (i) communication between entities, (ii) sharing, scheduling and partitioning of resources, (iii) the safety net, (iv) maintaining information about users (e.g., to enforce different levels of access), and (v) security.

With this in mind, even a minimal realization of our system must accomplish the following four steps: (i) realize remote operation of taskable machines, (ii) add programmability, (iii) add multiplicity and autonomy, and (iv) add collaborative remote experiment capability.

Regarding remote operation of taskable robots (our step one), the field of telerobotics has a 50-year history [38] and is a form of resource sharing. When we add the goal of Web-accessibility, relevant previous works include the following.

• The Mercury project at USC [19,21] consists of a robot manipulator moving above a section of earth known to contain artifacts. There is a downward-pointing camera attached to the distal end of the robot arm. By clicking on an image or buttons on the Web page, users can make the robot move along the X-Y axes and the camera along the Z axis. In real-time operation, GIF images of the camera view are updated on the Web page, and a session is logged as an MPEG movie; the only sensory data is the energy level. This project has been decommissioned since March 31, 1995.
• The Australia's Telerobot On The Web project at the University of Western Australia [24] challenges users to control the parallel-jaw grippers of a six-axis manipulator to pick up blocks on a table. Through a fill-out form, users can submit desired (X,Y,Z) coordinates, and roll,pitch,yaw actions. A fixed camera gives a side view of the arena, and the image is updated when the user command is submitted and executed.
• The Bradford Robotic Telescope [14,25] allows users to work either in batch mode or in real-time mode. The user describes what he wishes to observe and the telescope moves accordingly. One of the strong features of this project is the good implementation of user access control: users must register, login (passwords can be changed via e-mail), and submit jobs. Furthermore, jobs are prioritized; only those with highest priority are allowed real-time control of the telescope.

All three of these projects afford remote manipulation of taskable hardware through a Web interface. In this sense, they have demonstrated the feasibility of certain basic aspects of our project plan. However, in each of these projects there is only one piece of taskable hardware (the Mercury project uses an IBM manipulator, the UWA project uses an ASEA industrial robot, and the Telescope project uses a telescope interfaced to PCs); hence, issues of multiplicity and autonomy do not arise. Furthermore, since there is no programmability involved, neither programming environment nor data logging is an issue in these projects.

Regarding adding programmability (our step two), the most significant work we know of is the Onika project at Carnegie-Mellon University [18], which supposedly provides a ``virtual laboratory / virtual factory".

• Onika is an interface to a real-time operating system called Chimera which supports reusable real-time software. Through Chimera, reusable software modules downloaded from other sites can be immediately assembled. Onika's contributions are (i) an iconic interface for linking software modules (basically, like an object manager in an object-oriented environment), (ii) the ability to follow hyperlinks to retrieve remote software modules, and (iii) display of video and other information at run time. In a demonstration, remote and local software modules for controlling a Puma manipulator were linked and executed using the Onika interface, with real-time video of the Puma shown on the interface.

For our purposes, something similar to the Chimera operating system would be able to provide a good software development environment for collaborating sites, and a friendly user interface like Onika would be equally useful.

We know of no works that address the last two steps -- multiplicity, autonomy, and collaboration -- of our minimal system realization. Certainly, computer-supported collaborative design [41] and ``Virtual Environment'' efforts are well-developed research fields, and it is possible that techniques from those fields will allow collaborative remote experiment capability to be built on top of realizations of the first three steps above.