Historias de la computadora lunar. Parte 3

Apolo 11 en la luna

Cinco meses después, el Apolo 12 sobrevivió a un rayo durante la aceleración y se sentó en la luna. Gracias al nuevo "sustantivo 69" que agregamos al programa para permitir que el equipo cambie de posición en base a datos de seguimiento en tierra, los astronautas Pete Conrad y Alan Bean pudieron aterrizar el módulo lunar a poca distancia de los no tripulados el buque Surveyor, que aterrizó en la luna en abril de 1967. El aterrizaje preciso del Apolo 12 allanó el camino para aterrizar en un terreno más complejo.

Solo después del Apolo 12 comenzamos a comprender otros problemas graves.

Comencé cuando Clint Tillman de Grumman Aerospace (la compañía de construcción de módulos lunares) notó vibraciones del acelerador mientras simulaba la etapa de aterrizaje final cuando el empuje del motor era de alrededor del 5%. Esto llevó a Tilman a estudiar los datos de telemetría del Apolo 11 y 12, donde notó fluctuaciones en la etapa final del aterrizaje, con una amplitud del 25% de pico a pico (ver Fig. 12). Este fue un período en el que el comandante del barco podía usar simultáneamente el interruptor ROD para controlar la velocidad de descenso y el joystick para maniobrar el barco. Dado que los gráficos de estos datos se parecían a las paredes y torres del castillo (o la tuerca del castillo), este problema se llamó la "fortaleza del acelerador".



Fig. 11: Primer informe del acelerador

Clamp en Cambridge describió una fuente de excitación de las oscilaciones a un fenómeno desconocido, al que llamó "IMU bob" [18]. La IMU estaba ubicada arriba, y cuatro pies delante del centro de masa del barco. Las maniobras pequeñas pero rápidas, como durante el aterrizaje final, arrojaron la nave de modo que los acelerómetros interpretaron esto como un cambio en la velocidad vertical de la nave. Esto, a su vez, influyó en el cálculo de la velocidad vertical y la evaluación de la tracción necesaria.

Pero esta teoría solo explica parcialmente el comportamiento del acelerador observado en los datos de vuelo.

Los motores de cohetes estrangulados eran y siguen siendo una rareza, pero se necesitaba un motor de aceleración para un aterrizaje suave en la luna. Un motor de empuje fijo y ecuaciones de movimiento muy simples pueden aterrizar un barco más allá del punto deseado en la superficie lunar. Pero para sentarnos boca abajo, moverse suavemente, mantener el sitio de aterrizaje en la zona de visibilidad y con la posibilidad de flotar sobre el sitio de aterrizaje, necesitábamos un motor que pudiera equilibrar la gravedad lunar, cambiar la tracción a medida que disminuye la masa del vehículo y al cambiar el vector de empuje durante las maniobras. y cuando los astronautas querían cambiar la velocidad del descenso.

Las ecuaciones de movimiento determinan qué aceleración se le dará al aparato, con qué magnitud y en qué dirección. El piloto automático realiza maniobras para que la fuerza de tracción corresponda a una dirección determinada. La tarea del programa de control del acelerador es controlar la tracción. El control de estrangulamiento comienza calculando la masa del módulo lunar. Conociendo la masa, determinamos la cantidad de corrección del acelerador requerida para cambiar la aceleración de la nave en relación con la medida por los acelerómetros al valor necesario para cumplir con las ecuaciones de movimiento, y convertimos el valor resultante en unidades utilizadas por el conjunto del acelerador (aproximadamente 2.8 libras por pulso), y enviarlos a la interfaz de hardware.

Los acelerómetros en la IMU en realidad no miden la aceleración, miden el incremento de velocidad en relación con la última lectura. Dado que los cambios de aceleración durante la iteración anterior ocurren en algún punto entre las lecturas de los acelerómetros, el delta-V medido no muestra el efecto completo del cambio más reciente.



Fig. 12: Cambios de estrangulamiento durante la fase P66 del vuelo del Apolo 12 [19]

Se suponía que el control del acelerador compensaba este efecto. Una serie de compensaciones dependía de cuándo se enviaba el comando del acelerador durante el período, y también dependía de la velocidad a la que el motor ejecuta los comandos de aceleración. Los estudios experimentales han establecido que la aceleración tiene un retraso de 0.3 s.

Esto permitió al autor programar y probar el programa de control del acelerador. En los gráficos de simulación del modelo DPS exacto que usa un retraso de 0.3 s, observé oscilaciones en el empuje real que ocurrieron después de un gran cambio en la posición del acelerador, sin compensar el retraso del acelerador. Cuando encendí la compensación durante 0.1 s, vi cómo disminuían las oscilaciones. Cuando configuré la compensación en 0.2 s, las oscilaciones casi desaparecieron. Eso se acabó. Klump recordó cómo dije: "es como un medicamento, no necesita dar más compensación de la necesaria".

Klump sabía que no era "como una cura", pero nunca insistió en que programara el valor correcto. Explicando su motivación después de 15 años, Klump escribe:

“Pensé que era importante desarrollar la autoconfianza, permitir que los colegas tomen decisiones sobre pequeños problemas, incluso si no son óptimos. Por lo tanto, retuve mis pensamientos y mantuve la decisión de Don vigente, al menos hasta que la revisó por su cuenta ”[20].

Al explicar mis propios motivos, creo que me irritó la compensación en el programa de aceleración ya sobrecargado, y esto puede haber resultado en el deseo de hacer la compensación lo más pequeña posible. Sea como fuere, tanto el Apollo 11 como el Apollo 12 volaron con una compensación de 0.2 s con un retraso de aceleración de 0.3 s.

Pero ahora, tanto el análisis de Klump [21] como un informe independiente preparado por JA Sorensen en Bellcomm [22] concluyeron que "la naturaleza oscilatoria del comando de estrangulamiento P66 se debió obviamente al hecho de que el valor real la constante de tiempo del motor de aterrizaje es menor de lo esperado ”(Sorensen). Klump volvió a verificar los datos. Se mejoraron los parámetros del motor de aterrizaje, pero no se hicieron los cambios correspondientes en la documentación. El retraso real para el motor de aterrizaje fue de aproximadamente 0.075 s. Resultó que incluso lo sobrecompensamos. Como resultado, el acelerador estaba al borde de la estabilidad.

El análisis de Clampp dio un resultado aún más sorprendente. Mostró que si el software Apollo 11 compensara 0.3 s, el acelerador sería inestable. Las vibraciones del acelerador, en lugar de calmarse, se harían más grandes. Después de la aceleración en P63 o, posiblemente, en P66 cuando se energizó la IMU, el motor DPS oscilaría rápidamente entre el empuje mínimo y máximo. Sin lugar a dudas, el control de vuelo asociaría lógicamente el comportamiento del acelerador con las alarmas 1202, que tenían causas completamente independientes.

Un accidente sería inevitable. En mi humilde opinión, si el autor hubiera codificado el valor "correcto" en el programa de control del acelerador, Apollo 11 nunca se habría sentado. Invito a alguien que no tenga ningún interés personal y que esté bien versado en matemáticas a verificar esta teoría.


Alunizaje manual

* * *

Ajustamos el retraso del acelerador, y la simulación mostró que la inestabilidad de la posición del acelerador ha desaparecido. Se hicieron cambios en el software de la misión Apolo 13, pero esta misión no aterrizó en la luna.

Es curioso que se haya realizado un cambio en el software Apollo 13 antes de que se conozca el problema del acelerador, podría proporcionar una opción de respaldo si la automatización del control del acelerador no funcionara. Se definió un nuevo "sustantivo 92", que la tripulación podía elegir para ver el nivel del acelerador que produce el sistema de control. Se eliminó la lógica que detendría el control automático si el acelerador cambiara al modo MANUAL. Estos cambios [23] permiten que el astronauta controle el acelerador durante las fases P63 y P64, mientras que el sistema de control continúa controlando el movimiento de la nave. No sé si estos procedimientos complejos se han utilizado alguna vez.

Las alarmas de sobrecarga ejecutiva se han abordado varias veces.

El interruptor de radar de proximidad estaba en la posición LGC durante el despegue. En misiones posteriores, la lista de verificación ha cambiado. Agregamos lógica al LUMINARIO para verificar el modo de operación del radar de proximidad, y si no era LGC, los contadores del radar de proximidad se restablecían a cero.

Alan Clump estudió Ejecutivo desde una perspectiva diferente. Descubrió que cuando el TLOSS de una computadora se produce periódicamente, o el nivel de actividad de la computadora cambia en presencia de TLOSS, y la tarea del SERVIDOR no se completó, y se interrumpió cuando se ejecutaron los comandos de cálculo de posición para enviarlos al piloto automático, no se borró mediante el reinicio del software para para restaurar más tarde: en estas condiciones, existía la posibilidad de un cálculo de posición incorrecto para el piloto automático. Para el vuelo del Apolo 13, Klump desarrolló una solución en la que todo el trabajo del SERVICIO se restableció para ponerse al día si es necesario.



Fases del alunizaje

Pero en el futuro, ninguno de estos cambios nos liberó de las limitaciones de un período fijo de dos segundos del sistema de orientación. Para aterrizar en terreno difícil, fue necesario agregar un modelo de terreno al programa de radar. Se dejaron modificaciones al sistema de orientación para más adelante. No tuvimos tiempo para todo.

Desarrollamos un concepto que llamamos la "variable SERVICER", en el que el período del programa de orientación podría extenderse si fuera necesario. Los temores de que el intervalo de dos segundos está integrado en el software resultó ser infundado. Solo era necesario medir el período de funcionamiento del sistema de orientación, y usar este valor en lugar del valor de dos segundos, que se usa en solo unas pocas fórmulas. Implementamos la versión funcional de SERVICER en la versión fuera de línea de LUMINARY, y demostramos su gran resistencia a TLOSS [25].

La libertad del límite de dos segundos permitió considerar otras ideas. El astronauta John Young propuso una mejora, que llamamos P66 LPD. Pero en este momento, P66 era un programa mucho más flexible que en el vuelo Apollo 11. de Armstrong. Una de las nuevas características era que si el equipo cambiaba el modo ATT HOLD a AUTO, el sistema de orientación daría como resultado una velocidad horizontal cero. La idea de Young era que el LGC mostrara el ángulo LPD (como en la fase visible), lo que mostraría al comandante el punto por encima del cual vuela el módulo lunar si en ese momento el piloto automático se cambia a AUTO [26].

Para garantizar la precisión en el desempeño de esta función, el software tuvo que reaccionar instantáneamente cuando el astronauta cambió a AUTO, más rápido que dos segundos e incluso más rápido que el segundo período permitido, con el que trabajaron algunas partes del P66. Desarrollamos una versión en la que se iniciaba una tarea cada cuarto de segundo, verificamos un cambio en el modo de piloto automático, enviamos comandos de orientación y aceleración, y respondíamos lo más rápido y preciso posible a la entrada del interruptor ROD. En una simulación tripulada que se ejecuta en el simulador de módulo lunar (LM Mission Simulator, LMS) en Cabo Cañaveral, con sus fabulosos modelos de terreno visibles en las ventanas, mostramos que este sistema facilita un aterrizaje muy preciso.

Ni la "variable SERVICER" ni el LPD P66 han sido parcheados. La NASA ha decidido que el Apolo 17 será el último. Con tan pocas misiones restantes, el consejo de gobierno tomó una decisión conservadora: no debería haber cambios significativos en el software de aterrizaje. Al sincronizar los datos recibidos del radar de aterrizaje con la lectura de los acelerómetros, Robert Covelli liberó el tiempo suficiente para exprimir el modelo de terreno para los Apolos 15, 16 y 17 allí.



Módulo inercial (IMU) en MIT Lab

Apolo 14 le dio al autor fama a corto plazo. El interruptor de interrupción del tablero envió una señal periódica que evitó que Alan Shepard y Ed Mitchell se sentaran. Escribí un código que monitorea estos casos. Esta "muleta" simplemente cambió varios registros, el primero en engañar al monitor de interrupción de la misión para que pensara que la interrupción ya había ocurrido, y luego se borró para que el aterrizaje pudiera continuar sin consecuencias. El parche se transmitió por el aire y los astronautas lo pusieron en práctica sin problemas, este procedimiento incluyó 61 pulsaciones de teclas en DSKY. Quizás la parte más interesante del incidente del Apolo 14 fue la cantidad de versiones diferentes de esta historia. Pero el Apolo 14 es otra historia.

En diciembre de 1972, fui a Cabo Cañaveral para lanzar el barco Apollo 17. Este vuelo espacial fue increíble. El escritor Tom Wolfe, junto con la fotógrafa Annie Leibovitz, escribió un cuento corto de cuatro partes para la revista Rolling Stone, que fue el precursor de "The Right Stuff" [27]. Fue el único lanzamiento nocturno de Apolo. El cielo nebuloso de Florida arde de naranja de horizonte a horizonte cuando el enorme Saturno V se eleva hacia arriba en una columna de llamas de un cuarto de milla que se balancea al final como una llama de soplete.

Pasé varios días probando algunas de las funciones de LMS que llamamos "programación de memoria borrable". Eran parches que se suponía que debían usar VAC no utilizados y parchar algunos errores, el legado del incidente del Apolo 14. Luego volé a Cambridge para ver el aterrizaje.

Después de eso, disfruté escuchando a Gene Cernan y Jack Schmitt, un geólogo entrenando, explorando la Luna en un rover lunar, después de haber viajado más de 3 millas fuera de la vista de la nave espacial. Y esta fue la última vez que alguien caminó en la luna.



Fig. 13: Algunos de los participantes.

Gran foto, primera fila: Vince Megna, "Doc" Charles Stark Draper, autor, Dave Moore, Tony Cook; fila de atrás: Phil Felleman, Larry Berman, Allan Klumpp, Bob Werner, Robert Lones, Sam Drake. Foto pequeña, primera fila: Larry Berman, Peter Volante, el autor; fila de atrás: Sam Drake, Bruce McCoy. También participaron en los eventos Steve Copps, Romilly Gilbert, Ken Goodwin y Russ Larson.