Apollo's Rocket Scientists
On May 25, 1961, six weeks after the Soviet Union took a commanding lead in the space race by sending Yuri Gagarin into Earth orbit, John F. Kennedy went before Congress in a nationally televised address and asked his country to “commit itself to achieving the goal, before this decade is out, of landing a man on the moon.” Three months later, the fledgling National Aeronautics and Space Agency issued its first major contract under the new lunar program. It went to the MIT Instrumentation Lab, which was charged with designing a navigation and guidance system for all the Apollo spacecraft.
The decision was a contentious one. Ordinarily, companies angling for the contract would have had the chance to submit competing proposals. But as a nonprofit, the Instrumentation Lab was prohibited from bidding against industrial rivals. By hiring MIT to build the navigation system, NASA was declaring that no one else was in its league. “I had a lot of justifying to do,” recalls Bob Chilton ‘48, SM ‘49, who headed the Flight Dynamics Branch at NASA’s Space Task Group. “All the industrial people fussed and fussed and fussed.”
MIT ’s champions at NASA had a strong case. The Instrumentation Lab’s director, Charles Stark Draper ‘26, SM ‘28, ScD ‘38, was a pioneer in the use of gyroscopes and accelerometers to navigate aircraft. In 1953, one of Draper’s systems had piloted an airplane that took off from Hanscom Field, outside Boston, to within nine miles of an airstrip in Los Angeles.
In the mid-1950s, the lab had won contracts from the U.S. military for work on the navigation systems of several ballistic missiles, including the Polaris, which had to find its way to a fixed target from a submarine at an arbitrary location. To avoid jamming by enemy radios, the missile’s guidance system had to be completely self-contained–no external direction possible. The system performed brilliantly when it was tested in 1960, enhancing the lab’s reputation in Washington.
Also working in the Instrumentation Lab’s favor was a project it had initiated soon after the launch of Sputnik in 1957, using the modest funding for speculative research included in the military contracts. Several of the lab’s most brilliant thinkers began designing an unmanned mission to Mars, calculating trajectories for interplanetary travel and drawing up specifications for a general-purpose navigation computer. In four years, the Mars project had grown to include researchers at NASA’s Langley Research Center, and much of the work could easily be adapted to a lunar mission. The lab’s hold on the Apollo contract would remain secure because–as Aaron Cohen, NASA’s manager of the Apollo command and service module, recalls–“we didn’t think anyone else could do the job.”
The contract with NASA called for the lab to develop a navigation, control, and guidance system that would be carried by both the Apollo command module and the lunar lander. (The command module entered lunar orbit and returned the astronauts to Earth; the lander detached from the orbiting command module and carried the astronauts to the moon’s surface.) In both cases, navigation meant determining the craft’s current position, guidance meant keeping the craft on its trajectory through space and plotting any course corrections, and control meant maintaining the right velocity and “attitude”–ensuring that the command module’s nose was pointing in the right direction, or that the lander’s feet were square with the lunar surface.
For navigation, the Apollo craft wouldn’t have to rely solely on their onboard systems: Earth-based radar would track them, and mission control would send up course corrections as long as it could maintain radio contact. But during what were probably the most critical stages of a lunar mission, radio contact would be impossible. The long, curving trajectory of the spacecraft would bring it closest to the moon on the side facing away from Earth, so that’s where it had to enter lunar orbit and deploy the landing module–but of course, there would be no line of sight with Earth-based tracking stations. And when the returning command module entered Earth’s atmosphere, friction from its descent would heat the air around it and create a cloud of ions that would jam any radio transmissions.
The heart of the navigation and control system was Doc Draper’s brainchild, the inertial measurement unit, or IMU. The IMU was basically a disc surrounded by two concentric rings inside a spherical housing about a foot and a half across. The outer ring was attached to the housing by two hinges, so it could spin around one axis; the second ring was attached to the first one and spun around a perpendicular axis; and the disc spun around an axis perpendicular to the second ring’s, so it had perfect freedom of motion in three dimensions. On the disc–the inertial platform–were three accelerometers and three gyroscopes, also aligned in three different directions. If the IMU housing rotated, the gyros would register the motion, and motors would turn the rings to maintain the platform’s orientation: imagine a waiter who holds a tray of glasses parallel to the ground–even as he runs up and down walls and across the ceiling. If the inertial platform’s orientation remained perfectly stable, data from the accelerometers could locate the IMU anywhere in space by reference to its original position.
But the platform wasn’t perfectly stable. To allow for midflight course corrections, the Instrumentation Lab also designed a telescope and sextant that together could help locate the craft in space. Using an eyepiece on the command module’s console, an astronaut could find a trio of landmarks–say, Earth’s horizon, the moon’s, and Alpha Centauri–and press a button. The onboard computer would calculate the craft’s position from the angles between the sightings.
The IMU and the sighting optics had to provide virtually error-free information, and their design had to take into account the eccentricities of operation in space; hundreds of Instrumentation Lab engineers worked on them. Nonetheless, they were largely elaborations on existing technologies. The design of the Apollo guidance computer, however, took the Instrumentation Lab into uncharted waters.
In the annals of technology, the most important event of 1961 may not have been JFK’s unveiling of the lunar program but, rather, an announcement a few months earlier from a four-year-old company called Fairchild Semiconductor: the first commercial release of a computer chip. An early example of an integrated circuit, it combined multiple electronic components in a single piece of silicon.
Today, when Intel can cram a billion transistors onto a chip, the advantages of integrated circuits seem obvious. But that wasn’t the case in 1961. For one thing, the new chips didn’t hold a billion transistors each; they held three. Integrated circuits would, in principle, take up about 40 percent less space than so-called core transistors, which consisted of wires wound around magnets. But they also demanded more electricity, a serious drawback in spacecraft with limited resources. What’s more, it was not at all clear that integrated circuits could be mass-produced with the reliability that spaceflight required. NASA administrators originally specified that the Apollo flight computer would use the larger core transistors.
But Eldon Hall, who had been at the Instrumentation Lab since 1952 and led the design of the flight computer, had been intrigued for years by the prospect of integrated circuits. So he initiated two parallel design programs: one to build a computer using core transistors, and one using integrated circuits. By the fall of 1962, Hall says, “it was clear to both sides that it was easier to build a machine with Micrologic.” The integrated circuits could perform calculations more than twice as quickly as the core transistors, and their space savings meant that the computer would have much more room for memory circuits. Moreover, wiring them together was much simpler and posed fewer opportunities for something to go wrong. That winter, Hall persuaded NASA to redraw its contract with Raytheon, the company that was to manufacture the computer, and take a gamble on the new technology. “How did I con these managers into letting me use integrated circuits?” Hall says. “I didn’t have to con them. They didn’t care. I could do what I wanted to do.” NASA managers, concerned with more imminent missions such as the 1965 and 1966 Gemini flights, simply weren’t paying much attention yet (see “Getting the Job Done,” p. M16).
By today’s standards, the Apollo computer had a peculiar architecture: it used only one type of logic circuit, the NOR gate–so called because it outputs an electrical signal only when it receives a signal from none of its inputs. A computer built from NOR gates is less efficient than one that also uses other types of gates–the AND gate, for instance, which outputs a signal when it receives signals from all of its inputs. When asked why the Apollo computer relied so heavily on the NOR gate, however, Hall laughs and says, “Because that’s what Fairchild was able to build.” Once Hall and his team had a hardware design that worked, they weren’t about to take chances on even newer technologies. Instead, they worked closely with several potential manufacturers to ensure that the NOR gates could be built reliably.
By the time the first Apollo mission flew, Fairchild had abandoned its NOR-gate chips for more sophisticated architectures, so Philco supplied the computer’s logic circuits. Reliability, which had once been the integrated circuit’s chief drawback, was now its chief advantage. “Computers in those days wouldn’t work for more than a few days without repair,” Hall says. In 15 Apollo flights, however, the guidance computer never suffered a hardware failure–even when lightning struck during the Apollo 12 takeoff.
The design of the guidance computer, like those of the optics and the IMU, was largely complete by 1966. From then until the Apollo 8 mission put astronauts in orbit around the moon in December 1968, the lab focused on software development.
In the beginning, nobody would have predicted that. Early in the Apollo effort, “the lab sort of bifurcated,” says Fred Martin, SM ‘59, ScD ‘65, who would become project manager for the command module’s software. One group designed hardware. The other group, Martin says–the analysis group–“dealt with how you were going to get to the moon, and what kind of measurements you were going to make, and when you were going to fire this big engine, and what direction you were going to point it, and how to figure out the trajectories to get to the moon, and how to worry about the errors you were going to have.” Of course, the analysis group’s calculations would eventually have to be embodied in software; but devising equations was seen as the heavy lifting.
By the late 1960s, however, the Instrumentation Lab employed some 400 people on the software effort. Richard Battin ‘45, PhD ‘51, who headed the analysis group, says that another 200 programmers worked on the project as subcontractors.
No one foresaw the difficulty of the programming task, Martin says, because of its unprecedented scale. “Nobody had any experience in the world of software. In, fact the word was not very widely used,” he says. “And there was no such thing as computer science.” Fortunately, at the lab was one of the people who helped invent it.
The Reclusive Genius
“Hal was the most brilliant person we ever had the chance to work with,” says Dan Lickly ‘54, SM ‘55, the Instrumentation Lab engineer who developed the crucial reëntry program for the Apollo command module. Hal Laning ‘40, PhD ‘47, had joined the lab in 1945 as an applied mathematician, and in the early 1950s, he wrote a program called George that converted algebraic expressions into computer code. Because it was the first program to mediate between symbols intelligible to humans and those intelligible to machines, Lickly says, it was the “father of all programming languages,” preceding IBM’s similar but more expansive Fortran by a few years. “This happened just a few months after I joined the lab, and we thought, What on earth is Hal working on?” says Battin. At the time, he says, there was debate about whether it was even possible for a machine to interpret instructions written in a high-level language. “Hal would lock himself in his office–and all of a sudden it was working,” Battin says. (The Apollo flight simulators would be programmed in a home-brewed successor to George, called MAC–“much better than Fortran,” says Hall.)
By the mid-1950s, Laning had joined the Polaris missile team, and he and Battin together developed the groundbreaking Q guidance system, which vastly simplified the calculations that a missile had to perform in flight to reach its target. Laning was also one of the engineers who initiated the lab’s Mars project. Laning’s early design work on the computer for the Mars mission led to his most important contribution to Apollo: the so-called executive program.
At a given time, a spacecraft’s guidance computer might have to coördinate dozens of different tasks: repositioning radar antennas, taking readings from the radar and from the accelerometers, performing error corrections on the gyros, calculating the craft’s trajectory, and determining which rockets needed to be fired–to say nothing of transmitting data to NASA ground control and displaying data to the astronauts. The computer’s processor, however, could perform only one task at a time, so it would have to break up each task into smaller subtasks and alternate rapidly among them, creating the illusion of simultaneity. That division of labor was performed and overseen by the executive.
Apollo programmer Don Eyles explains that in the early 1960s, executive programs used the boxcar method, carving passing seconds into shorter intervals that flashed by like boxcars on a train. Part of a computational task was assigned to each interval, and when the interval ended–when the boxcar passed–the processor switched to another task, whether it had completed the first one or not.
But Laning realized that in an endeavor as unpredictable and time sensitive as sending a spacecraft to Mars–or, as it turned out, to the moon–the boxcar method could prove disastrous. If a few trivial computations ended up taking longer than expected, the whole system could break down. A spacecraft waiting to learn which direction its radar was pointing could end up crashing into a planet.
So Laning devised his own executive program, which assigned tasks different priorities and allowed high-priority tasks to cut in on low-priority ones. The idea may sound simple, but the execution was difficult, since it required the computer to allocate memory among different tasks, keep track of where it had broken off each of them, and determine which to resume once it had completed the task of highest priority. “He basically made it up out of whole cloth,” Eyles says. “But it was brilliant.”
As the lab’s work on Apollo expanded, Laning’s involvement in it waned. “Hal loved to do things like [the executive program], especially if it was a major contribution he could do by himself,” Battin recalls. “But when we got the Apollo job, he told me, ‘Dick, I’d like to help out, but I do not want to be a manager. The endless meetings and trying to explain things to people who don’t understand them–I can’t do that.’” Now 89, Laning says he can’t even remember where he was during the lunar landing–whether or not he joined his Instrumentation Lab colleagues around the “squawk box” in their Cambridge office to listen to the radio transmissions between NASA and the astronauts. For him, he suggests, work on spacecraft navigation had lost some of its charm with the introduction of human operators.
Ironically, however, it was during the last few minutes before the Apollo 11 lander touched down–one of the few points during the mission when the astronaut was supposed to take manual control of the vessel–that Laning’s executive function would face its stiffest test.
The Eagle Lands
No one could be sure in advance what the moon’s terrain would look like, so during the last 500 feet of the lunar descent, the astronaut piloting the lander had to be able to redirect it if the landing site initially chosen looked inhospitable. But even then, says Eyles, the astronaut’s control system was only “semi-manual”: “The software was still controlling the throttle,” he says, “and of course the autopilot was in control of maneuvering the vehicle.” Fred Martin argues that astronauts training for the Apollo missions on mockups of the lander–jokingly called “flying bedsteads”–demonstrated that controlling the lander’s descent was beyond human capacity. Two of the flying bedsteads, which had no autopilot, crashed during tests before Apollo 11, and the astronauts–Neil Armstrong was one of them–had to bail out.
So the approach to the lunar surface would be a very bad time for the onboard guidance system to fail. And about five minutes into the lander’s descent, the computer began displaying a series of alarms, indicating that its processor was overloaded.
Eyles was listening to the squawk box at the Instrumentation Lab. If at that moment the decision had been his, he says, he would have aborted the landing. “However,” he says, “the flight controllers who were used to looking at the system from the outside had actually run simulations that had similar alarms and had discovered that in fact it would keep flying. From that perspective, it was safe to say go.”
Ultimately, the culprit turned out to be the radar system that was supposed to gauge the distance to the command module when the lander was on its way back from the moon. Because of a mismatch between the power supplies of the radar and the guidance system, the computer was interpreting random electrical noise as important radar signals. This, added to all the other information that the computer had to process during the extremely tricky descent, was more than the processor could handle.
Hal Laning’s executive program was equal to the crisis. As Instrumentation Lab engineers scrambled to find out what was causing the alarms, the lander’s high-priority tasks–like throttling the rockets–were executing normally. The lander touched down safely; a boxcar executive would have gone off the rails.
Meeting the Enemy
After the command module returned safely to Earth, the celebrations began. The astronauts were given ticker-tape parades, invited to state dinners, and presented the Presidential Medal of Freedom. A couple of Instrumentation Lab engineers, on the other hand, got to go to Russia.
Richard Battin, his wife Marge, and David Hoag ‘46, SM ‘50, the lab’s program manager for the navigation system’s hardware, were invited to the Soviet Union as guests of the Soviet Academy of Sciences, to tour facilities in Moscow, Leningrad, and Tbilisi, Georgia. “The first night we were in Tbilisi,” Battin says, “there was an important football game going on, and our host wanted to go. So he said, Could you possibly take care of yourself–just have some dinner and then go to the hotel?” But the Battins ventured out on their own, taking a cable car up nearby Mtatsminda Mountain, home to a lovely mausoleum celebrating some Georgian heroes.
On the way back down, the cable car gave a sudden lurch, and Marge, not quite confident in Soviet engineering, grabbed her husband’s hand. Immediately, Battin says, a passenger jumped up and offered Marge his seat. When the other passengers realized that there were Americans in their midst, they crowded round and began questioning them. Battin, who was wearing a pin with an image of the command module on it, managed to explain his presence with the words “lunar Sputnik.” “They were so impressed,” he says, “and they were just so friendly.” One group congratulated Battin with a bottle of champagne; he gave them his button in return. “These were just ordinary people who’d bought some champagne at the top of the mountain,” Battin says, “and they gave it to us.”
The motive for the Apollo program had been competition with the Soviets; a year into the Instrumentation Lab’s work on the navigation system, the United States and the USSR had been on the brink of nuclear war. But these Soviet tourists were as excited as anyone else by the romance of the moonwalk. Neil Armstrong had been right: the flag he planted may have been the United States’, but the accomplishment was mankind’s.
Still, some members of mankind had a bigger hand in it than others. In 1975, in a NASA publication about the moon landing, George Low, who was manager of the Apollo Spacecraft Program Office in the final years leading up to the landing, wrote, “If you had to single out one subsystem as being most important, most complex, and yet most demanding in performance and precision, it would be Guidance and Navigation.” If the moon shot turned the term rocket scientist into the highest accolade that can be paid to human intelligence, then no one had more of a right to it than the engineers at the Instrumentation Lab.
The inside story of how ChatGPT was built from the people who made it
Exclusive conversations that take us behind the scenes of a cultural phenomenon.
How Rust went from a side project to the world’s most-loved programming language
For decades, coders wrote critical systems in C and C++. Now they turn to Rust.
Design thinking was supposed to fix the world. Where did it go wrong?
An approach that promised to democratize design may have done the opposite.
Sam Altman invested $180 million into a company trying to delay death
Can anti-aging breakthroughs add 10 healthy years to the human life span? The CEO of OpenAI is paying to find out.
Get the latest updates from
MIT Technology Review
Discover special offers, top stories, upcoming events, and more.