Apollo 11: 50 Year Anniversary

"It doesn't seem right," said one veteran of Apollo, who I won't quote directly because I didn't ask permission. He continued, "That it's been 50 years, and we're putting the blocks together, and they're mostly the same blocks."

I've heard officials in both government and at Lockheed refer to Orion as "Our Apollo," which is a name I never really liked. Because Apollo came and went and now it's history, and Orion felt too much like going through those same motions. Orion felt unimaginative. It felt like role-playing, or playing house when you're a kid. It felt like the term "Our Apollo" was more like "it's our turn" rather than "it's our chance". Maybe to other people the term is more of a call to action. Maybe they remember apollo from when they were a kid and that image sort of crystalzied into a fetish, and any chance to claim that exact moment for themselves is extremely motivating. But for me, it's not the chance I'm looking for. I want to pick up where Apollo left off, not re-watch the program.

The person I quoted above gave the following advice several times: "When you get your chance, don't screw it up."

While I grapple with the idea of what a "chance" is and try to untangle the mysteries of the space architecture decision making process, I'll present some information about what I think is the most interesting part of the Apollo architecture.

The Lunar Module

The lunar module was the first real "spacecraft" in that it was the first vehicle meant to only operate in space and not in the atmosphere. There is no heatshield, no parachutes, and no smooth aerodynamic surfaces.

Here are a bunch of pictures.

Saturn v schematic

stowed lunar lander

adapter

lunar module schematic

As-built landing gear configuration

Notice the difference between the picture of the as-built lunar lander above, and the proposed lunar lander below.

Original grumman proposal with five landng legs

Notice the five legs, Ok the rest are as-built.

Landing strut

  • homeycomb shock absorbers were partially pre-crushed prior to flight. The is because the initial force it takes to start crushing them is kind of high. At least they did this in testing. Haven't seen a reference that says they did it prior to flight, too. But considering they were concerned about the elastic/inelastic shock absorbing behavior of the system, they probably did the same thing in flight.
  • the legs have big probes that tell the commander to initiate engine shutdown. literally 5.6 feet. At this point the lunar module is probably descending at about 1 ft per second, so the commander has plenty of time to react. In the apollo 11 tapes it sounded like the engines were shut down about one or two seconds after contact was detected, and landing would have happened one or two seconds later.

Apollo 15 landing

Apollo 15 came to rest with one footpad in a crater and the other in the air, ending up with about an 11 degree tilt on the surface. 12 degrees is the limit for safe ascent.

Mission command David Scott said that, "…at the altitudes looking down as we approached the landing, it was very difficult to pick out depressions… as far as the shallow depressions there and the one in which the rear footpad finally rested, I couldn't see that they were really there. It looked like a relatively smooth surface."

landing window

Apollo 16 commander John Young commented in the mission's Technical Debrief: "I couldn't judge slope out the window worth a hoot, and that's the truth. Even down low. The ground looks flat, but I'm sure it would look flat if it had been a 6 -- 8-degree slope too. I don't see any way around that."

landing radar system

Lunar module power system

changes as a result of apollo 13

  • Capability of the LM to initiate power transfer to CSM
  • Added circuit pprotection to LM buses during power transfer
  • Capability to transfer power after LM staging
  • Added fifth descent stage battery (Lunar Battery), 12 kW (already planned for Apollo 15 and up for longer surface stays)
  • Any battery could be tied to any electrical bus

Explosive batteries and stuff

Lunar mision simulator

The LMS (LM Mission Simulator) at KSC. In the background is the command module simulator.

lunar module descent strategy

The lunar module and command and service module start together in a low lunar orbit of 100 km altitude above the surface. Then the lunar module would separate and perform a deorbit burn, which places on much smaller orbit with a closest approach to the moon of 15.24 km or 50,000 ft, but does not intersect the moon. So if something happened, they could recover without having to land first. 50,000 ft was chosen because apparently it's less efficient to target anything above that, and anything below that is too dangerous because of mountains and stuff.

The computer could only run one phase at a time, so you would have to switch from one program to another. The transitions could be either automatic or commanded by the astronauts.

The lower half had the descent propulsion system (DPS, pronounced "dips"), which was an engine that could throttle its thrust way down by varying the cross section of the injectors in the combustion chamber that release the fuel, Aerozine 50 fuel and dinitrogen tetroxide (N2O4). This variable-throttle engine was one of the major technological advances in rocket science that they knew they needed to figure out but just didn't know how to do when the program was announced. The top part of the LM had the ascent propulsion system (APS, pronounced "apps"), which was an engine that did not throttle. So I guess that was comparitively easy.

George Cherry and Allan Klumpp architected the guidance schemes. The descent guidance algorithm computed a quatratic acceleration profile which got the lunar module to touchdown at a specific spot. See, rocket science isn't that hard, you know what a quaratic profile looks like. It's just a parabola. This was an analytical solution, but it still only computed the guidance parameters once every two seconds. The computed parameters were a pointing vector and a thrust level command, which were then passed to the control system to determine how to actuate the hardware to achieve the desired state.

The thing was though that the guidance algorithm would ask for more thrust than the engine could provide.

descent thrust profile

The dotted line is the thrust magnitude as computed by the guidance algorithm. Notice that it goes up to 15,000 lbf, but the lunar descent engine could produce a maximum of 10,000 lbf of thrust.

Because the guidance equations ran only every two seconds, calculating the correct throttle was comparitively harder than it would be today with modern computers capable of doing the same in 25 milliseconds or less. Here's a passage from Don Eyles book that illustrates it.

The readings that came from our exquisite accelerometers did not actually measure acceleration, it seemed; they measured the net velocity change since the previous reading two seconds before. That was not the same thing, especially when, part way through that two second period, the actual acceleration was changed by the previous throttle command... As for mass, I looked around to see where that was being calculated -- and found to my surprise that it was not. The LM's mass at the start of the mission was known, but that was only a starting point because the spacecraft steadily became lighter as it burned fuel. Suddenly I was not just building a throttle controller, I was building a mass estimator.

There were two main languages that were used to write code for the apollo guidance computers: Interpretive and Basic. Basic is not the same as the Basic you have heard about before. It's specific to the apollot guidance computers, really closer to assembly language.

Here's something in c:

x = y + z

and here's the same thing in Basic

CA      Y       Load number at address Y into accumulator
AD      Z       Add number Z forming sum in accumulator
TS      X       Transfer result to storage at address X

The lunar descent module's software architecture was based off of two main functions, Executive and Waitlist. The Waitlist scheduled specific tasks at specific times, and Executive was for priority-based scheduling of longer jobs. These two names sound reversed to me. Anyway, a task scheduled by Waitlist, such as reading the accelerometers at a very specific time, would typically schedule a job with the Executive to to do further processing based on the measurement. Waitlist tasks were five milliseconds max and could not be interrupted. Executive jobs were long-running and could be interrupted. Jobs that needed to store memory in case of interruption would need to use a special area of memory called the vector accumulator (VAC) if they used the Interpretive language, but could just use the regular job memory area if they were scheduled through Basic. Apollo 11's 1201 errors during landing were caused by the radar taking too much of the VAC space, which only had space for five jobs.

In the case where the software tried to schedule too many jobs, the software would crash itself by intentionally attempting to execute a single-statement loop, which the computer hardware would detect and then force a reset.

WHIMPER     TC      WHIMPER     NOT WITH A BANG...

That was the original version at least. By apollo 11, it was handled entirely in software without using the hardware's instruction loop detection functionality. They considered removing the software functionality all together because it really complicated programming and testing to have to make a bunch of restart "checkpoints", but it turned out good that they did because the software restarted 5 times during Apollo 11's descent due to the landing radar. I really think they should have been able to catch that in ground testing, but maybe I'm being naive.

For the software developers and controls analysts, Apollo 11 was just the beginning. The first actual test of their system. They worked on numerous improvements after Apollo 11, new modes of autopilot guidance, major enhancements to the real-time software executive structure, guidance law improvements, and bug fixes, like for the radar system which caused several errors during Apollo 11's descent. Many of these changes never flew, because when the decision was made to end the Apollo program at Apollo 17, the management team decided to not include them in the remaining missions. Just critical fixes and a terrain model were allowed.

The guidance computer was a fixed-point machine, not a floating-point machine. That is a big difference. The programs that ran on it were printed on paper, and I think they were written in a few different languages, which were then compiled to Yul, which was printed out in a big book, and then eventually converted into magnetic tape which was then read by the little old ladies that threaded the core-rope memory. It took about six weeks to go from source code to a loadable piece of memory that you could hook up to the apollo guidance computer.

The first program to run on the lunar module for an actual mission was called SUNBURST. The SUNBURST program flown on Apollo 5 was 1284 pages long when printed out. At first it seems like having an entire program on paper and in assembly language would be the most awful thing in the world, but Don Eyles, the author of "SUNBURST and LUMINARY", says that it had one magical property. When you held in your hands that 1284 page book, you hold all the information you need in order to know what is happening on the computer. "You knew that for every riddle the listing posed, it contained an answer, if you could only follow the maze that connected them."

References

© Peter Brandt 2019 | all images in public domain unless otherwise stated