For
inquisitivemind, regarding many of your misconceptions:
Separation and Descent TimelineAs others have noted, you seem to believe the LM must immediately begin its descent upon separation from the CSM. This is not so. In fact the nominal lunar landing mission profile contains several activities that must be accomplished between undocking and PDI.
- Free drift. At undocking, attitude control is disabled for both spacecraft. The nature of the docking hardware causes each spacecraft to recede from the common separation plane. If one or the other spacecraft maneuvered, it could collide with the other. Recontact after separation is one of the common causes of mission failure.
- CSM separation. The CSM maneuvers to increase the separation between the spacecraft. This alters its orbit slightly. Visual inspections are performed of each spacecraft. Ground tracking updates the CSM orbital parameters, which are uplinked to the LM. The LM will use them in case an abort rendezvous is needed.
- Flight and thrust control checkout. The pilots exercise the LM controls, much as an airplane pilot works the controls before takeoff.
- Landing site reconnaissance. At this point in the process the LM is orbiting over the landing site. The pilots can familiarize themselves with lighting and terrain.
- Rendezvous radar checkout. The rendezvous radar is tested. This cannot be done until the LM is some distance away from the CSM, although both spacecraft are still in orbit; the LM has not yet begun its descent.
- IMU, COAS, and LPD alignment. All the pilots' attitude references are now calibrated. This cannot be done while docked. First the IMU is fine-tuned by aiming the spacecraft at two stars in turn and sighting them with the AOT. Then with a properly tuned platform, the COAS optics are aligned. Finally the LPD deviation is noted by aiming the spacecraft at a reference star and noting where on the LPD indices it falls. The commander will use that index when using the LDP during terminal descent.
- AGS calibration. The backup guidance system requires a similar calibration of its guidance platform.
- Observe CSM circularization. DOI was sometimes performed by the SPS on the CSM. Following nominal LM checkout, the CSM orbit is circularized in order to provide the best opportunity for abort rendezvouses. The LM orients itself to allow the LM crew to observe the CSM burn. Later the MSFN will update the LM computer with the CSM's new orbital parameters. These form the final pads for the abort scenarios.
- Landing radar checkout. The landing radar feeds a series of test signals to the computer. The LM is too high at this point to obtain accurate radar altitude data. But the connections and instruments pertaining to the radar can be checked.
- LPD altitude check. The LM is put into LVLH mode in the pitch axis and the LPD is used to sight a known landmark. The time at which this landmark appears determines whether the LM is at the right altitude.
- IMU retune. The guidance platforms on both primary and secondary guidance systems are once again tuned, but this time according to the nominal drift rates. That is, we know the rate at which these IMUs generally go out of alignment, so knowing the time since the last alignment allows us to apply an open-loop correction without reorienting the spacecraft.
- P63 spin-up. The braking-phase program, P63, is brought online with thrust disarmed. P63 is based on an orbital-mechanics model, so it works fine with no thrust applied. The pilots can look at the values computed by P63 during pre-descent orbital operations and determine that it is receiving good data and performing valid computations.
- MSFN uplink. Final state vectors are installed from ground-based tracking and the pads are updated if necessary. Abort phases are manually computed and entered. Then the LVLH mode via ORDEAL is initiated.
- AGS spin-up. The abort guidance system is initiated and allowed to accept input from the sensors and update its own state vector.
At this point P63 is given the authorization to fire the DPS when ready. The DPS engine arm switches are closed. P63 has been accumulating guidance data for about 15 minutes at this point, and it knows when ignition must occur in order to land properly.
Guidance Major ModesYou have stated that the problem of landing on a moon is merely a matter of managing horizontal and vertical velocities as if the entire problem were simply one of ballistics. That is true only in the most simplistic sense. In terms of pure physics, a powered descent transitions smoothly from an orbital regime to a ballistic regime. However there is no simple unified mathematical model for both regimes.
For that reason the LM had two major guidance modes (P63 and P64) and one terminal descent mode (P66). But that's not the only reason. Other factors such as lines of sight for the radar and the pilot are affected by the LM pitch angle. Hence, the pitch angle must vary for reasons other than thrust vectoring. Further, each physical regime suggests its own way of using the cockpit controls. All these needs translate into different guidance major modes.
We also program launch vehicles in different major modes to reflect the most adept control scenario for that phase of flight.
P63 is the braking-phase controller. It is based essentially on orbital parameters. Which is to say, it compares the current LM dynamic state (orbital velocity, range-to-go expressed as orbital anomaly, geodetic altitude, and descent rate) with a precomputed profile table indexed by burn time. The only control variable is the pitch angle computed by ORDEAL relative to LVLH (variable
theta in the P63 profile). The precomputed table incorporates the gradually decaying effects of orbital mechanics.
At heart, P63 is a simple proportional controller. An improper descent will result in a coordinated error in all the variables named above. The coordinated error is a function of all those variables. A new pitch angle is commanded as a function of the coordinated error. DPS throttle scheduling is a function of elapsed time regardless of guidance errors.
The roll and yaw channels are simply constrained to maintain the pitch perpendicular to the orbital plane. 0.5 Hz is plenty fast enough for this. P63 pitch profiles are basically piecewise linear at 30-second intervals, so you have at least 15 controller cycles in each profile segment.
No control inputs are especially significant during P63; the vehicle is flying by itself. The pilots simply monitor the instruments to confirm the proper operation of the computer.
While P63 is considered fuel-optimal for the desired mission profile. Which is to say, a different profile was used on G- and H-type missions than was used in J-type missions. The J-mission descent profile was steeper. While not fuel-optimal, it allowed access to mountainous terrain. The J-type LM DPS fuel loadout was greater, accommodated by increased capacity in the later models of the Saturn V launch vehicle.
P64 is the approach-phase controller. It is not fuel-optimal because the primary variable at this point in the landing becomes pilot visibility. Hence a shallower pitch angle is generally maintained. The mathematical model here is different because by this time the orbital-mechanics influence has decayed to a third-order effect.
This frees up computer capacity for multi-axis control. P64 accepts input from the hand controller to designate up- and down-range changes in landing range, which translate to pitch commands, and side-to-side changes in flight path, which translate to yaw and roll commands.
P64 set-point schedules are a function of altitude, not time.
To summarize the differences, P63 is mostly about horizontal trajectory, with special cases and control inputs for vertical deflections. P64 is mostly about vertical trajectory, with special cases for horizontal deflections. P63 assumes a round Moon. P64 assumes a flat lunar surface. P63 is essentially a single-channel controller. P64 is multichannel.
Breaking up continuous problems like this into discrete phases to optimize for different variables as they change significance is a key technique in control system design for spacecraft.
Counter InterruptsYou have argued that it is a waste of computing resources to increment counters via software interrupts. This fails for two reasons.
First, minimizing computing tasks is not a mission priority. A computer acting as an embedded controller, that is not operating near its full capacity, is being wasted. If counter incrementation fits into the overall computing budget, it is not a "waste."
Second, the Servicer routine is greatly aided by having certain data available already in-core. These data comprise sensor input values (such as IMU gimbal pick-off angles) and time indices represented as counter values. If these were not already available, the Servicer would have to query, or "pull," them from the outlying hardware. This requires I/O activity and places the Servicer into an unpredictable I/O-bound state.
Instead the sensors themselves "push" data into the AGC by requesting an interrupt. The AGC responds to the interrupt knowing that data are already available in the sensory input register, and responds by the very brief activity of incrementing a counter. The Servicer uses these associated counters to coordinate sensor readings by time. Otherwise it would risk mixing current sensor readings from one sensor with "stale" readings from another sensor.
This is the difference between high-level descriptions of control systems that a layman is likely to encounter, and the real-world implementation of such control systems by trained and experienced professionals. The "push" method of sensory updating imposes a known, constant, and deterministic load on the system, which allows the Servicer to run in a deterministic fashion and avoid non-deterministic I/O loads.
Why not use hardware incrementation and dedicated counter registers? Because that means any expansion of counter requirements pushes the computer back to hardware design. In the current design you can have as many counters as you need. Why not have multiple counter registers, but one hardware incrementor parameterized by a counter-index register? That's what the AGC did. The ISR for the counter interrupts simply set up the hardware incrementation.
What appears to be the straightforward way to a layman is not always the best way from the engineer's point of view. The engineer understands
all the pertinent variables, not just the one or two that a layman might believe are important.
P64 and PitchoverYou have argued that the pitchover maneuver is suspiciously abrupt. Your initial line of reasoning says that the guidance computer cannot accommodate a high pitch rate. But you have declined to perform any calculation or do any quantitative reason except to assert that a 0.5 Hz cycle time is too coarse to allow it.
You've made the mistake of assuming that the only way to converge properly using closed-loop control is by increasing the frequency of the controller. Instead we use the "phase plane" method that illustrates the 2D relationship between a variable X and its time-derivative X-dot. Two quantities apply: WL and HSLOPE. WL is a nominal error rate. In terms of, say, pitch, it is a pitch rate designated by the controller programmer to be an acceptable compromise between the need to correct errors quickly and the need to keep the vehicle dynamics within controllable limits. HSLOPE is a derived error rate that applies when the error magnitude is small. Specifically, it is a function of the error magnitude.
Consider the roll channel of a Boeing flight controller under heading-hold mode in the autopilot. Normally the controller maintains a zero roll angle and zero roll rate, within a certain deadband. When the selected heading is suddenly changed by a substantial amount, the autopilot responds to the heading "error" by commanding a turn. The flight controller answers this command by setting the desired roll angle to 20º in the appropriate direction. This immediately generates an "error" in the roll channel of 20º. The controller responds by driving the roll rate to WL, which is nominally 5º per second, by means of aileron commands. When the roll error decreases to less than 5º, the roll rate is lessened to HSLOPE, which is a linear function of the roll error -- the smaller the error, the smaller the commanded rate.
Now overshoot is possible in this case. But because of the WL versus HSLOPE distinction, overshoot will very quickly converge to the deadband because at most one or two controller cycles will drive the rate to WL; the majority will drive them to HSLOPE, which implements an simple and effective differential controller.
From the autopilot's perspective, the airplane now in a 20º bank is achieving a nominal turn rate, which is its own WL. As the plane nears the desired heading, the autopilot will want to "roll out" onto the desired heading. As the heading error drops below a certain threshold, the autopilot will command a shallower roll angle resulting in a smaller turn rate.
During powered descent, the LM's WL is 2º s
-1 and the attitude error deadband is 1º. HSLOPE is
k*0.8.
The differential nature of the control system -- i.e., the notion that the error-correction rate is often a function of the error magnitude -- makes it possible to achieve convergent control with relatively coarse cycle frequencies. This is typically lost on people who haven't experimented a bit with control theory.
Your second line of reasoning suggests such a maneuver is not fuel-optimal because it would require considerable correction at the end of the maneuver to trim it. This presumes fuel consumption rate is an overriding concern. It so happens that pitchover must be a smart maneuver because the LM loses radar lock while in a pitch transition. Landing radar data is more important that accumulated accelerometer measurements. Hence it is important that little time elapse between the 70º nose-up pitch and the 30º nose-up pitch attitude.
Here we see an important reason for conducting some particular maneuver as smartly as practicable. In the general case, the digital autopilot cannot know how important it is to return to the desired orientation. Hence while it may be fuel-optimal to command very slow correction rates, it is not likely to be mission-optimal. Because the DAP is a simple-and-stupid controller and not a policy agent, it acts according to a nominal profile.
Finally, it's not true that small impulses are fuel-efficient. Rocket engines undergo a startup transient in which they do not produce full thrust and do not use their propellants efficiently in terms of thrust per unit mass of propellant. The smallest impulse cycle for a Marquardt 100-lbf thruster is about 15 milliseconds. But when fired in that way, it will attain only 80 lbf thrust and only 60% rated efficiency. It consumes
more fuel to run the thrusters in low-impulse mode.
The actual nominal impulse duration is derived from rough guesses of the spacecraft's moment of inertia in the relevant axis. It doesn't need to be very accurate.