P20 and P22: How the AGC Tracked a Target Across Lunar Orbit

Two spacecraft are orbiting the Moon at 5,300 feet per second, roughly 60 nautical miles above the surface. One is the Command Module, carrying one astronaut and the only heat shield that will get anyone home. The other is the Lunar Module ascent stage, carrying two astronauts who just left the Moon’s surface. They are separated by dozens of miles and the gap is changing constantly—both vehicles are in slightly different orbits, each following its own curved path through the Moon’s gravitational field. The LM needs to close that gap, match orbits with the CM, and dock—all without ground-based radar tracking, because the Moon blocks the line of sight to Earth for half of every orbit.

The software that solved this problem was P20—Rendezvous Navigation. It ran in both computers, Colossus and Luminary, using different sensors but the same mathematical framework. P20 tracked the other vehicle, maintained a state vector for it, and computed the maneuver solutions that would bring the two spacecraft together. It was supported by P22 (Lunar Surface Navigation in the CM) for tracking the LM while it was on the ground, and by a suite of targeting programs (P32, P33, P34, P35) that computed the specific burns needed at each phase of the rendezvous sequence. Together, they represented one of the most complex real-time navigation problems ever solved by an onboard computer.

The Rendezvous Problem

Orbital rendezvous is not intuitive. You cannot point at a target and thrust toward it—doing so changes your orbit in ways that may move you further away, not closer. The physics of orbital mechanics means that speeding up raises your orbit and slows you down relative to a target in a lower orbit. Slowing down drops your orbit and speeds you up relative to a target in a higher orbit. Every maneuver affects your trajectory globally, not just locally.

Apollo’s rendezvous sequence was designed by Buzz Aldrin (whose MIT doctoral thesis was literally about orbital rendezvous techniques) and refined by the Mission Planning and Analysis Division at the Manned Spacecraft Center. The standard approach used a series of phased burns:

Coelliptic Sequence Initiation (CSI): A burn by the LM to adjust its orbit so that a specific geometric relationship existed between the two orbits—specifically, making the two orbits coelliptic (having the same shape but at different altitudes), which simplified the subsequent targeting.

Constant Delta Height (CDH): A burn to establish a constant altitude difference between the two vehicles. This placed the LM on a predictable trajectory below and behind the CM.

Terminal Phase Initiation (TPI): The burn that began the final approach. TPI was targeted so that the LM’s trajectory would intercept the CM’s orbit at a specific transfer angle (typically 130 degrees of orbital travel later). The TPI burn time was chosen so that the line-of-sight angle from the LM to the CM was at a specific elevation above the local horizontal—about 26.6 degrees for the standard Apollo rendezvous profile.

Terminal Phase Midcourse Corrections (TPM): Small correction burns during the transfer orbit to adjust for targeting errors and measurement uncertainties.

Braking: The final deceleration burns as the LM closed the last few hundred feet to the CM, reducing the closing velocity to near zero for docking.

Each of these burns required precise targeting, which required precise knowledge of both vehicles’ orbits, which required the navigation sensors and the P20 software.

Sensors: Radar and Optics

The two vehicles used fundamentally different sensors to track each other, and this difference shaped the P20 implementations in Colossus and Luminary.

The LM’s Rendezvous Radar: The Lunar Module carried a dedicated rendezvous radar system that tracked a transponder mounted on the Command Module. The radar emitted microwave pulses; the CM’s transponder received them and transmitted an amplified reply. The LM radar measured four quantities from the returned signal: range (distance to the CM), range rate (the rate at which the distance was changing), and two angle coordinates (shaft and trunnion) that defined the radar’s pointing direction and thus the line-of-sight direction to the CM.

These were direct measurements. Range was measured to an accuracy of about 50 feet at typical rendezvous distances. Range rate was measured to about 1 foot per second. The angles were accurate to roughly 0.5 degrees. The radar could acquire and track the CM’s transponder at ranges up to about 400 nautical miles—far more than any rendezvous scenario required.

The radar data was rich. Each measurement gave four independent pieces of information about the relative state of the two vehicles. P20 in Luminary processed this data through a weighted least-squares estimation filter (a variant of the Kalman filter) to maintain and continuously refine the CM’s state vector as seen from the LM.

The CM’s Sextant: The Command Module had no rendezvous radar. Its tracking sensor was the same sextant used for star sightings during P52—a 28-power optical instrument operated by the CMP. To track the LM, the CMP looked through the sextant, found the LM (visible as a bright point against the dark sky or the lunar surface), and pressed the MARK button to record the line-of-sight angles. Each mark provided two pieces of information: the shaft and trunnion angles of the sextant at the moment of the mark.

Optical tracking was less data-rich than radar. A sextant mark gave only a direction—a unit vector from the CM to the LM—with no range or range-rate information. The navigation filter in Colossus had to extract range information indirectly, by processing multiple marks taken over time and using the changing line-of-sight direction to triangulate the target’s orbit. This required more marks and more time to converge on an accurate state vector than the LM’s radar solution.

The CM also had a VHF ranging system that measured the distance between the two vehicles using the travel time of VHF radio signals. VHF range data complemented the sextant angles, providing the range component that optics alone couldn’t measure. When VHF ranging was available (the system required line-of-sight between the two vehicles), it significantly improved the CM’s navigation solution.

When the LM crew initiated P20, Luminary began a continuous cycle of radar tracking and state vector updates. The sequence was:

Radar acquisition: The rendezvous radar antenna searched for the CM’s transponder signal. The AGC could command the antenna to a predicted pointing angle based on the current state vectors, or the antenna could be placed in automatic search mode to sweep until it acquired the signal. Once locked on, the radar tracked the CM continuously, providing updated range, range rate, and angle data.

Data acceptance: P20 displayed the radar data to the crew on the DSKY—range, range rate, and the bearing angles. The crew evaluated the data for reasonableness. Wild data points (caused by multipath reflections off the lunar surface, for instance) could be rejected by the crew before they contaminated the navigation solution.

State vector update: When the crew accepted a data point (by pressing ENTER or PRO), Luminary’s navigation filter incorporated the measurement into the CM’s state vector estimate. The filter computed how much to adjust the state vector based on the measurement residual—the difference between the measured value and the value predicted by the current state vector estimate. Small residuals meant the state vector was already accurate and the adjustment was small. Large residuals indicated either a poor state vector (requiring a larger adjustment) or a bad measurement (which the crew should have rejected).

Repeat: The cycle continued, with new radar measurements refining the state vector over time. The filter’s uncertainty estimates shrank as more data was incorporated, converging toward the true state.

The radar provided measurements at roughly 1-second intervals when locked on. P20 didn’t process every measurement—the AGC didn’t have the computational bandwidth to run the filter that frequently. Instead, P20 processed measurements at a rate governed by the Executive’s scheduling, typically every few seconds, selecting the most recent radar data for each processing cycle.

The CM’s P20 was a more manual process because the sensor was a human being looking through an optical instrument rather than an automated radar system.

The CMP initiated P20, and Colossus drove the sextant to the predicted line-of-sight angle to the LM based on the current state vectors. The CMP looked through the sextant, acquired the LM visually, and used the hand controller to center the LM image on the crosshairs. When centered, the CMP pressed MARK.

Each mark recorded the sextant shaft and trunnion angles and the precise time. Colossus processed the mark through its navigation filter, updating the LM’s state vector. Multiple marks—typically 5 to 10 over a tracking pass of several minutes—built up the navigation solution. The CMP could evaluate the quality of each mark before accepting it; if the LM was hard to see or the mark felt imprecise, the CMP could reject it.

The optical navigation required skill and patience. The LM at rendezvous distances—10 to 100 nautical miles—appeared as a point of light in the 1.8-degree sextant field. Distinguishing it from stars or from reflections off debris required experience. The CMP had to maintain the sighting while the CM’s attitude control jets occasionally fired, bumping the line of sight. Each mark was a small act of precision in an environment that resisted precision.

When VHF ranging was available, Colossus incorporated the range measurement alongside the optical marks. The combination of angle data (from the sextant) and range data (from VHF) gave the filter both the direction and distance to the LM, dramatically improving convergence speed and accuracy.

Both versions of P20 used navigation filters based on the Kalman filter—the recursive estimation algorithm developed by Rudolf Kalman in 1960 that has since become the foundation of virtually all modern navigation systems, from GPS receivers to self-driving cars.

The AGC implementation was a simplified extended Kalman filter adapted for the computational constraints of the machine. The full Kalman filter requires maintaining and updating a covariance matrix—a matrix that tracks the uncertainty of every component of the state vector and the correlations between them. For a six-component state vector (three position, three velocity), the covariance matrix is 6x6, containing 36 elements (21 unique, due to symmetry). Storing and updating this matrix in double precision consumed a significant fraction of the AGC’s erasable memory.

The AGC’s navigation filter used a formulation called the W-matrix method, developed by Richard Battin and his colleagues at MIT. Instead of maintaining the full covariance matrix, the filter maintained a set of W-vectors that encoded the same information in a more compact representation. This saved erasable memory at the cost of slightly more complex computation—a trade-off that favored the AGC’s architecture, where rope memory (for the extra code) was less scarce than erasable memory (for the data).

The filter operated in a predict-update cycle:

Predict: Between measurements, the filter propagated the state vector forward using the equations of orbital motion (including lunar gravitational harmonics and, if thrusting, the engine acceleration). The uncertainty grew during propagation because the model was imperfect—gravitational perturbations, venting, and other unmodeled forces introduced small errors.

Update: When a new measurement arrived (a radar data point or an optical mark), the filter compared the actual measurement to the predicted measurement based on the current state vector. The difference—the residual—was multiplied by a gain factor (computed from the current uncertainty and the measurement noise) to produce a correction. The state vector was adjusted, and the uncertainty shrank.

The crew could see this process working by monitoring the measurement residuals displayed on the DSKY. Large residuals early in the tracking pass were normal—the initial state vector might be rough. Residuals should decrease over time as the filter converged. If residuals remained large or grew, something was wrong: the initial state vector was badly off, the sensor was malfunctioning, or the wrong target was being tracked.

P22: Tracking the LM on the Surface

While the LM was on the lunar surface, the CM continued orbiting overhead. Colossus’s P22 program allowed the CMP to track the landed LM’s position using the sextant and a technique called landmark tracking—measuring the line-of-sight direction to the LM (now a fixed point on the Moon’s surface) as the CM passed overhead.

P22 processed these sightings to refine the LM’s known position on the lunar surface and to update the CM’s own state vector. The geometry was favorable: as the CM moved along its orbit, the changing angle to the fixed LM site provided strong geometric diversity, allowing the filter to determine the LM’s coordinates with good accuracy.

This data was important for the ascent targeting. When the LM launched from the surface, Luminary needed to know the CM’s orbit precisely to compute the ascent burn that would place the LM on an intercept trajectory. The CM’s state vector, refined by P22’s tracking during the surface stay, was uplinked to the LM before launch. Similarly, the LM’s precise surface position—confirmed by P22 sightings—was used by both computers to establish the initial conditions for the rendezvous sequence.

Targeting: P32 Through P35

P20 provided the navigation—the “where are we” answer. The targeting programs computed the “what burns do we make” answer.

P32/P72 (CSI targeting): Computed the Coelliptic Sequence Initiation burn parameters for the CM/LM respectively. The program used the current state vectors of both vehicles to compute a burn that would establish the desired coelliptic orbit relationship.

P33/P73 (CDH targeting): Computed the Constant Delta Height burn, adjusting the orbit to achieve the desired altitude separation.

P34/P74 (TPI targeting): Computed the Terminal Phase Initiation burn, using an iterative algorithm to find the burn that produced the desired transfer trajectory from the current orbit to the target vehicle’s orbit. The TPI targeting was the most computationally intensive of the rendezvous programs, requiring iterative convergence on a Lambert’s problem solution—determining the orbit that connects two points in space at a specified time.

P35/P75 (TPM): Computed the midcourse correction burns during the terminal phase transfer, fine-tuning the approach trajectory.

Both vehicles computed the targeting solutions independently. Luminary computed the LM’s burns; Colossus computed what it thought the LM’s burns should be. The crew and Mission Control compared the solutions. If they agreed to within tolerance, the LM executed the burn. If they disagreed significantly, someone had a bad state vector, and the ground resolved the discrepancy before any burn was executed.

This cross-check was a fundamental safety feature of Apollo rendezvous. Two computers, using different sensors, maintaining independent state vectors, computing the same maneuver solution—if both agreed, confidence was high. If they disagreed, something was wrong, and the discrepancy would be resolved before anyone lit an engine.

When the Radar Lied: Apollo 14’s Rendezvous Anomaly

Apollo 14 tested the rendezvous navigation software under conditions that weren’t in the test plan. During the ascent from the lunar surface, the rendezvous radar had difficulty maintaining lock on the CM’s transponder. The radar signal was intermittent, and some of the range and range-rate data it provided was erratic.

Luminary’s P20 displayed the radar data to the crew, and the residuals were large and inconsistent. The navigation filter, if fed this bad data, would have corrupted the LM’s estimate of the CM’s state vector—potentially leading to an incorrect rendezvous burn. The crew and Mission Control recognized the problem and rejected the suspect measurements, relying instead on the ground’s tracking solution for the initial rendezvous burns.

As the two vehicles closed range, the radar performance improved (shorter range, stronger signal), and Luminary’s P20 began receiving clean data. The filter converged quickly, and the final terminal phase was flown using the onboard solution with full confidence. The incident demonstrated both the vulnerability of the navigation system to sensor failures and the robustness of the human-in-the-loop design—the crew’s ability to recognize bad data and reject it before it poisoned the filter was as important as the filter’s mathematical sophistication.

Closing the Gap

The final phase of every Apollo rendezvous was the braking and station-keeping sequence—the last few hundred feet, closed at a few feet per second, with the CMP in the CM watching the LM approach through the docking window. P20 continued running, refining the state vectors, but the actual piloting was manual. The CMP (or the CDR in the LM, depending on who was the active vehicle) flew the closing maneuver visually, using the relative motion of the target vehicle against the star field to judge range and closing rate.

The final docking was pure human skill—aligning the two vehicles to within 2 degrees and closing at less than 1 foot per second. The AGC had brought them from hundreds of miles apart to within visual range. The navigation filter had maintained state vectors accurate enough to compute burns precise to fractions of a foot per second. P20 had taken radar pulses and sextant marks and turned them into orbital knowledge.

But the last hundred feet were the pilot’s. The AGC had done the math. The human did the flying. And when the docking latches snapped shut and the two vehicles became one again, the rendezvous was complete—two computers, two sensor suites, two navigation solutions, two vehicles, converging on the same point in space above the Moon, guided by software that turned raw measurements into the orbital certainty that brought them together.