Motivation Autonomous field robots face unstructured, harsh natural environments. One unpredictable aspect is the radio medium used to maintain communication between an operator's base station and the robot. Terrain occlusions, competing networks and weather can all make the available bandwidth to the robot unpredictable and noisy. During times of high bandwidth, all available telemetry and command data should be transmitted to and from the robot, enabling precise teleoperation by a human operator in the face of hazards, and archiving all robot telemetry for post-processing and data analysis. However, in times of low bandwidth, only the highest priority telemetry and commands should be transmitted, allowing the robot to still be rescued if necessary. No design currently exists for sensing what bandwidth is available to make intelligent decisions about what data to send and receive. Background A particular application for this capability is the Hyperion solar powered field robot, being developed by the Sun-Synchronous Robotics Project at the Robotics Institute. In July 2001, this four-wheeled autonomous field robot will demonstrate long-distance (24 km) sun-synchronous circuits in the Canadian Arctic. On- and off-board intelligence will attempt to optimize solar energy gain while avoiding damaging obstacles. The prototype robot will operate continuously for 24 hours, demanding highly reliable mechanical, electrical and software systems. Communication with Hyperion will be performed by a radio Ethernet network using the 802.11 protocol. Messages are passed between processes on and off the robot using the IPC messaging API written by Reid Simmons (see www.cs.cmu.edu/afs/cs/project/TCA/www/ipc/ipc.html - NOTE: this does not refer to general UNIX inter-process communication). IPC message types are represented by standard C data structures. Messages can be passed in anonymous publish/subscribe, direct connect publish/subscribe and client/server. Software to transmit and log these IPC messages will be developed. Hyperion's onboard data storage resources are limited to a 1 GB hard drive so all telemetry cannot be logged onboard - some messages must be transmitted over the wireless Ethernet and logged at the base camp. Furthermore, a data log on Hyperion is inherently susceptible to damage due to vibration or harsh thermal conditions, so a data log in the base camp is preferable even if the robot did not have disk space limitations. Project Description Our class project will develop tools to tackle Hyperion's data-logging problem by developing a Telemetry Manager module to run on Hyperion. When bandwidth is available, our tools will ship telemetry over the wireless link. When bandwidth is low or zero, telemetry will be logged to Hyperion's local hard disk. Graceful degradation in the face of decreasing bandwidth will be a primary focus of our project. To guarantee integration and maximum utility for the robot's demonstration in July, our approach is to partition the design into the following well-defined subsystems (also see Figure 1): * Bandwidth Sensor. This subsystem is responsible for reporting the currently available bandwidth between the robot and the operator's base station. * Message Filter. This subsystem will use the output of the bandwidth sensor and examine the oldest messages logged locally and decide which messages should be shipped over the wireless link. A human operator will prioritize message types to aid in the decision process. * Telemetry Router. This largest subsystem will carry out the decisions of the message filter, either transmitting the message via IPC or logging it. The data log will be implemented similarly to a circular buffer, so as the robot's disk space runs out, old messages will be overwritten. [Figure 1. Telemetry manager architecture] The architecture proposed has the following benefits: * If the total size of all messages to be sent is less than the maximum attainable radio Ethernet bandwidth (which should always be the case), then in periods of high bandwidth the data log can be emptied across the network. * The Message Filter can implement complicated or simple message priority schemes. * Only the Bandwidth Sensor is dependent on the type of network protocol used. Furthermore, various bandwidth-sensing approaches could be used without modification of the rest of the system. Our initial bandwidth sensing approach will be to interrogate and possibly modify the driver for the wireless network PCMCIA adapter in Hyperion's computer. This driver implements the 802.11 protocol, which uses a scheme called dynamic rate shifting, a well-defined method of stepping down bandwidth in response to transmission problems. We hope that this will result in a low-noise bandwidth reading and overall a predictable system. If this approach fails, software will be written to measure the packet round-trip time between Hyperion and base camp. This approach may be simpler but could result in a very noisy bandwidth reading.