The Guidance computer, nothing more than a complicated assembly of wrires and tiny pieces of a common element called Silicon, was sending instructions to the spacecraft's rockets...
Signals (0s and 1s) were rushing about within the computer's brain, generating information...
Eldon C. Hall
Journey to the Moon,
The history of the Apollo Guidance Computer
1996
Esta entrada esta dedicada a todos aquellos
veteranos de la computación y
los sistemas de control
en los años 1950s y 1960s
e historiadores del presente
quienes tuvieron una gran
influencia durante
los 10 años de vida que
dediqué a esta investigación:
Eldon C. Hall, Hugh Blair-Smith,
Frank O'Brien, Cline Frasier,
Robert Stengel,
Ramón Alonso, Don eyles,
Alan Green
Dale Reed,
Gary Hartman, Gordon Hardy,
Ronald Burkey,
Milt Thompson,
Hal Lanning,
Richard Battin
Primero una aclaratoria. Muchas personas me han preguntado si los viajes a la luna y los alunizajes fueron verdad o ficción. Es muy difícil determinar en el presente que un acontecimiento así haya ocurrido. En general no es posible determinar científicamente ningún acontecimiento en la historia. El método científico obliga a que un determinado fenómeno sea reproducido en condiciones idénticas al fenómeno que se afirma, repitiendo el experimento en presencia de la persona que duda del hecho. Desde esa perspectiva no es posible entonces reproducir nada del pasado (no puedo yo reproducir el momento exacto en el cual salí hoy de mi casa, y mucho menos reproducir las condiciones climáticas y de otro tipo que se estaban dando en el momento en cuestión). Para los acontecimientos históricos se debe aplicar el método legal: basado en testimonios orales, escritos, en documentación de la época, y sobre todo siempre tener una mente abierta para colocar el acontecimiento en contexto con el estado del arte de la ciencia y la tecnología en la época.
Los primeros objetos artificiales (hechos por seres humanos) en alcanzar nuestro satélite, luego de hacer todo el recorrido basado en los cálculos sobre las fuerzas magneticas ejercidas por esos potentes magnetos que son el sol, la tierra y la misma luna, fueron contruidos por la Unión Soviética. De hecho fue el talento de varios matemáticos rusos, como Lev PONTRYAGIN, BOLTYANSKII y muchos otros, y sus modelos de control Óptimo, los que usaron, durante la década de 1960, los matemáticos y científicos norte-americanos para modelar y programar los sistemas de control para los módulos lunares del proyecto Apollo, con el principio Máximo (o Mínimo) de Pontryagin como ejemplar de este flujo de conocimientos entre dos naciones en aparente conflicto. La história es compleja. El escritor León Tolstoi trata este tema en profundidad en su epílogo a la batalla de Borodino en la obra Guerra y Paz.
Esta conferencia trató sobre la historia de la tecnología aeroespacial de los años 1960s, y en especial sobre los sistemas computadores que servían de guía y control a los diseños norte-americanos. Por lo tanto, cualquier polémica sobre si esa aventura del ingenio humano fue o no realidad nada tiene que hacer aquí. Tal vez la única explicación que puede darse es que aquel esfuerzo fue una manifestación del estado y uso del conocimiento y la ciencia para los años 1960.
En contexto puede decirse que se trató de un ejemplo de uso de todo el edificio de conocimientos sobre las fuerzas y atributos que operan y poseen los objetos en el universo. Conocimiento acumulado desde las poblaciones de la antiguedad, como la Helénica, que luego fue rescatada e interpretada, en su justo valor, durante el llamado Renacimiendo y posteriormente durante el siglo de las luces o la Ilustración (también llamado, por lo anglo-sajones, el siglo newtoniano). La reformulación (reforma, pudieramos decir) al arcano cuerpo doctrinario de la geometría de Euclides, realizado durante el siglo XIX por matemáticos como David Hilbert constituye un ejemplo de esa secuencia de descubrimientos/re-descubrimientos/re-visión/re-forma. El gobierno/complejo industrial/pueblo norteamericano, tal como lo vaticinó Julio Verne a mediados del siglo XIX, fue el que reconoció que una empresa como esta sería la que mejor representaba su espíritu competitivo y de conquista, sin olvidar la visión económica sobre la explotación de los recursos disponibles en ese "nuevo oceano" (como lo indicó el presidente Kennedy en 1961).
Las fuerzas que, lamentablemente, mueven el mundo hoy no incluyen las condiciones necesarias para la creación de conocimiento que permite interpretar este enorme espacio que llamamos Universo. Algunos de estos elementos pudieramos nombrarlos: reflexión, contemplación, meditación y acción como último elemento en la secuencia. Las leyes que gobiernan el movimiento en el Universo, al igual que los objetos de la matemática, son creaciones del intelecto humano. Todo ha ocurrido dentro de nosotros. Tal vez es ese el origen de las teorías de conspiración que dicen que nada de estas creaciones ocurrió. Cuando un ser humano está sometido a influencias como las que imperan en el mundo actual, su mente no es capaz de imaginarse (tener la meditación, reflexión y capacidad de contemplación necesarias) la correlación intrínseca entre las leyes matemáticas, firmemente sustentadas, que han llevado a predecir la influencia magnética que los objetos ejercen entre sí en esta enorme red interconectada da la cual somos parte y manifestación al mismo tiempo.
Breve Glosario:
AGC -> Apollo Guidance Computer (computador de guía/control/navegación de Apollo)
IMU -> Inertial Measurement Unit
CDU -> Couple Display Unit
DAP -> Digital Autopilot (software del piloto automático digital de Apollo)
FPGA -> Field Programmable Gate Array (circuito integrado VLSI configurable)
PNGS -> Se pronuncia "pings"; es el sistema digital para la guía y navegación en las aeronaves Apollo. Se trataba de un ente abstracto que abarcaba al AGC, al IMU (Plataforma Inercial), la circuitería que resolvía la posición de los ejes de rotación de la Plataforma IMU convirtiéndolas en pulsos digitales, a través del CDU (conversor Analógico-Digital/Digital-Analógico), los instrumentos ópticos (Telescopio y Sextante) y la interfaz con el usuario (DSKY).
Es importante aclarar que PINGS no era la fuente principal de referencia en la navegación/guía, este papel lo cumplía una red enorme de Atenas y redes de telecomunicación llamada "Deep Space Network". Esta red enviaba datos actualizados sobre posición a PINGS. La posición en el espacio era relativa a una Matriz de Referencia (REFSMMAT). Existía una Matriz de Referencia (REFSMMAT), en ejes Pitch, Roll, Yaw, para cada momento de la misión lunar; por ejemplo: en la superficie lunar, la referencia era Pitch = 0, Roll = 0 y Yaw = 0; luego, cualquier desviación (diferencia) de esta referencia inercial, durante el vuelo, era calculada por PINGS y mostrada a los pilotos en un horizonte artificial en la cabina. Dicha Matriz estaba almacenada en la memoria lectura/escritura del AGC y estaba definida en el listado fuente de programa como:
E3,1733 REFSMMAT ERASE +17D
La programación del Software que "habitaba" dentro de PINGS (su espíritu) se hacía en dos tipos de lenguajes de programación. La programación básica operacional se hacía en un lenguaje Assembler llamado YUL (diseñado por Hugh Blair-Smith - ver referencias [1], [2]). En YUL se programaba el Software básico de Control e interfaces. La programación del Software de guía y navegación (incluido el piloto automático digital) se hacía en un lenguaje interpretado cuyas instrucciones (códigos de operación) operaban sobre datos del tipo vectorial y matricial (ver referencia [1]).En el siguiente enlace puede revisar una lectura sobre la Cronología de los sistemas de control Aeroespaciales. Esta presentación abre el contexto sobre el tema que publico en esta entrada y sobre lo expresado en el paper publicado conjuntamente con la presentación. El tema tratado en el paper "ATTITUDE CONTROLLER ASSEMBLY INPUT PROCESSING" requiere una lectura más detallada. Así que recomiendo la revisión de la presentación y luego la lectura del paper (más abajo se incluye un acceso directo al paper). La idea central de esta investigación es el estudio de los sistemas de control del tipo "Model Following" o de seguimiento de modelo. Existen dos (2) métodos para ejercer control sobre un mecanismo que se desplaza en un medio. El primer método instruye que la reacción del controlador debe estar dirigida por la suma algebraica entre el comando de guia y una ó varias medidas tomadas del medio externo a traves del cual se desplaza el mecanismo controlado. El segundo método instruye que el controlador debe incluir un modelo del comportamiento "ideal" del mecanismo en su desplazar a traves del medio. Para lograr esto último el modelo debe ser una representación analógica o digital de la respuesta "ideal" del mecanismo. Además, a este método de ejercer control se le denomina "Self-Adaptive" o adaptivo. El ambito aeroespacial fue, históricamente, el que motivó el desarrollo de esta teoría del control. Para el final de la década de los años 1950 el avión cohete experimental X-15 incluía un sistema del tipo "Self-Adaptive" con una red electrónica analógica implementando el modelo "ideal". Para finales de la década de 1960 las naves Apollo incluían varios de estos controles "self-Adaptive" para el calculo de la navegación, guia automática y para ejercer las acciones de control. Los controles en Apollo estaban implementados digitalmente en Software (programas almacenados y ejecutados en el Apollo Guidance Computer):
http://klabs.org/mapld04/presentations/session_p/p202_portillo_s.ppt
Figura 1. Junto a Eldon Hall en el mostrador de NASA Office of Logic Design junto al Display/Keyboard del Módulo de Comando del Apollo 16
(Hall fue mi tutor en el hardware del AGC desde 1997)
Figura 2. Eldon Hall mostrando la red de Interconexiones de la Microarquitectura del AGC Block II
Se realizó el desensamble de un Computador de Guía y Navegación utilizados en las naves Apollo a la Luna.
Figura 3. Revizando la sección de los módulos de Memoria del AGC Block II
Figura 4. Microchip (NOR Gates) encapsulado. Fabricado por Philco-Ford
Se seleccionó el tipo de compuerta NOR, como elemento lógico
básico por su bajo consumo eléctrico y su uso general que permite construir
otros tipos de compuertas (AND, OR, NOT) usando las proposiciones de Augustus De Morgan:
(AV B)^c = A^c Λ B^c
(A Λ B)^c = A^c V B^c
Figuras 5, 5.1 y 6. El computador AGC Block II fue el primero en tener toda su lógica y Microarquitectura completamente diseñada (nada de forma Canónica ni mucho menos FPGA!) en base a un Microchip Planar de compuerta lógica (NOR Gate) de doble compuerta(izquierda en el diagrama). Un ejemplo de la red de compuertas lógicas para un sumador de un bit con acarreo (derecha arriba en el diagrama) diseñada por Albert Hopkins, Hugh Blair-Smith y su equipo en el MIT/IL. La foto inserta (centro en la imagen) muestra el gabinete de interconexiones de los módulos lógicos en los cuales estaba organizada la lógica digital como la que aparece en el diagrama. Las interconexiones entre los módulos lógicos eran "tejidas" por una máquina herramienta guiada por tarjetas perforadas (Gardner-Denver machine)
En la figura 3 aparece la interconexión del tray A. Existe
otro tray B conteniendo los módulos lógicos. Cada módulo lógico alberga 120
chips de doble NOR-Gate de tres entradas cada una. Toda la arquitectura del
computador, conjuntamente con la fuente de poder y el reloj oscilador está
contenida en una estructura de aluminio-magnesio bañada en color dorado (figura 6) para
aumentar la pasividad de la superficie a través de una capa de óxido que
impedía la corrosión.
Presentes en la sesión de trabajo estuvieron:
* Eldon C. Hall - Director del Proyecto de construcción del Computador AGC
* John Young - Astronauta de la Nasa, Misiones: Gemini III, Gemini X, Apollo X, Apollo VI, STS-1, STS-5
* Hugh Blair-Smith - Diseñador del Microprograma y de la Matríz de Decodificación que interpreta y ejecuta las instrucciones dentro del computador AGC
* Cline Frasier - Enlace entre la oficina de la Nasa y el MIT (ideó y dio impulso inicial a la creación de un piloto automático digital o DAP en lugar de una red electrónica complicada y pesada)
* Ramón Alonso - Diseñador de la primera versión del AGC
* Profesor/Escritor James Tomayko (Fallecido en 2006) - Escritor de varios ensayos monográficos en historia de la Tecnología Aeroespacial e Ingeniería de Software
* Frank O'Brien - Historiador del Programa Apollo y Piloto Licenciado
Video de la presentacion de Eldon C. Hall:
https://www.youtube.com/watch?v=Xtsrcc0c8Mo
Video de la presentacion de Cline Frasier:
https://www.youtube.com/watch?v=9FCii5-Etcg
Video de la presentacion de Hugh Blair-Smith:
https://www.youtube.com/watch?v=_sY662Op9AI
Video de la presentacion de Ramon Alonso:
https://www.youtube.com/watch?v=h1bCCiUkIrY
Figuras 7 y 8. El Astronauta, el Diseñador (junto a John Young y Eldon Hall). Foto tomada por el historiador y computista Frank O'Brien.
Astronauta John Young ingresando comandos en la interfaz del computador Apollo llamada DSKY (Display/Keyboard) del simulador del Módulo de Comando antes de la misión Apollo 10. Young fue la primera persona en operar una computadora en el espacio (Gemini III) y además tiene la distinción de ser el primer astronauta en viajar a la luna dos veces (Apollo 10, Apollo 16 - la tripulación del Apollo 10 tiene el record guinnes como la mayor velocidad alcanzada por seres humano: 40.000Km/h). Posteriormente fue el comandante de la primera misión del transbordador espacial Columbia en 1981.
Figuras 9 y 10. Eldon Hall (MIT/IL) con un AGC Block II en 1966, y un AGC Block II en 2004
Figura 11. Demostración del AGC - Ejecución del VERBO=16 + SUSTANTIVO=65 + ENTER , para ordenar al AGC mostrar su conteo de tiempo interno en Horas/Minutos/Segundos/Milésimas de segundo (imagen tomada de un video promocional del MIT/IL de 1965)
Figuras 12 y 13. Iniciando la presentación
(a mi izquierda el listado original del programa Luminary en Assembler YUL y del Intérprete del AGC; al frente un DSKY Block I)
Figura 14. Diagrama de las rutas eléctricas tomadas por el comando manual del Piloto en el Módulo Lunar Apollo y posterior proceso por parte del Piloto Automático Digital (DAP) [3]
Módulo de Interfaz conteniendo el Circuito "A" Analógico/Digital que se muestra en el diagrama arriba
Figura 15. Hugh Blair-Smith - Diseñador del Assembler YUL y de la arquitectura del AGC, mostrando el listado del programa Luminary. (Blair-Smith ha sido mi tutor en la parte de Software de Apollo)
Figura 15.1. Sección del programa LUMINARY correspondiente al major mode P66 de alunizaje (foto tomada al listado de Donald Eyles en Cambridge, MA - 1999)
Figura 16. Prof. James Tomayko (Murió en 2006)
Figura 16.1.
Un elogio a la locura. Correo enviado por George Cherry luego de leer el ensayo monográfico. Cherry fue el líder del grupo que diseñó el piloto automático digital Apollo a comienzos de los años 1960 (bajo su dirección estuvieron programadores y técnicos del MIT como Donald Eyles). También participó en el diseño de las ecuaciones de guía de aterrizaje lunar que fueron "mecanizadas" en el computador Apollo del módulo lunar, a parte de diseñar también el esquema de guia para el aterrizaje. Posteriormente (como el mismo lo dice en su email) ejerció la dirección del sistema de navegación, guia y control (PNGCS) para el módulo lunar Apollo (hay varias referencias a su trabajo en el libro de la colección Nasa History Series titulado "Chariots for Apollo" y en una página conmemorativa del Apollo 11 en la web del MIT - http://web.mit.edu/newsoffice/2009/apollo-vign-0717.html):
>From: gwcherry ...
>To: jportillo34@hotmail.com
>Subject: Lunar Module Attitude Controller
>Date: Sat, 07 Aug 2004 03:16:36 +0000
>
>Hi Jose R. Portillo Lugo:
>
>I just discovered your paper on the Apollo Lunar Module DAP. Your paper
>is a wonderful addition to the still-growing literature on the Apollo PNGCS.
>
>My name is George W. Cherry. I originated the design of the LM DAP
>before I became the LM PNGCS project manager.
>
>How did you come to write your masterful paper and how did you acquire
>so much info about the hardware and software?
>
>George W. Cherry
>gwcherry...
Cherry fue el creador de las ecuaciones de guía (pilotaje) que hacian uso del motor de potencia variable del módulo lunar Apollo durante el descenso y aluniaje. Dichas ecuaciones fueron luego mecanizadas (como flujo-gramas y codificadas en el lenguaje Interpretive y Basic de YUL), por los programadores Allan Klumpp y Donald eyles, en el programa LUMINARY del módulo lunar. [13]
Kenneth Cox, el líder de la Systems Analysis Branch, Guidance and Control Division, definió al Digital Autopilot así:
-"The LM DAP, with respect to design requirements and constraints, is considered to be the most complex Apollo control system in use" [14]
Richard Gran, uno de los ingenieros que formó parte del equipo de Cherry en el diseño y programación del piloto automático digital de Apollo cuenta lo siguiente (tomado de MATHLAB News & Notes) -
https://www.mathworks.com/company/newsletters/articles/fly-me-to-the-moon-then-and-now.html):
- Cita "Fly me to the Moon - Then and Now", Richard Gran
In 1962, "modern control theory" was still an academic pursuit. There were no textbooks written on optimal control and recent graduates, including me, were not yet versed in state-space methods and certainly had not been exposed to optimal bang-bang control systems. Engineers at MIT IL worked very closely with students at MIT and, as a consequence, were early adopters of state-space modeling and optimal control techniques based on Pontryagin's Maximum Principle. One of the engineers at the Instrumentation labs, George Cherry, proposed using an optimal control system for controlling the vehicle. The unique insight created by using this approach was that the almost perfect knowledge of the dynamics of the rotational motion of a spacecraft in space allowed the control to be done at a very slow sample rate.
At the NASA meeting where members of each design team presented their approach, George Cherry invoked the image of Sir Isaac Newton standing by his side and telling the controller what to do. Needless to say, NASA selected the MIT design, and the decision to select this approach was the right one. The Grumman design required a sample time of .02 seconds or faster, whereas the MIT approach (with Newton's help) only required a sample time of 0.2 seconds (ten times slower than Grumman's design). Since MIT IL needed engineers at the time, a once-in-a-lifetime opportunity came my way to go to Massachusetts on a field assignment for Grumman. I became one quarter of the LM digital autopilot design team. (Yes, for over three years only four people worked on the autopilot.)
The optimal controller developed by Cherry during the design competition was one that minimized a weighted mix of time and fuel.
...
The computer speed and storage limits imposed severe constraints. For example, most control systems engineers would implement this controller by looking at the attitude and rate at some fast sample time to decide where in the phase plane the system currently was. Based on this, the jets would be either turned on or off. In fact, this is the way the autopilot was implemented when the space shuttle was designed. However, the computer constraints on the LM meant that this strategy would not work since there was not enough processing power to allow fast sample rates. Enter Newton.
When the MIT IL team proposed their autopilot, they proposed that the control be done by sampling the attitude and rate at a very slow rate. If these measurements were such that the jets needed to be turned on to correct the attitude error, a calculation of the time needed to reach the off-switch curve was computed, and the jets were turned on. The jets were turned off at the appropriate time using a counter in the computer to create an interrupt (hence the reason we needed two levels of interrupt) that would process the turn-off command. This was the fundamental idea that allowed the long sample times. It was accurate because of the low measurement noise and the ability to precisely predict the trajectory in the phase plane. The only uncertainties were the precise value of the acceleration due to variations in jet thrust, imprecise knowledge of the vehicle inertia, and the noise in the measurements. With this scheme, MIT IL was able to demonstrate that the autopilot needed to be sampled at 0.2 seconds (0.1 seconds during the ascent from the moon when the LM inertias were small and the acceleration was large). NASA was so impressed by this structure that they decided not only to implement this LM autopilot, but to make it the primary system and relegate the analog system as the backup.
- Fin de cita "Fly me to the Moon" -
Otro elogio a la locura. Correo de Ronald Burkey (líder del proyecto Simulador del Apollo Guidance Computer - "Virtual AGC"):
- Cita Burkey
"Hi José,
I attended your talk at MAPLD '04. Actually, I think we briefly corresponded (prior to your talk) about some details in your paper. Your paper is a great resource, and I think it would probably have been much more difficult to implement the simulated LM rotational hand controller in my project if you hadn't done all of the groundwork in figuring out how the hardware and software fits together. So thanks for the great work you have done! I'm sorry I didn't think to convey my appreciation earlier".
Burkey es un matemático de la Universidad del Estado de Ohio co PhD. en física. Ha creado varios proyectos del tipo Free Software (GNU) y es colaborador desde hace varios años en el proyecto Gutenberg. Ronald no solo es mayor en edad que quien escribe; es también diez veces más creador y trabajador en tiempo libre. A Burkey, conjuntamente con muchos otros, se debe la publicacion del codigo fuente de los programas COLOSSUS y LUMINARY (el software de las aeronaves Apollo). Ahora son de dominio publico, pero en el ano 2003, cuando yo iniciaba mi monografia, no existian estos recursos. Por un contacto me entere que un listado del LUMINARY (programado para el Apollo 13) habia sido colocado en un site. Pero, previo al 2006 era dificil encontrar estas fuentes. Hoy dia, el Virtual AGC ofrece una plataforma virtual para disenar y programar, idea similar a la virtual pipeline MMIX de Donald Knuth. Los trabajos de investigacion, previos, como el que ocupo mi tiempo aquellos años fueron la base para la programacion del Virtual AGC. De la pagina del proyecto Virtual AGC
-"yaACA, yaACA2, and yaACA3 - The Attitude Controller Assembly (ACA)—also known as the rotational
hand-controller (RHC)—is used by astronaut to affect the pitch, roll,
and
yaw
of the LM. José Portillo has described the interaction
between the ACA and
AGC in great detail in a paper which is the basis of all ACA-related work in Virtual AGC."
La interfaz ACA - AGC era una de las mas complejas en las aeronaves Apollo. La medicion de las senales emanadas desde el ACA, por parte del computador AGC, aparecian en varios sub-programas (Major Modes y el Digital Autopilot) del programa LUMINARY y el procesamiento ocurria en diferentes niveles de abstraccion. Por ejemplo, la seccion de procesamiento P iniciaba, dentro del Digital Autopilot un flujo de trabajo que finalizaba con el encendido de los cohetes de control de actitud del navio. Este era el nivel mas bajo (Control). Luego venia el procesamiento de comandos seudo-manuales o semi-manuales que ocurria en la seccion del programa llamada "Lunar_Landing_Guidance_Equations", a traves de los cuales el piloto/usuario podia intervenir en el flujo de procesamiento del pilotaje automatico de alunizaje. Esto ultimo ocurria a un nivel de abstraccion mas elevado (Guidance) y con ramificaciones interesantes como el uso de una escala (tipo nomograma) dibujada en la ventana izquierda del navio en la cual el piloto/usuario podia observar, previo conocimiento de un numero de dos digitos decimales producido por las ecuaciones de pilotaje automatico, el sitio estimado de alunizaje calculado por el AGC. Usando la interfaz del ACA, el piloto/usuario podia ordenar cambiar el sitio estimado de alunizaje por otro mas conveniente a los objetivos de alto nivel de la mision (topografia del terreno a explorar, evitar obstaculos como crateres profundos y pedregosos). [3]
Página principal del proyecto del Virtual AGC de Donald Burkey:
http://www.ibiblio.org/apollo/index.html
El texto "Journey to the Moon: the history of the Apollo Guidance Computer" escrito por Eldon C. Hall es el primero en su tipo [4]. Uno de los jefes de Hall fue el científico de la computación Hal Laning. Laning creo el "sistema operativo" del computador Apollo, llamado Executive/Waitlist. También fue Laning el creador del languaje algebraico George en el cual John Backus y su equipo de IBM basó su diseño del lenguaje Fortran. Así que el lenguaje de Laning puede considerarse como el verdadero abuelo de los lenguajes de programación [1].
Actualización Abril, 2008:
Libro escrito por el prof. Mindell y publicado por el MIT llamado "Digital Apollo".
http://web.mit.edu/digitalapollo/chapter8.html
Actualización 2012:
Libro
escrito por Frank O'Brien titulado "Apollo Guidance Computer" [10].
La comunidad de entusiastas del AGC ha crecido mucho desde los años en los cuales inicié mi estudio. Hasta el momento de escribir estas líneas, existen desarrollos y ejemplos de uso complejos. Todos los listados fuente de los programas LUMINARY, COLOSSUS y COMANCHE han sido transcritos/copiados (desde las impresiones originales) hacia la Web. El simulador de Burkey y su equipo de desarrolladores GNU (Virtual AGC) permite ensamblar y ejecutar cualquier programa escrito en YUL/Intérprete. Después de 50 años, desde la época en la cual el Dr. Laning y Battin "orbitaban" virtualmente al planeta Marte en una IBM 650, aún sigue este mundo virtual de Apollo, ejemplos de matemáticas aplicadas.
Antecedentes a la Conferencia
En un período de ocho años (1995 a 2003), en paralelo a mi trabajo profesional, hice una especie de carrera en historia de la computación.
Este esfuerzo por investigar en las raices de la evolución de esta técnica llevó por varias bibliotecas en el mundo y en el uso adecuado de ese enorme computador llamado Internet (una evolución en sí mismo de la red Deep Space Network que armaron para el proyecto Apollo). Se hicieron varias entrevistas, entre los años 1998 a 2003 con científicos, matemáticos, programadores e historiadores como Eldon C. Hall, Hugh Blair-Smith, Cline Frasier, Ramón Alonso, Frank O'Brien, Robert Stengel, Gary Hartman, Gordon Hardy, James Tomayko y Donald Eyles.
En Enero de 1999 tuve el privilegio de pasar unas horas en el Draper Laboratory (otrora MIT/Instrumentation Lab), junto a Eldon C. Hall y a Dave Bates, viendo y palpando por vez primera una estación de navegación del Apollo que tenían allá (en el 2003 fue trasladada hacia el Museo del Cumputador). En esa misma visita se hizo una revisión bibliografía en la biblioteca del MIT.
Figura 17. Junto a Eldon Hall y frente a los circuitos aritméticos (dígitos de los registros acumuladores) del computador Whirlwind I en el Computer Museum en Boston - Enero 1999. En la imagen derecha el Astronauta de Apollo Dave Scott (Apollo 9, Apollo 15) junto a Eldon Hall en el Draper Lab y con una estación de navegante del Apollo - 1982. Se observó de cerca esa misma estación durante la visita incógnita al Draper Lab en 1999 junto a Eldon y Dave Battes. Dave Battes trabajó junto a Eldon en el proyecto del misil Polaris y junto a Werner Von Braun en el arsenal Huntsville en la parte de electrónica de misiles. En ese entonces el MIT/Draper Lab tenían el contrato para escribir el software de la estación espacial internacional.. Otros veteranos del proyecto Apollo, presentes aquel día en 1999 fueron: Cline Frasier (Enlace entre la oficina de astronautica Nasa y el Instrumentation Lab y quien propulsó la idea de usar la capacidad computacional del AGC para implementar, en software, un piloto automático digital para ambos módulos CM y LM); Ramon Alonso (Diseñador original, junta a Halcombe Laning, del computador Apollo y de su interfaz Verb-Noun en el DSKY); Donald Eyles (programador e ingeniero de software del computador Apollo quien programó los programas o Major Modes P64 y P66); Norman Sear (Coordinador del proyecto por MIT/IL); Alan Green (programador de la interfaz DSKY del computador). Con muchos de ellos mantuve una relación histórica muy nutritiva y enriquecedora para todos. Finalmente los encontré de nuevo en 2004.
Uno de los relatos más interesantes que pude recabar viene de Cline Frasier quien, durante los años que duró el proyecto de diseño de los sistemas del Apollo (primero en la historia en ser controlado enteramente por computadoras, a bordo y desde la tierra), hacia el enlace entre la oficina de la NASA en Houston y el MIT en Cambridge. Frasier fue el que encendió la chispa que motivó el uso de un sistema de piloto automático enteramente en software. Es un ejemplo de cuan bien se manejó ese proyecto y por lo cual es muy recordado. Esto fue lo que me contó Frasier
-"The first summer we were in Houston, daytime temperatures were from 35-42C. When it got to 42, the humidity went down to about 60%. From April to November, most of the time the temperature was close to 35C and the humidity high.
Today, we are having that kind of weather here.
The following is Cline's version of the DAP adoption. (I think I have the dates about right -- at least the sequence is right.
Dr. Joe Shea came to Houston to take over as Apollo Spacecraft Program Manager early in 1964. He brought in Dr. Clifford Duncan (an active duty U.S. Navy Captain who had been serving in DARPA) to head up the Guidance and Control Division.
Duncan then conducted a review of the GN&C system in the spring of 1964.
This review included a trip to MIT/IL, North American, Honeywell (the SCS contractor for the Command Module) and possibly Grumman. The people were Duncan, Chilton (the previous Guidance and Control Division Chief), Col.
Duffy (Air Force, Minuteman Program), another AF Col., myself (as a representative of the Crew Systems Division) and one or two others (possibly Tom Chambers).
During the meeting at Honeywell, it was clear that the current overall guidance, navigation and control (GN&C) system configuration was not going to work. It was too heavy and the redundancy concepts were not worked out (and complex). (At least it seemed clear to me, and I think it was to others -- but there seemed no other solution at the time.)
It was on this trip that it seemed to me that a simpler, lighter and more reliable approach would be possible if a DAP would work. There also seemed to be advantages to making the ground system (the MSFN) the primary navigation source, and eliminating one of the two AGC computers in the design for the CM. Now, I was a very junior person (a first line supervisor only), did not have any GN&C experience except about 1.5 years of looking at the Gemini and Apollo systems from the point of view of the crews use.
So, I kept my mouth shut during the trip.
After we got back, I was in a meeting with Dr. Duncan. I suspect that the meeting was about Apollo GN&C. Sometime during the meeting (I suspect it was at a bio break), I talked to Duncan about the configuration I thought might solve most of the problems (it was the configuration actually used for Block II). Duncan's response was to offer me the job of his technical assistant to work on the ideas. The job, and the promise of a pay grade promotion, made it sound great -- I jumped at it.
Then, I became the point man (or lightning rod) to push the ideas. I gave the briefings to Dr. Shea (with lots of coaching and support from Duncan), and ultimately to the President's Scientific Advisory Council -- PSAC (advisors to President Johnson). I was also the one sent to MIT/IL to tell them that they were going to do a DAP, that they no longer had the primary navigation system and that one computer was going to be eliminated.
Along the way, virtually everyone was against the idea of a DAP, and some of the other concepts that went along. MIT/IL was concerned that they could not make a DAP work in the computer design they had. They did not like losing primary navigation responsibility. Eldon Hall was concerned about the losing the redundant AGC. North American did not like the diminishment of their control system responsibilities. Virtually all the NASA and contractor control system experts "knew" that a DAP would not work satisfactorily. The astronauts were totally opposed.
Luckily, there were forces on the other side. The CM had a real weight and reliability problem -- and no solution from the conventional approaches.
Both the Minuteman and Titan ICBMs had used DAPs. Dr. Shea had proposed a DAP for the Titan program (against the advice of the people who made the booster), and Shea then led the program that made it work -- before coming to NASA. The DAP system configuration was clean, and I did the reliability analyses that showed better probabilities of crew safety and mission success (I presented these to the PSAC as part of the justification for the unconventional design).
North American bowed gracefully to the inevitable when Dr. Shea told them they were going to go with the DAP, or he would crack heads. The MIT/IL folks were really good troops. They were concerned, and there were some things they didn't like, but they dug in to make their part work.
With the CM configuration more or less settled, everyone got to work to make it a reality.
Obviously, we had many of the same issues with the LM. This was attacked next. The Grumman folks were a much tougher nut to crack. And, the control system of the LM was near and dear to the hearts of the astronauts.
Fortunately, all was overcome by LM weight problems, some very good DAP work by George Cherry, Bill Widnall and others at MIT/IL, and the precedence of the CM system. If we had tackled Grumman and the LM first, I doubt that we would have had a DAP.
At this point, my involvement in the DAP about vanished. My contribution was system configuration. It was people who really knew what they were doing that made the configuration work.
My next challenge was the CSM and LM rendezvous radars. North American could not find an acceptable mounting location for the backup RCA rendezvous radar. The same radars were to be used on the CSM and the LM and there was another problem. The radar development was having trouble making things work. This was when I realized that some of the accuracy analyses done by Norm Sears at MIT/IL suggested that we could rendezvous without range, or range rate, measurements if we could measure the angles accurately enough. Since the CM sextant would measure well enough, the thought was why not just eliminate the CSM radar.
The problem with this idea was that the visibility analyses indicated that you could not see the LM in the sextant at the distances required. Then, I found a mistake in the visibility analysis (an exponent had either been dropped or added -- I don't remember which). With the correct equation, it looked like we could use the sextant. So, my proposal was to eliminate the radar and rendezvous optically. To make everyone feel better, I also proposed measuring the range by modifying the voice communications radios to add ranging tones (like the scheme used by the radar). This overall scheme solved a technical problem, reduced Service Module weight by over 100 pounds and probably cut costs by around $40,000,000. It was adopted, and this is what flew. All optical rendezvous was tested on one mission and it worked as expected.
The next obvious thing was to try the same approach on the LM. There we could replace the PGNCS alignment optical telescope (AOT), a passive device, with an equal weight optical tracker and eliminate the rendezvous radar. This was appealing because the radar did not work and the weight reduction would be just about what the LM needed at that time.
As usual, the "experts" said that an optical tracker could not be developed to the specs needed and, if it could, it would take five years.
The LM and radar programs were in enough trouble that I got the money to develop the optical system in parallel with the radar. With superb work from the crew at AC Electronics (the people who actually built the PGNCS) and Hughes, the optical tracker (LORS) was designed, built and went through a competitive qualification evaluation with the radar -- all in 12 months.
By the time the competitive evaluation was complete, Grumman had found more ways to reduce the LM weight and RCA had a working radar. When the two systems were compared, they were about equal in future cost, the radar was ~75 pounds heavier and the radar was considered to have lower mission risks. So, the radar was kept.
My personal opinion is that the competition from the optical tracker system made a real contribution to getting all the radar related problems solved.
This is an opinion only, with no way to demonstrate what might have been without the optical development.
The optical stuff was about the last significant configuration thing I did on Apollo. As soon as it was going, Dr. Duncan put me in charge of getting all the PGNCS hardware built and qualified. My role changed from overall configuration to solving gyroscope bearing, relay, and other design and manufacturing problems.
Lots of fun to get it all done. After Apollo 8 went around the moon, I started to mentally disengage. I knew the design would work and knew that there might be a random component failure. After about Apollo 11, I worked on the electronics configuration for the Space Shuttle -- and set up pretty much what they are flying.
This narrative is in response to your question about my involvement. I had a couple of key system configuration ideas. They would have been of no value without the support I got from Duncan and Shea, and without the expertise and hard work of the literally thousands of people who took the concepts and made them into reality. I could list a long series of names who were absolutely essential to PGNCS. I was really lucky -- the right spot at the right time, with the right support and working with a lot of wonderful people.
Then, in June, 71, I went to MIT's Sloan School of Management for a year.
In the summer of 1973, I left the space program -- and didn't look back until recently." [12]
Figura 18. Visita al MIT/Draper Lab en Cambridge MA. De arriba hacia abajo: Donald Eyles (programador de las subrutinas del ciclo de alunizaje P64 y P66); Prof. John Deyst (creador de las ecuaciones del Two Body Problem usadas en la navegación Apollo. El texto "Astronautical Guidance" por el Prof. Richard Battin hace referencia a una solucion al problema de Lambert creado por Deyst, ver articulo "Interpretes" en este mismo Blog)
Hasta finales de la decada de 1990, la documentacion sobre procedimientos, interfaces y software de las aeronaves Apollo era aun escasa. Ejemplo de ello es la siguiente nota que intercambie con Donald Eyles en 1998, en relacion a su participacion en la creacion del procedimiento de contingencia para hacer un bypass del boton ABORT que fallo durante el alunizaje del Apollo 14 en 1971
-"
You are quite right that
the Apollo 14 procedure was relayed by voice.
In fact, the Apollo 14
procedure did not use instructions, as such.
The keystrokes that were entered were to change the value of certain
registers, or bits within a register, directly.
Certain other
contingency procedures were developed, called “erasable memory programs” or EMPs, that did in fact use instructions. In these cases the instructions were to be
stored in unused areas that were available to the executive for allocation to
new tasks and jobs, but which were known not to be used during the landing
phase.
I appreciate your
interest in an area that unfortunately has not received much documentation and
would be hard to learn about, even in the United States."
Figura 19. De arriba hacia abajo: Visita al Draper Lab (anterior MIT/Instrumentation Lab) junto a Eldon Hall; Alan Green (programador de las subrutinas PINBALL manejadoras de la interfaz DSKY)
Figura 22. ¿Por qué el AGC Block II tenía color dorado? Tomado de una entrevista a Eldon C. Hall -"The computer was a gold color
for thermal reasons. That is the best
color to reflect radiant heat. The heat
generated by each electronic assembly was supposed to be conducted into a cold
plate which was part of the mounting structure." [12]
Referencias y bibliografía recomendada
(algunas referencia llevan a páginas y documentos al presionar sobre sus títulos)
[1] Portillo, José - "
Diseño de computadores en 1950s, interpretes y el arte de diseñar lógica digital... 1ra parte" - 2010
[2] Portillo, José - "
Conferencia NASA MAPLD 2006" - 2007
[3] Portillo, José - "
Attitude Controller Assembly Input Processing" - 2004
[4] Hall, Eldon C. - "Journey to the Moon" - 1996
[5] Battin, Richard; Martin, Frederick - "
Computer-Controlled Steering of the Apollo spacecraft" - Journal of Spacecraft - 1968
[6] Gran, Richard - "
Fly me to the Moon - Then and Now" - 1999
[7] Stengel, Robert - "
Manual Attitude Control of the Lunar Module" - 1969
[8] Scott, David - "
The Apollo Guidance Computer - A Users View" - 1982
[9] Mindell, David - "
Digital Apollo"
[10] O'Brien, Frank - "The Apollo Guidance Computer"
[11] Hall, Eldon C. - "
From the farm to pioneering with digital computers: An autobiography" - 2000
[12] Entrevistas a Eldon C. Hall, Cline Frasier, Ramón Alonso, Hugh Blair-Smith, Frank O'Brien, Robert Stengel, Donald Eyles, Gary Hartman - 1997-2003
[13] Klumpp, Alan - "A Manually Retargeted Automatic Landing System for the Lunar Module (LM)" - Journal of Spacecraft and Rockets - Febrero, 1968
[14] Cox, Kenneth J. - "A Case Study of the Apollo Lunar Module Digital Autopilot" - 1969
Visita al Air and Space Museum en Dulles (el Transbordador Enterprise está al fondo)
(Hacer click para ver el detalle)
Astronauta/Piloto de Pruebas Fred Haise
Tuve el privilegio de pasar una tarde en el Air and Space Museum junto a Frank O'Brien y a Hugh Blair-Smith. Ambos, O'Brien y Blair-Smith (al igual que Eldon Hall, Frasier y otros) fueron mi guia y mis compañeros durante los años que dediqué a estudiar el computador de Apollo. En la foto de izquierda a derecha: el Piloto/Historiador, el Historiador loco y el Diseñador del AGC (O'Brien, Portillo Lugo y Blair-Smith) frente a la capsula de comando del Apollo XI.
