3 Gordon Drive, P.O.Box 1347 Rockland, Maine 04841 U.S.A.
Find Tools for Your Chip


 

© 2004 Avocet Systems, Inc.
Call Us Today at 207-596-7766 ("Picton Press")
Avocet Systems, Inc. : The Complete Solution for Embedded Systems Development Tools
Embedded Update
Computers in the Apollo Program

The comp.realtime newsgroup has carried an interesting discussion of computers used on board the Apollo Command and Lunar modules. For those of you who haven't seen this, here's a repost of a fascinating story about these antique machines.

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 at least 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 reliability.

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 reticule 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 barely 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 after all. 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 discrepancy 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 occurred 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 envelope 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, unintentionally 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 (at least 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.