The Story of the Apollo Guidance Computer, Part 2

In the late 1950’s, before NASA had any intentions of going to the Moon – or needing a computer to get there — the MIT Instrumentation Laboratory had designed and built a small prototype probe they hoped would one day fly to Mars (read the background in part 1 of this story here).  This little probe used a small, rudimentary general-purpose computer for navigation, based on the inertial systems for ballistic missiles, submarines, and aircraft the Lab had designed and built for the military since World War II.

The folks at the Instrumentation Lab thought their Mars Probe concept — and in particular the navigation system — would be of interest to the those involved in the fledgling planetary exploration efforts, such as the US Air Force and the Jet Propulsion Laboratory. But when the MIT Lab approached them, neither entity was interested. The Air Force was getting out of the space business, and JPL had plans to operate their own planetary spacecraft, doing navigation from the large Goldstone communication dish in the Mojave Desert. The 26-meter radar dish had been constructed for tracking the early robotic Pioneer probes.  

Both the Air Force and JPL suggested the Lab talk to people at the newly formed NASA organization.

Lab members visited Hugh Dryden, the Deputy Administrator of NASA in Washington D.C., and Robert Chilton, who was leading NASA’s Flight Dynamics Branch at the Langley Research Center. Both men thought the Lab had done some very fine work on the design, especially on the guidance computer. NASA decided to give the Lab $50,000 to continue their studies on the concept. 

Later, a meeting was set up between the Lab’s leader, Dr. Charles Stark Draper and other NASA leaders to discuss the various long-range plans NASA had in mind, and how the Lab’s designs might fit into a spacecraft piloted by humans. After several meetings, it was determined the system should consist of a general-purpose digital computer with controls and displays for the astronauts, a space sextant, an inertial guidance unit with gyros and accelerometers, and all the supporting electronics. In all these discussions, everyone agreed the astronaut should play a role in operating the spacecraft and not just be along for the ride. And all the NASA people especially liked the self-contained navigation capability, since there was fear the Soviet Union could interfere with communications between a U.S. spacecraft and the ground, endangering the mission and the lives of the astronauts.   

But then, Project Apollo was born. President John F. Kennedy challenged NASA in April of 1961 to land on the Moon and return safely to Earth — all before the end of the decade.  Just eleven weeks later, in August 1961, the first prime contract for Apollo was signed with the MIT Instrumentation Laboratory to build the guidance and navigation system.

“We had a contract,” said Dick Battin, an engineer at the Lab who had been part of the Mars Probe design team, “but … we had no idea how we were going to do this job, other than to try model it after our Mars probe.”

Part of the lore of the Apollo Guidance Computer (AGC) is that some of the specifications listed in the Lab’s 11-page proposal were basically pulled out of thin air by Doc Draper. For lack of better numbers – and knowing it would need to fit inside a spacecraft — he said it would weigh 100 pounds, be 1 cubic foot in size, and use less than 100 watts of power.

But at that time, very few specs were known about any of the other Apollo components or spacecraft, as no other contracts had been let, and NASA hadn’t yet decided on its method (direct ascent, Earth Orbit Rendezvous, or Lunar Orbit Rendezvous ) and the types of spacecraft to get to the Moon. 

“We said, ‘We don’t know what the job is, but this is the computer we have, and we’ll work on it, we’ll try to expand it, we’ll do all that we can,’” Battin said. “But it was the only computer that anybody has in the country that could possibly do this job…whatever this job might be.”

Battin recalled how at first, the option for flying to the Moon was going to be Earth orbit rendezvous, where the various parts of the spacecraft would be launched from Earth and combined in Earth orbit and fly to the Moon and land there as a whole. But eventually, the lunar orbit rendezvous concept won out — where the lander would separate from the Command Module and land on the Moon.

“So when that came about, then the question was…do we need a whole new and different guidance system for the Lunar Module than we have for the Command Module?” Battin said. “What are we going to do about that? We convinced NASA to use the same [computer] system in both spacecraft. They have different missions, but we could put a duplicate system in the lunar module. So that’s what we did.”

The early conceptual work on the Apollo Guidance Computer (AGC) proceeded rapidly, with Battin and his cohorts Milt Trageser, Hal Laning, David Hoag and Eldon Hall working out the overall configuration for guidance, navigation and control.

Guidance meant directing the movement of a craft, while navigation referred to determining present position as accurately as possible, in relation to a future destination. Control referred to directing the vehicle’s movements, and in space the directions related to its attitude (yaw, pitch, and roll) or velocity (speed and direction). MIT’s expertise centered on guidance and navigation, while NASA engineers – especially those who had experience working on Project Mercury — emphasized guidance and control. So, the two entities worked together to create the maneuvers that would be required based on data from the gyros and accelerometers and how to make the maneuvers part of the computer and software.

For the MIT Instrumentation Lab, one big worry about the Apollo Guidance Computer was reliability.  The computer would be the brains of the spacecraft, but what if it failed? Since redundancy was a known solution to the basic reliability problem, people at The Lab suggested including two computers on board, with one as a backup. But North American Aviation — the company building the Apollo Command and Service Modules — was having their own troubles meeting weight requirements. North American quickly balked at the size and space requirements of two computers, and NASA agreed.

Another idea for increased reliability included having spare circuit boards and other modules onboard the spacecraft so the astronauts could do “in-flight maintenance,” replacing defective parts during while in space. But the idea of an astronaut pulling open a compartment or floorboard, hunting for a defective module, and inserting a spare circuit board while on approach to the Moon seemed preposterous — even though this option was strongly considered for quite some time.

“We said, ‘we’re just going to make this computer reliable,'” Battin recalled. “Today, you’d be thrown out of the program if you said you’re going to build it so that it doesn’t fail. But that’s what we did.”

By the fall of 1964, The Lab started designing their upgraded version of the AGC, mainly to take advantage of improved technology. One of the most challenging aspects of the Apollo mission was the amount of real-time computing required to navigate the spacecraft to the Moon and back. When the engineers at the Lab first began their work on the project, computers were still relying on analog technology. Analog computers were not fast, or reliable enough for a mission to the Moon.

Integrated circuits, which had just been invented in 1959, were now more capable, reliable and smaller; they could replace the earlier designs using core transistor circuits, taking up about 40 percent less space. As quickly as technology had advanced since MIT won the AGC contract in 1961, they felt confident the lead time until Apollo’s first flight would allow greater advances in reliability, and hopefully reductions in cost.  With that decision, the AGC became one of the first computers to use integrated circuits, and soon, over two-thirds of the total U.S. output of microcircuits was being used for building Apollo computer prototypes. 

Lead image caption: An early integrated circuit, known as the Fairchild 4500a integrated circuit. Image courtesy: Draper.

Even though many design elements for the computer hardware began falling into place, a nagging issue by the mid-1960’s became obvious: memory.  The original design, based on the Mars Probe, had just 4 kilobytes words of fixed memory and 256 words of erasable. As NASA added more aspects to the Apollo program, the memory requirements kept rising, to 10 K, then 12, 16, 24 and finally to 36 Kilobytes of fixed memory and 2 K of erasable.

The system the Lab devised was called core rope memory, with software being carefully created with nickel alloy wire woven through the tiny magnetic ‘donuts’ to create the non-erasable memory. In the language of computer ones and zeros, if it was a one, it ran through the donut; if it was a zero, the wire ran around it. For one memory component, it took bundles of a half a mile of wire woven through 512 magnetic cores. One module could store over 65,000 pieces of information.

Battin called the process for constructing the core-rope memory the LOL method.

“Little Old Ladies,” he said. “Women in the Raytheon factory would literally weave the software into this core-rope memory.”

While women primarily performed the weaving, they weren’t necessarily old. Raytheon employed many former textile workers, adept at weaving, who needed to follow detailed instructions to weave the wires.

When the core-rope memories were first being built, the process was quite labor intensive: two women would sit across from each other they would weave by hand a stream of wires through tiny magnetic cores, pushing a probe with the wire attached from one side to the other. By 1965, a more mechanical method of weaving the wires was implemented, again, based on textile machines used in New England’s weaving industry. But still, the process was extremely slow, and one program could take several weeks or even months to weave, with more time needed to test it. Any errors in the weaving meant it would have to be redone. The Command Module computer contained six sets of core-rope modules, while the Lunar Module computer held seven.

In total, there were approximately 30,000 parts in the computer. Each component would be put through an electrical test and a stress test. Any failure called for rejection of the component. 

“Even though the memory was reliable,” Battin said, “the thing NASA didn’t like about it is was the fact that very early on you needed to decide what the computer program was going to be. They asked us, ‘What if we had a last-minute change?’ And we said we can’t have last-minute changes, and anytime you want to change the memory, means a six-week slippage, minimum. When NASA said that was intolerable, we told them, “Well, that’s the way this computer is, and there isn’t any other computer like it that you can use.”

While designing and building all the hardware posed challenges, as work progressed on the AGC through 1965 and into 1966, the magnitude and complexity of another aspect stood out: programming the software. It became the major defining problem of the computer, in meeting both timelines and specifications.

All programming was basically done at the ones and zeros level, assembly language programming. In designing the software to conduct complicated tasks, the software engineers needed to come up with ingenious ways to fit the code within the memory constraints. And of course, none of this had ever been done before, at least not to this level of scale and complexity. At any given time, the AGC might have to coordinate several tasks at once: taking readings from the radar, calculating trajectory, performing error corrections on the gyros, determining which thrusters should be fired, as well as transmitting data to NASA’s ground stations and taking new inputs from the astronauts.

Hal Laning devised what he called an executive program, which assigned tasks different priorities and allowed high-priority tasks to be done before low-priority ones. The computer could allocate memory among different tasks, and keep track of where a task had been interrupted.

The Lab’s software team, began intentionally designing the software with a priority scheduling capability that could identify the most important commands and allow those to run without interruption from less important commands.

However, by the fall of 1965, it became obvious to NASA the Apollo computer was in serious trouble, as the development of the programs was significantly behind schedule. The fact that a relatively unknown quantity called ‘software’ could delay the entire Apollo program was not well received by NASA.

Next: Part 3, figuring it all out.

You can read more stories of Apollo — including the MIT Instrumentation Lab team — in Nancy Atkinson’s new book, “Eight Years to the Moon: The History of the Apollo Missions.”

See more images from the MIT Instrumentation Laboratory, now known as Draper, at their special “Hack The Moon” website for the Apollo 50th anniversary.