Path: egsner!convex!cs.utexas.edu!uunet!decwrl!pa.dec.com!nntpd.lkg.dec.com!sousa!sndpit.enet.dec.com!smith From: smith@sndpit.enet.dec.com (Willie Smith) Newsgroups: comp.robotics Subject: Waldo/Tycho teleop projects Message-ID: <1636@sousa.ltn.dec.com> Date: 24 Sep 91 15:22:44 GMT Sender: newsa@sousa.ltn.dec.com Organization: Digital Equipment Corporation Lines: 691 From: SNDPIT::SMITH "CLID: telecom arms race 23-Sep-1991 1955" 23-SEP-1991 20:25:20.57 To: @[.MAIL]TELEOP.DIS CC: Subj: (Simulated Lunar) Teleoperations Projects [Waldo/Tycho] [ I mailed this to my mailing list, but something went _very_ wrong on the net, and I don't know if it got out at all or everyone get 10 copies. Ayway, I'm also posting it to comp.robotics for your reading pleasure. The following is the second release of my (Simulated Lunar) Teleoperations Projects documentation, Copyright 1991 William P.N. Smith, all rights reserved. For a properly formatted hardcopy with color photos, please send a stamped ($1.67 to cover 7 ounces), self-adressed 8.5x11 inch envelope to: William P.N. Smith Teleop Documentation PO Box 150 Hamilton, MA 01936 Release dates: Hardcopy @ CHICON-V Aug. 29, 1991 Email to TELEOP.DIS Sept. 23, 1991 BTW: The adress smith@sndpit.enet.dec.com will be invalid after 09/27/91, and my expected new adress (wpns@pictel.com?) isn't yet active or final. Please adress all correspondence to me at the PO Box above.] 1. OVERVIEW I have been conducting teleoperations research since 1987, focusing on modelling vehicles that might be used in support of a lunar colony. Tycho, the first generation machine, has been complete since mid- 1988, and Waldo, the second generation machine, is Phase One Complete (a very basic teleoperated vehicle). The Tycho project was done in part for the Lunar Society, a volunteer organization promoting manned space exploration and colonization. I have been conducting this research in my spare time, with assistance from numerous people. 2. INTRODUCTION Teleoperation is basically remote control of a device from a separate (usually distant) location. Lunar teleoperation is the remote operation of a vehicle which is on the surface of the moon while the operator is on the Earth. This offers a significant advantage, as the vehicle can be operated 24 hours a day, with no requirement for additional personnel on the moon. The general case of a lunar teleoperated vehicle is one which can be moved by radio controls (telecommand) and which sends real-time pictures (and other telemetry) back to the operator by means of a video camera and transmitter. Waldo has (or will have) other features, such as a bulldozer blade, a manipulator arm, a stereo camera pair, etc. that allow it to do useful work in support of a lunar colony, or other inhospitable/inaccessible environment. 3. MOTIVATION 3.1 Low Support Costs The cost of supporting each person in a lunar colony is expected to be very high. Getting any mass to the moon will be very expensive, and the high price to import any expendable or consumable items such as air, water, and food will cause these ongoing costs to be a significant factor in the operation of a lunar colony. A teleoperated vehicle will use little or no expendable resources, only power to recharge, some maintenance time, and spare parts, considerably less than the usage of a corresponding human worker. Thus, even if the task were to take longer to accomplish by teleoperations, it would still be more cost- effective. 3.2 Continuous Operation A teleoperated vehicle will not need rest as people do, nor will it be restricted from surface activities during periods of dangerous radiation caused by solar flares. With the exception of recharging time and maintenance, it will be able to operate continuously, with multiple shifts of Earth-based operators. Further, the Earth-based operators could be at a variety of locations on the Earth, as overall staffing and availability dictate. 3.3 Initial Construction Teleoperated vehicles will be able to do some initial work on the colony before the first colonists arrive, as no life support or initial infrastructure is required. For instance, a number of tasks, like leveling and grading a landing field, digging foundations for the habitat modules, and surveying the colony area could all be completed by the time the first colonists arrive. 3.4 Amplifying Presence Once the colonists are on site, the teleoperated vehicles will assist them in their construction and other tasks, allowing one on-site colonist to do the work of several with the help of one or more earth- based operators. For instance, a teloperated vehicle could transport supplies, supply electrical power, pick up dropped tools, and assist in assembly and construction work. 3.5 Mining Teleoperations can also be used for mining the lunar regolith, in support of either the mining operations of a colony or an automated mine. Lunar regolith contains oxygen, aluminum, and other valuable raw materials that can be recovered, but large amounts of regolith may have to be transported to a central smelting/refining complex. 4. TELEOPERATIONS SIMULATION ISSUES 4.1 Teleop Delay The most significant feature of lunar teleoperations is the (approximately) 3-second speed-of-light roundtrip communications delay. If the operator of a lunar teleoperated vehicle tells it to stop, he will not see the vehicle stop until 3 seconds later. This is the major obstacle to efficient Lunar teleoperations work, and in order to develop command/control systems and train operators, this delay must be effectively modeled. 4.2 Real-World vs. Model In the case of real lunar teleoperations, the operator's command signals would be delayed by 1.5 seconds and the camera's video signals would be delayed by another 1.5 seconds. The apparent 3-second delay is the sum of these two delays, as the operator sees the vehicle respond to commands 3 seconds after they are given. Due to the cost of hardware needed to generate a 1.5 second video delay, we instead delay the control signals by 3 seconds to give the same net effect. A computer intercepts the commands from the operator's controls and transmits them to the vehicle 3 seconds later. 4.3 Variable Delay Note that in the real-world case, the teleop delay varies slightly as the moon orbits the earth and the earth turns. An ideal delay-modelling computer would take these effects into account when generating the delay. It will be interesting to see if teleoperators work better with fixed delays or (very slowly varying) variable delays. Different programs can also be developed to find the optimum method for training operators. For instance, delay could slowly be increased from zero to three seconds as the operator acclimatizes to the increasing delay, or the operator could be trained at 4 seconds to see if operation at the nominal delay increases his performance. 4.4 On-site Workers In the real world, there may be colonists working with the vehicle. In this case, there is a 3-second audio communications delay between the Earth-based operators and the lunar workers. This may be modelled with a bucket-brigade analog delay line, ADCs and DACs with computer memory buffers, or other means. At this time there are no plans for modelling this delay, as we are researching vehicle operations without nearby colonists. If such a capability becomes available however, we'll put it to good use. 5. TYCHO The first generation vehicle was built using radio-control hobbyist equipment originally intended for use in R/C planes and cars. It is named Tycho after the prominent crater on the moon of that name. 5.1 Hardware The basic vehicle is a highly modified Tamiya Clod-BusterTM four wheel drive car-crushing pickup truck model chassis with a Futaba 7- channel radio control. A Sony Watchcam camera and a wireless VCR extender get a TV image back to the operator. An S-100 machine with a 7 MHz Z-80 running CP/M and a Commodore Amiga with genlock make up the computer gear. Future upgrades might include a 450 MHz Amateur TV transmitter to increase range, but most development work is now taking place on the Waldo project. 5.2 Software Code written in Z-80 assembly reads the operator's controls, generates the 3-second delay, logs control positions, and drives a modified R/C transmitter. Amiga BASIC code provides a Heads-Up- Display to give the operator easily assimilated information on control positions. The two machines communicate through an RS-232 link using a predefined protocol. 5.3 Goals The major goals of the Tycho project were to prove that teleoperated vehicles could be built inexpensively and to build such a device. We planned to do some examples of useful work that would show a proof of concept that lunar teleoperations can be done, that they would be useful, and that operators could be trained to control vehicles with a 3-second delay. We also planned to gather data on a number of different operators with a number of different control schemes and massage the data to determine empirical answers to the questions: What is a good way to set up the controls? and What makes a good operator?. 5.4 Successes We proved that modelling lunar teleoperations is possible by building the model, and we convinced ourselves that operators could indeed learn to cope with the 3-second delays. As a proof of concept, Tycho is a success. We also managed to build the project without a NASA budget (see below). 5.5 Failures We didn't do many of the originally planned tasks with Tycho, as the mechanical parts are too flimsy and the vehicle is too small to attach, for example, a bulldozer blade and try to push some sand around. We also failed to answer the "goodness" questions above, due to lack of time and inconsistent data from a vehicle that's difficult to control. 5.6 Costs The total costs of the Tycho project were around $3,000. This does not include donated equipment, computer equipment we had on hand, or anyone's time. It was arrived at by adding up all the costs of the things that we wouldn't have bought if we weren't doing the project. 6. WALDO The second generation vehicle is being built using the lessons we learned while building Tycho. Most of them revolve around the theory that Bigger is Better, and Keep It Simple, Stupid. The name was chosen because it more closely defines the project - a waldo is a remote manipulator used for handling objects at a distance. 6.1 Design Goals The major problems with Tycho had to do with the small size. Waldo is as large as practical, consistent with moving it through doorways and transporting it in a car. Steering control with Tycho is difficult at best, so the problems of steering and suspension are eliminated at the source. Waldo has four fixed lawn-tractor wheels with independent drive motors, and steering is done by driving the wheels on either side at different speeds (or in opposite directions). An 8031-based microcomputer runs the drive motors, and is commanded through touch-tones or RS-232. Touch-tones are transmitted from a ham radio portable transceiver (HT) and can perform basic movements (forwards, backwards, turns, select speeds). RS-232 commands come from packet radio gear or the main on-board computer, which is expected to be Z-80, 64180, or 68HC11 based. Dual ATV (Amateur TV) transmitters will send separate or stereo TV images back to the operator(s). A bulldozer blade will allow earthmoving experiments, and a manipulator arm will be used for more precise work. Other accessories will be added as time (and budgetary constraints) allow. The original goals of determining operator and control "goodness" remain in effect. Operating time is at least an hour between recharges, and recharge currently happens overnight. A fast-charge, on the order of an hour, is possible, but has not yet been implemented. 6.2 Design Non-Goals We are not building something that will be expected to go to the moon, so we don't need to worry about vacuum, temperature, lunar soil composition, or gravitational effects. We are not building an all- terrain vehicle, nor one that can operate more than 1/2 mile from the control point. While we will attempt to make the control point easily portable, it is possible that moving it will require a small van and a day or so of packing/unpacking and setting up. While these are interesting topics of conversation, they aren't problems that need to be considered for the Waldo project to be successful. 6.3 Timetable Since we are doing this in our spare time and with a limited budget, there is no deadline or timetable. Tycho took about a year to get to the point where the hardware was reasonably stable, and we expect that the Waldo project may take 2-3 years to get to the same point. We would like to have a moving platform by the end of 1990, however, so that we can start using the basic vehicle while adding on features. Benchmark: Dec. 11, 1990 The frame has been built, the platform, wheels, and motors have been fitted for the last time (lock-tight on all relevant fasteners), the motor source wiring has been completed, and the FET power-drivers are halfway to completion. The vehicle should be moving under control of the on-board computer by mid January. Benchmark: July 23, 1991: The motor-control computer is in place with FET drivers and reversing relays functioning properly, the basic radio gear (144-MHz transceiver and TNC) are connected, and the vehicle moves with Touch-Tone commands. The preliminary ATV gear is undergoing modification and integration, and we expect to have video feedback within a month. Benchmark: Aug. 4, 1991: The ATV gear and camera have been mounted, the antenna systems have been put in place, and the wiring harness has been redone. The vehicle is officially "Phase One Complete", which means it has command (Touch-Tone commands to the Drive Computer) and telemetry (video feedback to the operator) capabilities. While a lot of work remains to be done, Waldo is officially a teleoperated vehicle! 6.4 Pending Tasks The following tasks are those which have not been started or which are otherwise incomplete. They represent a partial list of tasks which are planned to bring the vehicle up to fully functional status: o Cameras - stereo configurations, mounting and pointing o Bulldozer blade - mechanical design and fabrication, electrical and computer interface, drive motors, etc. o Radio gear - selection, operation, antennas, duplexers, packet, ATV o Audio delay to simulate onsite workers (optional) o Operator's console - controls, telemetry displays o Postprocessing - operator and control "goodness" o Manipulator arm - programming, operator and computer interfaces o Flux-Gate compass - computer interface and autopilot programming o Sonar - rangefinding, "LORAN" positioning, collision avoidance o Laser - pointing, position finding o Batteries - fast and float chargers, state of charge determination o Base computers - hardware interfaces, lots and lots of software(!) o Documentation - written, photographic, schematic, CAD. 6.5 Current Design Concepts The following are our current ideas of how Waldo is going to be configured. They are subject to change at any moment. The two major parts of the project are the vehicle and the base station. 6.5.1 Vehicle The main constraints on the vehicle are that it be light in weight (two- person carry is our goal), be able to fit through doorways, and be transportable in a VW Golf. With those constraints in mind, it should be as large and sturdy as possible. The vehicle is a flat platform with four fixed wheels. Differential steering will be used (like a Bobcat), and suspension problems have been eliminated at the source (there is no suspension, the wheels are fixed to the chassis). The main height constraint is that the vehicle can be carried through doorways sideways. This means that the vehicle must be less than 2 feet high, not counting removable subsystems like antennas. The width constraint is the size of the hatchback and trunk on a VW Golf: 39 inches. In order to steer easily, the vehicle should have an approximately square aspect ratio. The base is 29.5 inches long without plow blade. Weight should be kept below 100 pounds to allow two-person carry. Removable subsystems (manipulator arm, batteries, plow blade, etc) will allow us to keep the carry weight down while allowing the assembled weight to exceed the 100 pound limit. Total assembled weight should still be under 200 pounds. [Note that we will probably exceed our weight limits, as the Phase One vehicle weighs 113 pounds, but we still want to keep the weight down to allow two-person carry]. Chassis: The frame is made of 1.25-inch square aluminum "U" channel bolted together. Solid aluminum blocks are used at the corners to provide strength and prevent the bolts from collapsing the channels. The frame is 29.5 inches long and 25 inches wide, with a single stiffener in the middle between the wheels. Additional solid blocks are fastened to the bottom of the channels to provide mounting points for the shoulder bolts which function as stub axles. The wheels bring the total width to 36.5 inches. Drive: The wheels are Wheelhorse garden tractor front wheels with 13x5.00-6 tires, and are chain-driven from modified Makita and Sears cordless drills. The vehicle moves about 4.2 feet per second, or 2.8 miles per hour on flat, level concrete. More speed is not desirable, as it leads to less precise control over the vehicle. Worst case, Waldo may move about 12 feet before the operator can react! Computer: There will be at least two onboard computers, one for the drive subsystem and one to control the rest of the vehicle. The drive subsystem is run by a Micromint RTC-52 single-board computer with assembly language routines to control PWM motor drivers. While this computer has an onboard BASIC interpreter, we found that it couldn't generate the four PWM outputs fast enough. The main onboard computer has not yet been selected, but may be a Micromint RTC-180, a 64180-based single-board computer. It will control the radios, robot arm, autopilot, plow blade, and other systems. It will be programmed in Z-80 (or 64180) assembly. Radio: The radio gear operates on the amateur bands, and comprise packet radio command and telemetry links as well as two channels of ATV video feedback for the operator. The video channels will be switched between various cameras and other on-board video sources (computer terminal, etc). The "command" frequency is in the 144 MHz band. This frequency is used for commanding the vehicle through Touch-Tones, and will be the half-duplex packet radio channel for RS-232 control. We will select a frequency in the 450 MHz band for use as the "back channel" when we convert the packet radio link to full duplex. The packet radio link will transmit commands to the vehicle and telemetry back to the base in both half and full duplex modes. The primary ATV channel is in the 915 MHz band, and uses FM TV to avoid the problems inherent in VSB (Vestigial Side Band) or AM TV. The secondary video channel will probably be in the 1270 MHz band, depending on the results of testing the 915 MHz gear. Cameras: The primary camera is a Sony CCD-TR5 8-mm camcorder with wide-angle adapter lens. This camera has autofocus, power zoom, and overlay capabilities. We will be building a pan/tilt mount for this camera to enable the primary operator to inspect the vehicle and the area around it. This will be supplemented by a stereo pair of tube-type Sony Watchcam cameras for use with the manipulator arm. There may also be "overview" cameras positioned around the worksite to give the operators (and observers) alternate views. Manipulator Arm: A Heathkit HERO-2000 robot arm modified for battery operation will be mounted on the back of the vehicle facing aft. Assembly of the arm was completed during the beginning of July, 1990. The arm will be used for fine-control experiments. As a final exercise, a teleoperator in training may have to stack glassware with a three-second delay! Power: Power will be provided by Gates Cyclon lead-acid batteries. Voltage regulators and/or converters will provide other voltages for other subsystems as needed. Separate batteries will be used for drive, computer, arm, and radio gear to prevent interactions. If power to the computers or radio gear fails or drops below certain minimums, all power to the vehicle will be disabled to prevent uncontrolled movement. The drive battery is four 'BC' cells in series, giving 25 amp- hours at 8 volts to drive the four motors. Since the cordless drill motors are rated to run on 7.2-volt NiCad batteries, this is a good compromise. As the Cyclon cells have a much higher current capacity than the original NiCads, the drive computer will have to monitor currents and limit drive power if a wheel stalls, to prevent motor burnout. Backup over-current protection is provided by ganged 30-amp circuit breakers on the drive motors. Bulldozer Blade: There will be a blade on the front of Waldo that will allow the operator to do some construction work, such as leveling a landing field, excavating a habitat module foundation, covering a habitat, and so on. Digging in the sand at a beach will be a good test of these skills. 6.5.2 Base Station The base station is where the operator sits, controls the vehicle, and views the telemetry. The other support personnel also sit here. We hope to be able to make the base reasonably portable, so that we can (for instance) go to a beach and dig in the sand or go to an SF convention and recruit test operators. By monitoring the response of novice operators, we can get a better idea of control "goodness". 6.5.2.1 Computers There are a number of computers available to us for the Waldo project. Some of them have other tasks, and cannot be dedicated to the project, and more could be obtained if a need is demonstrated for them. Update:July 23, 1991 - It's starting to look like the base computer will be our PC Clone or one very similar to it. Despite the limitations and downright kludges of the PC hardware and software architectures, more peripherals, programs, and tools are available at low cost than for any other types of machine. It's possible that Windows 3.0 can do most of the display tasks, including video overlay, which would greatly simplify the programming tasks. 6.5.2.2 Tasks The base station involves a number of tasks which must be performed simultaneously. This involves either multi-tasking on one or more computers or distributing tasks among multiple CPUs. Willie's Corollary to Pournelle's Law is One Task, At Least One CPU. Controls Interface: This involves reading the operator's control positions, modifying them according to the control laws in effect at the time, and assembling command packets to be transmitted to the vehicle. Delay: Command packets must be delayed by 3 seconds. In more refined versions, the delay would be variable and match the real current earth-moon distance, or allow different operator training programs. Control of Radio Gear: This involves everything from keying transmitters to changing frequencies, monitoring output power, tuning receivers, pointing antennas, and avoiding interference with and from other amateur radio operators. This function is only performed by a licensed Amateur, though it may be computer-assisted. Telemetry Display: This displays the complete telemetry information as returned from the vehicle. This involves location, heading, pitch and roll angles, remaining battery power, motor speed, etc. It also includes information on operator control position and time (realtime, delay time, and mission elapsed time). If this is done in Windows, the operator may reposition, resize or iconify various parts of the display. Operator Display: This includes Heads-Up-Display of current control positions, selected telemetry, video from the vehicle and site cameras, and other necessary information. The operator can choose the subset of telemetry data that he wishes to see. All command and telemetry packets are logged to disk with time stamps and comments for postprocessing. As with the Tycho project, the Waldo project will have a defined data format for these files so that postprocessing can be done offsite. The main purposes of logging and postprocessing is to determine operator and control "goodness" and generate ideas for modifications. Video data will be recorded with time stamps, so that a particular mission can be replayed. 6.5.2.3 Task partitioning The various computing tasks will be partitioned between the various CPUs available to us. We are not yet tied to any particular configuration, but our current best guess is that a PC-clone will perform most of the tasks, with some of the critical real-time processing done by dedicated, Z-80 based microcontrollers. 6.5.2.4 Personnel There will be a variable number of people involved in the operation of Waldo. Some people can perform more than one function, and there may be more than one person at any one position. The total number can vary from one (one person performs all functions simultaneously, not recommended!) to five plus any number of observers. Vehicle Operator: The person who is actually driving the vehicle. He has all controls and telemetry data available to him. While he can select from the data he wants displayed, he may or may not be able to modify the control laws. His major concern is the current task. Arm Operator: This is the person in charge of performing tasks with the arm. If she is not the vehicle operator, she may co-ordinate with him for vehicle positioning, carrying tasks, etc. Supervisor: This is the person who sets goals for the operator(s), evaluates the completion of them, and watches over the state of the vehicle. He has a realtime emergency stop control which he can use if the vehicle gets into danger. His major concerns are the welfare of the vehicle and mission planning. Radio Operator: This is a licensed Amateur radio operator who is responsible for the proper operation of the radio gear. She will have controls that allow her to command the radio gear on the vehicle in real-time. Her primary concern is the legal and interference-free operation of the command, telemetry, and ATV transmitters. Her secondary concern is the tuning of receivers and pointing of antennas to permit noise-free command, video and telemetry reception. Safety Officer: Unlike the others, this person is not at the base station, but follows the vehicle around and keeps it in sight at all times. Like the supervisor, he has a realtime emergency stop control, but his only concern is that the vehicle not do any damage or injure anyone. Observer: This person watches a display of telemetry and other data, but has no controls and ideally cannot even be heard by the others. She can enter comments into a terminal which will be logged with the command and telemetry data. 6.5.3 Data Flow This section covers the general flow of data through the base station and vehicle. It is not presented as a precise representation of the configuration of the two systems, as such details are not yet defined, but as more of an overview of how things work. Keep in mind that the specifics of which computer performs which task are unknown and therefore subject to change at any moment... There are two types of data that flow through the system, command and telemetry. Command data is comprised of everything coming from the base and destined for the vehicle, telling the vehicle and it's subsystems what to do, while telemetry is all data gathered at the vehicle destined for display at the base. While it is strictly speaking a form of telemetry, the video signals from the vehicle are not included in this discussion, as they are not computer data. Video signals are merely displayed in real-time (with the appropriate Heads Up Display overlays) as they are received, and logged to videotape. 6.5.3.1 Base Station The dataflow through the base station consists of two types: Command data to the vehicle and telemetry data from the vehicle. We will consider the two types separately. COMMAND: Operator Interface: Command data starts with the operator controls. These include keyboards, joysticks, potentiometers, switches, and any other means the operator has to control the actions of the vehicle and it's subsystems. Command data also includes computer-generated commands (for instance, "TRANSMITTER ID"), and overrides from other operators. Control Laws: The raw command data is passed through the various control laws in effect for this mission and otherwise processed. An example of a control law might be: Use the first 75 percent of the throttle control to generate 0 to 25 percent of full speed. The resulting processed data is in the proper format to be sent to the vehicle. Logging: The processed data is then logged to disk for post-mission analysis, with time stamps and other synchronizations to allow reconstruction. Logging to disk may cause unacceptable timing delays, so logging to RAM disk or memory buffers (with post- mission disk write) are reasonable substitutes. Note that the log file must also contain information allowing reconstruction of the control laws in effect at the time. Delay: The command stream is then delayed by 3 seconds. This delay can be variable, for training and realism purposes. Note that override commands such as "Emergency Stop" are not subject to delay. If necessary, the delay may be tuned slightly to null out processing delays in the rest of the chain, to give the correct delay between the operator and vehicle. Transmission: The command stream is then transmitted to the vehicle over the radio link. This should include link functions such as error-detection and correction, which may be performed by a TNC. TELEMETRY: Sources: Telemetry data is received from the vehicle over an error- corrected link (see above). It includes all vehicle and subsystem status. Portions of it may be in raw form, that is binary data from sensors, and portions of it may have been processed into more familiar engineering units. The raw telemetry data is decoded and processed into a standard format for use by the following subsystems. Logging: The formatted telemetry data is logged to disk with time stamps and other synchronizing information to allow it to be reconstructed for post-mission evaluation. As above, logging may be to disk, RAM disk, or memory buffers. Combining command and telemetry log files is acceptable, as long as control law information is preserved and both command and telemetry data can be recovered and synchronized with videotape playback to re-enact a particular mission. Display: After logging, the formatted telemetry data is distributed to the various display devices. For instance, heading and tilt sensor data would be sent to the Artificial Horizon window, while battery state-of-charge data would drive a fuel gauge-like telemetry display. Note:There are other command and telemetry data (such as delay time, mission elapsed time, time-of-day, display configuration, etc) that do not cross the radio link. This local data should still go into the log files to allow accurate mission replay. 6.5.3.2 Vehicle COMMAND: Data flow on the vehicle is reasonably straightforward. The error-corrected command data is received by the main onboard computer and decoded into commands for the various subsystems. The commands are then distributed to the appropriate subsystems for action. For instance, a command to drive forward at half speed would be routed to the motor- control computer, which would watch the wheel speed and control drive power to keep the wheels turning at the correct rate. TELEMETRY: The onboard computer also gathers telemetry for transmission back to the base. This may include direct readings taken by the computer, such as heading and tilt angles (for the artificial horizon) and readings taken by other subsystems (such as motor currents and drive battery state-of-charge reported by the drive computer). This telemetry information is then transmitted back to the base over the error-corrected link. Willie Smith smith@sndpit.enet.dec.com smith%sndpit.enet.dec.com@decwrl.dec.com {Usenet!Backbone}!decwrl!sndpit.enet.dec.com!smith