LM Descent to the Moon - Part 6 - Programming (1971)

(Apollo Lunar-Descent Guidance, 1971)

[The following MIT / NASA's 1971 text, partial reprint of the reference /0/, describes the descent algorithms used in the Apollo Lunar Module computer program (Luminary version 099/1A, about 63,000 lines of YUL assembly code) and flown summer 1969. This paper actually describes an advanced version of the algorithm which was not used since the older version which was more tested at that time (1969) was good enough for the job. What so ever, the text gives a good glance to the manned planetary descent programming.]

Figure 1. Components of the Lunar-Descent Guidance System.

APOLLO LUNAR-DESCENT GUIDANCE /0/

"Lunar-descent guidance begins with the lunar module (LM) at about 15-km altitude in a slightly elliptical coasting lunar orbit, and ends with the LM on the lunar surface.

Figure 56. MCC (Mission Control Center) in MSC (Manned Spacecraft Center, currently JSC, Johnson Space Center), Houston, Texas contained everything that was needed to control the flight of the Apollo spacecrafts during active missions, includeing the Real Time Computer Complex (RTCC) with IBM and other computers and human flight controllers in the MOCR (Mission Operations Control Room).

The guidance is performed by the onboard LM guidance computer (LGC), which takes input data and commands directly from the LM crew and via the uplink from NASA's Real Time Computation Center (RTCC) in Houston, Texas.

Figure 57. Apollo Real Time Computer Complex inside MCC (Mission Control Center) Houston, Texas, showing IBM 7094 computer, year about 1966

The crew consists of a commander and a LM pilot. (See Figure 1.) Standing on the left, the commander monitors and controls the descent using visual cues and various hand controllers and switches. Standing on the right, the LM pilot monitors the computer display, vocally relays pertinent data to the commander, and enters any necessary data into the computer via the keyboard.

Figure 58. LM PGN(C)S Installation and Related Systems.

The primary guidance mode for the lunar descent is automatic; the LGC (LM Gudance Computer, see figure 58.) controls both attitude and thrust. The commander can, temporarily or permanently, select nonautomatic guidance modes if he wishes to control, manually, attitude or thrust or both. The nonautomatic modes, not described further in this report, provide attitude and thrust references for the commander to follow if he chooses to fly the LM manually along the automatic guidance profile.

This report describes how the Apollo lunar-descent guidance works, why it was designed this way, and, in several cases, how it might have been designed differently. The concepts described can be applied to landing on any planetary body, with or without atmosphere, should man resolve to continue this adventure. The solutions presented offer ample opportunity for checking the theory. Such checks have been made, and all algorithms are known to work as conceived."

Figure 2. Lunar-descent-guidance Phases and Targets

Descent Phases

"The lunar descent is a nominally-planar trajectory consisting of three phases illustrated in Figure 2 and described as follows:

1.  The braking phase (Program 63, or P63) is initiated by keyboard entry about 10 minutes before nominal ignition time. P63 first computes the precise time and attitude for ignition. Next, at typically 492-km slant-range from the landing site, P63 ignites the DPS. Finally, P63 transfers the LM to the terminal state required as initial conditions for the succeeding approach phase. The transfer takes typically 514 seconds and is near-optimal.
2.  Approach-phase (P64) guidance begins with initial conditions consisting of, typically    a) 2.2-km altitude and 7.5-km ground range and   b) -44-m/sec vertical velocity and 129-m/sec forward velocity. In typically 146 seconds, P64 transfers the LM to a point almost directly above the landing site. P64 provides continuous visibility of the lunar surface and, specifically, of the landing site until around 5 seconds before terminus. During P64 the commander can direct the LGC to land at any visually chosen point on the lunar surface by a landing-site redesignation procedure which can be continued until initiation of the terminal-descent phase.
3.  The terminal-descent phase (P66) begins automatically at typically 30-m altitude and 11-m ground range from the landing site, or it may be initiated by the commander any time during P64. The P66 guidance algorithm controls velocity only; there is no position control. P66 nulls the forward and lateral velocity components to produce a vertical approach to the lunar surface, an objective which cannot be achieved from visual cues when the surface is obscured by a sheet of radially moving dust. P66 controls altitude rate to a reference value that is incremented or decremented by 0.3-m/sec each time the commander raises or lowers a three-position rate-of-descent (ROD) control switch located near his left hand."

Figure 59. Lunar Module Landing Controls inside LM cockpit. Most notably the ROD control switch and ACA next to DSKY (LGC Display and Keyboard unit).

Navigation, Guidance, and Control Configuration

"The Navigation, Guidance, and Control configuration illustrated in Figure 3 applies to all LM powered-flight guidance maneuvers. This report describes only the yellow blocks of Figure 3. All routines are processed once every two seconds, except the vertical channel of the P66 guidance algorithm is processed once per second, and the digital auto pilot is processed 10 times per second.

Figure 3. Navigation, Guidance, and Control Configuration.

Navigation. Navigation (see Kriegsman /1/) provides an estimate of the current state vector based on data from an inertial measurement unit (IMU) and a landing radar. IMU data are used throughout all thrusting maneuvers, but, to avoid accumulation of inertial errors, IMU data are not used during coasting flight except for a minimum period immediately preceding and following each thrusting maneuver. The landing radar provides altitude data below typically 10-km altitude, and velocity data below 610-m/sec.

Guidance. Guidance transfers the LM from the current state to the terminus of the current phase. In addition to the current state estimate from Navigation, Guidance is based on precomputed targets from the ground-based targeting program. The outputs from the Guidance algorithm are a unit thrust command and a unit window command issued to the Powered-flight Attitude-maneuver Routine, and a thrust-acceleration command issued to the Throttle Routine. Through these routines, Guidance controls the thrust vector magnitude and direction with respect to inertial space.

Powered-flight Attitude-maneuver Routine. The Powered-flight Attitude-maneuver Routine (ATT) connects all guidance programs, descent and ascent, to the digital auto pilot (DAP). ATT inputs are two command vectors; a unit thrust command and a unit window command. ATT estimates a unit thrust vector from accelerometer measurements, and issues incremental commands to the DAP. These commands cause the DAP to drive the estimated unit thrust vector into coincidence with the unit thrust command and the symmetry plane of the LM into coincidence with the unit window command.

During P64, as long as the landing site would be visible, the unit window command issued to ATT by Guidance is the line-of-sight vector to the current landing site. By rotating the LM symmetry plane into coincidence with the line-of-sight vector, ATT superimposes the landing-point designator reticles of Figure 1 on the current landing site."

Throttle Routine. The Throttle Routine (THROT) connects several powered-flight guidance programs to the DPS. The DPS is used by all descent guidance programs, one of the two abort programs, and one guidance program whose purpose is to provide a velocity-vector increment computed by the Real Time Computation Center in Houston and transmitted to the LM.

The DPS must be operated either at the maximum-thrust point (about 92% of the rated thrust of 46,706 newtons) or within a permitted-thrust region (11 to 65% of rated thrust). The intervening region (65 to 93%) is forbidden because in this region oxidizer flow and fuel flow make independent transitions from cavitating to non cavitating regimes. The independent transitions cause gross deviations from the required mixture ratio and produce excessive erosion of the DPS nozzle.

Using a computed mass estimate, a thrust-acceleration measurement, and the thrust-acceleration command from the guidance equations, THROT computes the current and commanded thrusts and issues thrust increment commands to the DPS. These commands either

1.  drive the computed thrust into coincidence with the commanded thrust whenever the commanded thrust lies within the permitted thrust region,
2.  produce maximum thrust whenever the commanded thrust lies above the permitted-thrust region, or
3.  produce minimum thrust whenever the commanded thrust lies below the permitted-thrust region.

Braking-phase and Approach-phase Targeting Program. The targeting program provides targets for P63 and P64. The targets define braking- and approach-phase reference trajectories as independent vector polynomials centered at individual target points as illustrated in Figure 2. Although only P63 and P64 are targeted, the targets are designed to achieve all the guidance objectives of P63, P64, and P66.

Digital Auto pilot. The DAP (see Widnall /2/) controls the attitude of the LM during powered flight by means of control effectors consisting of a reaction control system and a trim gimbal system. As the name implies, the trim gimbal system is a slow system used primarily for trimming the DPS thrust vector through the LM center of mass."

DEFINITIONS OF LUNAR DESCENT COORDINATE FRAMES, ATTITUDE ANGLES, AND GIMBAL ANGLES

"Three coordinate frames are required for lunar descent guidance because

1. (P) all inertial measurements are with respect to the stable platform of the IMU,
2. (G) P63 and P64 guidance is with respect to a landing site which rotates with, and can be redesignated along, the lunar surface, and
3. (B) thrust-vector determination and landing-site redesignations are with respect to LM body axes."

Figure 4. Lunar-descent Coordinate Frames.

These coordinate systems are illustrated in Figure 4 and defined as follows:

1. Platform coordinates. Variables in platform coordinates are tagged P. The origin is at the center of the moon, the XP-axis pierces the nominal (unredesignated) landing site at the nominal landing time, the ZP-axis is parallel to the orbital plane of the Command Module* and points forward, and the YP-axis completes the right-hand triad. Platform coordinates are nonrotating. [*The LGC transfers state vectors in platform coordinates to an abort guidance system (AGS). The AGS requires the state to be expressed in a frame whose Z axis parallels the orbital plane of the command module.] 
2. Guidance coordinates. Variables in guidance coordinates are tagged G. The origin coincides continuously with the current landing site (the frame rotates with the moon); the XG-axis is vertical; the ZG-axis lies in, or near, the plane containing the LM and the landing site and points forward; and the YG-axis completes the right-hand triad. Thus, the origin and orientation of the guidance frame are altered each time the landing site is redesignated. Guidance-frame unit vectors expressed in platform coordinates are the row vectors C_GPx, C_GPy, C_GPz of the matrix CGP.
3. Body coordinates. Variables in body coordinates are tagged B. These are the generally accepted LM coordinates. The XB-axis is in the direction of the nominal thrust vector (up), the ZB-axis is directed forward (during the final), and the YB-axis completes the right-hand triad. Body-frame unit vectors expressed in platform coordinates are the row vectors C_BPx, C_BPy, C_BPz of the matrix CBP (underscore is used to mark a vector, see "Nomenclature" at the end of this paper for details). [Notice that this is NOT the normal airplane body axis convention which is: x forward, z down, and y right.]

From these definitions it is noted that if the LM lands at the nominal site at the nominal time in a nominal erect attitude, the three frames will be parallel at the instant of touchdown.

The following conventions are defined for orthogonal matrices:

1. A matrix element is denoted by two subscripts which indicate the row and column respectively of the element. Thus CBPXy denotes the Y-component of the row vector C_BPx.
2. A matrix transpose (inverse) is denoted by interchanging tags.
3. From the definitions, it follows that matrix products are obtained by deleting internal tags."

By conventions 2 and 3, a vector V_ is transformed to body from guidance coordinates by

LM attitude angles are a set of Euler angles defined as clockwise rotations about the XB-axis (yaw), the displaced YB-axis (pitch), and the displaced ZB-axis (roll).

LM gimbal angles are a set of Euler angles defined as clockwise rotations about the YB-axis (inner), the displaced ZB-axis (middle), and the displaced XB-axis (outer)."

BRAIKING-PHASE AND APPROACH-PHASE GUIDANCE

"The guidance programs for P63 and P64 are almost identical. The two phases use the same guidance algorithm, the same Throttle Routine, and the same Powered flight Attitude-maneuver Routine. The differences are

1. the guidance equation selects different sets of targets,
2. the erection of the guidance coordinate frame is slightly different, and
3. landing site redesignation capability is available only in P64."

Guidance Equation Derivation

"To guide a spacecraft from any initial or current state to a specified target state can be viewed either as an explicit guidance problem or as an implicit guidance problem. Explicitly, we can repetitively determine, as the mission progresses, a vector polynomial function of time that intersects the current and target states. Guidance then commands the corresponding profile of acceleration vs time. Implicitly, we can define, in advance of the mission, a reference trajectory as a vector polynomial function of time that evolves backward from the target state but cannot be expected to intersect a dispersed initial (or dispersed current) state. Onboard guidance then commands an acceleration vector profile composed of three terms, namely the acceleration along the reference trajectory minus two feedback terms proportional to the deviations in velocity and position of the actual trajectory with respect to the reference trajectory. In either the explicit or the implicit case, repetitively solving the guidance problem produces convergence upon the specified target state even though the target point may be redesignated in flight and the commanded acceleration is not precisely achieved because of control errors.

The implicit guidance equation derived here is categorically superior to the explicit guidance equation because the explicit equation is merely a special case, as will be shown. Besides being intellectually more satisfying, the implicit equation has demonstrated in simulations significantly faster reduction of deviations from the reference trajectory. Deviations come from navigation errors and from displacing the reference trajectory to intersect a redesignated landing site. Rapid reduction of deviations restores a nominal approach to the redesignated landing site. Unfortunately, the implicit equation had not been developed when the program for Apollo 11 was coded, and the advantages were insufficient to recode the guidance program for later missions.

Cherry (/3/) derived the explicit guidance equation. Klumpp (/4/, /5/) simplified it for LGC coding and generalized it to nth order. Moore et al (/6/) derived an implicit equation which did not generalize the explicit equation. The general implicit guidance equation is now derived and specialized to the explicit case.

It is convenient to think of the reference trajectory as evolving backwards in time from the target point, with the time variable T reaching zero at the target point and negative prior to that point. Thus target-referenced time (T) is to be distinguished from clock-time (t). Because guidance gains would become unbounded, the target point is never reached. Instead, a guided phase is terminated at a negative time T and the succeeding phase is started. Both the terminus and the target point lie on the reference trajectory, but the target point lies beyond the portion that is actually flown, similar to a suggestion of McSwain and Moore.(/7/)

In terms of a vector polynomial function of target-referenced time, we wish to define a reference trajectory that satisfies a two-point boundary value problem with a total of five degrees of freedom for each of the three components. This number of degrees of freedom is required in order to constrain terminal thrust in P63 and to shape the trajectory design in P64, as is discussed in connection with the targeting program.

A quartic polynomial is the minimum order with which five constraints on the reference trajectory can be satisfied. With the reference trajectory evolving backwards in time from the target point, it can be defined as

where R_RG is the position vector on the reference trajectory in guidance coordinates at the negative time T, and R_TG, V_TG, A_TG, J_TG, and S_TG are the target position, velocity, acceleration, jerk, and snap.

The acceleration to be commanded at any point in space consists of three terms: the acceleration of the reference trajectory at the particular time T, minus two feedback terms proportional to velocity and position deviations from the reference trajectory. Taking derivatives of Eq. (1) as the velocity and acceleration on the reference trajectory yields the three-term guidance equation

where A_CG is the commanded acceleration (vector), V_G and R_G are the current velocity and position (vectors), and KV and KR are the nondimensional feedback gains.

Combining like terms in Eq. (2) yields

Equation (3) is the implicit guidance equation. Although the reference trajectory is quartic, the trajectory generated by the implicit guidance equation is obviously not. The implicit equation can, however, be specialized to the explicit equation - which does generate a quartic - by a specific choice of the feedback gains KV and KR. First we note that Eq. (2) may be identified with the linear second-order differential equation

by the associations (noting T is negative)

where omega_n is the undamped natural frequency and zeta is the damping ratio. Of course the system is time varying. However, this association does afford some intuition on gain setting. Solving Eqs. (4) yields

where P is the undamped period (2 pi/omega_n), and

Equation (5) provides a means of controlling the system response time in terms of the nondimensional ratio P/T, and Eq. (6) provides a means of setting the damping ratio.

An interesting set of values to choose for response and damping is

This choice yields

When these values are substituted into Eq. (3), the result is the explicit guidance equation derived in references /3/ to /5/,

The discussion of implicit vs explicit guidance is concluded by introducing the concept of a space containing all permissible combinations of guidance parameters. Implicit guidance-parameter space is one quadrant of the zeta, P/T plane or, equivalently, one quadrant of the KR, KV plane. Explicit guidance-parameter space is a single point in either plane.

Equation (7) presents the explicit guidance equation assuming negligible transport time delay. The explicit equation programmed in Apollo is corrected to command an acceleration appropriate for the time at which the acceleration is predicted to be achieved. Let this predicted target-referenced time be

where LEADTIME is the transport delay due to computation and command execution. An explicit guidance equation will now be derived that fits a quartic polynomial through the target position, velocity, and acceleration, and through the current position and velocity. The acceleration of the quartic at the predicted time Tp is the acceleration to command at the current time T in order to realize the quartic profile. It will be shown that the resulting guidance equation reduces to Eq. (7) for Tp = T, and therefore Eq. (7) generates a quartic profile when the transport delay is zero.

Constraining the actual trajectory to be a quartic function of time allows the current position and velocity to be expressed as

where J_TGA and S_TGA are the jerk and snap vectors which would be achieved at the target point, and are not targets loaded into LGC memory. Solving Eq. (8) for the jerk and snap yields

The acceleration to be commanded at the current time T and realized at the predicted time Tp is

Substituting Eq. (9) into Eq. (10) and simplifying yields the Apollo lunar-descent guidance equation

Note that when time T is large in magnitude compared to the transport delay, Tp/T approaches unity, all bracketed coefficients in Eq. (11) approach unity, and Eq. (11) approaches Eq. (7) identically. The net effect of Eq. (11) not achieved by Eq. (7) is a gain reduction as the target point is approached. Because Eqs. (7) and (11) are identical for Tp=T, Eq. (7) generates a quartic profile when the transport delay is zero.

In the derivation of the guidance Eq. (7) or (11), nothing constrained the time T. At any point in a guided phase, T could be set to any arbitrary negative value, and Eq. (7) or (11) would satisfy the boundary-value problem from that point forward. Landing-site redesignation, which can arbitrarily stretch or shrink the trajectory, would produce an unnecessarily severe guidance response if T were not correspondingly adjusted. Because T is arbitrary, it can be computed to satisfy an additional boundary constraint. In Apollo, this additional constraint is imposed on the downrange (Z) component of jerk. Thus the Z-component of the jerk polynomial of Eq. (9) is solved for T by using a target Z-component of jerk JTGz. Separating this scalar cubic polynomial from Eq. (9) yields

One root of this cubic is the required time T.

An alternate criterion for computing T reduces the propellant-consumption penalty of downrange landing-site redesignations. Although extensively tested, the alternate was developed too late for incorporation in the LGC program. The alternate criterion sets the downrange position error to zero. Thus T is one root of the quartic

Braking-Phase Targeting Objectives

"The near-optimal transfer provided by P63 targeting must satisfy a throttling constraint that the DPS be operated within the permitted-thrust region for, nominally, the final two minutes of the phase. This throttling duration absorbs dispersions in DPS performance and errors in lunar terrain modeling. With a total propellant consumption of over 6,600-kg, Yang (/8/) shows that the Apollo guidance and targeting are within 16-kg of an optimal trajectory satisfying the same throttling constraint.

To provide thrust within the 11 to 65% region for the last two minutes of P63, the targets are chosen to produce a constant thrust level of about 57% of rated thrust at P63 terminus. The targeting program accomplishes this by constraining the magnitude of the terminal thrust-acceleration vector to be

and constraining the Z-component of terminal jerk to be (essentially)

where F is the required terminal thrust, M is the estimated terminal mass, M_dot is the estimated terminal mass flow rate (negative), and K is a jerk coefficient to account for the vertical component of thrust. The targeting program achieves the two minute duration of constant thrust by adjusting the initial range.

Properly targeted, the guidance algorithm commands during most of P63 a thrust-acceleration in excess of what can be achieved. The throttle routine multiplies this thrust-acceleration command by the estimated mass to yield the guidance thrust command (GTC), and provides maximum thrust until the GTC falls below 57%.

Figure 5. Actual Thrus Profiles and Guidance Command Thrust Profiles During P63.

Figure 5 illustrates the profiles of GTC and actual thrust for a properly targeted P63 phase and shows the effects of adjustments of the ignition time and of the DPS thrust level.

The targeting program computes the P63 targets by projecting computed terminal conditions forward typically 60 seconds. Although the targets are projected, they are computed to produce the required terminal conditions on a nominal trajectory. Trajectory dispersions cannot be eliminated prior to the target point, but they can be reduced sufficiently by terminus to achieve the targeting objectives. Both the ignition time and the projected targets are computed iteratively using a descent simulation in the iteration loop."



Approach-Phase Targeting Objectives

"The P64 targets are computed to provide lunar-surface visibility until about 5 seconds before terminus, and continuous throttling. In addition, the P64 targets are computed to produce at terminus a matched set of values for the Z-components of acceleration, velocity, and position such that, in the nominal case, the P66 algorithm will produce no initial pitch transient and will simultaneously null the Z-components of velocity and position. Unlike P63, the P64 reference trajectory can be determined in closed form from specified trajectory constraints. Thus the projected targets are computed without numerical iteration."



Landing-Site Redesignation Procedure

"To steer the LM via the automatic P64 guidance to a visually selected landing site, the commander uses an iterative procedure akin to steering an automobile. The procedure consists of

1. identifying the current landing site where the LGC would take him in the absence of intervention and
2. steering the current site into coincidence with his visually selected site by commanding incremental landing-site displacements (redesignations).

Because the P64 targets are defined in the guidance coordinate frame, which is repetitively erected through the landing site, the P64 target point is displaced accordingly.

To identify the currently selected landing site to the astronauts, the LGC

1. orients the LM about the thrust axis to superimpose the landing point designator (LPD) reticles (see Figure 1) on the current site and
2. displays a number which is read by the LM pilot and vocally relayed to the commander.

By sighting through the indicated point of the LPD reticles, the commander identifies the current site. He registers his eye by superimposing the two LPD reticles, one of which is painted on the inside window panel, and one on the outside window panel. The separation between reticles is 2.5 cm.

By manipulating his controller left, right, forward, or aft, the commander directs the LGC to displace the landing site (and the P64 targets) along the lunar surface by a correspondingly directed fixed angular increment (1°) with respect to the current line of sight.

The LGC redirects the thrust to guide to the redesignated (now current) site, and reorients about the thrust axis to maintain superposition of the reticles on the current site. The commander can continue this redesignation process - steering the current landing site into coincidence with his chosen site - until 10 seconds before reaching the P64 target point, at which time P66 is initiated."



P63, P64 Guidance Algorithm

"Figure 6 illustrates the P63, P64 Guidance Algorithm.

Figure 6. P63, P64 Guidance Algorithm.

As shown in Figure 3, the algorithm receives guidance targets, the current state vector, and the current gravity vector as inputs and issues a thrust-acceleration command, a unit thrust command, and a unit window command as outputs.

Because the landing site moves due to lunar rotation and landing-site redesignation, the LM is guided with respect to the guidance coordinate frame, which is erected through the landing site each pass. Guidance targets are fixed in this floating frame. Other inputs and all outputs are expressed in platform coordinates.

The landing site vector L_P is updated for lunar rotation (Eq. (6.1)) using an approximate algorithm that avoids computation of trigonometric functions, yet preserves the magnitude of the lunar radius. The algorithm accounts for the lunar rotation rate V_MOONP and the elapsed clock-time since the preceding update (t - tOLD).

For the landing-site redesignation algorithm (Eqs. (6.2) - (6.7)), whenever the commander manipulates the controller (Figure 1) in the automatic mode, the LGC is interrupted and the azimuth command count (NCAZ) or the elevation command count (NCEL) is incremented or decremented according to the direction of manipulation. The redesignation algorithm fetches and resets to zero the NCAZ and NCEL accumulators and rotates L_OSP (the unit line-of-sight vector to the current landing site) by 1° per count (Eq. (6.3)). If NCAZ and NCEL are both zero, the redesignation algorithm has no effect. Given that attitude control maintains coincidence of the ZB, XB plane and L_OSP, the rotations of L_OSP are about two axes normal to L_OSP. Elevation redesignations rotate L_OSP about the YB-axis, and azimuth redesignations rotate L_OSP about an axis normal to L_OSP in the ZB, XB plane.

Figure 7. Landing-site Redesignation Geometry.

The landing-site redesignation geometry shown in Figure 7 depends upon the defined LM platform orientation, namely that the XP-axis is near vertical through the landing site. The constraint that LOSPx be at least as negative as -0.02 (Eq. (6.5)) prevents redesignating the landing site beyond the horizon. Equation (6.7) computes the displaced point near the surface shown in Figure 7 and places the redesignated site directly beneath this point.

The displayed LPD angle (theta_LPD, Eq. (6.8)) is the angle between L_OSP and the ZB-axis.

The computation of the state vector in guidance coordinates (Eq. (6.9))places the origin of the guidance frame at the landing site and yields the velocity of the LM relative to the lunar surface.

Target-referenced time T is computed using Newton's method starting with a good estimate (Eqs. (6.12) - (6.13)). Note that the denominator of Eq. (6.12)is the derivative of the numerator.

The guidance equation (Eq. (6.15)) is identical to Eq. (11). The thrust acceleration command( Eqs.(6.16)- (6.17)) is merely the total acceleration command minus current gravity G_P, and the unit thrust command (Eq. (6.18)) is the direction of the thrust-acceleration command. The so-called radial-acceleration guidance correction described in reference /9/ is rendered unnecessary by current targeting techniques and is omitted from this report, although present in the LGC program.

The computation of the unit window command presented here is a simplification of the LGC coding which produces the same result. The object is to keep the landing site in the center of vision (superimpose the LPD reticles on the current site) whenever the geometry permits and, otherwise, to command a forward-facing attitude.

Figure 8. Why the
landing site cannot always be kept in the center of vision.

Figure 8 shows why the landing site cannot always be kept in the center of vision.

Figure 9. Geometry pertinent to computation of the unit window command.

Figure 9 shows the geometry pertinent to computation of the unit window command U_NWCP. Commanding the line-of-sight vector (U_NWCP = L_OSP) alines the reticles with the landing site; commanding the forward vector (U_NWCP = F_ORP) produces a forward facing attitude. If the first alternative is chosen (U_NWCP = L_OSP) the LM will rotate about the XB-axis to aline the YB-axis with the vector L_OSP x C_BPX. Thus the direction of L_OSP x C_BPX indicates whether a normal forward-facing attitude or an abnormal attitude would result from the command U_NWCP = L_OSP. In addition, the magnitude of L_OSP × C__BPX measures the degree of indeterminacy in the command U_NWCP = L_OSP. The projection (PROJ, Eq. (6.20)) of L_OSP x C_BPX on the YG-axis detects both the magnitude and the direction of L_OSP × C_BPX. Thus PROJ is used as the criterion for mixing L_OSP and F_ORP into U_NWCP. If the descent trajectory is planar, the mixing (Eq. (6.21)) yields U_NWCP = L_OSP for theta_LPD ≤ 65°, U_NWCP = F_ORP for theta_LPD ≥ 75° , and U_NWCP a mixture linear with cos theta_LPD for 65° ‹ theta_LPD ‹ 75°. Regardless of whether the trajectory is planar or nonplanar, it is never possible to command a side-facing or a rear-facing attitude.

Figure 10. Plan View of Guidance-coordinate-frame Erection.

Erection of the guidance coordinate frame (Eqs. (6.22) - (6.24)) is illustrated in Figure 10. With K=1 in P63, the guidance coordinate frame orientation about the vertical XG-axis is such that the YG-component of jerk would reach zero at the target point if the trajectory were flown there (see reference /5/). With K=0 in P64, the ZG-axis is in the vertical plane containing the line-of-sight vector. For cross range landing-site redesignations, setting K=0 in P64 was found to consume less DPS propellant than setting K=1 to null the cross range jerk at the target point."



P63 Ignition Algorithm

"Trajectory dispersions preceding P63 require an accurate ignition time and attitude to be computed to

1. avoid excessive variations of the time duration of throttle control in P63 and
2. to avoid commanding an excessive attitude transient the first time the P63, P64 Guidance Algorithm is processed.

The P63 ignition procedure consists of:

1. Computing onboard the precise ignition time and attitude about 10 minutes in advance of ignition
2. Orienting the LM to the ignition attitude
3. Initiating reaction control system ullage 7.5 seconds prior to ignition
4. Igniting the DPS at minimum thrust and holding constant thrust and constant attitude for 26 seconds, the maximum time required for the DAP to orient the DPS trim gimbal system to point the thrust vector through the LM center of mass
5. Connecting the guidance algorithm, which immediately commands maximum thrust and begins commanding an attitude profile according to the current state vector and the P63 targets.

Figure 11. P63 Ignition Algorithm.

To determine the required ignition attitude, the ignition algorithm (Figure 11) calls the guidance algorithm as a subroutine. The ignition algorithm supplies inputs consisting of an accurate extrapolation of the state vector and the corresponding gravity vector (both valid at GUIDTIME, the estimated clock-time of the first P63 guidance pass). In preparation, Eqs. (11.1) - (11.5) initialize guidance algorithm inputs. On the first iteration, the state vector extrapolation represented by Eq. (11.6) is performed by an orbital integration routine and, on subsequent iterations, by a Kepler routine. Equation (11.9) corrects the extrapolated velocity vector by the velocity increment imparted during the 26 seconds of minimum thrust preceding this point. (The errors due to not correcting the extrapolated position vector and not correcting for ullage are negligible.) The guidance algorithm produces a unit thrust command U_NFCP, which is the direction to point the XB-axis. Because the direction of the velocity correction is unknown on the first iteration, the above procedure is iterated thrice.

An outer ignition-algorithm loop accounts for dispersions with respect to the nominal trajectory. Equations (11.11) - (11.12) adjust GUIDTIME to correct the RGz component of position at GUIDTIME as

1. a linear function of the dispersion in orbital speed VG and of the dispersion in the RGx component of position (essentially altitude) and
2. as a quadratic function of the out-of-plane position RGy.

RBRIGx and RBRIGz are nominal initial altitude and range components of position in guidance coordinates; VBIRIG is the nominal initial speed; and KX, KY, and KV are correction coefficients. The nominal initial altitude, range, and speed are computed by the targeting program. The correction coefficients are computed using a manual procedure based on descent simulations.

When converged, this process yields a precise time and attitude for igniting the DPS. Trajectory dispersions result in typical variations of 2 seconds in the time duration of throttle control and typical attitude transients of 2 milliradians commanded by the guidance algorithm on the first P63 pass."

TERMINAL-DESCENT-PHASE GUIDANCE

"Horizontal and vertical velocity are controlled in P66 by completely independent algorithms. P66 provides a nonautomatic attitude-hold mode in which the commander can control the LM attitude to translate or not, as he wishes, horizontally over the lunar surface. P66 issues no unit window command; yaw is controlled manually. A description of P66 including the nonautomatic modes is provided by Eyles. (/10/)"



P66 Horizontal Guidance Algorithm

"The P66 horizontal guidance algorithm (Figure 12), processed once every two seconds, nulls the horizontal components of velocity relative to the lunar surface by directing the thrust vector a small angle away from vertical in opposition to horizontal velocity.

Figure 12. P66 Horizontal Guidance Algorithm.

The horizontal algorithm neither measures nor commands thrust-acceleration magnitude; the algorithm is derived on the assumption that the vertical component of thrust-acceleration equals lunar gravity.

Just as velocity feedback damps a position control loop, acceleration feedback damps a velocity control loop. Because of the sampled-data character of the system, a good measure of current acceleration is the acceleration commanded the preceding pass. The P66 horizontal algorithm feeds back the velocity error (current velocity VPy, VPz minus lunar surface velocity VMOONPy, VMOONPz) and, to provide the required damping, feeds back a fraction of the thrust-acceleration command from the preceding pass (Eqs. (12.2) - 12.3)). On the first P66 pass, the thrust acceleration fed back is that commanded the final P64 pass.

The direction of the thrust-acceleration command is limited to 20° from vertical (Eqs. (12.4) and (12.5)) to maintain a nearly erect LM attitude. The LIMIT function of two arguments limits the magnitude of the first argument to the value of the second argument.

The unit thrust command (Eq. (12.6)) is the direction of the limited thrust acceleration command.

The assumption in generating horizontal commands that the vertical component of thrust-acceleration equals lunar gravity (Eq. (12.1)) is realized only if the LM is not accelerating vertically. The purpose of ignoring vertical acceleration is to eliminate coupling from ROD inputs to LM attitude. The effect of vertical acceleration, which occurs whenever the commander manipulates the ROD switch, is to modulate the gains of the horizontal channels. This gain modulation is negligible because only limited changes in the descent rate will ever be commanded; the vertical acceleration can be significantly nonzero only for short periods of time.



P66 Vertical (ROD) Guidance Algorithm

"The ROD guidance algorithm, processed once per second, controls altitude rate to the reference value by throttling the DPS. The ROD algorithm has no control over the LM attitude; the thrust-acceleration command it issues accounts for any non-vertical orientation of the thrust vector.

Figure 60. The ROD switch is located on the panel 5 in LM cockpit.

The object of the ROD guidance is to respond rapidly without overshoot to ROD increment commands. The algorithm provides a time constant of 1.5 seconds, even though the sample interval is 1.0 second, by capitalizing on the sampled-data character of the system. Using a computed estimate of the total acceleration at the ROD sample instant, the ROD algorithm extrapolates sample-instant measured velocity by the effective transport lag of 0.35 second and thus commands an acceleration appropriate for the velocity error at the time the acceleration command will be realized. A sampled data analysis (reference /11/) shows that the compensation for effective transport lag is highly effective in stabilizing the vertical channel. The significant system dynamics reduce to a single zero and two poles in the plane. The zero is

One pole is at the origin, and the second pole is

The poles are the same as for an ideal system containing neither a transport lag nor an extrapolation.

The ROD algorithm has been simplified for this report as follows:

1. In the LGC coding, the ROD algorithm begins each pass by reading the accelerometers and recording the time at which they are read. This time is called the ROD sample instant. ROD sample instants occur irregularly, but the interval between them, called the ROD sample interval, averages 1 second. The accelerometer readings are used to compute

• a) the three-component current velocity vector valid at the ROD sample instant, based on updating the velocity vector supplied by the state vector update routine (SVUR, Figure 3), and
• b) a thrust-acceleration measurement which is the average over the ROD sample interval.

To compute the velocity vector it supplies, the SVUR also reads the accelerometers, each pass, at the SVUR sample instant occurring at regular 2-second intervals. The irregular ROD sample instants are essentially asynchronous with the regular SVUR sample instants. Consequently the interactions between the ROD algorithm and the SVUR in updating the SVUR-supplied velocity vector are extremely intricate. In this report, the data processed by the ROD algorithm are shown as inputs. How these inputs are obtained is described in reference /9/.

2. Although the vertical orientation of the XP-axis is capitalized upon by several LGC routines, including the P66 horizontal algorithm and the landing-site redesignation algorithm, the LGC ROD algorithm laboriously manipulates complete vector state data to maintain validity for any platform alignment. Presented here is the scalar equivalent valid for the lunar-landing platform alignment.

Figure 13. P66 Vertical (ROD) Guidance Algorithm.

Figure 13 shows the ROD algorithm. The inputs are all valid at the ROD sample instant. Equation (13.1) computes the sample-instant total vertical acceleration by adding, to the thrust-acceleration measurement (averaged over the ROD sample interval), current gravity and a correction for the throttle change concluding the preceding ROD pass. The thrust correction increment theta_FA is supplied by the Throttle Routine. Equation (13.2) extrapolates the sample-instant measured velocity. The commanded vertical velocity (reference altitude rate) is initialized as the vertical velocity existing at the time P66 is initiated, and is incremented or decremented by Eq. (13.3) each ROD pass according to the ROD commands issued by the commander since the preceding ROD pass. Equation (13.5) first computes the total vertical acceleration required as the negative of the extrapolated velocity error divided by the ROD time constant (1.5 seconds). The equation then obtains the required vertical thrust-acceleration by subtracting current gravity. Finally, dividing by CBPxx, which is the cosine of the angle between the XB-axis and the vertical XP-axis, Eq. (13.5) yields the thrust-acceleration command AFCP. To avoid an empirically discovered instability which occurs when the throttle routine or the DPS cannot comply with the thrust-acceleration command from P66, Eqs. (13.6) and (13.7) restrict AFCP to produce thrust within the permitted-thrust region."

POWERED-FLIGHT ATTITUDE-MANEUVER ROUTINE

"A link in the attitude control chain of command, the Powered-flight Attitude maneuver routine (ATT) connects the various powered-flight guidance programs to the DAP. The functions of ATT are:

1. For the small attitude changes normally required each guidance cycle, ATT commands a maneuver of constant rate such as to achieve the required attitude 2 seconds later.
2. For gross attitude maneuvers which may be required at phasic interfaces or upon abort, ATT commands a rate-limited maneuver which may extend over several guidance cycles.
3. For all attitude maneuvers ATT avoids the gimbal-lock region (middle gimbal angle › 70° magnitude). ATT issues a gimbal-lock alarm code if and only if the commanded attitude computed from guidance inputs lies within the gimbal-lock region. ATT commands a maneuver which circumvents the gimbal-lock region and issues no gimbal-lock alarm code when the most direct path to the commanded attitude passes through the gimbal-lock region.

Switching from a descent program to an abort program may produce up to 180° change in commanded thrust direction. A break with traditional approaches, ATT makes gimbal lock during any maneuver inherently impossible by

1. computing commanded gimbal angles,
2. limiting the magnitude of the middle commanded gimbal angle, and
3. issuing to the DAP a series of incremental attitude-maneuver commands that monotonically* drive the gimbal angles from their current values to their commanded values. [*Except the outer gimbal angle profile may not be monotonic in the geometrically complex case of a large maneuver about multiple axes at substantial middle gimbal angle and with magnitude limiting of the X-axis attitude angle change on at least one pass through ATT.]

Provided the attitude is not currently in gimbal lock, and given that the middle commanded gimbal angle is magnitude limited at the gimbal-lock boundary, it is inherently impossible to maneuver through gimbal lock; the middle gimbal angle is confined to the range between its current and commanded values. Other attitude-maneuver schemes with appended gimbal-lock avoidance require more computation to produce similar maneuvers.

Figure 14. LM Powered Flight Attitude Control Block Diagram.

Figure 14 presents an overview of the LM powered-flight attitude control process, including some information on the procedures on the DAP side of the interface. Two computational coordinate frames are introduced. From guidance and navigation inputs, ATT computes a commanded-body frame (tag CB) to represent the commanded attitude inherent in the input vectors. From ATT inputs, the DAP computes reference gimbal angles to compare with measured gimbal angles for computing the attitude errors. The reference gimbal angles define a reference-body frame (tag RB). ATT computes that the attitude errors are zero when these two computational coordinate frames coincide. Of course, there may be DAP control errors undetected by ATT, but any thrust pointing error is detected in the steady state by a thrust-direction filter, and corrected.


The guidance and navigation inputs to ATT, shown in Figure 14, consist of a unit thrust command, a unit window command, and a thrust-acceleration measurement. ATT processes the thrust-acceleration measurement in a thrust-direction filter to determine an estimated unit thrust vector with respect to the reference-body frame. Correcting for the offset of the estimated unit thrust vector with respect to the XRB-axis, ATT uses the unit thrust command and the unit window command to erect the commanded-body frame. From the commanded-body frame matrix, ATT extracts commanded gimbal angles which it compares with the reference gimbal angles to generate inputs to the DAP. Ten times per second, the DAP updates the reference attitude and generates the corresponding control commands. The dynamic response is sufficiently fast and tight that the reference attitude is a good measure of instantaneous spacecraft attitude.


A feature of this configuration is that, although ATT runs at a sample rate of 2 seconds, close to the fuel-slosh resonant frequency at certain points in the mission, it avoids exciting fuel slosh by avoiding all coupling with the actual spacecraft attitude except through the slow thrust-direction filter.

Figure 15. Powered-flight Attitude Maneuver Routine Block Diagram.

Figure 15 details the Powered-flight Attitude-maneuver routine. The thrust direction filter computes the thrust-acceleration measurement in reference-body coordinates by constructing the required transformation from the reference gimbal angles (Eq. (15.1)). The change in thrust direction is limited on each cycle to 7-mr (Eqs. (15.3) and (15.4)), the maximum travel of the trim gimbal in 2 seconds. The total excursion of the estimated unit thrust vector is limited to 129-mr (Eqs. (15.5) and (15.6)), the mechanical excursion limit of the trim gimbal plus mechanical deflection and thrust offset with respect to the nozzle. The X-component of the estimated unit thrust vector is not needed and not computed.

If either

1. guidance provides a unit window command too closely alined with the unit thrust command to adequately determine the attitude orientation about the XCB-axis, or
2. the guidance program is P66 (which provides no unit window command),

then ATT provides a unit window command suitable for erection of the commanded-body frame and resets a flag to indicate that no attitude rotation is allowed about the XCB-axis. ATT first provides the current ZB-axis (Eq. (15.8)). But this choice may also be nearly collinear with the unit thrust command, so a second possibility, the current negative XB-axis, is also offered (Eq. (15.9)). Because the ZB- and XB-axes cannot both parallel the unit thrust command, no further checks need be made.

The matrix CCBP, whose row vectors are the commanded-body frame unit vectors expressed in platform coordinates, is computed to satisfy the unit thrust command, the unit window command, and the thrust offset (the angular displacement between the estimated unit thrust vector and the XRB-axis). CCBP is computed in two steps as illustrated in Figure 16.

Figure 16. Geometry of Erection of Commanded-body Frame Viewed on a LM-centered Unit Sphere.

The first step (Eqs. (15.10) - (15.12)) uses the unit thrust command and the unit window command but fails to account for thrust offset. The second step (Eqs. (15.13) - (15.15)) corrects for thrust-offset components UNFRBy and UNFRBz. Since these corrections are small, no unit need be taken in Eq. (15.14). A small window pointing error, shown in Figure 16, is introduced by the thrust-offset correction. Defined as the angle between the ZCB, XCB plane and the unit window command, the window pointing error is the product of the sine of the LPD angle and the thrust-offset angle about the ZCB-axis. Although the trim gimbal has a maximum displacement of 6°, the maximum thrust offset during descent is about 1°, which yields a maximum window pointing error of 0° at 0° LPD angle and 0.9° at 65° LPD angle, the lower edge of the LM window.

Because the matrix CCBP is the transformation from platform to commanded body coordinates, it can be expressed in terms of the IMU gimbal angles which would place the body axes in the commanded directions. Therefore, commanded gimbal angles can be extracted from the commanded-body matrix. Expressing CCBP as the product of the three matrices that correspond to rotations about the three gimbal axes yields

where S and C indicate sine and cosine, and X, Y, and Z indicate the commanded X, Y, and Z gimbal angles. From Eq. (13), it is apparent that the commanded gimbal angles are extracted from the elements of CCBP by Eqs. (15.16) - (15.18), with ARCTRIG defined as follows.

The ARCTHIG function of two arguments yields the angle whose tangent is the ratio of the first and second arguments. ARCTRIG extracts the angle anywhere in the circle by using the ratio of the smaller-magnitude argument to the larger magnitude argument as the tangent of the angle or its complement, and by using the signs of the arguments to determine the quadrant of the angle. Equations (15.16) and (15.17) yield the outer and inner commanded gimbal angles anywhere in the circle. Because the second argument is always positive, implying a positive cosine, Eq. (15.18) yields the middle commanded gimbal angle between ±90°.

To preclude commanding gimbal lock, Eq. (15.20) limits the middle commanded gimbal angle to 70° magnitude. Because the unlimited value lay between ±90° and the outer and inner commanded gimbal angles were computed consistent with the middle commanded gimbal angle range, no quadrant switching of the outer or inner commands is required by gimbal-lock limiting. If limiting charges the middle command, the guidance is commanding gimbal lock, and the gimbal-lock alarm code is issued.

Unlimited reference gimbal angle changes are the changes which would be required to bring the DAP's reference gimbal angles into coincidence with the commanded gimbal angles. These are computed by subtracting, modularly, the current reference gimbal angles from the commanded gimbal angles (Eq. (15.21)). The modular subtractions yield the smaller angular differences, i.e.,

If a Y or Z gimbal angle change greater than 45° is required, the flag is reset indicating no attitude rotation is allowed about the XCB-axis. This is necessary to prevent false starts about the XCB-axis as derived in the appendix of reference /12/.

Equations (15.24) - (15.28) yield the reference gimbal angle changes by limiting the magnitude of the attitude changes to 20° in 2 seconds (10°/sec) about each of three orthogonal axes; one axis is coincident with the XCB-axis and the other axes lie in the YCB, ZCB plane. This permits an angular-rate vector of length Sqrt(3*10^2) deg/sec. Note that if the flag is reset, the attitude rotation about the XCB-axis is made zero, resulting in an outer gimbal angle change to offset the inner gimbal angle change (Eq. (15.28)).

The DAP commands consist of the reference gimbal angle increments to be applied by the DAP each 1/10 second, the reference attitude rates, and the permitted lag angles. The reference gimbal angle increments are the reference gimbal angle changes multiplied by the ratio of the DAP and ATT sample intervals (Eq. (15.29)). The reference attitude rates are computed by the non orthogonal transformation of the reference gimbal angle changes shown in Eq. (15.30). The permitted lag angles, which account for the angles by which the attitude will lag behind a ramp angular command due to the finite accelerations available, are computed using the available acceleration alpha_vec_RB, and then individually magnitude limited (Eq. (15.31)). The DAP avoids attitude-rate overshoot by permitting lagging attitude errors equal to the permitted lag angles."

THROTTLE ROUTINE

"The throttle routine connects the currently operating guidance algorithm to the DPS, as illustrated in Figure 17.

Figure 17. DPS Thrust Control Block Diagram.

For ease of understanding, all thrust levels are represented as percentages of the DPS rated thrust of 46,706 newtons. THROT generates thrust increment commands to drive the input thrust-acceleration measurement into coincidence with the input thrust- acceleration command whenever the resulting thrust would lie within the illustrated permitted-thrust region. When the resulting thrust would lie below or above the permitted-thrust region, THROT causes minimum or maximum thrust. The hysteresis-like region from 57 to 65% thrust avoids frequent alternation between the maximum-thrust point and the permitted-thrust region when the thrust command dwells at the boundary between the permitted-thrust and forbidden-thrust regions.

A digital-to-analog interface between the LGC and the DPS is provided by the descent engine control assembly (DECA). Each guidance cycle (once per two seconds, except once per second for P66) THROT generates the thrust increment command delta_FC% which is converted to a pulse train and issued to the DECA. Each pulse causes about 12.5 newtons thrust change, and the pulse rate is 3,200/second. Following issuance of a thrust increment command, the thrust therefore changes at the rate of 40,000 newtons/second (85% of rated thrust per second) until the thrust increment is achieved. With a guidance cycle as short as one second and an engine response time which may be a substantial fraction of one second, it is necessary for P66 and THROT to account for this transport delay.

As illustrated in the rightmost box of Figure 17, in the region from 11 to 93% the DPS thrust is a nearly linear function of the pulse count accumulated by the DECA. Not shown in Figure 17 is the manual throttle command, which is summed with the DECA output command by the DPS and provides the minimum 11% thrust when the DECA command is zero. The DPS contains a mechanical stop at typically 93% rated thrust. This thrust level minimizes propellant consumption on a nominal descent, considering the loss of specific impulse at higher thrust. To ensure that the DPS is driven to the mechanical stop, the DECA saturates at a substantially higher thrust level (about 99%) and the throttle routine drives the DECA into saturation whenever maximum thrust is required.

Non linearities in response and uncertainties in DECA and DPS scale factors are overcome by the thrust increment command concept. Nominally, THROT provides dead-beat response to step inputs, but with downstream non linearities and scale-factor errors THROT drives the thrust-acceleration error to zero in the steady state.

Figure 18. Throttle Routine Block Diagram.

Figure 18 illustrates the Throttle Routine computations. The thrust command and thrust measurement are computed using the input mass estimate (Eqs. (18.1) - (18.2)). The input thrust-acceleration measurement is the average over the preceding sample interval, during which a thrust increment command was issued producing an instantaneous thrust profile as illustrated in Figure 19.

Figure 19. Thrust Dynamics within a Single Guidance Sample Interval.

Therefore, to obtain the current sample-instant thrust, Eq. (18.3) corrects the thrust measurement by adding the thrust correction increment computed the previous cycle.

The thrust-control logic for providing the required overall system response illustrated in Figure 17 is to pick one of four possible thrusting policies according to the regions of the preceding and present thrust commands (FCOLD% and FC%), and to reset the thrust command if necessary to satisfy DPS constraints. Equation (18.4) or (18.8) resets the thrust command to the thrust actually anticipated. A thrust command augment (FC_AUG%) is computed that either drives the DECA into saturation if the policy is to initiate or retain maximum thrust (Eq. (18.5) or (18.9)), or corrects for the region between the DPS mechanical stop and the DECA saturation value if the policy is to initiate thrusting within the permitted-thrust region (Eq. (18.7)). No thrust command augment is required when the policy is to continue thrusting within the permitted-thrust region. No equivalent thrust-control logic is needed at the minimum-thrust point because minimum thrust would occur only if the commander could issue five or more downward ROD commands within a single P66 guidance sample interval, practically impossible.

The thrust increment command (Eq. (18.12)) is composed of the actual thrust increment delta_FA%, plus the thrust command augment FC_AUG% to drive the DECA in or out of saturation, when required.

Preparatory to computing the thrust correction increment for the succeeding pass, Eq. (18.13) computes the total effective transport lag. The terms in the effective transport lag are

1. the computation duration t - tSI,
2. the estimated DPS time constant of 0.08 second, and
3. the effective DECA delay equal to half the time required to output the thrust increment command pulse train at 85% thrust change per second.

As long as the actual thrust increment delta_FA (Figure 19) is contained entirely within the sample interval delta_t, it is clear that, as LAG approaches zero, the thrust measurement (obtained by differencing accelerometer readings at the sample instants) approaches the sample-instant thrust F. Similarly, as LAG approaches the sample interval delta_t, the thrust measurement must be augmented by an amount approaching the actual thrust increment delta_FA to obtain the sample-instant thrust F. From this heuristic argument, it is apparent that the thrust correction increment which must be added to the thrust measurement to yield the sample-instant thrust is proportional to LAG as computed by Eq. (18.14). A rigorous derivation of this result is presented in Appendix A of reference /11/. The sole purpose of Eq. (18.15) is to interface the P66 Vertical (ROD) Guidance Algorithm.

With the thrust command FC% either within the permitted-thrust region or reset to the value which will actually be achieved, delta_FA% is an accurate prediction of the actual thrust increment, and sigma_FA% or sigma_FA is an accurate thrust correction increment, sigma_FA% or sigma_FA is slightly in error when initiating thrusting within the permitted-thrust region. The slight error is due to neglecting FC_AUG% in the computation of LAG."

S69-34038 (18 May 1969)
View of activity at the flight director's console in the Mission Operations Control Room in the Mission Control Center, Building 30, on the first day of the Apollo 10 lunar orbit mission. Seated are Gerald D. Griffin (foreground) and Glynn S. Lunney, Shift 1 (Black Team) flight directors. Milton L. Windler, standing behind them, is the flight director of Shift 2 (Maroon Team). In the center background, standing, is Dr. Christopher C. Kraft Jr., MSC Director of Flight Operations.

BRAKING-PHASE AND APPROACH-PHASE TARGETING PROGRAM

"The targeting program generates mission-dependent data for the P63 Ignition Algorithm and for the P63, P64 Guidance Algorithm. All data are expressed in guidance coordinates. The ignition algorithm requires nominal initial altitude, range, and speed data that determine ignition time and indirectly determine the throttle control duration. The guidance algorithm requires targets for P63 that provide an efficient transfer and targets for P64 that provide a trajectory meeting several constraints on geometry, visibility, and thrust. Described in detail in reference 5, the P64 constraints provide a fast shallow approach phase more akin to an airplane approach than a helicopter approach, although the terminal-descent phase is essentially vertical in helicopter fashion. The landing site must be approached along a nearly straight-line path depressed typically 16° from horizontal, terminating typically at 30 m altitude ii m ground range. The landing site must be visible continuously until a few seconds before approach-phase terminus, and the DPS thrust must begin at around 57% and must lie continuously in the 11 to 65% region.

Geometry, visibility, and thrust during approach cannot be specified explicitly. Visibility depends upon the position and attitude profiles, and these profiles (with the thrust and mass profiles) are constrained to satisfy the laws of physics. The guidance algorithm will provide the transfer from any arbitrary initial state (within bounds) without regard to any visibility or thrust constraints. The task of the targeting program is to set up the P64 initial state and guidance targets such that suitable visibility and thrust profiles are realized implicitly.

Figure 20. Composition of the Lunar-descent Trajectory.

During the final portion of P63, and throughout P64, the guidance algorithm will generate a trajectory whose position vector is a quartic polynomial function of time, as shown in Figure 20. Targeting consists of

1. defining each of the two polynomials and
2. extracting the guidance targets as the position vector and its derivatives at a target point, lying on the polynomial, substantially beyond phase terminus.

The P64 targeting concept is to construct the approach-phase quartic by imposing necessary and sufficient constraints. With quartic degree, five independent constraints may be imposed in each of three axes. The nominal trajectory is arbitrarily made planar, requiring the Y-components in guidance coordinates of position and all its derivatives to be zero and leaving two axes to specify. Because the initial state can be controlled by the preceding braking-phase guidance, all five constraints in each of the two remaining axes may be specified arbitrarily. Since these ten constraints - called a P64 constraint set - completely determine the P64 trajectory, the geometry and visibility profiles can be determined in closed form, and the thrust profile can be determined from a prior knowledge of mass. Thus P64 targeting consists of generating closed-form solutions for a number of P64 constraint sets and picking one which provides adequate visibility and thrust. Specification of P64 constraint sets is reduced to a two-dimensional search, as will be described in the following section.

The P63 targeting process is not so clean. Because the engine must be run at fixed maximum thrust for most of the phase, the guidance commands are not satisfied, and therefore, as shown in Figure 20, the maximum-thrust portion of P63 is not quartic. When throttle control is recovered, generation of a quartic is begun. But the throttle recovery point is not close to any target point. Therefore the state vector at this point cannot be controlled, and we have no closed-form solution for it. Since the initial position and velocity on the braking-phase quartic must be free, there remain only three constraints, in each of two axes, which can be imposed arbitrarily. The guidance algorithm permits a fourth constraint in one axis by solving for the current target-referenced time such as to satisfy a constraint on the ZG-component of jerk. Thus a P63 constraint set composed of seven constraints is specified arbitrarily, and the remaining three conditions required to define the braking-phase quartic are determined iteratively by simulation. Three or four iterations are generally required because there is bilateral interaction between the targets and the simulation."



Constraints

"The P64 constraint set is constructed as follows:

1. Four constraints at a specified target-referenced terminal time TAPF: Two terminal vertical constraints, specified by the mission commander, are the terminal altitude (RAPFGx = 30-m typically) and altitude rate (VAPFx = -l-m/sec typically). Two terminal horizontal constraints, imposed by the choice of effective P66 horizontal time constant tau, are that the terminal position, velocity, and acceleration shall be related by

These P66 compatibility constraints cause the pitch commands at P64 terminus and P66 inception to be identical (avoiding a pitch transient at the phasic interface) and cause the P66 algorithm to null the horizontal position error as well as the horizontal velocity error, without position feedback. Because the P66 horizontal algorithm feeds back the prior acceleration command, and because of the transport delay, an effective tau of 8 seconds has been found satisfactory rather than the 5 seconds used by the P66 algorithm.

2. Four constraints at an unspecified target-referenced midpoint time TAPM: The midpoint constraints are specified by the commander according to his sense of safety and comparability with a possible manual transition to P66. Typically, he may specify -5-m/sec altitude rate at 150-m altitude, and a 16° slope, completely determining the midpoint state R_APMG, V_APMG given

3. Two constraints at an unspecified target-referenced initial time TAPI: The initial position is arbitrarily specified to lie on the 16° path and to provide an approach phase of typically 7.5-kin length, determining the initial position vector R__APIG given

This completes the P64 constraint set except for specifying the times TAPM and TAPI at which the midpoint and initial constraints apply. These times are determined by running the Approach-phase Targeting Routine over the two-dimensional sweep of values of TAPM and TAPI. From the cases run, one is picked that exhibits suitable attitude and thrust behavior (based on an a-priori P64 initial mass estimate). If subsequent simulation proves the mass estimate excessively in error, the initial thrust will be unsatisfactory, and an alternate case must be picked.

The seven P63 constraints are specified as follows: Four constraints are specified by compatibility of the terminal state on the braking-phase quartic with the initial state on the approach-phase quartic. Two constraints are imposed on terminal acceleration by requiring the terminal thrust to be 57% and by specifying the terminal pitch angle. The final constraint is imposed on the horizontal component of terminal jerk by requiring zero rate of change of thrust at terminus. The terminal pitch angle, typically around 60°, is chosen by trial and error to minimize propellant consumption."

Figure 61. LGC computer upside down showing the wire wrap connections area which actually built up the computer's logic units when connecting the discrete logic component modules facing down.

Approach-phase Targeting

"Figure 21 illustrates the Approach-phase Targeting Routine.

Figure 21. Approach-phase Targeting Routine Block Diagram.

Normally, this routine is first run separately in search of targets for the approach phase, and then run jointly with the Braking-phase Targeting Routine (Figure 22) to determine targets for the entire lunar descent.

In the XG-axis (altitude), the terminal acceleration, jerk, and snap are computed by Eq. (21.2), which is obtained immediately from

where TMF and TIF are the midpoint and initial terminus-referenced times computed by Eqs. (21. 1).

In the YG-axis, position and all its derivatives are zero to produce a planar trajectory.

In the ZG-axis, Eq. (21.4) is obtained by substituting the P66 compatibility constraints

into the ZG-axis version of Eq. (14) and inverting. Equations (21.5) and (21.6) complete the definition of the approach-phase quartic. It remains to compute the approach-phase targets as the position vector and its derivatives at the target point on the quartic.

For a quartic polynomial, a 5 x 5 state transition matrix Phi(T1, T0) can be defined by

where R_i to S_i are row vectors. Phi(T1, T0) can be derived using linear systems theory,

with the solution

where I is the 5 × 5 identity matrix. The exponential series is zero after the fifth term because alpha_i = 0 for i  › 5. All the properties of state transition matrices can be applied to scalar and vector polynomials.

Equations (21.7) yield the complete target and initial states by using state transition matrices and the definition of target-referenced target time as zero."

Figure 62. DSKY (Display and Keyboard) was a vital part of the computer used to communicate with the human operator (astronaut) ... actually the LGC was connected to almost all switches and display devices in the LM cockpit additional to DSKY (so there was almost "no life" without the computer already 1960's)

Braking-phase Targeting

"To target P63, we must completely determine the braking-phase quartic shown in Figure 20. Seven of the ten necessary conditions are determined in closed form, although three are based on a P63 terminal mass estimate which must be updated by simulation. The remaining three conditions necessary to define the quartic are determined iteratively by simulation. The terminal pitch angle theta_PBRF is a fixed input to the Braking-phase Targeting Routine.

Figure 22. Braking-phase Targeting Routine Block Diagram.

Figure 22 illustrates the routine. Four conditions are specified by setting the P63 terminal position and velocity equal to the P63 initial state* (Eqs. (22.1)). [*Not shown is the capability of the targeting program to set the P63 terminal state to a backwards extrapolation of the P64 initial state to allow for a short transition during which the acceleration is assumed to change linearly with time. This capability is not always used, and to show it would unnecessarily complicate the presentation of Figure 22.] A unit vector in the terminal-thrust direction is computed from the terminal pitch angle theta_PBRF (Eq. (22.2)), and the terminal acceleration is calculated by Eq. (22.3) using the terminal thrust FBRF, the P63 terminal mass estimate MBRF, and allowing for lunar gravity GM. The XG-component of terminal jerk must be determined by simulation and is therefore set to zero for the first iteration (Eq. (22.5)). The ZG-component of terminal jerk is computed by Eq. (22.5) to produce zero rate of change of thrust at terminus, accounting for the estimated terminal mass flow rate computed by Eq. (22.4); the jerk coefficient KJ, typically 1.2, accounts for the XG-component of thrust. The terminal snap must be determined by simulation and is therefore set to zero (Eq. (22.6)) for the first iteration. This completes the first-iteration definition of the braking-phase quartic.


Braking-phase targets are computed by Eq. (22.7), using the state transition matrix and the definition of target-referenced target time as zero. Using the computed targets, a simulation is run to produce corrected data.

The nominal initial range used by the ignition algorithm is corrected by Eq. (22.8) to correct the error in the target- referenced time of throttle control recovery.

The simulation produces a braking-phase quartic satisfying the target values of position, velocity, acceleration, and ZG-component of jerk. The remaining conditions necessary to define the quartic can be obtained from the current state on the last pass of the braking-phase simulation. The equation for the current state,

is readily solved to yield the achieved target jerk and snap according to Eq. (22.9). Solving for the ZG-component of achieved target jerk provides a check on the computation of T by the guidance algorithm; agreement between achieved and input values is typically to seven places.

In preparation for correcting estimates at the terminus, the complete state at terminus is computed by Eq. (22.10). Equation (22.10) yields a terminal state at the specified terminal time TBRF precisely, whereas the state RG, VG applies at the time T which may differ from TBRF by up to the 2-second granularity.

Equation (22.11) corrects the P63 terminal mass estimate using the rocket equation. Equations (22.12) - (22.14) correct the terminal acceleration, jerk, and snap using the corrected P63 terminal mass estimate, the achieved XG-component of terminal jerk, and the achieved XG- and ZG-components of terminal snap.

Finally, state convergence test quantities are computed by Eqs. (22.15) - (22.17). Since only three conditions (JBRFGAx, SBRFGAx, and SBRFGAz) defining the braking-phase quartic are sought iteratively, only three convergence criteria are needed. The three criteria chosen are important for guidance performance and are related non singularly to three conditions sought. If any one of the state convergence tests fails, or if the throttle control recovery time convergence test fails, the braking-phase targets are corrected and another simulation is run; otherwise the targeting is concluded by correcting the ignition algorithm inputs per Eq. (22.18).

The P66 vertical channel was developed by Craig W. Schulenberg. The analytical design and gain setting of the P66 horizontal channels was done by Nicholas J. Pippenger using concepts suggested by Jerrold H. Suddath. The concept of analytically extrapolating to yield the predictive guidance equation for P63 and P64 was conceived by William S. Widnall. The existence of an analytical solution for the guidance frame orientation to yield zero crossrange target jerk was recognized by Thomas E. Moore. The thrust direction filter configuration for eliminating thrust-pointing errors due to attitude bias within the digital autopilot deadband was conceived by William S. Widnall and Donald W. Keene."

AUTHORS

[Allan R. Klumpp - "1963 he joined the MIT Instrumentation Laboratory (later renamed the Draper Laboratory) to work for the “more ambitious” Apollo program. Though determined not to take all of the credit (he is quick to acknowledge that the equations used were derived years earlier by George W. Cherry), Klumpp was the principal designer of the Apollo Lunar Module on-board descent software."


George W. Cherry - "Spent the majority of his career as a computer scientist and programmer for MIT. He authored several books in the area of computer programming, including "Pascal Programming Structures," "Parallel Programming in ANSI Standard" and "Software Construction by Object Oriented Pictures." However, one of George's greatest achievements was writing the "Apollo Lunar Landing Guidance Scheme" for NASA's Apollo mission."]

REFERENCES

/1/ Kriegsman, B.A., "Radar-Updated Inertial Navigation of a Continuously-Powered Space Vehicle", IEEE Aerospace Systems Conference, Seattle, Washington, July 11-15, 1966.

/2/ Widnail, W.S., "Lunar Module Digital Autopilot", Journal of Spacecraft and Rockets, Vol. 8, No. i, January 1971.

/3/ Cherry, G.W., "E Guidance -- A General Explicit, Optimizing Guidance Law for Rocket-Propelled Spacecraft", MIT Instrumentation Laboratory Report R-456, August 1964.

/4/ Klumpp, A.R., "A Manually Retargeted Automatic Descent and Landing System for LEM", MIT Instrumentation Laboratory Report R-539, March 1966.

/5/ Klumpp, A.R., "A Manually Retargeted Automatic Landing System for the Lunar Module (LM)", Journal of Spacecraft and Rockets, February 1968.

/6/ Moore, T.E., G.G. McSwain, and J.D. Montgomery, "Guidance Laws for Controlling Off-Nominal LM Powered Descent Trajectories Back to the Nominal", Internal Note MSC-EG-69-9, Project Apollo, NASA, Manned Spacecraft Center, Houston, Texas, February 28, 1969.

/7/ McSwain, G.G. and T.E. Moore, "False High Gate Targeting for LM Powered Descent", Internal Note MSC-EG-68-07, NASA, Manned Spacecraft Center, Houston, Texas, May 27, 1968.

/8/ Yang, T.L., "A Targeting Seheme for Fuel Optimal Rocket Trajectories -- With Applications to the LM Descent Braking Phase", Technical Memorandum TM-71-2014-I, Bellcomm January 22, 1971.

/9/ MIT Charles Stark Draper Laboratory Report R-567, "Guidance System Operations Plan for Manned LM Earth Orbital and Lunar Missions Using Program Luminary ID", Section 5, Guidance Equations, Rev. 9, December 1970.

/10/ Eyles, D.E., "Apollo LM Guidance and Pilot-Assistance During the Final Stage of Lunar Descent- Software Considerations", Fourth IFAC Symposium on Automatic Control in Space, Dubrovnik, Yugoslavia, September 6-10, 1971.

/11/ Klumpp, A.R. and G.R. Kalan, "Elimination of Noise and Enhancement of Stability and Dynamic Response of the Apollo LM Rate-of-Descent Program", MIT Charles Stark Draper Laboratory Report E-2543, October 1970.

/12/ Klumpp, A.R., "FINDCDUW -- Guidance Autopilot Interface Routine", MIT Instrumentation Laboratory LUMINARY Memo No. 27, Rev. i, September 26, 1968.

/13/ Bennett, F.V., "Lunar Descent and Ascent Trajectories", AIAA Eighth Aerospace Sciences Meeting, New York, January 19-21, 1970.

/14/ Bennett, F.V., "Mission Planning for Apollo Lunar Module Descent and Ascent", to be published as a NASA Technical Note.

/0/ Klumpp, A.R., "Apollo Lunar-Descent Guidance", MIT Instrumentation Laboratory Report R-695, DSR Project 55-23890, Manned Spacecraft Center (MSC) of the National Aeronautics and Space Administration (NASA) Contract NAS9-4065, June 1971.

Greek alphabet chart.

NOMENCLATURE

Symbols are normally defined where first introduced. Therefore it is necessary to define here only those symbols used in more than one section of this report. Most symbols are self-defining by being constructed of standard identifiers as follows:

1.Type of variable. Position and its derivatives velocity, acceleration, jerk, and snap are denoted R, V, A, J, S. Thrust is denoted F, thrust acceleration AF, unit vectors U_N, clock-times by lower case t, and target-referenced times (times with respect to the target point of a particular mission phase) by upper case T.

2. Mission phase. The braking phase (P63) is denoted BR, the approach phase (P64) AP.

3. Applicable point in phase. Inception is denoted I, terminus F, and target point T.

4. Coordinate frame of reference. Platform coordinates are denoted P, guidance G, and LM body B.

5. Achieved (as opposed to nominal) values are denoted A.

Thus by construction, R_BRFGA is the position vector expressed in guidance coordinates achieved at the braking phase terminus. Without a phase identifier, R_TG to S_TG represent the braking or approach phase targets R_BRTG to S_BRTG or R_APTG to S_APTG, whichever phase is current. Vector elements are denoted by subscript, e.g., Vz. Vector magnitudes are implied whenever a symbol reserved for a vector lacks the underscore. Row vectors of 3 x 3 matrices are denoted C_x, C_y, C_z, and matrix elements are identified by row and column, e.g., Cyz is the Z component of the row vector C_y. (The vector sign underscore can be below the first letter, above it, or after it.)

* * *