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 ?