Case Study: Anatomy of a GN&C Loop — Apollo 11's Powered Descent

"Program alarm. It's a 1202." — Neil Armstrong, during the descent of Eagle, 20 July 1969

Executive Summary

The twelve minutes of Apollo 11's powered descent to the lunar surface are the most scrutinized guidance, navigation, and control sequence in history — and a perfect specimen, because in that single flight every box of this chapter's loop is visible, was tested to its limit, and (twice) nearly failed. In this case study we take the descent apart along the lines of §27.1: we watch navigation fuse the inertial platform with the landing radar (a Kalman-style update we compute by hand), guidance command the throttle and attitude to fly the targeted trajectory, and control hold the vehicle against the disturbances — and then we examine the famous 1202 program alarm as a story about autonomy and the priority-scheduled robustness that let the loop keep flying when its computer was overloaded. The numbers here are approximate and widely reported (Tier 2); a few are illustrative round figures (Tier 3) chosen to make the arithmetic legible. The point is not the exact digits but the anatomy: how a real closed loop flew two men to the Moon, and why it was built to survive its own worst moment.

Skills applied

  • Reading a real flight as the GN&C loop of §27.1 (sense → estimate → decide → actuate).
  • Computing a landing-radar navigation update with the scalar Kalman filter (§27.2, from Chapter 13).
  • Relating targeted descent guidance and throttle control to §27.3–27.4.
  • Analyzing autonomy and computer robustness from light-time and processor loading (§27.6).

Background

Eagle, the Apollo 11 Lunar Module, separated from the Command Module in lunar orbit and coasted down to a perilune of roughly $15\ \text{km}$ ($50{,}000\ \text{ft}$). There, over the far side's terminator, it lit its throttleable Descent Propulsion System (DPS) for powered descent — beginning at about $1{,}700\ \text{m/s}$ of horizontal velocity and ending, twelve minutes later, at a dead stop on the surface. Flying it was the Apollo Guidance Computer (AGC), a machine with about $2\ \text{KB}$ of erasable memory and a $36\ \text{KB}$ rope-core program store, running the descent programs P63 (braking), P64 (approach), and P66 (manual-assisted landing). Every element of the GN&C loop ran in that computer, in real time, a quarter-million miles from the nearest engineer.

Phase 1: Navigation — the inertial platform, corrected by radar

The AGC's primary navigator was an inertial measurement unit (IMU): a gyro-stabilized platform and accelerometers that dead-reckoned Eagle's state forward from a known starting point, integrating acceleration to velocity and position exactly as §27.2 describes. And exactly as §27.2 warns, that estimate drifted — small accelerometer and alignment errors accumulated over the descent into a position error of hundreds, then thousands, of feet. The IMU alone would have landed Eagle over a kilometre from where it thought it was.

The fix was an absolute sensor: the landing radar, which measured true altitude and velocity relative to the surface. When it acquired the ground at around $12{,}000\ \text{m}$, its reading disagreed with the IMU's dead-reckoned altitude — and the AGC blended the two through a Kalman-style update rather than trusting either blindly. Let us compute one such update with the scalar filter of §27.2.

Suppose the IMU-propagated (predicted) altitude is $\hat{x}^- = 12{,}500\ \text{m}$ with an accumulated uncertainty of $\sigma_{\text{pred}} = 300\ \text{m}$ (variance $90{,}000\ \text{m}^2$), and the landing radar reports $z = 12{,}100\ \text{m}$ with $\sigma_{\text{meas}} = 100\ \text{m}$ (variance $10{,}000\ \text{m}^2$). The gain is

$$ K = \frac{90{,}000}{90{,}000 + 10{,}000} = 0.9, $$

so the filter trusts the sharper radar nine-tenths of the way. The corrected altitude is

$$ \hat{x}^+ = 12{,}500 + 0.9\,(12{,}100 - 12{,}500) = 12{,}500 - 360 = 12{,}140\ \text{m}, $$

with updated uncertainty $(\sigma^+)^2 = (1 - 0.9)(90{,}000) = 9{,}000\ \text{m}^2$, i.e. $\sigma^+ = 94.9\ \text{m}$ — sharper than either input, the inverse-variance miracle of §13.6. Sanity check: the correction moved the estimate $360\ \text{m}$ toward the radar and cut the uncertainty from $300$ to $95\ \text{m}$; a few such updates per second drove the drifted inertial state back onto the truth. On the real flight the crew were asked to accept the radar update ("the LR data is good"), and once they did, the navigation was trustworthy enough to land. (Specific values here are illustrative — Tier 3 — but the mechanism and the magnitudes are faithful.)

🔗 Connection: This is precisely the IMU-plus-absolute-sensor architecture of §27.2 and §14.4 — a fast, drifting inertial estimate reset by a slow, absolute measurement — and the blend is the Kalman filter that Chapter 13 built. Apollo flew one of its earliest operational uses.

Phase 2: Guidance — throttle and steering to a target

With a trustworthy state, guidance decided the path. The descent used an explicit, targeted guidance law (a close cousin of the powered explicit guidance of §27.3): each cycle it computed the thrust magnitude and direction needed to fly from the current state to a target state — a chosen point above the landing site, at a chosen velocity and time — and commanded the throttle and attitude accordingly. This is why the DPS was throttleable (a genuine engineering feat for a rocket engine): closed-loop guidance needs to modulate thrust to track its target, not merely switch on and off.

A single deceleration number shows the scale. To null $1{,}700\ \text{m/s}$ of horizontal velocity over the roughly $600\ \text{s}$ braking phase requires an average deceleration of

$$ \bar a = \frac{1{,}700\ \text{m/s}}{600\ \text{s}} \approx 2.8\ \text{m/s}^2, $$

a little under twice lunar gravity ($g_{\text{Moon}} \approx 1.62\ \text{m/s}^2$) — modest, because the Moon is a gentle place to land. Sanity check: the DPS produced up to about $45\ \text{kN}$ against a descent-stage mass falling from roughly $15{,}000\ \text{kg}$ toward $7{,}000\ \text{kg}$, giving thrust accelerations of order $3$–$6\ \text{m/s}^2$ — comfortably above the $2.8$ the average braking demanded, with margin to throttle and steer. Guidance spent that margin flying the target trajectory.

Phase 3: Control — the digital autopilot holds the vehicle

Guidance said where to point and how hard to burn; control made it happen. The AGC's Digital Autopilot (DAP) held Eagle's attitude with the reaction control system (RCS) thrusters (Chapter 14), firing them in a feedback loop to keep the actual attitude on the commanded attitude despite the shifting center of mass, propellant slosh, and the torque of an off-axis descent engine — the disturbance-rejection job of §27.4. The throttle command likewise closed a loop on the guidance's demanded thrust. Fast inner control loops, slower outer guidance loop: the nested architecture of §27.5, running in $2\ \text{KB}$ of memory.

Phase 4: Autonomy and the 1202 alarm

Here is where the descent nearly came apart, and where the design philosophy of §27.6 earned the mission. The Moon is close by spaceflight standards — light-time is only

$$ t_{\text{one-way}} = \frac{384{,}400\ \text{km}}{3.0\times10^{5}\ \text{km/s}} \approx 1.28\ \text{s}, $$

a round trip of about $2.56\ \text{s}$. That is short enough for the ground to sit in the slow loop — Mission Control made the periodic GO/NO-GO calls — but far too slow for the fast control loop, which needed to correct attitude many times a second. So the fast loop had to be autonomous, onboard, in the AGC. And during the descent, the AGC cried for help.

At about $12{,}000\ \text{m}$, Eagle's computer flashed a 1202 program alarm, then more, then a 1201. Both meant the same thing: the computer was overloaded — it had more work queued than it could finish in a cycle and was running out of the memory areas it needed to hold tasks. The cause, diagnosed later, was that the rendezvous radar had been left in a configuration that flooded the AGC with spurious interrupts, stealing an estimated $13\%$ or more of its processing cycles for work the landing did not need.

A crude duty-cycle picture makes the danger concrete. Suppose the essential guidance, navigation, and control tasks consumed about $85\%$ of the AGC's capacity in nominal descent. Add the radar's stolen $\sim 13\%$–$15\%$ and the demand exceeds $100\%$:

$$ 85\% + 15\% = 100\%\text{-plus} \;\Rightarrow\; \text{the computer cannot finish everything in one cycle.} $$

On an ordinary computer, "more work than time" means the whole program hangs or crashes — and a crash of the descent guidance, with no time for the $2.56\ \text{s}$-away ground to intervene, would have been fatal. But the AGC was built by the MIT Instrumentation Laboratory around a priority-scheduled executive that did something smarter: when overloaded, it shed the lowest-priority tasks and restarted, protecting the high-priority guidance, navigation, and control jobs. The 1202 was not a failure; it was the computer announcing that it was triaging — dropping the inessential to keep flying the essential. Guidance never stopped. In Mission Control, the 26-year-old guidance officer Steve Bales and back-room expert Jack Garman recognized within seconds that as long as the alarms were intermittent and guidance data stayed good, the landing was safe, and called "GO." Eagle flew on.

🔧 Engineering Reality: graceful degradation is a design choice, not luck. The 1202 survival was engineered years earlier, when the AGC's designers decided the executive would prioritize and restart rather than run every task to completion or die trying. That single architectural decision — protect the control loop above all, shed everything else — is the essence of autonomous robustness (§27.6). A vehicle that must fly itself cannot assume its computer will never be overloaded; it must be built to keep the loop closed even when it is. Apollo 11 is the canonical proof that how a system fails is as much a GN&C design problem as how it flies.

Phase 5: The human closes the loop

At about $150\ \text{m}$, entering program P64/P66, Armstrong saw the automatic guidance was steering Eagle toward a boulder field around a sharp-rimmed crater. He took semi-manual control — commanding attitude and rate-of-descent while the computer still managed throttle and the inner loops — and flew horizontally to a smoother spot. This too is the GN&C loop: a human inserted as the guidance box, closing the loop with his eyes and hands while the machine kept navigation and inner control. He landed with the propellant nearly gone — famously seconds of margin on the low-level warning — but he landed. The loop, part silicon and part human, held to the end.

Discussion Questions

  1. Identify, for each of the four boxes (navigation, guidance, control) plus autonomy, the specific Apollo hardware or software that played it during the descent.
  2. The landing-radar update moved the altitude estimate $360\ \text{m}$ and cut its uncertainty from $300$ to $95\ \text{m}$. Explain, using the Kalman gain, why the filter trusted the radar so heavily — and what would have changed if the radar had been noisier than the IMU.
  3. The Moon's $2.56\ \text{s}$ round-trip light-time let the ground make GO/NO-GO calls but not fly the control loop. Contrast this with a Mars landing (§27.6). Where is the boundary, in light-time, between "ground can supervise" and "must be fully autonomous"?
  4. Was the 1202 alarm a failure of the computer or a success of its design? Argue both sides, then take a position.

Your Turn: Extensions

  • Option A (analysis). Redo the Phase 1 navigation update assuming the IMU had drifted less ($\sigma_{\text{pred}} = 120\ \text{m}$) than the radar's noise ($\sigma_{\text{meas}} = 100\ \text{m}$). Compute the new gain and updated estimate, and comment on how the filter's "trust" shifts. (Do the arithmetic by hand and check $\sigma^+$ is below both inputs.)
  • Option B (computation). Write a short Python function that takes the AGC's nominal task load and a stolen-cycle fraction and reports whether the processor is overloaded and by how much. Trace it for $85\%$ nominal and a $15\%$ radar theft. (Do not run it; add # Expected output:.)
  • Option C (design). Propose a modern fix for the 1202 root cause (spurious radar interrupts). Would you add processing margin, change the interrupt handling, or forbid the offending switch configuration? Argue which best serves autonomous robustness.

Key Takeaways

  1. A real flight is the loop of §27.1 made physical. Apollo 11's descent shows navigation (IMU + radar), guidance (targeted throttle/steering), and control (the digital autopilot) running as one onboard system.
  2. Absolute sensors rescue a drifting inertial navigator. The landing-radar Kalman update pulled a thousands-of-feet IMU drift back to the truth — the §27.2 architecture, flown for real.
  3. Autonomy is forced by light-time, and robustness is designed in. At $2.56\ \text{s}$ round trip the ground could supervise but not fly the fast loop; the priority-scheduled AGC kept guidance alive through the 1202 overload because it was built to shed the inessential.
  4. The human is a loop element. Armstrong took the guidance box himself to dodge the boulders — feedback control with a person in it, the oldest autonomy of all.