Klumpp (1974): Apollo Lunar Descent Guidance

Source

Klumpp, Allan R., “Apollo Lunar Descent Guidance,” Automatica, Vol. 10, 1974, pp. 133-146. Jet Propulsion Laboratory, California Institute of Technology.

Download PDF

Eyles wrote the code. Klumpp designed the algorithm the code implements. Where Eyles describes what it was like to program P63, P64, and P66, Klumpp derives the mathematics that those programs evaluate every two seconds during powered descent — the polynomial guidance law that turned navigation state vectors into throttle and attitude commands. This paper completes a chain: Hoag defined the system, Battin designed the navigation, Klumpp designed the guidance, and Eyles wrote the flight software.

Klumpp was at JPL, not MIT. The guidance algorithm was a JPL contribution to a system designed and built at MIT’s Instrumentation Laboratory. The paper was published in Automatica in 1974, after the final Apollo landing, making it a description of the algorithm as it actually flew rather than a pre-flight proposal.

The Problem

Bring the Lunar Module from perilune — approximately 50,000 feet altitude, 5,560 ft/s horizontal velocity — to a hover above a specified landing site on the lunar surface. One engine, throttleable between approximately 10% and 60% of rated thrust, or above approximately 92% (a dead band exists between 57% and 92% where throttle response is nonlinear and therefore avoided). A 2-second guidance computer cycle. Approximately 18,000 lbs of propellant, of which roughly 90% is consumed during braking. Touchdown fuel margin: 30 to 60 seconds of hover time.

The descent trajectory covers about 250 nautical miles of ground track and takes approximately 12 minutes from powered descent initiation to touchdown.

The Polynomial Guidance Law

Klumpp’s central contribution is a guidance law where the commanded thrust acceleration is expressed as a polynomial in time-to-go ($t_{go}$):

$\mathbf{a}_c(t) = \sum_{n=0}^{N} \mathbf{a}_n \cdot t_{go}^{\,n}$

The coefficients $\mathbf{a}_n$ are computed at each 2-second guidance cycle from the current state ($\mathbf{r}$, $\mathbf{v}$) and the target state ($\mathbf{r}_T$, $\mathbf{v}_T$), subject to boundary conditions that ensure the LM arrives at the target with the correct position and velocity.

For the simplest case (position and velocity targets only), the commanded acceleration reduces to:

$\mathbf{a}_c = \frac{6}{t_{go}^2}\left(\mathbf{r}_T - \mathbf{r} - \mathbf{v} \cdot t_{go}\right) + \frac{2}{t_{go}}\left(\mathbf{v}_T - \mathbf{v}\right) + \mathbf{g}$

where $\mathbf{g}$ is the local gravitational acceleration. This is a linear guidance law — the acceleration command varies linearly with time-to-go. It approximates the fuel-optimal gravity-turn trajectory while remaining computable within the AGC’s 2-second cycle.

The polynomial form has a property that made it attractive for the AGC: the same algorithm structure serves all three descent phases. Changing the polynomial order and target conditions adapts the algorithm from fuel-optimal braking to terrain-avoidance approach to rate-commanded landing, without changing the core computational loop.

Why Polynomials

More sophisticated optimal control formulations (Pontryagin’s maximum principle, numerical trajectory optimization) would have been computationally intractable on the AGC. The polynomial guidance law is an explicit closed-form solution — evaluate a formula, get a thrust command. No iteration, no numerical integration, no convergence checking. Klumpp designed the algorithm for the machine that would run it, not for an idealized computer.

Three Phases, One Algorithm

Braking (P63)

The braking phase removes most of the orbital velocity. The engine runs at maximum thrust (approximately 9,900 lbf) for the majority of this phase, following a trajectory close to the fuel-optimal gravity turn. The guidance law operates in its lowest-order mode, minimizing fuel consumption.

At a computed point — roughly 7,000 feet altitude — the engine throttles down. This throttle-down event serves as a critical verification: if it occurs at the predicted time, the guidance solution is tracking reality. During Apollo 11, Eyles describes throttle-down arriving “on schedule” as a confidence builder for the flight controllers. That was Klumpp’s algorithm confirming its own accuracy.

The LM flies face-down during braking, with the engine pointing against the velocity vector. The crew cannot see the surface. Navigation comes entirely from the IMU and the landing radar (which begins providing altitude and velocity data at approximately 25,000 feet).

Approach (P64)

At high gate (approximately 7,000 feet), the guidance transitions to the approach phase. The polynomial order increases, providing trajectory shaping authority that the braking phase deliberately sacrificed for fuel efficiency.

The LM pitches upright so the commander can see the landing site through the forward window. The Landing Point Designator (LPD) — an angle scale etched on the window glass — shows where the computer’s current trajectory targets. The commander reads the LPD angle and assesses the terrain.

If the target is in a boulder field, a crater, or otherwise unsuitable, the commander redesignates using the hand controller. Each input shifts the target point by a fixed increment — approximately 2 degrees of LPD angle per click. Klumpp’s guidance law handles this smoothly: only the target state $\mathbf{r}_T$ changes. The polynomial coefficients are recomputed at the next 2-second cycle, and the commanded acceleration adjusts without discontinuity.

This is what Armstrong did during Apollo 11 — he redesignated away from the boulder field west of the original target and flew the LM to a clear area. The guidance computer followed his redesignations, recomputing the trajectory each cycle while Armstrong assessed the terrain through the window.

Landing (P66)

Below approximately 500 feet, the commander transitions to P66 — rate-of-descent mode. Each click of the hand controller changes the commanded vertical descent rate by 1 ft/s. The guidance computer holds attitude and maintains horizontal velocity; the commander controls only the vertical rate.

P66 is not a polynomial guidance mode. It is a separate rate-command/attitude-hold controller. The transition from P64 to P66 is crew-initiated — the commander presses the PROCEED button on the DSKY when satisfied with the approach trajectory and ready to take manual control of the descent rate.

The Throttle Dead Band

The DPS engine could not be throttled continuously. Between approximately 57% and 92% of rated thrust, the engine response was nonlinear and unpredictable. Klumpp’s guidance design avoided this region entirely — the engine operated either above 92% (braking) or below 57% (approach and landing). The throttle-down at high gate was not merely a verification point; it was a mandatory transition across the dead band to reach the controllable low-thrust regime. This hardware constraint shaped the entire mission profile.

Time-to-Go

The guidance law requires $t_{go}$ — the time remaining until the target state is reached. This is not directly measurable. Klumpp describes an iterative estimation scheme:

1. Estimate $t_{go}$ from range-to-go divided by average velocity
2. Compute the guidance solution using this estimate
3. Refine $t_{go}$ using the resulting trajectory
4. Repeat until convergence

The iteration converges within the 2-second guidance cycle. The converged $t_{go}$ is used for the current cycle’s thrust command, and the process repeats at the next cycle with updated navigation data.

Getting $t_{go}$ wrong has immediate consequences: too short an estimate means the guidance demands excessive thrust (trying to arrive sooner than physically possible), and too long an estimate means the guidance commands insufficient thrust (the LM arrives late and high). The iterative scheme keeps $t_{go}$ accurate to within the guidance cycle precision.

Gravity and the Engine

Two implementation details are worth noting.

Gravity compensation is explicit. The gravitational acceleration $\mathbf{g}$ appears directly in the guidance equation. The AGC computes the local gravity vector at each cycle and includes it in the acceleration command. This is necessary because the 2-second guidance cycle is too slow for implicit gravity compensation through feedback — accumulated gravity errors between cycles would degrade the trajectory.

Engine lag matters. The guidance command is a desired acceleration vector. Converting it to throttle and attitude commands requires a model of the engine’s response. The ICD specified a 0.3-second lag; the actual engine had approximately 0.075 seconds. Eyles describes the consequences of this mismatch — the software overcompensated for a lag that barely existed, and by accident this produced acceptable behavior. Klumpp’s guidance law assumed the engine would respond as specified. It did not, and the system worked anyway.

Fuel Optimality

Klumpp demonstrates that the polynomial guidance law approaches the fuel-optimal solution as the polynomial order decreases. The lowest-order solution (linear acceleration with time) corresponds to a gravity-turn trajectory, which minimizes fuel consumption for a given initial and final state.

The braking phase uses this near-optimal mode. The approach and landing phases sacrifice fuel efficiency for trajectory shaping — the ability to target a specific landing point, accept redesignation inputs, and provide the crew with visual contact. This tradeoff is quantified: the approach phase consumes roughly 10% of the total propellant while covering only a fraction of the deceleration. The extra fuel buys crew visibility and landing site selection authority.

With a total fuel margin of 30-60 seconds at touchdown, the fuel efficiency of the braking phase was not an academic concern. Every pound of propellant saved during braking was available for redesignation, hover, and the final manual landing.

What This Paper Teaches

Klumpp’s paper is the mathematical counterpart to Eyles’ operational account. Together they form the complete description of Apollo lunar descent: the algorithm design and the flight software implementation. Reading them side by side reveals the distance between a guidance equation on paper and a 36,864-word program in core rope that evaluates that equation while an astronaut looks out the window at boulders.

The most striking feature of the polynomial guidance law is how much it was shaped by what it could not do. It could not iterate to convergence (the AGC had 2 seconds per cycle). It could not command arbitrary thrust levels (the engine had a dead band). It could not compensate for gravity implicitly (the cycle was too slow). It could not afford to waste fuel (the margins were 30 seconds). Each constraint narrowed the design space, and what remained was a polynomial in time-to-go — a closed-form expression that the AGC could evaluate, the engine could follow, and the crew could override.

---

Eyles (2004): Tales from the LM Guidance Computer The programmer who coded P63/P64/P66 -- the implementation of Klumpp's guidance algorithm

Hoag (1963): Apollo G&N Architecture The system architecture within which the descent guidance operated

Hopkins, Alonso & Blair-Smith (1963): AGC Architecture The computer that evaluated the polynomial guidance law every 2 seconds

Space Software Engineering Collection overview and document inventory