System Requirements

A taskable robotic system for remote experimentation has the following requirements for mobility, sensing, and data logging, real-time response, communication, user interface, and programming support.

• Mobility implies the following technical problems. (i) Energy. Mobile robots must carry their own energy sources or must derive their energy from the environment using, e.g., solar cells. If the robots are dependent on an external source of energy, then they must be able to navigate safely to a refueling station when necessary. (ii) Location. To exploit maps of the environment, or to navigate to prescribed sites, robots must determine their positions; possibilities include differential Global Positioning System (absolute coordinates), beacon system (relative coordinates), or landmark-based navigation (in unstructured environments). Robots must also be able to determine locations of other objects relative to their own frame of reference. (iii) Collision avoidance. Robots must detect both static and moving objects in the environment and execute avoidance algorithms.
• Data logging must be sufficient for the scientific application at hand (e.g., remote monitoring or exploration), as well as for reconstruction and analysis of the scientific experiment itself. For the former, on-board data storage is required along with possibly intelligent data/image processing prior to downlink in power- or bandwidth-limited scenarios. For the latter, low-level sensor and actuator traces, and perhaps (compressed, low-sample rate) video and program traces should be archived for eventual transmission to the remote experimenter.
• Real-time response is required since the robots are mobile in possibly hazardous environments. On-board requirements include a fast CPU and an approximation of real-time preemptive multi-tasking. Remote user requirements include low-resolution feedback of sensing and actuation (possibly including some form of video feedback). Since such feedback has multiple sources with varying bandwidth requirements, flexibility in the spatial or temporal resolution of the feedback streams must also be possible.

• Communication must be sufficient for the agents in the robot colony to coordinate their actions. There is a tradeoff among communication bandwidth, sensing and processing, in that communication can be achieved implicitly by monitoring other robots, by sensing the effects of other robots' actions, or most directly through explicit messages that are transmitted over some communication channel [13]. If robots are able to model other robots (i.e., beliefs, states, goals, etc.), then communication requirements will be correspondingly decreased. For our purposes, standard wireless networking technologies provide the necessary bandwidth and flexibility in topology. Communication must also enable telemetry (uplink of operator control and downlink of scientific data). As noted above, real-time downlink might include behavioral state and low-level sensory data. If video feedback is desired, it will dominate the downlink requirement and bandwidth on the order of hundreds of Kbps will be necessary.
• The user interface must provide facilities for user validation and acquisition of the taskable resource, program submission, experiment registration, experiment setup (i.e., to achieve repeatably a prescribed initial configuration of robots and obstacles), on-line control of the experiment, viewing of near real-time feedback (e.g., the low-resolution video and sensor traces noted above), and receiving/viewing of the experimental data (e.g., in the form of a report). Additionally, tutorial facilities may be offered. For universal accessibility, the interface should be graphical and Web-based.

• Programming support should be on at least three levels: Level 1 allows interpreted, immediate execution; Level 2 allows scripts of Level 1 instructions; and Level 3 affords high-level language support and access to hardware via an application programmer's interface (API). Simulation facilities can speed experiment design and programming, as well as off-load demands on the actual robotic resource when the user community is large. Particularly, with sophisticated experiments that require Level 3 support, the API should allow both scripting capability and low-level access to the robots. An ideal solution would be Unix-based with a standard mechatronic interface [34] to low-level control of the robot. Such an approach would leverage the mature Unix development environment, affording scripting and rapid prototyping capabilities, while retaining low-level hooks into the hardware.