Ad: netjeff recommends
rShopping
app for Android, for your shopping list needs.
My Fascinating Interview with Allan Klumpp,
the Principal Designer of the LM Computer
Descent Guidance Software
by Stanley R. Mohler, Jr.
Dec '94
A few months ago I posted a message in sci.space.tech seeking info
on the Lunar Module on-board computer and its software. I soon got
some private e-mail from Allan Klumpp, the principal designer of
the Apollo Lunar Module on-board descent software. He also wrote
the steering system for the digital autopilot. He invited me to
call him which I did. I thought I would summarize here my
understanding of some of the fascinating info he gave me over a
1.25-hour period.
Allan was one of about 300 people who designed the LM's software
over a 7 year period for 46 million 1967-era dollars. He did his
work as a graduate student at the MIT Draper Lab during the Apollo
years.
The LM and CM had identical computers on board, each the size of a
shoe box. Each contained a total storage capacity of 36K of 14-bit
words. This means total storage was roughly equal to the 64K bytes
of a Commodore-64 computer. The LM's computer had a "memory cycle
time" of 11.7 micro-seconds. However, virtually all cpu operations
required atleast 2 clock cycles making the effective memory cycle
time 23.4 micro-seconds, i.e., it effectively ran at only about 43
kHz (0.043 MHz)! Note that the original IBM PC-XT ran at 4.77 MHz,
and the latest PC's run at about 66 MHz. The fastest computers
today run at about 300 MHz. The LM computer is probably comparable
in speed to a pocket calculator. Numbers were represented using
14-bit words in double-precision (i.e., 28 bits). The 15th and
16th bit were for the sign of the number and for parity checking
(i.e., to make sure the chips were all in sync with the clock
pulses). Calculations were fixed-point (not floating-point).
The on-board program, named "LUMINARY", was stored in read-only
core-rope memory which took months to manufacture (the program
fills about 10 cm of print-out). Therefore the software had to be
in final form months before launch. LUMINARY version 99 landed
Apollo 11. Version 209 was the final version.
The computer also contained a small eraseable area of about 2K 14-
bit words to temporarily store variables in. The computer was
built entirely out of integrated circuit NOR gates: one type of
gate for high reliablility.
Allan, his friend Don Eyles, and about 300 others wrote their
programs in the first high-order computer language, called MAC (MIT
Algebraic Compiler), then compiled it BY HAND into assembly
language, which they typed onto punched cards (there were no
terminals or text editors). Incidentally, the Shuttle's software
is written in a language called HAL/S, named after Hal Lanning, the
author of MAC. HAL/S is an improved version of MAC.
The LUMINARY program consisted of many subprograms which were
priority driven, i.e., they took turns executing according to their
priority. Each program would move data in and out of the very
small eraseable area of memory (2K in size). The biggest debugging
challenge was to keep programs from erasing, or "overlaying",
another program's data at inappropriate times. If too many tasks
were demanding the computer's time, it would simply delay or THROW
AWAY what it had been working on, issue an alarm, and start working on
the new item.
Such frightening alarms occurred during the Apollo 11 landing
(first moon landing). If you listen to recordings of the landing,
you will hear the Capcom say "1201 alarm" and "1202 alarm." The
astronauts' checklist had erroneously called for the astronauts to
turn on the rendezvous radar before initiation of the descent.
Subsequently, the program that managed the radar began demanding
too much of the computer's spare margin of time. The power supply
for the radar was not properly synchronized with the LM's main
power supply. Consequently, as the two power supplies went in and
out of synchronization, the rendezvous radar generated many
spurious input signals to the LM's computer. In responding to these
signals, the computer delayed some of its guidance calculations and
left others unfinished. This situation caused the computer to
issue alarms during the landing. During a normal descent, the
guidance program, which brought the LM to its target landing site
using a minimum of fuel, would issue commands once every two
seconds. Steering commands to the digital autopilot, which kept
the LM stable, were issued every 10th of a second. Although the
landing, which had an 11-minute guidance phase, was successful, a
full minute's worth of guidance commands were never issued by the
computer due to rendezvous radar!
For debugging, the programmers at MIT had an IBM 360 model 175
mainframe computer that acted as a simulator of the LM. Allan and
his colleagues would test their software in this simulator, which
interfaced with their software just as the real LM, with its
associated dynamics, would. The IBM 360 produced printed output as
well as plots of the trajectories of the simulated landings.
In the real LM, the on-board computer had a digital display and a
keyboard. During landing, the computer would display a number,
updated periodically. The LM "Pilot", who was on the right and
never touched the controls, would continuously read out updated
values of this number. The Commander on the left, who was actually
manipulating the controls, would find this number on a retical
painted on the window. The target landing spot, where the computer
was trying to land, would be visible at that location out the window.
The commander would "fly" the LM by redesignating to a new landing
spot by clicking a hand controller. In this way, Neil Armstrong
carefully steered the LM away from an unexpected crater full of
Volkswagen-size boulders, setting the LM down with only 30 seconds
of fuel left! One click of the hand controller would move
the landing spot by a couple of degrees. Allan chose to program in
2 degrees left/right, and a half degree up and down (i.e., forward
and backward). Later he changed it to 1 degree both ways, at the
astronauts' request. The commander could also increase or decrease
his descent rate by one foot/second by clicking a second hand
controller.
LUMINARY was never completely bug free. Allan told me about a
fascinating series of events that could have easily prevented the
first moon landing and might have caused disaster. Allan was the
principal designer of the LM's descent guidance program which
steered the LM by gimballing and throttling the descent engine.
Whenever the computer commanded the engine to increase or decrease
thrust, the engine (and LM) reacted after a short time lag.
Allan's descent program needed a routine to accurately estimate the
new thrust level, which could be accomplished by reading the
"delta-V" (change in velocity) measured by the LM's accelerometers.
He wrote a short routine that took into consideration, i.e.,
compensated for, the engine's lag time, which TRW's "interface
control document", full of useful information for the programmers,
said was 0.3 seconds. It took 0.3 seconds for the LM's descent
engine to achieve whatever thrust level the computer might request.
The final version of the thrust routine, which was put into the LM,
was written by Allan's friend Don Eyles. Eyles was sufficiently
enthusiastic about the programming challenge that he found a way of
writing it which required compensating for only 0.2 of the 0.3
seconds. The IBM 360 simulator showed Eyles' program worked
beautifully. His routine was aboard Apollos 11 and 12 which
landed successfully. However, telemetry transmitted during the
landings later showed something to be very wrong. The engines were
surging up and down in thrust level, and were barley stable. A guy
at Johnson Space Center called Allan and informed him that the LM's
engine was not a 0.3-second-lag engine afterall. It had been
improved some time before Apollo 11's launch such as to lower the
lag time to only 0.075 seconds. Correction of this item in the
interface control document had simply been overlooked. Once this
discrepency was discovered, the IBM 360 simulator was reprogrammed
to properly simulate the actual, faster engine. Running on the
simulator, Don Eyle's thrust program, with the 0.2-second
compensation, exhibited the surging that had occured on the real
flights. But here's the most interesting fact: the simulator also
showed that had Allan Klumpp chose to "correct" Don Eyles' program
by compensating for the full 0.3 seconds that was printed in the
document, the LM would have been unstable and Apollo 11 would never
have been able to land. By pure luck, Don Eyles was creative enough
to write the thrust routine in a way that kept the LM just inside the
stability enveloppe and allowed successful landings!
Allan's descent program called "P64" periodically computed a
polynomial function to describe the optimum descent trajectory.
This polynomial would smoothly merge the LM's current position and
velocity vectors into the target point position and velocity
vector. The "target point" for P64 was just above the landing
point (When the LM reached the target point with a small vertical
descent rate, P64 would cease execution and the landing phase would
be handled by a program called "P66"). The computer would then
make the LM fly the trajectory, which would be recomputed every 2
seconds. An opportunity for disaster presented itself here. Many
sci.space.tech readers may know enough mathematics to understand
the undesirable "wiggles" that can be generated by high-order
polynomial curve fits. Under conceivable circumstances, the
polynomial function computed by P64 could droop down, go beneath
the lunar surface, rise out of the surface, then descend to the
target point! If such a trajectory were computed during a real
landing, and the LM were allowed to follow it, the LM would crash.
There was no logic coded in to detect this situation and prevent
it. No programming solution was ever found. An example scenario
where this disaster could have happened follows. If the LM was off
course, away from the terrain model stored in the computer, and
flying over a deep crater, the landing radar would fool the computer
into thinking the LM was higher relative to the mean surface than
it previously assumed. This could cause a newly computed polynomial
trajectory to "droop" down sharply, unintenionally intersect the
real lunar surface, then rise back out of the surface, inviting the
LM to crash! Allan said this problem could conceivably be remedied
by an astute astronaut retargeting the landing point beyond the fuel
range (atleast for a while!).
What would the computer have done if the LM's descent engine quit
cold a mile above the moon? The computer would not have initiated
any automatic solutions. Allan said the astronauts simply would
have pressed an abort button, which would have jettisoned the
descent stage and ignited the ascent engine for return to the CM.
I would like to thank Allan Klumpp for the time he spent explaining
this stuff to me. It was absolutely fascinating to hear him talk.
I hope sci.space.tech readers have enjoyed reading my description
of Allan's comments.
+------------------------------------------------------------------+
Stanley R. Mohler, Jr. 75570.3303(at)compuserve.com
+------------------------------------------------------------------+
Humor collection