DSKY — Volume 14 — The Whole Mission: Command Module, LM & Fly-by-Wire

About This Volume

It is tempting, after thirteen volumes spent circling the lunar landing, to think of the Apollo Guidance Computer as a machine that existed to land on the Moon. It was not. Landing was the most dramatic twelve minutes of its working life, but it was twelve minutes out of more than a week. The same little computer — sometimes two of them, one in each spacecraft — flew the entire mission, from the moment the Saturn V cleared the tower to the moment the charred command module splashed into the Pacific under three orange canopies. It monitored the launch, threw the stack toward the Moon, corrected the aim by the light of the stars, slipped into lunar orbit, brought the ascent stage back up off the surface and flew it through the delicate ballet of rendezvous, pushed the crew home across a quarter-million miles, and then — its final and in some ways most astonishing trick — steered a blunt cone through the top of the atmosphere at twenty-five thousand miles an hour and put it down within sight of the recovery ship.

This volume is about that whole arc, and about the two identical computers that flew it. It is also about two famous moments that show the machine at its most human: the in-flight software patch that saved Apollo 14, keyed into the DSKY by hand while the spacecraft coasted toward the surface; and the quieter story of what happened to the AGC after Apollo, when surplus units became the brain of the first aircraft ever to fly with a digital computer as its primary flight control — the ancestor of every fly-by-wire airplane in the sky today.

Two Computers, Same Hardware

The single most important thing to understand about the AGC’s role across a mission is that, for most of Apollo, there were two of them flying in formation. They were identical machines — the same Block II hardware, the same erasable memory, the same DSKY, the same wirewound core-rope read-only memory described in earlier volumes. What made them different was the software baked into the ropes, and the spacecraft wrapped around them.

The computer in the Command Module was the Command Module Computer, the CMC. It ran a software system called Colossus. The computer in the Lunar Module was the Lunar Module Guidance Computer, the LGC, and it ran a system called Luminary. The split ran deep enough that the MIT Instrumentation Laboratory — soon to be renamed the Draper Laboratory — gave the two code bases different naming conventions: Command Module routines were tagged “CO,” Lunar Module routines “LU.” Colossus development was led by Frederic Martin; the lunar landing software that grew into Luminary was led by George Cherry, with the descent guidance largely the work of Don Eyles, whom we met in Volume 13.

The reason for two programs is simply that the two vehicles had different jobs and different bodies. The Command Module never landed; it never even fired a descent engine. Its guidance problems were the long-haul ones — translunar injection, midcourse navigation by star sighting, lunar-orbit insertion, the burn home, and the searing return through the atmosphere. The Lunar Module’s problems were the close-in ones — separation, descent, ascent, and the rendezvous back with its mother ship. Colossus knew how to fly a heat shield through air; Luminary knew how to throttle a rocket down onto dust. Neither needed the other’s knowledge, and rope memory was far too precious to waste carrying it. So the same chassis became two specialists, distinguished only by the program woven into the wires.

This is worth dwelling on because it is a remarkably modern idea. The AGC was, in effect, a platform — a general-purpose digital computer whose behavior was defined entirely by its software load, deployed in two configurations for two missions from one production line. That is how we build computers now. In 1968 it was close to revolutionary.

Launch and the Road to the Moon

The CMC’s mission began before the crew had left Earth. During the launch of the Saturn V, the rocket flew under its own guidance — an independent computer in the instrument unit atop the third stage did the steering — but the CMC ran a monitoring program, watching the trajectory and standing ready, with the crew, to call an abort if the great machine beneath them strayed. The astronauts watched their ascent partly through the DSKY, the green numbers confirming that velocity and altitude were tracking the plan.

Once in Earth orbit, the most consequential burn of the early mission was translunar injection — the firing of the third stage that flung the spacecraft out of orbit and onto a path to the Moon. Here again the launch vehicle did the work, but the CMC tracked it, ready to take over the aim if needed. After injection the crew performed the transposition and docking maneuver, pulling the Command Module away, turning it around, and mating nose-to-nose with the Lunar Module still nestled in the spent stage — a piloting task in which the DSKY’s read-outs of attitude and rates were a constant companion.

Then came the long coast, and with it the part of the mission that most resembled the dream the MIT engineers had started with in the early 1960s: celestial navigation. The spacecraft did not rely on the ground to know where it was. Using the onboard sextant and scanning telescope, the crew sighted on stars, marking their angle against the Earth’s or Moon’s horizon, and fed each “mark” into the computer with a press of a button. The CMC’s navigation programs took those sightings and refined its knowledge of the spacecraft’s position and velocity — a self-contained system, deliberately built so that a crew could find its own way home even if it lost contact with Houston entirely. The midcourse corrections that kept the spacecraft on its narrow corridor to the Moon were small burns, computed and timed by the CMC, trued up by these star sightings. It was the oldest form of navigation in the world, sextant and star, married to a digital computer.

Arrival at the Moon meant lunar-orbit insertion: a long burn on the far side of the Moon, out of radio contact with Earth, in which the spacecraft’s big service-module engine fired to brake the stack into orbit. The crew flew it on the CMC, watching the residual velocities tick toward zero on the DSKY, trusting the machine through the only minutes of the mission in which no one on Earth could help them.

Down, and Back Up Again

The descent to the surface — Programs P63 through P67, the braking and approach and the shared-control hover — is the subject of Volume 13, and we will not retell it here. What that volume left waiting on the surface was the other half of the lunar adventure: getting back.

Ascent was, in a sense, the descent run backwards, but simpler and more brutal. The Lunar Module’s ascent stage lit its single engine, left the descent stage behind as a launch pad, and the LGC flew it straight up off the Moon and into orbit. There was no shared control here, no hovering, no landing-point designator — just a hard climb into a precise orbit, with the computer nulling the velocities to put the spacecraft exactly where the rendezvous plan required. If the ascent engine had failed, no software could have saved the crew; but it did not fail, not once.

What followed was the part of the mission that engineers quietly regarded as the AGC’s masterpiece: rendezvous. The ascent stage came off the Moon into a low, fast orbit, tens of miles behind and below the Command Module, and had to close that gap and arrive alongside its mother ship gently enough to dock. This is not a matter of pointing and thrusting; orbital mechanics are perverse, and to catch a spacecraft ahead of you, you must often slow down to drop into a lower, faster orbit and overtake from beneath. The choreography Apollo used was the coelliptic rendezvous, and the LGC ran it as a sequence of named maneuvers — Coelliptic Sequence Initiation (CSI), Constant Delta Height (CDH), and Terminal Phase Initiation (TPI) — each a burn computed from the computer’s continuously updated picture of where both spacecraft were.

That picture came from the rendezvous radar. Mounted on the top of the Lunar Module, it locked onto a transponder on the Command Module and fed the LGC range and angle to the target roughly once a minute. The computer’s rendezvous navigation program, P20, drove the radar to keep it pointed, took those marks — at least five to fix a solution, repeated to keep it fresh — and steadily refined the relative orbit of the two vehicles. The same rendezvous radar, it is worth recalling, was the indirect cause of the famous 1202 alarms of Apollo 11 (Volume 12): a switch left in the wrong position flooded the computer with phantom radar data during the descent, when the radar’s real job lay ahead in the ascent. On the way back up, that radar was no nuisance at all but the crew’s eyes in the dark.

The endgame was the human one. As the ascent stage closed the last miles, the two computers and two crews — one in each spacecraft, each with its own DSKY — converged on the same solution, the Command Module Pilot sighting the Lunar Module’s flashing beacon through his sextant while the LGC drove its radar. The final approach and docking was flown by hand, but on numbers the computers had supplied. When the docking latches snapped shut, the AGC’s hardest navigational problem of the mission was solved.

The Long Way Home and the Fire of Reentry

With the crew reunited in the Command Module and the Lunar Module cast off, the CMC’s Colossus took over again for the journey home. Transearth injection was another far-side burn, the service-module engine firing to break out of lunar orbit and onto a path back to Earth, computed and monitored by the CMC and trued by the same kind of star sightings that had guided the outbound leg.

And then, at the very end, the computer did the thing that is easiest to overlook and hardest to do. The Command Module came back into Earth’s atmosphere at roughly thirty-six thousand feet per second — interplanetary speed, far faster than any orbit. It had to shed all of that energy as heat without cooking the crew or skipping back off the atmosphere into space, and it had to land near the ships waiting to pick it up, in an ocean that the spinning Earth was carrying out from under it the whole time. The margin for error in the entry corridor was famously thin: too steep and the deceleration would be fatal, too shallow and the capsule would graze the atmosphere and bounce away.

The Command Module was not a dead weight falling. It was blunt but lifting — flown slightly nose-up and offset so that it generated a small amount of aerodynamic lift, and by rolling the capsule the guidance system could point that lift up, down, or sideways, steering the trajectory the way a pilot banks an aircraft. This was the AGC’s entry guidance, and it was genuine closed-loop flying. The computer took over at the “0.05 g” point, where deceleration first became measurable, and from there it commanded a continuous sequence of roll maneuvers — at times deliberately a partial skip, pulling the nose up to stretch the flight and bleed speed high in the atmosphere before settling back into the dense air for the final plunge. Throughout, it was steering toward a target splashdown point hundreds of miles downrange, adjusting the roll moment by moment as the real deceleration diverged from the predicted. A blunt cone with no wings and no engine, flown by software to a point in the open ocean by banking lift it barely looked capable of generating. When the drogues and then the main parachutes deployed, the computer’s job was done; it had threaded the needle.

The Patch in Flight: Apollo 14

Of all the things the AGC and its keepers ever did, the most legendary may be a piece of typing.

On 31 January 1971, Apollo 14’s Lunar Module Antares, with Alan Shepard and Edgar Mitchell aboard, was in lunar orbit preparing to descend. Then the computer began reporting something impossible: an abort signal, intermittently, from the cabin’s abort switch — the very switch a crew would throw to jettison the descent stage and rocket back to orbit if a landing went wrong. The signal was spurious. The leading suspicion, then and since, was a tiny loose ball of solder floating inside the switch, intermittently bridging the contacts. Tapping the panel with a pen would clear it for a while; then it would come back.

The danger was precise and severe. The switch itself was not commanding anything yet, because the descent engine was not running. But the descent software monitored that abort discrete continuously. The instant the engine lit for powered descent, if the computer saw the abort signal it would do exactly what it had been told to do — throw away the descent stage and abort the landing — and there would be nothing the crew could do to stop it. With Antares already in orbit and a landing only hours away, the mission was about to be lost not to a real failure but to a phantom one.

The problem landed on the desk of Don Eyles, the twenty-seven-year-old MIT programmer who had written the very code that read that switch. “I’d written the code that looked at that switch,” he later said, “and so the problem became mine to solve.” Eyles saw the paradox at the heart of the fix almost at once: the only way to make the software ignore the abort switch was to tell it that an abort was already in progress. If the computer believed it was already aborting, it would stop monitoring the switch — and provided you did it at the right moment and then quietly cleared the indication, the actual effect on the descent would be nil.

There was no time to change the rope memory — the software was literally woven into wire and could not be altered in flight. The fix had to be made entirely through the DSKY, by reaching into the computer’s erasable memory and changing individual values by hand, using the verb-and-noun grammar described in earlier volumes. Working in the simulator at MIT, Eyles and his colleagues built and tested a procedure in about two hours: a sequence the crew would key in to set the “abort in progress” bit, fly past the dangerous moment, and then patch the guidance back so the descent would proceed normally. The procedure ran to dozens of keystrokes — accounts put it at a 26-step sequence amounting to some 61 individual key presses — and it had to be entered perfectly, in the right windows of time, with the spacecraft descending.

It was read up to the crew with minutes to spare. Shepard keyed it in by hand, every digit correct. The software ignored the switch. Antares flew its descent and landed at Fra Mauro. Eyles received a NASA Public Service Award and a permanent place in the folklore of people who have saved a spacecraft with a keyboard. It remains the cleanest demonstration in the program of why there was a keyboard at all: because a computer you can reprogram in flight, through a human at a keypad, can survive a failure its designers never imagined.

Apollo 13: The Lifeboat

A year earlier, the AGC had been at the center of a very different drama. When an oxygen tank in Apollo 13’s Service Module exploded on the way to the Moon, the Command Module — and with it the CMC — had to be powered down almost completely to save its batteries for the one job only it could do, the reentry. The crew moved into the Lunar Module Aquarius and used it as a lifeboat, and the burns that bent their trajectory back toward Earth and corrected it along the way were flown from the Lunar Module.

Here the two onboard computers shared the load with a third system. For the critical free-return burn around the Moon, the crew used the LGC. But for much of the long coast home, including a pair of midcourse corrections, they flew on the Lunar Module’s independent backup, the Abort Guidance System — a separate, simpler computer built by TRW with a strapdown inertial unit, carried specifically so the crew would never be wholly dependent on the primary AGC. It was a thrifty, robust little machine, and on Apollo 13 it earned its passage. The throughline, again, is redundancy and human judgment: two spacecraft, three computers, and a crew that knew how to use all of them brought everyone home.

After Apollo: The Fly-by-Wire Legacy

The Apollo computer’s working life did not end with the last lunar mission. The AGC and DSKY flew again on Skylab and on the Apollo–Soyuz Test Project of 1975, the final flight of Apollo hardware. But its most consequential afterlife happened not in space at all, but in the skies over the California desert.

When Apollo wound down, NASA’s Flight Research Center at Edwards — soon the Dryden, now the Armstrong Flight Research Center — was pursuing a radical idea: an aircraft flown entirely by a digital computer, with no mechanical linkage at all between the pilot’s stick and the control surfaces. The pilot’s commands would become numbers; the computer would decide how to move the surfaces; wires, not cables and pushrods, would carry the orders. This is fly-by-wire, and doing it with a digital computer had never been tried as an aircraft’s primary control system.

The engineers needed a flight computer that was already proven, already flight-rated, and exhaustively understood. They had one: the Apollo Guidance Computer. Working with the same Draper Laboratory that had built the AGC, the program took a surplus Apollo computer — and its DSKY — and made it the brain of a modified U.S. Navy F-8C Crusader. On 25 May 1972, test pilot Gary Krier flew it, and the F-8 Digital Fly-By-Wire aircraft became the first fixed-wing airplane in history to fly with a digital computer as its sole primary flight-control system, no mechanical backup behind it.

It worked because the AGC had already solved, in space, the deepest problem of fly-by-wire: how to put a digital computer reliably and safely between a human pilot and the vehicle, sampling the pilot’s intent and translating it into stable, continuous control — the very human-in-the-loop, computer-in-the-loop relationship that Volume 13 found at the heart of the lunar descent. An F-8 has no orbital mechanics to compute, but the architecture is the same, and the lineage is direct. Everything that followed — the digital flight controls of the Space Shuttle, the relaxed-stability agility of the F-16, the flight envelope protections of the Airbus airliners, and ultimately nearly every modern jet — descends from that desert-flown F-8 and, through it, from the computer that landed on the Moon.

There is a small, perfect coda to this. The DSKY photographed at the very start of this series, in Volume 1 — the unit whose worn keys and steady electroluminescent glow opened the whole account — was not flown to the Moon. It was an F-8 Digital Fly-By-Wire unit. The keyboard we have spent fourteen volumes admiring is, fittingly, one that helped invent the way modern aircraft fly.

The Throughline

Pull far enough back from any single phase — launch, navigation, landing, rendezvous, reentry, or a desert test flight — and the same shape appears in all of them. In every case the AGC is not flying instead of the human, and the human is not flying despite the computer. The machine does the relentless arithmetic and holds the vehicle steady; the human supplies the judgment, the goal, and the override; and the DSKY is the narrow, deliberate channel between them. That arrangement — human-supervised, computer-in-the-loop control — was not the way machines had been flown before Apollo. It is the way essentially everything is flown now. The AGC’s deepest legacy is not that it reached the Moon, but that it taught us how a person and a computer could fly something together.

Next — Volume 15: Manufacturing the Impossible.