¿Cómo funcionaba la computadora de guía Apollo con tan poco poder de procesamiento?

Aquí hay algo que la mayoría de la gente no se da cuenta de su humilde computadora en casa. La mayor parte de su potencia de procesamiento es utilizada por el sistema operativo gráfico.

De hecho, a menos que esté jugando un juego, transmitiendo video, hablando con satélites GPS, o usando hojas de cálculo para calcular números o algo así, la mayoría de las veces, la mayoría de las computadoras no hacen más que administrar la elegante interfaz gráfica de usuario y ejecutar docenas o cientos de subprocesos, la mayoría de los cuales son de poca utilidad la mayor parte del tiempo, pero pueden ser útiles de vez en cuando.

Cuando comencé a programar, tenía una Apple IIe con un procesador Rocket Chip de 4 MHz, y podía hacer la mayoría de las cosas que necesitaba hacer mucho más rápido que en una máquina moderna de doble núcleo con Windows. Eso es porque estaba usando herramientas de modo de texto: hojas de cálculo, procesadores de texto, compiladores y similares, y tenían mucho, mucho menos procesamiento que hacer para lograr el mismo objetivo.

La computadora de guía Apollo tenía una interfaz mucho, mucho más simple que la Apple IIe. Su interfaz funcionaba así:

1. Escribe el código numérico * sin sentido para el programa deseado.
2. Escribe un código numérico igualmente sin sentido para la operación que desea y presiona la tecla “sustantivo”.
3. Luego escriba el código numérico sin sentido para el operando con el que necesita trabajar (para refinar la operación o alimentar sus datos) y presione la tecla “verbo”.
4. A continuación, el AGC mostrará un error (porque tocó un código numérico sin sentido, primate torpe) o esperará a que confirme que realmente desea continuar, o le pedirá más datos parpadeando todavía otro código numérico sin sentido para que usted entienda y reaccione.
5. Cuando esté listo, no preguntará “¿está seguro?” En una ventana emergente agradable y legible. Simplemente mostrará lo que ingresó como una videograbadora después de un corte de energía y esperará a que presione la tecla “ejecutar”.

Esta no era una interfaz amigable. Algunos de ustedes recordarán haber jugado juegos primitivos en la primera generación de calculadoras programables con una interfaz similar (y renunciar a dichos juegos porque eran una molestia). Esta no era una interfaz que cualquier persona en su sano juicio propondría para un producto de consumo convencional (aunque era similar a la interfaz de las primeras computadoras domésticas, las vendidas por Heathkit y Altair para entusiastas de la tecnología doméstica, el tipo de personas que construyen sus propios televisores y radios en el pasado solo por diversión, y aquí creías que vivías en la era de los creadores.

Una vez que el AGC recibió la instrucción adecuada, la mayoría de sus operaciones fueron bastante simples: cosas como extraer las medidas del ángulo de la plataforma inercial y el sextante y usar esos dos números para calcular la orientación de la nave espacial en relación con una estrella almacenada en la memoria (y seleccionada por la tripulación por número de índice). Durante las maniobras fue cuando el AGC tenía más trabajo que hacer, a veces controlando el motor mientras grababa datos de la plataforma y el radar al mismo tiempo. Esta fue en realidad una tarea bastante simple, solo una secuencia repetida de cálculos relativamente simples, pero como todos sabemos, el AGC podría sobrecargarse simplemente dejando encendido el radar de acoplamiento durante el descenso lunar.

Entonces, en respuesta a la pregunta, “¿Cómo funcionó la computadora de guía Apollo con tan poca potencia de procesamiento?” Al recibir la carga de trabajo más ligera, los ingenieros pudieron descubrir cómo lograrlo y un “sistema operativo” brillantemente priorizado que permitió que fallara con gracia , al deshacerse del trabajo menos importante primero cuando se sobrecarga.

Pero, contrariamente a la creencia popular, el AGC no realizó ninguno de los cálculos necesarios para elegir las trayectorias objetivo durante la misión. Eso fue hecho con anticipación por un IBM System 360 en Houston. Todo lo que tenía que hacer el AGC era maniobrar (o ayudar a los astronautas a maniobrar) a lo largo de una trayectoria planificada previamente desde el suelo.

Un teléfono celular moderno podría, con la aplicación correcta, calcular un cambio de trayectoria ad-hoc de, digamos, la órbita lunar a la trayectoria de retorno libre. El AGC no pudo. Si deseaba hacer tal cambio, tenía que hacerlo a la vez y de acuerdo con los planes elaborados de antemano en el terreno.

* De acuerdo, técnicamente, todos estos códigos tenían significados muy específicos, pero el punto es que eran significados arbitrarios. El programa 22 no era el programa 22 porque tenía algo que ver con el número 22, solo era el programa vigésimo segundo que figuraba en el manual y había que memorizarlo.

Si te gusta la ciencia espacial, puede que te guste mi ficción, y puedes obtener mi galardonado muestra de ciencia ficción aquí.

Hay algo que ninguna de las otras respuestas ha tocado todavía.

Sí, las computadoras de guía tenían pequeñas CPU pequeñas, aproximadamente equivalentes a las AVR más pequeñas de la actualidad, o incluso menos. Puede comprar tanta potencia de procesamiento por menos de un dólar.

Pero estaban conectados a un sistema de navegación inercial que equivalía a un coprocesador de hardware para la navegación. Eso era mucho más poder de procesamiento; análogo, con comportamientos de error extraños, y solo capaz de calcular dos cosas (en qué dirección estoy mirando, y en qué dirección apunta el telescopio en relación con la nave espacial), pero esas fueron las preguntas críticas para volar la nave espacial.

Los civiles no pudieron obtener un INS tan bueno nuevamente hasta la década de 1980, y aún no se puede comprar uno a un precio razonable; un INS con instrumentos tan buenos todavía cuesta más de $ 20k. Lo que hacemos ahora que hace funcionar cosas como los auriculares VR y los drones de consumo es utilizar nuestras computadoras mucho mejores para hacer frente a los problemas de calidad de los sistemas INS realmente horribles pero baratos, que fabricamos en grandes cantidades porque inicialmente se fabricaron para ABS y airbag para automóviles sistemas que no necesitan precisión y tienen restricciones de precios realmente difíciles.

Se utilizó una versión especial del lenguaje ensamblador (o ensamblador), un paso por encima del código de máquina, para el Apollo Guidance Computer (APG). Cada bit de memoria tenía que ser usado. Este es un uso increíblemente escaso de la potencia de procesamiento en comparación con los lenguajes de programación modernos que utilizan paradigmas orientados a objetos o secuencias de comandos e interpretación, en los que se utilizan cientos o miles de líneas de código para realizar operaciones.

Interfaz de hardware Apollo APG

Cuando el Laboratorio de Instrumentación del MIT se propuso desarrollar el software de vuelo para el programa Apollo a mediados de la década de 1960, inventaron el código desde cero. Este fue el código de procedimiento. Fue minuciosamente detallado paso a paso las instrucciones. Cada línea estaba allí por una razón cuidadosamente definida. Había una línea o bloque de código para cada contingencia o eventualidad que pudiera imaginarse. Fue increíblemente laborioso y costoso de desarrollar y probar. He visto estimaciones de $ 100,000 (en dinero real de la década de 1960) para cada línea de código. Ese costo incluyó la construcción de modelos, la creación de escenarios, la escritura de códigos y, sobre todo, las pruebas.

Recuerde, este proyecto comenzó 7 años antes de que el lenguaje C comenzara una revolución en el paradigma de programación. Además, no estaban programando para un sistema operativo. Cada programa tenía que priorizar los recursos en la computadora, por lo que fue un acto de equilibrio increíble.

Margaret Hamilton, directora de ingeniería de software para el proyecto AGC, de pie junto a una pila de papel que contiene el software. (¡Se le atribuye haber acuñado el término “ingeniería de software”!)

Fuente principal: el código que llevó a América a la luna se acaba de publicar en GitHub, y es como una cápsula del tiempo de la década de 1960

El código estaba bien escrito. En aquellos días, los programadores sabían cómo conservar los recursos e intentaron activamente hacerlo. Como resultado, una gran cantidad de capacidad de procesamiento podría exprimirse de las computadoras relativamente lentas de la época.

Hoy en día, los programadores no se preocupan por el rendimiento en absoluto, y la prioridad es sacar el software y comenzar a cobrar cheques. Como resultado, las computadoras que son un millón de veces más rápidas que las utilizadas en las misiones Apollo tardan tanto en hacer las cosas como las computadoras viejas. No importa cuán rápido se vuelvan las computadoras, la acumulación de software absorbe las ganancias y la velocidad real de la computadora promedio en el uso diario realmente no cambia.

Si el software de hoy se escribiera de manera tan eficiente como el de las misiones Apollo, todo lo que podría hacer en su PC se haría instantáneamente, antes de que pudiera parpadear.

Es sorprendente lo que puede hacer cuando tiene un rol específico y tiene control sobre el diseño de un sistema operativo completamente despojado de un procesador pequeño.

El final reciente de la misión a Saturno ( Cassini ) es un ejemplo. Comenzaron el diseño y la arquitectura hace 30 años. Ese pequeño caballo de trabajo hizo todo lo que estaba diseñado para hacer sin problemas. Esto incluía el control sobre la transmisión de datos, telemetría, posicionamiento de sensores científicos y la recepción de instrucciones para cambios de orientación. La CPU de la computadora de control central era un sistema MIL-STD-1750A redundante.

Fue construido específicamente para las misiones lunares. Todo, desde el lado del hardware hasta el sistema operativo y sus programas. Había algunas computadoras a bordo y, si recuerdo bien, una de ellas tenía el único trabajo de calcular la trayectoria y tal.

Aunque los teléfonos celulares modernos son más potentes, la programación no es tan buena como en las computadoras Apollo. Este es un video que lo explica muy bien, así que échale un vistazo:

Cualquiera que haya visto “El día que la tierra se detuvo” probablemente recuerde el problema matemático que el profesor Barnhard tenía en su pizarra. Era un problema en la mecánica celeste no muy diferente de los problemas que tenía que resolver la computadora de navegación Apollo. Una calculadora programable moderna e incluso su iPhone pueden procesar este tipo de problema en milisegundos. En comparación con la potencia de procesamiento requerida para mostrar una película haciendo los cálculos, es insignificante.

En UC-Irvine, desde 1970 hasta 1975 más o menos, el Dr. John Hamming de Bell Labs enseñó el Seminario Senior para Información e Informática. Dijo que las computadoras a bordo eran máquinas de ocho bits que calculaban la posición del módulo unas diez veces por segundo. Distancia desde la plataforma de lanzamiento, distancia desde la luna y otras tres distancias hasta las torres de comunicación. Se rio mucho. Él dio a entender que las unidades eran millas o pulgadas de acuerdo con el resultado esperado; la precisión era un decimal. (Vago, lo sé, pero eso es lo que dijo).

Hay mucho más hinchazón en entornos de software modernos de lo que la mayoría de la gente cree. Es posible hacer una cantidad sorprendente de procesamiento con recursos mínimos. Considere la Máquina de lectura Kurzweil (la descripción en este enlace es de 1977). Esta máquina lee libros ordinarios en voz alta usando inglés inflexionado. En 1982, 200 de estos se habían vendido, en gran parte a bibliotecas. La máquina tenía medio megabyte de RAM y utilizaba un emulador de CPU Data General Nova 4 mejorado que funcionaba a 6 MHz.

También vale la pena señalar que los editores de texto “antiguos” como emacs y vim fueron diseñados para ser extremadamente rápidos, en un momento en que las máquinas corrían mucho más lento de lo que corren ahora. Son aún más rápidos ahora. Hay una razón por la que los usuarios experimentados siguen usándolos, y no es que no hayan probado herramientas más nuevas. Las velocidades limitadas de la CPU y los pequeños recuerdos no necesariamente significan un procesamiento lento.

Siempre me ha fascinado el sistema de guía inercial. Hay varios buenos documentales históricos sobre su desarrollo y estaba buscando uno de ellos cuando me encontré con esta conferencia. Es una muy buena conferencia. Es mejor que cualquier cosa que pueda escribir en una respuesta corta.

Comienza con una explicación mínima de la red del espacio profundo y luego presenta una explicación realmente excelente de cómo funcionaba el AGC.

Máquinas lunares. El sistema de orientación.

Puede obtener el código fuente del módulo de control en github. La NASA lo publicó hace un tiempo.

chrislgarry / Apollo-11

Una PC doméstica o un teléfono inteligente usan, probablemente el 90% o más de su potencia de CPU al dibujar la GUI (interfaz gráfica de usuario)

Todas las alas bastante brillantes que hace su sistema operativo para hacer que su experiencia sea más agradable y estéticamente agradable le cuesta a su computadora millones de operaciones.

La computadora de la nave espacial tenía una fracción del trabajo que hacer a costa de una interacción más intensa por parte del usuario (es decir, ingresaría códigos y presionaría una tecla para ejecutar una acción)