“Apollonauts” reflect on lunar landing and return to the moon
CAMBRIDGE, Mass. — The engineers who developed the computers that enabled the Apollo 11 lunar landing had little doubt the mission could be a success, and half a century later have advice for how NASA should return to the moon.
In the 1960s, the MIT Instrumentation Laboratory had a NASA contract to develop the Apollo Guidance Computer, one of the first portable digital real-time computers, used on both the command and lunar modules. Engineers took advantage of emerging technologies from that era, like integrated circuits, to develop a system that guided Apollo to the moon and to six successful landings on the lunar surface.
The facility, now known as Draper and spun out after Apollo as a nonprofit organization, is marking the 50th anniversary of Apollo 11 with a “Hack the Moon” exhibition recalling its role in developing the Apollo Guidance Computer. At a media event at its headquarters here July 9, several of the engineers — dubbed “Apollonauts” by Draper — discussed their experiences developing the computer.
While the Apollo Guidance Computer pressed the limits of technology of the era, with the added constraints of schedule and size, those involved in the program said they never doubted they would be successful.
“The landing was kind of a nail-biter, but I don’t think anybody thought we weren’t going to do it,” recalled Peter Kachmar, a rendezvous engineer who still works at Draper today supporting work on the Trident missile’s guidance system. “Whatever we set our minds to do at the lab, we can do. I had always felt it was going to be successful.”
That confidence, though, didn’t mean development of the computer and its software was without problems. While advanced for its time, the computer had only 36,000 words, or 72 kilobytes, of memory. “That’s why we rolled mission phases in and out, but they caused errors,” said Margaret Hamilton, who led the team that developed the software for the computer.
One such example, she recalled, was something her young daughter discovered playing with a model of the computer. Inputting commands to start a pre-launch program while in the middle of the mission caused the computer to crash. She then advised her management at MIT and NASA about the problem, and suggested a software fix to prevent it from happening.
They rejected her suggestion. “We just can’t do it,” she said they told her. The astronauts, they reassured her, “are too well-trained. It’s not going to happen.” It, in fact, did happen on Apollo 8, resetting the navigation system. Afterwards, she said management agreed to the software change to prevent that from happening again.
The limited capacity of the computer also led to major cuts in the software. Jim Kernan, a lunar module software engineer, said that at one point the software exceeded 150 percent of the available storage. On a day dubbed “Black Friday” NASA management directed major cuts to the software in order to fit into available storage.
“Up until that point we all had the idea that the software would be self-contained and fly the mission without the help of the ground,” he said. “They chopped out a lot of the capability that was dear to hearts. Now the ground was preeminent, and we couldn’t fly the mission without the ground.”
Perhaps the best known issue with the computer system was the program alarms during the lunar module’s descent on Apollo 11. That was triggered by a rendezvous radar that was on during the lander’s descent, something the engineers said hadn’t been anticipated during development and testing of the computer.
Hugh Blair-Smith, who worked on the computer’s hardware and software, said that Buzz Aldrin had decided to leave the rendezvous radar on during descent, even though it wasn’t needed. That decision was based on the experience with Apollo 10, when the lunar module briefly lost attitude control as it prepared to return to the command module.
“He became doubly aware of the possibility that they’d have to abort and start using the rendezvous radar quickly,” he said. “He made sure in Apollo 11 that the rendezvous radar was as ready for instantaneous use as it could possibly be.”
The fact that the radar was on, as well as what Blair-Smith called a “weird situation” with the power supplies on the spacecraft, meant that the radar was taking up computer cycles, triggering the alarm. “Buzz gets a lot of blame” for that, unfairly, he said. “Everything he had done was perfectly rational and very well founded on the events of Apollo 10.”
The engineers worked directly with a number of astronauts on the computer system. Dan Lickly, a software engineer on the system, singled out Neil Armstrong as someone particularly interested in the computer. “We were giving a lecture to a group of astronauts that was supposed to take one hour, and it took an hour and a half because Neil would just not stop asking questions,” he said. “We had no trouble communicating, because it was one geek to another. We got along fine.”
Without the Apollo Guidance Computer, engineers said the Apollo landings would not have been possible. “There wouldn’t have been a mission,” said Peter Volante, a software engineer. He recalled comments made by Chris Kraft at a symposium 10 years ago about Apollo. “Among the things he said in his talk that day was that it would not have been possible to do Apollo without the modern digital computer.”
Computer systems have advanced remarkably in the half-century since Apollo, but the engineers who worked on the Apollo Guidance Computer still had advice for NASA as it returns to the moon with Artemis. One example of that advice is centralizing development.
“One of the most important features of the way the program was set up was that it was all here in one building,” Blair-Smith said. If someone ran into problems, “he didn’t send off an interdepartmental memo, he trots down two doors and asks me.”
Hamilton said that she’s still seeing the use of the “traditional lifecycle” approach to software engineering used in Apollo, which can be time-consuming and expensive. She called for the use of alternative approaches that avoid those problems. “It’s maybe going to happen, but it’s still going to take time,” she said.
“The most important thing is to understand exactly what miracles in project management were developed and worked,” Blair-Smith said. “We had plenty to complain about at the time, but it really was amazing.”