Stories of the lunar computer. Part 3

Apollo 11 on the moon



Five months later, Apollo 12 survived a lightning bolt during acceleration and sat on the moon. Thanks to the new “noun 69” that we added to the program to allow the team to change their position based on ground tracking data, astronauts Pete Conrad and Alan Bean were able to land the lunar module within walking distance of the unmanned the Surveyor ship, which landed on the moon in April 1967. The precise landing of Apollo 12 paved the way for landings on a more complex terrain.



Only after Apollo 12 did we begin to understand other serious problems.



I started when Clint Tillman of Grumman Aerospace (the lunar module building company) noticed throttle vibrations while simulating the final landing stage when the engine thrust was around 5%. This prompted Tilman to study the telemetry data of Apollo 11 and 12, where he noticed fluctuations in the final stage of landing, having an amplitude of 25% of peak to peak (see Fig. 12). This was a period when the ship commander could simultaneously use the ROD switch to control the descent speed and the joystick to maneuver the ship. Since the graphs of these data resembled the walls and towers of the castle (or castle nut), this problem was called the "throttle fortress."







Fig. 11: First Throttle Report



Clamp in Cambridge described a source of excitation of vibrations to an unknown phenomenon called by him “IMU bob” [18]. The IMU was located above, and four feet in front of the ship's center of mass. Small but fast maneuvers, such as during the final landing, threw the ship so that the accelerometers interpreted this as a change in the vertical speed of the ship. This, in turn, influenced the calculation of vertical speed, and the assessment of the necessary traction.



But this theory only partially explains the throttle behavior observed in flight data.



Throttled rocket engines were and remain a rarity, but a throttle engine was needed for a soft landing on the moon. A fixed thrust engine and very simple equations of motion can land a ship past the desired point on the lunar surface. But in order to sit upside down, moving smoothly, holding the landing site in the visibility zone, and with the possibility of hovering over the landing site, we needed an engine that could balance lunar gravity, changing traction as the vehicle mass decreases, and when changing the thrust vector during maneuvers and when the astronauts wanted to change the speed of the descent.



The equations of motion determine what acceleration is to be given to the apparatus, with what magnitude, and in which direction. The autopilot makes maneuvers so that the traction force corresponds to a given direction. The task of the throttle control program is to control the traction. Throttling control begins by calculating the mass of the lunar module. Knowing the mass, we determine the amount of throttle correction required to change the acceleration of the ship relative to that measured by accelerometers to the value necessary to comply with the equations of motion, and convert the resulting value to units used by the throttle assembly (about 2.8 pounds per pulse), and send them to the hardware interface.



The accelerometers in the IMU do not actually measure acceleration, they measure the increment of speed relative to the last read. Since throttling changes during the previous iteration occur at some point between the readings of the accelerometers, the measured delta-V does not show the full effect of the most recent change.







Fig. 12: Throttling changes during the P66 phase of Apollo 12 flight [19]



Throttle control was supposed to compensate for this effect. A series of compensations depended on when the throttle command was sent during the period, and also depended on the speed at which the engine executes throttling commands. Experimental studies have established that throttling has a delay of 0.3 s.



This allowed the author to program and test the throttle control program. In the simulation graphs of the exact DPS model using a 0.3 s delay, I observed oscillations in the real thrust that occurred after a large change in the throttle position without compensating for the throttle delay. When I turned on the compensation for 0.1 s, I saw how the oscillations decreased. When I set the compensation to 0.2 s, the oscillations almost disappeared. That was all over. Klump recalled how I said: “it’s like a medicine, you don’t need to give more compensation than necessary.”



Klamp knew that it was not “like a cure,” but he never insisted that I program the correct value. Explaining his motivation after 15 years, Klump writes:



“I thought it was important to build self-confidence, to allow colleagues to make decisions on small issues, even if they are not optimal. Therefore, I withheld my thoughts and upheld the decision of Don in force, at least until he revised it on his own ”[20].



Explaining my own motives, I believe that I was irritated by the compensation in the already overloaded throttling program, and this may have resulted in the desire to make the compensation as small as possible. Be that as it may, both Apollo 11 and Apollo 12 flew with a compensation of 0.2 s with a throttle delay of 0.3 s.



But now both Klump’s analysis [21] and the independent report prepared by JA Sorensen at Bellcomm [22] have concluded that “the oscillatory nature of the throttling command P66 was obviously due to the fact that the actual value the landing engine time constant is less than anticipated ”(Sorensen). Klump rechecked the data. The parameters of the landing engine were improved, but the corresponding changes were not made to the documentation. The actual delay for the landing engine was about 0.075 s. It turned out that we even overcompensated it. As a result, the throttle was on the verge of stability.



Clampp's analysis gave an even more striking result. He showed that if the Apollo 11 software compensated for 0.3 s, the throttle would be unstable. Throttle vibrations, instead of calming down, would become larger. After throttling in P63 or, possibly, in P66 when the IMU was energized, the DPS engine would quickly oscillate between minimum and maximum thrust. Undoubtedly, flight control would logically associate throttle behavior with alarms 1202, which had completely independent causes.



An accident would be inevitable. In my humble opinion, if the author had encoded the “correct” value in the throttle control program, Apollo 11 would never have sat down. I invite someone who has no personal interest and is well versed in mathematics to double-check this theory.





Manual moon landing

* * *

We adjusted the throttle delay, and the simulation showed that the instability of the throttle position has disappeared. Changes were made to the Apollo 13 mission software, but this mission did not land on the moon.



It is curious that a change in the Apollo 13 software was made before the throttle problem became known, could provide a backup option if the throttle control automation would not work. A new “noun 92” was defined, which the crew could choose to see the throttle level that the control system produces. The logic that would stop automatic control if the throttle were to switch to MANUAL mode was deleted. These changes [23] allow the astronaut to control the throttle during phases P63 and P64, while the control system continues to control the motion of the ship. I do not know if these complex procedures have ever been used.



Executive overload alarms have been addressed several times.



The proximity radar switch was in the LGC position during take-off. In subsequent missions, the checklist was changed. We added logic to the LUMINARY to check the proximity radar operation mode, and if it was not LGC, the proximity radar counters were reset to zero.



Alan Clump studied Executive from a different perspective. He found that when a computer’s TLOSS occurs periodically, or the computer’s activity level changes in the presence of TLOSS, and the SERVICER task was not completed, and it was interrupted when the position calculation commands were executed to send them to the autopilot, it was not cleared by a software restart in to be restored later - under these conditions there was a chance of an incorrect position calculation for the autopilot. By the flight of Apollo 13, Klump had developed a solution in which all SERVICER work was reset to catch up if necessary.







Moon landing phases



But in the future, none of these changes freed us from the limitations of a fixed two-second period of the orientation system. To land on difficult terrain, it was necessary to add a terrain model to the radar program. Modifications to the orientation system were left for later. We did not have time for everything.



We developed a concept that we called the “SERVICER variable”, in which the orientation program period could be extended if necessary. Fears that the two-second interval is built into the software tightly turned out to be unfounded. It was only necessary to measure the period of operation of the orientation system, and use this value instead of the two-second value, which is used in only a few formulas. We implemented the working version of SERVICER in the offline version of LUMINARY, and demonstrated its very high resistance to TLOSS [25].



Freedom from the two-second limit allowed other ideas to be considered. Astronaut John Young proposed an improvement, which we called P66 LPD. But by this time, P66 was a much more flexible program than in Armstrong’s Apollo 11 flight. One of the new features was that if the team switched the ATT HOLD mode to AUTO, the orientation system would result in zero horizontal speed. Young's idea was for the LGC to display the LPD angle (as in the visible phase), which would show the commander the point above which the lunar module flies if at that moment the autopilot is switched to AUTO [26].



To ensure accuracy in performing this function, the software had to react instantly when the astronaut switched to AUTO, faster than two seconds, and even faster than the second allowed by some parts of P66. We developed a version in which the task was launched every quarter of a second, checked the autopilot mode change, sent orientation and throttle commands, and responded as quickly and accurately as possible to the input from the ROD switch. In a manned simulation running on the lunar module simulator (LM Mission Simulator, LMS) on Cape Canaveral, with its fabulous terrain models visible in the windows, we showed that this system facilitates a very accurate landing.



Neither the “SERVICER variable” nor the P66 LPD have ever been patched. NASA has decided that Apollo 17 will be the last. With so few remaining missions, the governing council made a conservative decision - there should not be any significant changes to the landing software. By synchronizing the data received from the landing radar with the reading of the accelerometers, Robert Covelli freed up enough time to cram the terrain model for the Apollos 15, 16 and 17 there.







Inertial Module (IMU) at MIT Lab



Apollo 14 brought the author short-term fame. The dashboard interrupt switch sent a periodic signal that prevented Alan Shepard and Ed Mitchell from sitting down. I wrote code that monitors these cases. This “crutch” simply changed several registers, the first to trick the mission interruption monitor into thinking that the interruption had already occurred, and then delete itself so that the landing could continue without consequences. The patch was broadcast over the air and put into action by the astronauts flawlessly, this procedure included 61 keystrokes on DSKY. Perhaps the most interesting part of the Apollo 14 incident was the number of different versions of this story. But Apollo 14 is another story.



In December 1972, I went to Cape Canaveral to launch the Apollo 17 ship. This space flight was awesome. Writer Tom Wolfe, along with photographer Annie Leibovitz, wrote a four-part short story for Rolling Stone magazine, which was the forerunner of “The Right Stuff” [27]. It was the only overnight launch of Apollo. Florida's foggy sky burns orange from horizon to horizon when the huge Saturn V soars upward on a quarter-mile column of flame that swayed at the end like a blowtorch flame.



I spent several days testing some of the LMS functions that we called “erasable memory programming”. These were patches that were supposed to use unused VACs and patch some bugs, the legacy of the incident with Apollo 14. Then I flew to Cambridge to observe the landing.



After that, I enjoyed listening to Gene Cernan and Jack Schmitt, a geologist by training, exploring the Moon in a lunar rover, having traveled more than 3 miles out of sight of the spacecraft. And this was the last time someone walked on the moon.







Fig. 13: Some of the participants.



Great photo, front row: Vince Megna, “Doc” Charles Stark Draper, author, Dave Moore, Tony Cook; back row: Phil Felleman, Larry Berman, Allan Klumpp, Bob Werner, Robert Lones, Sam Drake. Small photo, front row: Larry Berman, Peter Volante, the author; back row: Sam Drake, Bruce McCoy. Also in attendance were Steve Copps, Romilly Gilbert, Ken Goodwin and Russ Larson.