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  and is a form of resource sharing. When we add the goal of Web-accessibility, relevant previous works include the following.
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 , which supposedly provides a ``virtual laboratory / virtual factory".
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  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.