THE CART PROJECT: A PERSONAL HISTORY, A PLEA FOR HELP AND A PROPOSAL Hans Moravec Stanford AI Lab May 20, 1974 CONTENTS INTRODUCTION THE PAST THE PLAN ESSENTIAL SUPPORT DESIRABLE SUPPORT MEANS THE CHASSIS THE TV TRANSMITTER THE DATA LINKS SENSORS PERSPECTIVE PROPOSAL INTRODUCTION This is a proposal for the re-activation of the essentially stillborn automatic car project for which the cart was originally obtained, and presents a process through which this activation could be accomplished painlessly. The project would be financed from the lab's operating grant, and would interact strongly with, while being independent of, any Mars rover research initiated by Lynn Quam. Since I seem to be the only one, apart from John McCarthy, with an active interest in this aspect of things, the following is written entirely from my point of view. THE PAST My involvement with the cart project began a year ago, following my leaving of Colby's group. Discussions with Baumgart, Quam and McCarthy, and my own opinions, led me to propose a plan not too different from that found in the next section of this document. In the process of investigation preliminary to implementation of the plan (the cart has almost no documentation), several impediments became glaringly obvious. The most serious was the state of the control link. The original analog system installed by Rod Schmidt, which permitted rough servoed setting of camera azimuth, steering angle and drive motor torque, had been modified by Baumgart (for reasons not obvious to me) to a on-off system, in which the drive, steering and pan motors could be made to run forwards and backwards, and turned on and off, but in which there was no indication, other than inference from the way the view seen by the camera changed, as to which way anything was pointed. More seriously, this link didn't work well even within its limitations. About twenty percent of the time a sequence indicating roll forwards, steer right or pan left was transmitted, the vehicle rolled backwards, steered left and panned right (also vice versa). It seemed to me that attempting to write any kind of control software with this sort of behaviour would be an unadulterated nightmare, so before doing any serious programming I set about to remedy it. Examination of Baumgart's system revealed that the control link transmitted, thirty times a second, a pulse width modulated train containing six pulses, of which four were functional. Of these four, the first acted as mode bit, while the second, third and fourth represented the functions drive, steer and pan. When the mode bit was zero (called "direction mode"), the remaining bits caused no motion in the cart, but were saved in a register which indicated which direction (right or left, forwards or backwards) future motions would take. When the mode bit was one, a one in any other bit caused the corresponding function to happen, in the direction indicated by the contents of this register. The motion continued as long as this "action" sequence was repeatedly transmitted. (An implication of this setup is that all motors had to be stopped whenever a direction change in any function was desired. This implies that continuous steering correction as the vehicle rolled forward would not have been possible.) The normal mode of control was to operate only one function at a time, and to do it by sending a "direction mode" sequence for about a second, to set that function's direction, followed by an "action" sequence for as long as the function was supposed to happen. I traced the problem that was causing the directions to be randomized to the fact that when the inputs to transmitter were rapidly changed (as in going from a direction mode signal to action one), the transmitter glitched, and sent a spurious random sequence. This burst frequently reset the direction register just as the motion was about to begin, with the observed results. The lossage was remedied by simply placing RC circuits between the D to A's which provided the input to the transmitter (yes, D/A's. The transmitter portion of the link was unchanged from the time when it was used to send analog information) and the transmitter itself, to slow the risetime to a few milliseconds. This reduced the frequency of this kind of error to about one command in 30. The remaining errors were due to noise in the received signal, and were not so easy to remedy (I later realized that most of the interference was coming from the TV transmitter, and might have been eliminated with a filter). In making the fixes to the control transmitter, I noticed that it was, in fact, designed to send six channels (as opposed to four), and that there were D/A's connected to the unused channels. This suggested that it should be quite easy to modify the system so that six bits of data were sent in each burst, with two bits being provided for each of the three functions, thus obviating the need for a seperate direction sequence. With this system transmission errors would not be so serious, since an error in one burst would be cancelled by the next. Steering while in motion could also be accomplished. Experiments revealed that neither of the two extra D/A's worked. I traced the problem to three faulty cards in the logic driving the D/A's, and replaced them. It was now necessary to build new decoding logic in the receiver. The problem of not knowing in which way the camera and steering were pointed could be alleveiated by providing a "centering" operation for these functions. Since there would now be two bits provided for each function, it would be possible to represent this in the transmission (e.g. 10 would mean "steer left", 01 "steer right", 00 "turn off steering motor" and 11 "center", i.e. "steer straight ahead"). The logic was built, and the steering and pan drives were equipped with pots, to implement the centering feature and also to act as limit switches (there must have been pots in place when the vehicle ran in analog mode, but they no longer existed). My circuitry also provided more error checking than had existed in Baumgart's implementation. The control link was now pretty reliable, and it was time to start working on software. As step one, I chose to provide a low level controller which was capable of causing the cart to carry out sequences of actions in real time. It is a small program whose heart is a spacewar module which runs on the PDP 6 (on whose I/O bus the transmitter D/A's are connected). It receives its instructions, via inter-job mail, in the form of strings of commands, each having a six bit action code (the actual bits to be transmitted), and 18 bits to specify the duration (in milliseconds) of the action. It refers to the Petit clock to carefully time the transmissions. Step two was the provision of a higher level subroutine which accepts arguments specifying a desired position and orientation change (to be made with respect to the current location). The arguments specify how many feet to move forwards, how many to the right and how many degrees to the right the vehicle should be rotated. A sequence of actions to do this, in a continuous non-stop motion, is constructed and mailed to the controller, which carries it out. Writing this dead reckoner involved creating a model of the cart's behaviour in response to the various commands. On flat ground, when the drive motors are turned on, the vehicle slowly accelerates to a terminal velocity (of about 2 ft/sec), which it maintains until they are turned off. It then coasts for about 5 ft before coming to a stop. The steering shows a similar, but more highly damped behaviour. A model which assumes that the acceleration is a negative exponential function of the difference between the current velocity and terminal velocity when accelerating, and simply of the current velocity when decelerating was, with appropriate parameters, found to fit the measured behaviour very well. This type of formulation had the additional property of being very tractable analytically, making it possible to derive closed expressions for how long the motors had to be energized to go a given distance, and in what times given portions of the path would be traversed. A second piece of mathematics in this subroutine involves the shape of the path traversed in achieving the position and orientation change. The number of possible paths is, of course, infinite. The path which requires the largest minimum radius of curvature consists of two arcs of equal radius, tangent to each other, one passing through the vehicle's initial position, and tangent to the center line of the vehicle there, the other passing through the final position, tangent to the center line of the vehicle in its orientation there. Note that since there are three parameters in this path, namely the radius of both arcs, and the length of each one, and three variables in the desired result (distance forward, distance to the right and orientation change), there can be at most a finite number of solutions of this type (there are, in fact, two). Again, the results have nice analytic properties, and it is possible to write closed expressions for the radius, the total path length, and the distance along the path where the transition from one arc to the other takes place. Of course, the cart is not able to exactly follow a path of this type without stopping at the point where the transition from one arc to the other happens, because it takes a finite time to steer the wheels to the new direction. Unfortunately, the complicated problem involving this sloppy transition between the two arcs does not admit to closed form solution. I solved the problem by using an iterative procedure based on an accurate simulation of the cart's behaviour. Given a desired position and orientation change, the program proceeds as follows. It uses the analytic formulas to generate a two arc solution, from which it makes a tentative sequence of cart commands, dividing the steering interval for the transition between the two arcs equally on either side of the crossover point. (It uses the centering function wherever possible to recalibrate the wheel position. For instance, in going from one side to the other in this two arc transition, it first operates the centering mode for 10% longer than it calculates is needed to bring the steering to center (to make absolutely sure it is centered), and then runs the steering motor for the time needed (as determined by its formula) to achieve the desired angle). It then does an accurate simulation of where this sequence of commands actually leaves the cart, using analytic results for those portions of the path where such results are available, and numeric integration where they are not (such as when the vehicle is rolling and steering at the same time). This usually results in a position and orientation within 20% of the desired ones. The program then repeats the above process, starting with determination of the two arc solution, but this time tries for a position the same distance from the desired one that the simulation indicated it would end up, but on the opposite side. Since this tends to compensate for the systematic error caused by the drawn out steering period, the next simulation usually results in a position within 2% of the desired one. A third iteration generally brings it within the 1% error demanded by the program. The resulting list of commands is then mailed to the cart controller, which implements it. At this point the real world strikes. If the cart has just been tuned up, had its chains tightned, pots adjusted, batteries charged, etc., and is on level ground, the actual result is usually correct within 10%. On rough, or inclined, ground the result can be in error by as much as 100%, restricting this mode of control to short sprints, where corrective action can be taken after each try. Still, its a start. While I was doing this, Quam had been modifying picture correlators for integration into a system which would also include my controller, whose first task would be to make the cart go in a straight line by tracking a horizon feature. We were making the first tentative steps towards this goal when I did a bad thing. One morning, while trying to guide the cart down the ramp over the front steps, via remote control, I misjudged the position of the right side of the ramp by about an inch (the camera was angled fairly high, and I could only see ramp's far end). This left the right side of the vehicle unsupported, and it toppled. The battery supports and one of the forks were bent, and some acid was spilled. The mechanical damage, however, was trivial and easily fixed. Much more serious was the fact that the TV transmitter, though barely scratched, had ceased to work. I have spent the last six months doing little but trying to restore this function (a more detailed account of these efforts can be found later in this document). This effort has been frustrating, and in my opinion a misdirection of my time. This proposal stems partly out of my frustration. THE PLAN Given a functioning vehicle, I propose to write programs which cause it to do following: 1) Change its orientation at a specified rate while rolling forward, tracking horizon features with the camera to verify and correct its progress. A special case of this is a rate of orientation change of zero, i.e. motion in a straight line. The feature location needed by this task and those that follow will probably accomplished by a algorithms similar to Quam's planet surface correlators, implemented on the SPS 41 for speed. 2) Detect obstacles while rolling forwards. In principle this can be done by locating the same features in two pictures taken a short time apart, and from this deducing their approximate three dimensional locations. Even with uncertainty about the rolling speed, it can be determined whether the features lie in the path of the vehicle, and approximately how far in the future a collision will occur. This scheme suffers from the inability to detect the interior of large featureless objects, such as plain walls. The considerably more difficult task of inferring the presence of wall-like objects from edge features will be left for later. Hopefully there won't be too many walls in the road at this stage of the project. 3) Avoid obstacles while rolling forwards. An obvious extension of step 2. 4) Detect and avoid moving obstacles. If all motion is assumed to be linear in an interval this can be done by extending the fixed obstacle detector to work with three instead of two frames. In fact, an average over a larger number of pictures will probably be required to eliminate the effects of camera shaking. 5) Locate the edges of the road. While the previous tasks do not require understanding of what the features in the scene represent, this task requires some. My first attempt will involve trying to find the strongest edges (in the Heukel operator sense) close to where the roadsides were last observed to be. There is a good chance that this scheme will fail. Subsequent tries would involve region growing algorithms and texture operators. 6) Detect forks in the road and the temporary absence of road (such as in a parking lot) by extending the techniques of step 5. This will probably be quite difficult. 7) Navigate over short stretches of road and eventually circumnavigate the lab on the basis of a crude map giving the topology of the route and approximate lengths of the various branches. This should follow quite naturally from adequate completion of step 6. 8) Recognize more difficult things. Cars, people, trees, traffic signs, puddles, lamp posts, bicycles, dogs, etc., whatever is possible in a reasonable amount of my time. It might be argued that some of these things could be worked on without a vehicle, using a set of stored pictures. What I hope to achieve is a system that accomplishes at least some of the above tasks reliably. It is highly probable that any system optimized for a (necessarily) relatively small training set of scenes will have poor performance on new data. Yakimovsky's region classifier is a prime example of this. It requires massive manual re-training for new pictures, even when these seem to have only trivial differences from previously encountered ones. I hear that he is considering abandoning his old approach entirely in the face of lack success on the scenes at JPL. If real, ever-changing, data is used consistently, techniques that are not effective will be abandoned early. Secondly, the problems involved in controlling the vehicle, though undoubtedly easier than those in the vision, are just about impossible to attack realistically without a the actual hardware. A third factor favoring a running cart concerns my motivation. It would be easier for me to maintain a high level of effort and interest in the project if I could see convincing, concrete results now and then. ESSENTIAL SUPPORT The minimum hardware needed to make this scheme feasible consists, in addition to the existing PDP 10 system, of the following: 1) A mechanically reliable vehicle. The cart as it currently exists and as it has existed does not meet this criterion. It regularly pops sprocket chains, bends motor support plates, suffers major losses in steering and camera pan direction calibration, ruins servo pots because of misalignment in the coupling gears, bends wheel forks, shakes it major bolts loose and is generally disagreeable. 2) A TV transmitter that is capable of sending a good picture across the length of the lab. The original transmitter built by Rod Schmidt, and made inoperable by the crash I caused, was barely able to do this over the distance of the machine room. Its power output was 1/4 watt on the modulation peaks, about 1/12 watt on the average. We are permitted an average power of 5 watts, sixty times that, and experiments with the transmitter I have been trying to build indicate that an average power of 3 watts (10 watts on the peaks) is adequate. At the moment we do not have such a device. 3) A radio control link that works reliably over the same distance. The existing model airplane transmitter and receiver, though capable of improvement, and sometimes subject to interference from other nearby transmitters (it operates in citizens band), works adequately since I repaired the D to A's which run the transmitter and rebuilt the digital logic connected to the receiver. It now transmits six bits 30 times a second, which is just adequate to control the existing (minimal) functions, providing two bits each for steering, drive motors and camera pan. More functions could be provided at the cost of a card of digital logic at each end of the link. Fairly extensive error checking is necessary if spastic behaviour in the cart is to be avoided. My logic provides two levels of this, cutting the error rate down to one short glitch about every five minutes. DESIRABLE SUPPORT The probability that my program could be carried out successfully would be increased by the existence of certain other features. Some are clearly more likely to happen in the near future than others. 1) New logic in the control link, to permit more functions, such as those outlined below, to be added. A system organized like a computer I/O bus, where each transmission burst represents a device code and data for that device, seems least restrictive. The bursts would include check bits, and there would be extensive error checking done at the receiver. 2) Tilt angle control for the camera, allowing it to be pointed downwards when negotiating ramps and other tricky ground. This would help prevent accidents such as the latest crash. The motor for this function is already in place. It needs a driver and control logic. 3) Speed control for the motors. This would permit matching the rolling speed to the complexity or perceived danger in the scene, and permit compensation for up and down grades. It would require control logic, and switching drivers. Note that the pulse train for the drivers could best be generated by digital methods, for instance by a register to hold the desired setting, a free running counter and a comparator which tests for "greater than". 4) Focus and iris drives for the camera, and a disable for the automatic target voltage feature. This would enable the actual brightness of objects to be measured. The focus feature could also used to estimate the distance of nearby objects. 5) A data link from the cart to the computer. This would be needed to support the devices in the following items. Another radio control link and data multiplexed onto some scan lines in the video are two possible ways of implementing this. 6) Potentiometrs for monitoring steering angle, and camera pan and tilt angle and analog to digital converters so that these readings can be transmitted. Optical resolvers are an alternative. Some pots are already in place (I installed them to implement the centering function for steering and pan), but the readings are (of course) not transmitted. 7) Touch sensing switches. These would help in minimizing the damage resulting from collisions. 8) A tachometer for monitoring the speed of the vehicle, so that the distances between pictures could be determined with more than laughable accuracy. This device could would also help in long term navigation. 9) An orientation sensor. In combination with a tachometer this could, at the cost of a little numeric integration, provide a rough estimate of the cart's position. The function of the vision would then be fine tuning of this estimate. Given such a device, occasional loss of understanding of the observed scene would not be fatal. I've recently acquired a surplus flux-gate compass, the heart of which is a set of three saturable core inductors, each having two cores and three coils. In each inductor two of the coils are supplied with AC, and drive the cores into saturation on the tips of the cycle. An external magnetic field (e.g. the earth's) hastens the saturation in one core while it hinders it in the other. The third coil is used to detect this. A few op amps and some logic (I have a circuit) could convert this into a digitally reading magnetic compass. 10) A level sensor (e.g. two low torque pots with pendulums). The output from this could be used (in the computer) to correct the error that deviations from vertical cause in the compass, and to anticipate the power settings needed to maintain vehicle speed in the presence of changes in the slope of the path. 11) Color vision. Color provides a grat deal of information about the nature of objects, and would make the recognition tasks much easier (i.e. more likely to succeed). A filter wheel is the simplest way of approximating this. Its inherent slowness, however, makes such a device just about useless while the cart is in motion. A color camera does not have this limitation. Such a camera, generating an NTSC (the american color TV standard) signal could be connected directly to the existing (*sigh*) transmitter, since the color information is cleverly disguised to look exactly like 3.6 MHz video. At the receiving end, the digitizer would need circuitry for decoding this signal, and either a higher data rate to memory (the new MOS memory could handle it) or a lower sampling rate. The transmitted signal could also be understood by any color TV receiver. Conventional color cameras are large and expensive. Sony has recently begun to manufacture, for the portable video recorder market, a small camera built around a single vidicon whose faceplate is covered with tiny red, green and blue vertical stripes, and black registration marks (sort of a trinitron in reverse). I believe the price is within a factor of two of a good black and white camera. MEANS There are a number of ways the required hardware support can be achieved. Here are some: THE CHASSIS - Vic Scheinman's interest in the cart has recently been rekindled. He has proposed various fixes for its many ills, struts to make the forks more rigid, reconstruction of the motor support plates (which now bend significantly when the motors run), removal of two motors while increasing the amperage limits for the other two (to reduce complexity), replacement of the motors with lighter more efficient permanent magnet types, possible replacement of the wheel hubs, and other things. If these things were done, at the cost of undetermined hundreds of dollars in Vic's and my time and in parts, we would still be left with a rather inferior product. The result would remain without a suspension, and would thus still subject everything aboard to serious jolts, loosening bolts and damaging electronics (I suspect that the camera is still functional mainly because of the shortness of the running time accumulated so far by the cart). It would still need constant adjustments to keep the chains aligned and tight. The steering and pan functions would continue to need recalibration after each run. The difficulties in finding space for equipment and sensors would remain. Alternatively we might buy a new vehicle. I have obtained information about various golf carts, wheelchairs and industrial vehicles. Golf carts, even the small ones, are large and heavy and sell for $700-$1000. Most have suspensions and wheels large enough to negotiate rough ground. They have mechanical steering linkages which would require fairly extensive modifications to suit our purposes. Industrial vehicles come in many shapes and sizes. Most are designed for carrying loads over flat ground and are too low slung to be reasonable for our needs. Those that would suit us are priced at about $2000., are pretty large and also have mechanical steering. They seem to be sturdier than the golf carts. The wheelchairs are small and reasonably priced, starting at $500. They have two motors, each driving a rear wheel, with freewheeling casters in front. Steering is accomplished by running the motors at different speeds, a technique directly amenable to remote control. A universal problem with the wheelchairs is the small wheel size and ground clearance. All have a caster size of about 8 inches and most have a drive wheel diameter of 10 inches, sizes which would make much of the ground we have run the cart on inaccessible. It may be possible to obtain used vehicles (probably golf carts) form the university or the medical center, since both entities have a fairly large fleet of them. The most promising offer comes from Roy Kaylor of Environmental Electronics in Menlo Park. He currently makes his living manufacturing small quantities of electric cars, and would build us a custom vehicle for $700. A design we worked out together has three large wheels, two in front and one behind. The front wheels are powered by individual motors and steering is by speed differences. The rear wheel operates like a caster and drives a pot which measures its angle relative to the body. By servoing the motor speeds to keep this wheel at a given angle we could steer at least as accurately as with a conventional arrangement. The frame is built mostly of tubing for strength and lightness, and there is a good suspension. It has brackets and platforms wherever needed to support equipment. THE TV TRANSMITTER - This is the most expensive item on the cart, by any measure. I estimate the cost of the first one to have been $8000, calculated on the basis of 18 months of Schmidt's time and $500 in parts. For this amount we obtained a baroque 12 stage design with extremely unstable tuning characteristics (e.g. it quit if its temperature rose over 80 degrees, or if a different antenna was substituted) and a miniscule average power output of 1/12 watt. At about the same time (in 1968) SRI bought a rugged 10 watt fm microwave video transmitter for their robot from RHG Electronics Lab in Long Island for $5000 (they also had to buy a receiver for the same price, but that's beside the point I'm trying to make). This is not to denigrate Schmidt's ability, but simply to point out that construction of circuitry at these frequencies is an art that non specialists (this includes everybody here) cannot compete in cost effectively. At about the time that the old transmitter's deficiencies became apparent to us, RCA and Motorola began to sell 10 watt hybrid circuit modules for the newly opened 440-470MHz UHF communications band for prices that, because of mass production, were more than an order of magnitude less than those usually associated with equipment for these frequencies and powers. RCA, in particular, had an amplifier which seemed to be exactly what we needed, if it could be made to work at our 524MHz frequency. It would produce a power output of 10 watts from a 1/10 watt input. RCA agreed to select one that would work, at a cost of $90, and we ordered it, intending to drive it with the old transmitter. The incident on the front ramp happened before it arrived. The intolerance of the old transmitter to slight changes in its load impedance, and the non-linearity of the RCA module described below, make it fairly clear that combining the module with the old transmitter wouldn't have worked in any case. After the crash, in which the transmitter was shaken up and detuned, but not seriously physically damaged, all my efforts and those of the best RF expertise the lab could muster (Gafford and McGuire) were not enough to resuscitate it. After a month of trying I gave up and began to build a new one, based on a design found in a ham radio magazine. Four months and five reconstructions later we had a unit with about the same performance as the old one, albeit with only a third the number of transistors and with somewhat more stability. Its response to modulation was unpleasant in that it depended on tricky tuning. At about this time the RCA module arrived, and was attached to my transmitter. Because of non-zero lead lengths, and other problems typical at these frequencies, that didn't work at all. I rebuilt the transmitter again, this time making careful provision for placement of the module, and was rewarded with a full ten watts of output. Other problems became apparent immediately. The amplifier module was designed for frequency modulation, and its gain is reasonably constant over a wide range of frequencies. Gain, on the other hand, drops steeply, in a poorly defined manner, as power increases. For our application this means that a good amplitude modulated input results in a distorted output. In particular, the difference between the sync pulse tips, which should be represented by maximum carrier, and reference black, slightly below this, is just about lost. Since the portion of the video waveform which indicates the beginning of a new frame consists solely of transitions between these two levels, receivers are unable to sync reliably on the transmitted signal. There were many ideas about how to fix this, and in the process of trying out some of these, I ruined the amplifier module by accidentally disconnecting its power lead while it was in operation (I'd be happy to elaborate if this seems confused). It was mailed back to RCA with a covering letter explaining the situation, and they agreed to replace it at no charge, stating that a probable defect in the module made it too sensitive to those conditions. The replacement has not yet arrived. The cost so far, for 6 months of my time and $200 in parts, is $2500. It is conceivable that if we keep up this nonsense for a few more months, we might have a transmitter that almost works, if it's kept tuned, isn't shaken too hard and if the temperature and supply voltage are right. Again we have an obvious alternative. I have made extensive inquiries (of over 300 manufacturers) about the availability of a commercial transmitter that fits our needs. The positive responses come from three catagories of supplier. First there are makers of broadcast equipment for television stations, who have exciters which meet, or can be modified to meet, our specifications. These units typically occupy a two foot height in an equipment rack, weigh about a hundred pounds and cost $6000 to $10000. Most generate an fm sound signal (from audio input) as well as a video carrier. Their great size (and power consumption) makes them impractical for a small vehicle like ours. The second group offers oscillators and amplifiers, in aluminum boxes, primarily designed for laboratory prototyping. Low power units sell for several hundred dollars each, but a linear UHF amplifier with 10 watts of output costs at least $2500, bringing the total cost of a working transmitter to about $3500, not including the labor needed to interface the oscillator, modulator, video amplifier and power amplifier (not trivial at 524MHz). The third set of manufacturers makes portable microwave video links, primarily for military applications. These are small, extremely rugged, almost universally FM, and operate at several times our frequency (SRI's link is of this type). Since these units are made in small quantities, and are constantly undergoing re-design, these manufacturers have the capability of tailoring one to our specifications. The best (i.e. least expensive) firm offer we have comes from Emhiser Rand in San Diego (they make tv transmitters for drones), and would give us a complete 10 watt transmitter for $4350. Interestingly, the price for this (custom) design is slightly below that of a similar standard unit with the same power output. The explanation I received for this curious effect is that, since our frequency is lower than that of the standard transmitter, cheaper components can be used. In addition to this saving we have the fact that a standard TV set can be used as receiver (instead of a unit costing as much as the transmitter). We also have an offer for a standard unit from 3DBM company in Los Angeles which will put out 2 watts at our frequency for $2750. They have stated their willingness to let us try it out for the summer, at no cost or obligation. It is interesting to note that (my inquiries reveal) the price of transmitters of this type has remained just about unchanged over the last 10 years, the decrease in the cost of components having been cancelled out by increases in labor costs. This implies that we could have had a good transmitter in 1967 (SRI did). This leaves one remaining hope to mention. SRI has retired their robot, and has no plans for the video link. We have contacted them about inheriting it, and Steven Coles thinks it is a good idea and Peter Hart has said (unenthusiastically) that he would look into it. I don't know what probability of success that implies, or whether that probability would be increased by pestering them some more, or when we could get it. Perhaps we should ask to borrow it for a while. The potential problems are that 1) obtaining a license might take a year 2) at that frequency (1.5GHz) transmission is strictly unobstructed line of sight and 3) We need ARPA approval for a transfer of this kind. Problem 1 might be solved by running under SRI's license for a while. Problem 2 could be handled by placing the receiver high on the roof (Hilf's tower?). I feel incompetent to talk about problem 3. THE DATA LINKS - The D/A's driving the control transmitter have recently stopped working. This occurrence seems to be associated with Ted's removal of much of the old equipment in the kluge bay to make room for the new generation of devices. He intends to remove the D/A's altogether in the near future, so there isn't much point in trying to fix them. This is not a disaster, since their function, in the current digital mode of operation, can be replaced by a half-full card of logic. The problem is that we do not have authorization to obtain even that much support. The IC's in the new receiver logic were cannibalized from the old receiver, filched from the shop, and some were my personal property. Systematic requests, as for the DEC wire-wrap board needed above, are usually met with "Well, who's going to pay for it?", a question which I am unable to answer. There are much better radio control links available than the one we now use. The advantages of a better one are subtle but real, being basically a potentially higher data rate and a lower error rate. I had an offer last summer, from Jeff Raskin, for a more powerful R/C transmitter and a superhet receiver (the existing receiver is regenerative, and thus quite sensitive to interference) for a combined cost of $60, but was unable to take it. Systems of this kind can be obtained on the open market for under $200. If we choose to continue to do our R/C in citizen's band (and I see no reason not to), then it would probably be best to put telemetry from the cart on a significantly different frequency, to enable measurements to be made while commands are being sent. The simplest, and probably best, answer to this problem, given a reliable TV transmitter, is to place data on several scanlines in the video. At the transmitting end this requires little more than a fast threshold detector, to locate the sync pulses, and a shift register. The receiving can initially be done through the existing video digitizer, in combination with a small program. There is some confusion as to whether our license permits us to do this. In my opinion the spirit of the clause which states "There shall be no telemetering operations at this frequency, video transmission only is authorized" is to prevent raw, non video formatted, data, which could easily exceed video bandwidth and which cannot be interpreted by a TV set which might be subjected to interference from it, from being transmitted. Note that the clause does not state that the video must come from a camera, or that it cannot be synthesized by an electronic circuit. SENSORS - Good servo pots, including extremely low torque versions, such as would be desirable for a level sensor, can be obtained on the surplus market for under $20. Interfacing circuitry could be built here at a parts cost on the order of a few hundreds of dollars. PERSPECTIVE There is a massive reservoir of bad feeling associated with the cart project here. Of the established powers, only John McCarthy presently shows any signs of faith or enthusiasm. I believe this negative attitude is largely unjustified, although the process through which has developed is not entirely obscure. The history of the cart project, as I see it, is as follows: 1966 A cart, thrown together by Mechanical Engineering for a short term research project, becomes available to the AI Lab. Earnest siezes on this as an opportunity to add mobility to the lab's bag of tricks, and convinces Rod Schmidt to do his thesis on the subject. 1967-1971 Schmidt spends several years singlehandedly constructing radio links between the cart and the PDP 6. In this he values quick completion over high quality, and succeeds at least in minimizing the quality. It quickly becomes obvious that the model airplane control link (unlike the link used by M.E., presumably) is incapable of specifying the position of the four wheel steering (which has a range of two full turns) with manageable accuracy (a 5% jitter in the control pulse width is a 30 degree change in the wheel orientation). His solution is conversion of the steering to a conventional arrangement, which requires a much smaller total range of steering angles. Scheinman helps, but his emphasis too is on speed over sturdiness. The first few attempts don't work very well, because simple connection of the front wheels with a chain drive causes them to want to go in slightly different directions when pointed anywhere but straight ahead. A bar linkage is finally installed. This doesn't work very well either, because of the short wheel base, but everyone is tired, and in any case there are no other new ideas. The result is a general mechanical degradation. Schmidt, now under the guidance of McCarthy, uses this vehicle to write a thesis concerning automatic cars. Realizing how long he has already been here, he applies to the thesis the same attitude that has made the hardware what it is, and completes it with the minimum possible expenditure of effort. He is aware of the state of things, and includes in it (on p 151) the paragraph: "In conclusion let me comment that this vehicle was intended as a low-budget way of getting some experience with driving problems, and that if this research is continued, a new vehicle should be obtained. The lmitations on operating time caused by battery discharge and the lack of equipment space, nonexistent suspension, and low speed of the present vehicle will make future work increasingly difficult and unrealistic." Nobody listens or cares. 1970-1973 Baumgart decides he likes the idea of a robot that reasons visually, and concocts a grand scheme in which every scene viewed by the camera would be related to a model of the lab and surrounding territory. He notices the uncertainty in the analog link, and decides make it into a digital one. This is his first digital design effort, and the result, which provides for on-off control of the motors and has no indication of the orientation of anything, is considerably inferior to the original in concept, and in addition works unreliably. The original servo electronics are disassembled or misplaced, making his changes irreversible. He rationalizes that the problems with the link are unimportant, since, when his visual reasoner works, it will be able to deduce the state of things, and detect when a transmitted command has failed, to try again. The enormity of the effort needed to make his plan a reality becomes apparent to him as he works on sub-problems. Since it would become possible to actually use a vehicle only when his proposed scheme was almost completed, and since he now sees that it is unrealistic to think that it could be brought to fruition in a reasonable number of years, he abandons any serious efforts directly concerned with the cart, but maintains his association with it, as a status symbol and a toy. He occasionally drives it around for show, often over rough ground, contributing to its mechanical decline. During this time several other graduate students are steered towards this essentially nonexistent "cart project". They are disillusioned by the lack of a coherent plan and suffer from too little guidance and from conflicts with Baumgart's personality. All these associations are short lived and unhappy. Baumgart finds success and happiness working on the graphics and vision sub-problems suggested by his original concept. 1973-1974 Quam, having done his thesis on the processing of Mars pictures, expresses an interest in using the cart for Mars rover research. He has picture processing algorithms, but little else. Interfacing with Baumgart is impractical, so nothing much happens. Moravec, who had decided he liked the idea of an automatic car before he came here, and who had wanted to come to Stanford largely because of that, decides it is time to start serious work towards a thesis on this topic. He is steered towards Quam, who, at this stage, has little to offer other than admonishions to "get this show on the road". He trys, rebuilds the control link to make it a little more reasonable, and plays with the vehicle for a few weeks, contributing to further deterioration in its already delicate mechanical condition. Then, in collaboration with Quam, who is tuning up his picture correlation programs, he writes a control package for vehicle. Before these two efforts can be combined, he throws a wrench into the works by running the cart off a ramp, which provides the excuse to stop working that the TV transmitter had been looking for from the day it was born. He spends six months trying to recover from the effects of his folly, with only limited success. Very frustrated and anxious to get back to productive work, he writes a proposal to McCarthy and Earnest, begging for help out of his predicament. For similar reasons, on a slightly larger scale, Quam writes a proposal to his friends at NASA. Well yes, the story is neither heart warming nor awe inspiring. It is an example of that well known conservation law "you can't get something for nothing". By definition, there can hardly be a cart project without a cart, since in the absence of a vehicle we have only computer vision. The impression grows on me that what we have now is worse than no vehicle at all. At no time has the state of the cart hardware ever approached a level comparable to that of the hand-eye in the Rancho arm days, yet the comparison between the two projects is undoubtedly behind the hostility the cart now faces. I wonder if any arm theses would have gotten beyond the first few months if the arm required massive repairs after every half hour of operation, and if these repairs had to be effected by the student trying to write the programs. This situation is exactly the one that has faced everyone considering doing a cart thesis. It instantly excludes those who are not hardware inclined, and makes technicians of those who are. Yet the existence of this junkpile (see elaboration in footnote) is an effective bar to the obtaining of anything more reasonable, requests for things of this nature being met with a monotonous "do something with what you have first". footnote - There is one good thing about the cart, namely the TV camera. The vidicon has some burns in its target, and is old and will probably burn out and have to be replaced soon, but overall it is a nice camera, probably better than the COHU on the hand-eye table. The original mechanical portion of the vehicle was also tolerable for short term use, except for certain weaknesses, notably the inadequate strength, rigidity, and precision of the drive motor support structure. This weakness shows up as continual loss of chain tension, popping of the drive sprockets, munging of the sprocket wheels, and recently, fracture and total failure of a support plate. Most of the subsequent mechanical modifications, however, and all of the electronics are unadulterated (and unreliable) kluges, whose only virtue is that, at the time they were installed, they were the fastest and cheapest way anyone could think of, of getting a thing done. PROPOSAL My proposal for what should happen concerning the matter of lab support of the cart project is as follows. Since a normal request for equipment will undoubtedly be met with the "Well, do something with what you have first" attitude mentioned before, I propose that the "do something ..." process be systematized. In particular, I want a bargaining session with Earnest and whoever else has a major say in the distribution of ARPA money and objects to significant expenditures of it for cart hardware. The session would be for the purpose of drawing up a list of hardware acquisitions which would shortly follow successful completion of various steps in the plan described earlier (or any steps decided, in the session, to be more appropriate). The benefits from the existence of a commitment of this type are obvious. I, and whoever else might be induced to work in this area, would be highly motivated, since completion of a specific task would instantly be seen to lead to better working conditions. The cart project would have a definite means of bootstrapping itself out of the morass into which it has been sinking since its inception. The cost to the lab of the process would be a function of the success it achieved. Failure, in particular, would cost no more than it does now. Here is a rough estimate of the cost of some of the articles we would like to have, summarized from the previous sections. TV transmitter 5000 Chassis 1000 Control transmitter 200 Control logic 500 Small effectors 500 Sensors 500 Color camera 2000 Color digitizer ? Technician time ?