El ordenador del Apolo (medio siglo del Apolo 11 parte 2)

Por Daniel Marín, el 8 julio, 2019. Categoría(s): Apolo • Astronáutica • NASA ✎ 65

En cada nave Apolo tripulada junto a los tres astronautas había un cuarto tripulante imprescindible. Se trataba del AGC (Apollo Guidance Computer), aunque todo el mundo lo conoce como «el ordenador del Apolo», a secas. Sin embargo, cada vez que se habla del AGC suele ser para hacer énfasis en sus prestaciones, que eran irrisorias comparadas con cualquier cacharro electrónico de hoy en día. Curiosamente, se suele pasar de puntillas sobre el asunto más importante de todos: ¿para qué necesitaban realmente el ordenador los astronautas del Apolo? Y, sobre todo, ¿era necesario un ordenador tan complejo —según los estándares de la época— para poner un ser humano en la Luna?

El ordenador AGC del Apolo (izquierda) con el panel DSKY al lado (NASA).

Los ordenadores del Apolo (sí, en plural)

Pero no empecemos la casa por el tejado. Ante todo conviene aclarar que, en realidad, había varios «ordenadores del Apolo». El más famoso era el AGC del módulo de mando y servicio (CSM), pero no debemos olvidar que el módulo lunar (LM) contaba con un ordenador idéntico. Para evitar confusiones, al AGC del LM se le solía denominar LGC (Lunar Guidance Computer) y, a veces, al del CSM como CGC (Command Module Guidance Computer). Puesto que ambos eran gemelos, comentaremos en detalle su funcionamiento de forma conjunta más adelante. El siguiente ordenador a tener en cuenta era el del cohete Saturno V, encargado de guiar el enorme cohete hasta la órbita. Mucha gente piensa que el AGC del módulo de mando se ocupaba de esta tarea, pero durante el lanzamiento el AGC solo servía como ordenador de reserva y como herramienta para mostrar los datos a la tripulación.

La Unidad de Instrumentación del Saturno V (IBM).

El ordenador del Saturno V se denominaba oficialmente LVDC (Launch Vehicle Digital Computer) o FCC (Flight Control Computer) y estaba situado en la Unidad de Instrumentación (IU) de la tercera etapa S-IVB del cohete. Situado en un contenedor cilíndrico, el LVDC había sido construido por IBM usando una arquitectura y un software totalmente distintos a la del AGC. Tenía una memoria ROM de 32 kilobytes y operaba a una frecuencia de 2 megahertzios. En el Apolo 12, el Saturno V pudo completar su misión y llegar a la órbita gracias al LVDC después de que el AGC quedase fuera de servicio cuando un rayo alcanzó el vehículo poco después de despegar. Si el LVDC fallaba en vuelo, el AGC debía relevarlo. Pero si este también fallaba, el comandante podía teóricamente pilotar el cohete hasta la órbita, algo que nunca fue necesario (controlar un cohete de tres mil toneladas a mano: eso sí que hubiese sido algo digno de ver).

Partes de la IU del Saturno V. La flecha roja señala el ordenador (NASA).
Detalle de la IU donde se encontraba el ordenador (NASA).

El segundo ordenador del Apolo era en realidad un conjunto de ellos. Hablamos de los ordenadores del RTCC (Real-Time Computer Complex) del centro de control de la misión (MCC) en Houston, encargados de calcular la posición y trayectoria de la nave a partir de la señal de radio del vehículo. Durante las misiones lunares Apolo, los ordenadores del RTCC eran cinco IBM 360-75J con 1 MB de memoria cada uno. Una vez que ya sabemos que en el Apolo había varios ordenadores, ahora ya sí, pasemos a hablar del AGC.

Ordenadores IBM 360-75J del MCC (NASA).

¿Para qué queremos un ordenador en una nave espacial?

Hoy día damos por sentado la necesidad de contar con algún tipo de ordenador que sirva de interfaz entre los imperfectos seres humanos y los sistemas de un vehículo como, por ejemplo, un avión o una nave espacial. Pero en los años 60 los controles fly-by-wire eran de todo menos obvios. Un ordenador —o, al menos, una calculadora— es imprescindible si queremos garantizar un control efectivo de un vehículo espacial. Las naves se orientan en el espacio mediante propulsores de maniobra, pero hay que tener en cuenta que el centro de masas de una nave espacial cambia constantemente al disminuir la cantidad de combustible o al acoplarse con otra nave. Por lo tanto, la fuerza ejercida por los RCS no pasa normalmente a través del centro de masas de la nave, lo que provoca movimientos en otros ejes.

El CSM y el LM del Apolo (NASA).

Por ejemplo, en el Apolo, los cuatro RCS frontales y traseras del sistema RCS del CSM presentaban toberas inclinadas para disminuir el impacto de los gases en el fuselaje del módulo de servicio y en el módulo lunar, toberas que además también estaban ligeramente descentradas con respecto al centro de masas. Como resultado, sin un ordenador que controlase el sistema RCS, un movimiento hacia atrás o adelante del CSM ocasionaba un giro en el eje de guiñada y de cabeceo. Lo mismo ocurría en mayor o menor medida con resto de movimientos de rotación y traslación de la nave generados por los dieciséis RCS y por el motor principal SPS (en el caso del LM la posición de los doce RCS era aún más asimétrica). De ahí que se requiriese un ordenador para ayudar a un astronauta a controlar la nave o para hacer que esta permaneciese estática con respecto a un sistema de referencia determinado.

Sistema RCS del CM y SM (NASA).

Sin embargo, no hace falta un ordenador muy complejo para cronometrar igniciones o permitir el vuelo fly-by-wire, ni siquiera en los años 60. Entonces, ¿por qué se desarrolló un ordenador tan avanzado como el AGC del Apolo? La respuesta es simple: guiado y navegación. ¿Y eso qué es? Pues básicamente, saber dónde está la nave espacial y hacia dónde se dirige. Es decir, su posición (navegación) y trayectoria (guiado). Y eso ya son palabras mayores. Porque, ¿cómo podemos averiguar dónde estamos en medio del espacio cislunar? Cuando se concibió el diseño del CSM del Apolo a principios de los años 60 se hizo con una premisa clara: la nave debía guiarse de forma autónoma en todo momento. Esta condición se introdujo porque nadie sabía si era posible mantener un enlace estable de comunicaciones con una nave a casi cuatrocientos mil kilómetros de la Tierra. La posibilidad de que se produjese algún tipo de interferencia en las comunicaciones por parte de la Unión Soviética también fue un factor que se tuvo en cuenta (no olvidemos que la Crisis de los Misiles de Cuba, el punto álgido de la Guerra Fría, ocurrió en 1962). En definitiva, la tripulación del Apolo tenía que ser capaz de regresar sana y salva a la Tierra incluso sin ayuda del control de la misión.

La tripulación original del Apolo 13 (Lovell, Mattingly y Haise), posan con un sextante y un astrolabio (NASA).

Guiado y Navegación

El ordenador AGC del Apolo usaba como fuente de datos para el guiado y la navegación la unidad de medida inercial o IMU. La IMU era un conjunto de tres giróscopos y acelerómetros que detectaban cualquier cambio en la aceleración del vehículo en sus tres ejes. Por lo tanto, se podía saber el sentido y la dirección de las fuerzas que habían actuado sobre la nave y durante cuánto tiempo. Con estos datos, un ordenador puede extrapolar la posición de la nave en cualquier momento. La tecnología IMU estaba por entonces en pleno apogeo gracias a su uso en aviones militares y en misiles balísticos. El problema es que el cálculo de la posición de una nave por este método va acumulando errores de forma continua y, más tarde o temprano, los datos ya no son fiables. Si la misión es corta, como la de un misil, no pasa nada, pero en caso contrario, como un viaje a la Luna, es necesario calibrar la IMU con datos externos de forma periódica.

Una IMU del Apolo. En su interior se aprecian los tres giróscopos (NASA).

Y aquí es donde entra en juego la complejidad del sistema empleado para el Apolo. Una forma de obtener datos independientes de la posición y trayectoria de la nave es usar sensores estelares y solares, algo que usan de forma rutinaria las sondas espaciales. Pero los encargados del Apolo no se fiaban de este sistema, que todavía estaba en pañales. Las naves Apolo no llevarían «simples» sensores estelares automáticos, sino que se fue un paso más allá. Efectivamente, los astronautas deberían poder calcular la posición de la nave a partir de la observación de estrellas de referencia como si fueran navegantes del siglo XIX. Los datos de la posición de estrellas y otros cuerpos celestes servirían para actualizar la IMU de tanto en cuanto. La introducción del elemento humano en el sistema de guiado y navegación aumentó su complejidad —y masa— de forma considerable, pero se consideraba imprescindible. De este modo, si el AGC fallaba, la tripulación contaría con un elemento de reserva para garantizar su supervivencia.

Elementos del sistema primario de navegación y guiado (PGNCS) del Apolo (NASA).

En este punto es importante subrayar que las tareas de control de la nave —o sea, piloto automático— y de guiado y navegación son distintas y que pueden llevarse a cabo por dos o más ordenadores independientes, aumentando la redundancia de la nave y reduciendo la complejidad de cada ordenador. De hecho, esa fue la decisión que se tomó al principio del programa Apolo. Estaba previsto que cada nave Apolo llevase dos ordenadores, uno analógico, diseñado por Honeywell para controlar el vehículo, y otro digital a cargo de Raytheon para las nuevas tareas de guiado y navegación. Evidentemente, algunas de las tareas y capacidades de los ordenadores se solapaban —el ordenador de guiado y navegación debería ser capaz de controlar los propulsores RCS del vehículo—, pero, en todo caso, al final tendríamos un sistema más resistente a posibles fallos.

«Doc» Draper en el simulador del sistema PGNCS del Apolo situado en la azotea de un edificio del MIT (NASA).

Pero el programa Apolo no era lugar para gente tímida y conservadora. En enero de 1964 la NASA tomó la decisión usar un único ordenador en Apolo. Por si fuera poco, el ordenador debería ser idéntico para el CSM y el LM —a excepción del software, obviamente— algo que causó pánico en los contratistas principales de ambas naves —North American y Grumman, respectivamente—, ya que si diseñar un único ordenador era difícil, hacerlo compatible para dos vehículos tan dispares era un desafío de primer orden. El nuevo ordenador se llamaría AGC (Apollo Guidance Computer), aunque el nombre era un poco engañoso, pues, como hemos visto, se encargaría de muchas otras tareas además del guiado. El contratista principal sería Raytheon, mientras que el famoso MIT (Massachusetts Institute of Technology) se encargaría de la selección de la arquitectura y la programación del ordenador. El equipo del MIT, dirigido por Charles «Doc» Draper, se hizo con el diseño del AGC gracias a sus trabajos previo con los militares, entre los que destacaba el ordenador del misil balístico Polaris lanzado desde submarinos, que poseía un ordenador de control de tan solo 10 kg y 4 kB de memoria.

Draper con von Braun (MIT).

El AGC

Al comienzo del programa, la NASA le preguntó al MIT cuánto ocuparía su ordenador. El equipo de Draper no lo sabía con certeza, así que supuso que un pie cúbico —unos 28 litros— sería suficiente. A medida que el AGC fue haciéndose más y más complejo, el MIT tuvo que luchar para no superar esta barrera de volumen. Con el fin de mantener el peso y el tamaño bajo control, el AGC sería un ordenador digital que emplearía la nueva tecnología de circuitos integrados, una tecnología que por entonces estaba en sus inicios. El primer prototipo del ordenador, el AGC3 estuvo listo en una fecha tan temprana como 1962. Este prototipo, y la insistencia de expertos como Eldon Hall, convenció a la NASA de que los circuitos integrados eran el camino a seguir. O mejor dicho, era la única forma de que un ordenador tan complejo cupiese en la nave. La NASA se pasó al microchip y tomó la decisión de que todos los ordenadores del Apolo usasen circuitos integrados. Dos años más tarde se finalizó el prototipo AGC4B para las primeras misiones de tipo Block 1 del Apolo. El AGC Block 2 definitivo estuvo listo en 1966. El AGC Block 1 se empleó en las misiones no tripuladas AS-201, Apolo 4 y Apolo 6, mientras que el AGC Block 2 se usó en el Apolo 5, no tripulado, y en todas las misiones Apolo tripuladas.

Un técnico de Raytheon prueba un prototipo del AGC (la caja a su derecha de la que salen gruesos cables negros). Se aprecian dos DSKY que servían de interfaz para las pruebas (Raytheon).
Partes del AGC (NASA).

Siempre que se citan las prestaciones del AGC es para hacer mofa de ellas comparándolas con cualquier ordenador o teléfono móvil actual —como si eso nos hiciese sentir mejor de algún modo—, pero huelga decir que, para la época, eran impresionantes. El AGC del Apolo disponía de una memoria ROM —o sea, de solo lectura— de 36 kilobytes y una RAM de 2 kilobytes (en realidad el AGC no usaba bytes, sino «palabras» con una longitud de 16 bits, pero eso es otra historia). Era un avance frente al AGC Block 1, con una ROM de solo 24 kB y una RAM de 1 kB. La frecuencia de funcionamiento era de 1 MHz y contaba con un total de 5600 circuitos integrados. El peso final era de 31,8 kg y su consumo eléctrico de 55 vatios.

El AGC con los módulos de memoria separados (NASA).

Sin duda, la característica más llamativa de la memoria del Apolo es que no era magnética, sino que era del tipo de «núcleos cableados» (core rope memory). O sea, estaba formada por diminutos anillos metálicos por los que se hacía pasar un cable por dentro del mismo —lo que representaría un ‘1’ binario— o por su lado —un ‘0’–. Es decir, los programas del AGC del Apolo no eran algo etéreo, sino que se podían tocar con las manos, literalmente. Por tanto, las líneas de código binario del software se debían traducir a una compleja matriz de cables y bobinas. Un ejército de mujeres de la empresa Raytheon se encargaba de «coser» esta memoria de núcleos usando máquinas especiales, de ahí que a este tipo de memoria se le conozca, de forma un tanto despectiva, como LOL (Little Old Ladies). El AGC llevaba seis módulos de memoria LOL y cada uno requería un mínimo de seis semanas para ser tejido.

Detalle de una memoria de núcleos (NASA).

Los módulos tenían que estar listos para someterse a las pruebas correspondientes tres o cuatro meses antes del lanzamiento. La NASA era consciente de que el éxito del programa Apolo dependía en gran medida de las mujeres que tejían la memoria del AGC, así que se aseguró de que los astronautas visitasen regularmente la planta de Raytheon en Waltham (Massachusetts). Una vez tejida la memoria no había forma de cambiar el código de los módulos ROM, lo que provocó no pocos quebraderos de cabeza entre los ingenieros de la NASA. Por otro lado, la memoria RAM del AGC usaba un sistema muy parecido —memoria magnética de núcleos de ferrita (ferrite core)— capaz de cambiar los unos y ceros de las bobinas invirtiendo el sentido de la corriente inducida en cada una de ellas.

Un módulo de memoria LOL (NASA).

En un principio hubo un debate muy intenso entre la NASA y el MIT sobre la capacidad de reparación en órbita del AGC. Los ingenieros e informáticos del MIT querían que los astronautas supiesen reparar el AGC, una tarea que requería un intenso entrenamiento en electrónica e informática —aunque por entonces esta disciplina no existía como tal— y además implicaba llevar unos enormes manuales a bordo del módulo de mando (se sopesó la posibilidad de llevar los manuales en formato de microfilm ante su enorme volumen). Los astronautas se negaron categóricamente —ya les había costado mucho aceptar que ellos no «pilotarían» realmente la nave— y la NASA desistió. El AGC no tendría capacidad de ser reparado en órbita. Curiosamente, y a pesar del despliegue tecnológico que suponía el AGC, nadie fue capaz de diseñar una conexión física entre el CGC del módulo de mando y el LGC del módulo lunar. Puesto que el CGC era el ordenador primario durante toda la misión, eso implicaba que los astronautas debían introducir los datos de posición y orientación manualmente de un ordenador a otro, una tarea ciertamente tosca que consumía mucho tiempo (para colmo, los ángulos de referencia de los dos vehículos eran diferentes, complicando todavía más el procedimiento de alineación de la IMU del LM cuando se activaba en vuelo).

Una trabajadora de Raytheon «cosiendo» la memoria (NASA).

Programando el viaje a la Luna

Crear el software del Apolo fue una tarea tanto o más compleja que diseñar el hardware. El AGC se hizo famoso en el mundo de la informática por presentar una arquitectura innovadora. Aunque un análisis exhaustivo de este tema daría para escribir varios libros —algo que ya se ha hecho—, basta con señalar que la memoria LOL codificada en binario era traducida por un lenguaje de mayor nivel denominado «Intérprete», que, a su vez era gestionado por una especie de ‘protosistema operativo’ conocido como «Ejecutivo». La gran genialidad del AGC del Apolo es que este sistema operativo permitía ejecutar varios programas al mismo tiempo, o sea, una forma de multitarea rudimentaria. El AGC era capaz de gestionar siete programas a la vez en orden de importancia sin «colgarse» ni «resetearse». Entre los principales encargados del software del Apolo  fue Hal Laning, que posteriormente se haría famoso como uno de los inventores del famoso lenguaje de programación FORTRAN. Por si fuera poco, el AGC era capaz de apagarse y encenderse en menos de dos segundos sin pérdida de datos. Es por este motivo que los astronautas no tenían demasiado miedo al equivalente de un «pantallazo azul» en medio de una maniobra crítica. En caso de emergencia siempre se podía reiniciar el AGC y seguir como si nada.

Hal Laning, uno de los principales artífices de la programación del AGC (NASA).

Aunque los AGC del CSM y del LM eran físicamente similares, obviamente su software era muy diferente. El sistema operativo del CGC se denominó en las misiones tripuladas Sundisk y Colossus, mientras que el del LGC recibió la denominación de Sunburst, Sundance y Luminary. Se crearon varias versiones de cada uno, casi a versión por misión. En el Apollo 11 se usaron el Colossus 2A —también conocido como Comanche 055— en el módulo de mando y el Luminary 1A (revisión 99) en el módulo lunar. Los astronautas interaccionaban con el AGC usando una interfaz de aspecto futurista para la época denominada DSKY (Display and Keyboard). El DSKY, pronunciado como diski, tenía unas rudimentarias pantallas digitales de color verde fosforescente y un teclado de 19 botones que incluía números y varias instrucciones. A día de hoy mucha gente confunde el DSKY con el AGC propiamente dicho, aunque solo era la interfaz (por cierto, no me resisto a mencionar que el programa encargado de gestionar la pantalla del DSKY se llamaba Pinball Game Buttons and Lights).

Evolución de los sistemas operativos del Apolo (NASA).

A través del DSKY los astronautas podían introducir o requerir datos. Esto no se hacía directamente, sino a través del uso de ‘verbos’ (verbs, conjuntos de órdenes), ‘nombres’ (nouns, una orden en concreto) o programas. Estos últimos eran un conjunto de instrucciones complejas que podían servir desde para aterrizar sobre la Luna hasta para alinear la plataforma de navegación. Por ejemplo, durante el descenso y alunizaje el LGC usaba los programas P63, P64 y P66. Si un astronauta quería seleccionar, pongamos, el programa P63, debía introducir en el DSKY la secuencia «verbo + 37 + enter + 63» (‘verbo 37’ era la instrucción encargada de seleccionar un programa determinado). Otras tareas solo requerían verbos, como la activación del piloto automático (‘verbo 46’).

Detalle del DSKY original (NASA).
Botones del DSKY (NASA).
El DSKY del panel principal de mandos del CSM (NASA).
Partes del DSKY (NASA).

Los números que mostraba el DSKY no tenían parte decimal. La tripulación debía saber a priori qué cifras significativas tenía que tener la parte entera de cada magnitud. Y es que, a pesar de sus ventajas, el AGC no era una bestia fácil de dominar. Para alinear la plataforma inercial se requerían entre 30 y 130 pulsados de botones del DSKY y en un viaje a la Luna se podían alcanzar más de diez mil pulsaciones. Como resultado, la tripulación pasaba un porcentaje importante de su tiempo en el espacio tecleando oscuras instrucciones en el panel DSKY. En el módulo de mando había dos paneles DSKY, uno situado en el panel principal de instrumentos y otro en la parte posterior junto al sistema de guiado y navegación óptica. En el LM solo había un DSKY, localizado en la consola central entre el comandante y el piloto del módulo lunar.

Panel de mandos del módulo lunar con el DSKY en la parte inferior (NASA).

La robustez del AGC quedó demostrada en el Apolo 11 durante la fase crítica del alunizaje. Buzz Aldrin, el piloto del módulo lunar, activó un modo específico del radar de acoplamiento del LM con el fin de tenerlo listo por si acaso tenían que abortar el descenso y acoplarse con el CSM, una tarea que no estaba prevista en las listas de comprobación de la misión. Como resultado, el sistema operativo Luminary del LGC se vio desbordado al tener que gestionar un programa adicional y activó las alarmas 1202 y 1201 de sobrecarga del sistema en varias ocasiones durante la fase crítica del descenso propulsado a la superficie. Gracias a la capacidad multitarea del LGC, el ordenador no se colgó, aunque se reinició sin pérdida de datos (recuerda que tardaba menos de dos segundos en reiniciarse). Nadie en el control de la misión de Houston sabía qué eran esas alarmas, pero el equipo de guiado (GUIDANCE) de la misión situado en otra habitación del MOCR, encargado de monitorizar el LGC, sí sabía lo que significaban y le comunicaron a su jefe, el oficial GUIDO Steve Bales, que no pasaba nada siempre y cuando no se repitiesen continuamente y provocasen un reinicio con pérdida de datos.

Detalle del DSKY del módulo lunar (NASA).
Inicio del código del Colossus 2A (Comanche 55), el ‘sistema operativo’ del AGC del Apolo 11 (NASA).

Tanto el CGC como el LGC constituían el sistema de guiado y navegación primario del Apolo o PGNCS (Primary Guidance, Navigation and Control System), pronunciado de forma creativa como pings. No obstante, y a pesar de que el LGC era muy seguro, la NASA quería un sistema de reserva en el módulo lunar para garantizar que los astronautas no se estrellarían contra la superficie durante el descenso o el ascenso, dos maniobras críticas que no podían repetirse ni pausarse para analizar cualquier error que pudiera surgir. Por eso el LM llevaba un segundo ordenador conocido como AGS (Abort Guidance System), pronunciado aggs. El AGS era un ordenador MARCO 4418 con una memoria ROM y RAM de 2 kB cada una (en realidad, «palabras» de 18 bits). Contaba con su propio display particular parecido al DSKY, pero que recibía el nombre de DEDA (Data Entry and Display Assembly) y se situaba en la parte derecha de la consola de mandos, frente al piloto del módulo lunar.

Panel de mandos DEDA del ordenador de emergencia AGS del módulo lunar (NASA).

A día de hoy, es habitual que se confunda el DEDA del AGS con el DSKY del AGC en muchas referencias del Apolo debido a su similitud. Sin embargo, el AGS era un elemento mucho más simple. El AGS usaba los datos de navegación del LGC, así que una de las tareas más tediosas del piloto del módulo lunar era introducir estos datos en el AGS manualmente antes de cada maniobra crítica. Además, usaba una IMU más simple y menos robusta que la del PGNC. Afortunadamente nunca fue necesario usar el AGS en una misión Apolo, aunque se probó su funcionamiento en el Apolo 10. El AGS es una buena respuesta a la pregunta ‘¿se podía haber viajado a la Luna con un ordenador más simple?’. La respuesta es sí, aunque, evidentemente, el AGS era menos seguro que el LGC. Por su parte, en el módulo de mando el sistema de reserva del PGNCS era el SCS (Stabilization and Control System). A diferencia del AGS del módulo lunar, que era un ordenador más rudimentario que el AGC, pero un ordenador al fin y al cabo, el SCS era básicamente un ordenador analógico muy sencillo —más bien calculadora— que solo se ocupaba del piloto automático de la nave y disponía de giróscopos más simples que los de la IMU.

Elementos del SCS, el sistema de reserva del PGNCS en el módulo de mando (básicamente un ordenador analógico simple que aseguraba el fly-by-wire) (NASA).
Margaret Hamilton, una de las principales programadoras del Apolo, en un simulador del CSM (AP/Shutterstock).

La plataforma inercial

El AGC se encargaría del control del vehículo y de sus propulsores y, en tareas de guiado y navegación, usaría los datos de la plataforma IMU y el sistema de navegación estelar (como hemos visto, el conjunto de estos elementos formaba el sistema de navegación primario o PGNCS). La IMU solo tenía tres giróscopos —uno por eje— y, debido a esta limitación, los astronautas deberían tener cuidado durante sus maniobras para no bloquear la plataforma, una situación conocida como gimbal lock. El gimbal lock ocurría cuando dos de los ejes de los giróscopos acababan en el mismo plano, por lo que los datos de la IMU ya no eran fiables y había que «resetearla» con datos externos. No se trataba de ninguna emergencia, pero el tener que volver a alinear la plataforma era una molestia para las tripulaciones por el tiempo que requería (evidentemente, si el gimbal lock se producía durante una fase crítica de la misión, el asunto podía ser potencialmente mucho más serio).

El FDAI o «horizonte artificial» con la zona de bloqueo de la plataforma que debían evitar los astronautas (NASA).

Los datos de la IMU de la posición de la nave con respecto al sistema de referencia elegido se representaban en el panel de mandos del CSM y el LM mediante el instrumento FDAI (Flight Director/Attitude Indicator) que los astronautas apodaban «8 ball» y que tenía el aspecto de un simple horizonte artificial como el que se encuentra en cualquier aeronave. Los astronautas habían insistido en la inclusión del FDAI en el CSM, aunque muchos de los ingenieros pensaban que estaban demasiado condicionados por su experiencia aeronáutica (su uso en el LM estaba más justificado porque, bueno, en la Luna sí hay un horizonte de referencia). El FDAI tenía una zona pintada en rojo para alertar a los astronautas visualmente del riesgo de gimbal lock.

Elementos del PGNCS del módulo lunar (NASA).

Curiosamente, la limitación del gimbal lock se podía haber evitado fácilmente con la incorporación de un cuarto giróscopo. Sin ir más lejos, el ordenador LVDC del Saturno V y el de las naves Gémini incorporaba esta cuarta unidad para evitar el bloqueo de la plataforma. Sin embargo, la NASA decidió usar solo tres giróscopos para evitar que la IMU aumentase de peso, sobre todo por culpa de las estrictas limitaciones de masa del módulo lunar (y, recordemos, el AGC del LM debía ser idéntico al del CSM). Además, tres giróscopos acumulan menos errores que cuatro, haciendo más precisa la plataforma. Pero, paradójicamente, para evitar el gimbal lock los astronautas terminarían por gastar más tiempo y combustible del necesario —por no hablar de la tensión extra que causaba el tener siempre presente este riesgo durante las maniobras—, así que, visto en perspectiva, el ahorro de masa probablemente no fue muy buena idea.

Partes de la IMU (NASA).

Viajando a la Luna con las estrellas

Para alinear la IMU regularmente, el AGC usaba el complejo sistema óptico de navegación estelar al que hacíamos referencia antes. Si Apolo hubiese sido diseñado apenas unos años más tarde, sin duda este sistema hubiera estado formado por sensores automáticos, pero la NASA quería una capa extra de redundancia por si el ordenador fallaba. El sistema principal de navegación óptico del módulo de mando empleaba un pequeño telescopio denominado AOT (Alignment Optical Telescope) y un sextante (SXT) fabricado por Kollner. El sextante contaba con un ocular que proporcionaba un aumento de 28x, mientras que el telescopio no tenía aumentos. Ambos oculares se hallaban en la parte trasera del módulo de mando, a los pies de los asientos de los astronautas.

Ron Evans (Apolo 17) mirando por el sextante del PGNCS del CSM. A la derecha se ve el ocular del AOT (NASA).

Diseñar la óptica del módulo de mando no fue una tarea obvia, ya que tuvo que ser construida para que no comprometiese la integridad del escudo térmico (la salida de la óptica estaba localizada en la parte del escudo que más se calentaba). Originalmente debía contar con una óptica desplegable, pero los ingenieros de North American se horrorizaron con la posibilidad de que este sistema no pudiese replegarse durante la reentrada. El sistema óptico del LM prescindía del sextante e incorporaba únicamente el telescopio AOT con 1 aumento en una configuración de periscopio. Debido a estas limitaciones, el sistema óptico del LM únicamente permitía dar información sobre la orientación del módulo lunar, pero no de su posición y trayectoria, mientras que el sextante y el telescopio del CSM eran capaces de ofrecer ambos parámetros.

Aperturas en el casco del módulo de mando para el AOT y el sextante (NASA/Eureka).
Localización del sistema óptico del módulo de mando (NASA).

El concepto básico del sistema era increíblemente ingenioso. Los ordenadores CGC y LGC llevaban cada uno los datos de la posición de 37 estrellas, que, a todos los efectos, estaban fijas en la bóveda celeste y servían para definir el sistema de referencia principal, conocido con el oscuro acrónimo de REFSMMAT (Reference to Stable Member Matrix). Este sistema de referencia cambiaba según el vehículo y la fase de misión, por lo que había nueve tipos diferentes (rampa de lanzamiento, órbita baja, viaje hacia y desde la Luna, órbita lunar o superficie lunar, por ejemplo). En el caso más simple, el del LM, se podía determinar la orientación de la nave observando por el telescopio AOT, que disponía de un retículo en forma de cruz. El AOT solo podía apuntar a seis zonas predeterminadas del cielo que cubrían un ángulo de 60º cada una.

El AOT del módulo lunar (NASA).
Campo de visión del AOT del módulo lunar (NASA).

Si se conocía la posición de dos de las estrellas de referencia se podía determinar la orientación de la nave. El astronauta solo tenía que elegir una de las estrellas de referencia y le indicaba al ordenador —apretando un botón— el momento en el que la estrella cruzaba los ejes x e y del retículo del AOT. Repitiendo la maniobra con una segunda estrella de la lista, el ordenador era capaz de averiguar la orientación de la nave con respecto al REFSMMAT elegido. Si el módulo lunar estaba en la superficie lunar, a veces no se podía ver una segunda estrella con el AOT, pero, a cambio, se podía usar el vector de la aceleración gravitatoria —que, obviamente, apuntaba al centro de la Luna— para suplir la falta de una estrella. En la superficie lunar el módulo estaba quieto, como es lógico, así que los astronautas no podían esperar a que una estrella cruzase los ejes del retículo. Lo que hacían eran rotar el retículo hasta que uno de los ejes coincidiese con el de la estrella e introducían en el ordenador el ángulo de la inclinación del ocular y la distancia al centro del retículo. Este último dato se medía indirectamente haciendo girar el ocular nuevamente hasta que la estrella coincidiese con una marca en espiral que también estaba marcada en el retículo.

Retículo del AOT del módulo lunar y el método para determinar la orientación de la nave usando dos estrellas y su posición en el retículo del ocular (NASA).

Para la navegación en el CSM el sistema era parecido, pero más preciso gracias al uso sextante. Con el fin de calibrar la IMU, el piloto del módulo de mando —Michael Collins en el Apolo 11— introducía el código de una estrella para pedirle al ordenador que apuntase la óptica del sextante hacia ella. El astronauta podía medir entonces con precisión la desviación con respecto al centro del ocular debida a los errores acumulados en la plataforma. A continuación solo tenía que mover la línea de visión del sextante hasta que la estrella quedase en el centro y apretaba un botón para dejarle claro al ordenador dónde estaba realmente la estrella.

Jim Lovell usando la óptica del PGCNS durante el Apolo 8 (NASA).

Esta técnica servía para navegación, o sea, para determinar la orientación de la nave, pero para el guiado del vehículo era necesario saber la posición en el espacio entre la Tierra y la Luna. En la mayoría de libros sobre el Apolo se confunden habitualmente ambos conceptos, pero obviamente son muy diferentes. Conocer la orientación —o «actitud»— de la nave es necesario, pero no suficiente, a la hora de planear las maniobras propulsivas de la misión. Como hemos visto, con el sistema óptico del LM no se podía determinar la posición de la nave, solo su orientación, pero el CSM sí disponía de esta capacidad. ¿Cómo lo lograba?

Funcionamiento del sextante para determinar la posición de la nave Apolo (NASA).
Las estrellas de referencia del Apolo. Las estrellas 3, 17 y 20 eran en realidad los nombres de la tripulación del Apolo 1 al revés. Navi (Gamma Cassiopeiae) era Ivan (Virgil Ivan Grissom); Regor (Gamma Velorum) era Roger (Roger Chaffee); Dnoces (Talitha o 9 Ursae Majoris) Second (Ed White II). La tripulación les había dado sus nombres como broma por lo débiles que eran a la hora de identificarlas y luego se mantuvo esta nomenclatura como homenaje (NASA).
Carta estelar con las estrellas del Apolo (Kollman).

La clave estaba en el uso del sextante. Este instrumento disponía de dos líneas de visión que se podían superponer en el mismo ocular (si no, no hubiera sido un sextante). Usando el programa P23, el astronauta usaba su mano derecha para controlar la orientación del CSM mediante un mando similar al del asiento izquierdo del módulo de mando. La nave se movía hasta que una las líneas de visión del sextante quedaba apuntando a un punto determinado, que podía ser el horizonte terrestre, el horizonte lunar o una zona concreta de la superficie lunar (también de la superficie terrestre, pero en órbita baja la determinación de la posición con el sextante no era una prioridad). A continuación, usaba su mano izquierda para controlar un mando de dos ejes que le permitía mover la óptica del sextante hasta que la otra línea de visión quedase apuntando a otro objeto, normalmente una de las estrellas de referencia. Una vez que las dos imágenes estuviesen superpuestas, el astronauta apretaba el botón de «marca» para indicar al ordenador los ángulos relativos entre las dos imágenes. Repitiendo la maniobra varias veces y con varias estrellas o puntos de referencia se podía lograr una precisión muy alta en la determinación de la posición de la nave. La clave de esta técnica es que la Luna y la Tierra no eran objetos estáticos para una nave Apolo, sino que se trataba de cuerpos que cambiaban su tamaño aparente en cada fase de la misión dependiendo de la distancia a ambos.

El sextante y el AOT de una nave Apolo (www.ion.org).

En órbita lunar se empleaba el programa P22 con dos marcas de la superficie como referencia para el sextante. Por esta razón, los astronautas solían poner apodos a muchas características del terreno lunar, no por capricho o vanidad, sino porque les iba la vida en ello. Quizá el ejemplo más famoso sea el Monte Marilyn, una montaña bautizada por Jim Lovell durante el Apolo 8 en honor de su mujer y que se usaría como referencia en el alunizaje del Apolo 11. Los cálculos de posición (guiado) tenían que ser especialmente precisos pocas horas antes y después de los encendidos principales de la misión, como el TLI hacia la Luna, el LOI de inserción orbital y el TEI hacia la Tierra. Por otro lado, los astronautas a bordo del módulo lunar cronometraban el tiempo que tardaban en sobrevolar dos puntos de referencia de la superficie para estimar su posición en órbita lunar de forma elegante y simple gracias a las leyes de Kepler, supliendo así parcialmente las limitaciones de su sistema óptico.

Aldrin y Lovell, la tripulación de la Gémini 12. Aldrin lleva un sextante portátil para estudiar su viabilidad para determinar la posición (NASA).
El sextante de la Gémini 12 (NASA).

Durante el programa Gémini se probó el uso de sextantes en órbita y se comprobó su idoneidad como herramienta para determinar la posición y trayectoria. Antes de la reentrada en la atmósfera terrestre el piloto del módulo de mando también estimaba su trayectoria mediante el horizonte terrestre y alguna estrella o la Luna como referencia, pero no usaba el sextante, sino la posición relativa de estos objetos con respecto a unas marcas grabadas en la ventanilla izquierda de acoplamiento del módulo de mando. Para lograrlo, la cápsula debía orientarse hacia la Tierra brevemente tras la separación del módulo de servicio antes de volver a poner el escudo térmico por delante.

Posición de la Luna con respecto al horizonte terrestre para determinar la trayectoria del módulo de mando antes de la reentrada (NASA).
Uso de la posición de la Luna respecto a la ventana de acoplamiento del CSM para tareas de guiado (NASA).

Aunque los astronautas se mostraron al principio muy reticentes al uso del sistema de guiado y navegación, pronto se hicieron expertos en su uso y competían entre ellos por ver quién era el que conseguía más «cinco bolas», el término informal usado para referirse a los cinco ceros que mostraba el AGC cuando el error de alineación de la plataforma era nulo. No obstante, el uso del sistema de guiado y navegación no estaba exento de errores. Durante el Apolo 8, Jim Lovell, el piloto del módulo de mando en esa misión, cambió sin darse cuenta el sistema de referencia de la nave haciendo creer al AGC que no estaba en órbita lunar, sino en la rampa de lanzamiento. Fue precisa la ayuda del control de la misión para alinear nuevamente la plataforma, pero el fallo sirvió para introducir una serie de salvaguardas en el software que serían de vital importancia posteriormente, como el propio Lovell pudo experimentar dieciséis meses después en el Apolo 13 (para maniobras realmente delicadas, como el encendido del motor principal, el ordenador preguntaba antes a la tripulación si estaban seguros de llevar a cabo la acción mediante el mensaje de ‘PRO’ (proceed) en la pantalla del DSKY).

Campo de visión del sextante para una medida de posición tras la inyección translunar (NASA).

¿Y si el AGC fallaba? En ese caso la tripulación podía determinar su orientación y posición usando la óptica del CSM o el LM o, si esta también fallaba, mediante el COAS (Crewman Optical Alignment Sight), una especie de pequeño telescopio que se usaba como ayuda durante los acoplamientos. Para este fin los astronautas contaban con numerosas plantillas y gráficas para realizar los cálculos a mano —o con ayuda de Houston—, aunque, obviamente, la precisión alcanzada con este sistema de reserva era notablemente inferior a la proporcionada por el sistema PGNCS.

La mira óptica COAS podía servir como ayuda en tareas de guiado y navegación de emergencia (NASA).

La paradoja del ordenador «inútil»

Durante el programa Gémini quedó patente que el guiado de las naves desde las estaciones terrestres era increíblemente preciso, una precisión que aumentó en el Apolo. La distancia y velocidad de las naves Apolo se podían determinar usando el tiempo de retardo en la señal de radio y su desplazamiento Doppler. Con estos datos, los ordenadores del RTCC en Houston —y otros de reserva situados en varios puntos del país— podían calcular la posición de la nave con respecto al sistema de referencia elegido. De hecho, los cinco IBM 360 del MOCR de Houston serían los verdaderos «ordenadores del Apolo» encargados de las labores de guiado y navegación. El sistema óptico PGNCS del Apolo quedaría relegado a un papel de «segundón» y como elemento de emergencia por si se interrumpían las comunicaciones, algo, por otro lado, muy poco probable dado el gran número y tipo de antenas que había en el LM y el CSM.

Antena de 26 metros de diámetro, situada en la Estación de Seguimiento de Vuelos Tripulados de Fresnedillas de la Oliva en Madrid, parte del complejo de estaciones terrestres del Apolo (ABC).

Los ordenadores del RTCC podían calcular la posición de la nave Apolo con una precisión de 10 metros y su velocidad con una precisión de 0,5 metros. De hecho, la mayor fuente de error era la posición exacta de la red de antenas de seguimiento terrestre, que a veces se conocía con una precisión de varios metros. Por este motivo, los datos principales de guiado y navegación eran los proporcionados por Houston y no por el sistema óptico, sobre todo de cara a los encendidos principales de la misión (eso sí, las tareas de navegación para determinar la orientación de la nave no eran tan superfluas y las tripulaciones las usaban reiteradamente para calibrar la IMU, aunque ciertamente se podían haber automatizado fácilmente). Por tanto, la paradoja del ordenador del Apolo es que terminó siendo mucho más complejo de lo previsto para acomodar tareas de guiado y navegación manuales, unas tareas que, finalmente, no resultaron cruciales. No obstante, la presencia del AGC le dio a la NASA la seguridad para llevar a cabo misiones cada vez más complejas. Sin este ordenador el viaje a la Luna hubiera sido posible, pero quizá no en julio de 1969.

Resto de entradas sobre el 50º Aniversario del Apolo 11:



65 Comentarios

  1. Que gozada de articulo. De principio a fin.

    Para los aficionados a la astronomia, las estrellas 3, 17, y 20 son respectivamente Gamma Cassiopeiae, Gamma Velorum, e Iota Ursae Majoris.

  2. Básicamente esta tecnología se implemento luego a los civiles luego de su éxito en la luna, me refiero a los circuitos integrados.
    Pues aunque como tu dices Daniel, aunque redundante por el uso de muchas computadoras fue un gran éxito.

  3. Daniel, leí este artículo de un tirón casi sin respirar y quedé 😳😳😳

    Es informática en un sentido completamente diferente a lo que normalmente manejamos.

    ¿Y en 2019 cómo lo haríamos a todo esto? Nos fijamos en muchos detalles constructivos, mas lo explicado aquí se pasa olímpicamente por alto.

    Sospecho que la Starship de SpaceX llevará sextante y toda nave en el Sistema Solar tendrá uno en cabina. Saludos

    1. Perdona mi desconocimiento pero sería realmente necesario. Es decir con la cantidad de naves robóticas presentes en marte para orientarte y la DSN de la NASA unido a que no todos los tripulantes de una starship vayan a tener conocimientos suficientes para operarlos.
      De hecho es probable que solo se oriente una y el resto la siga como si de una bandada de pájaros migratorios se tratase.

      1. Gracias Martín,
        mas no me refería a Marte.
        Starship está pensado (o soñado) para usar al menos entre LEO, Luna, Marte y el Sistema Joviano.
        Obvio se terminará disponiendo de una infraestructura de guiado, orientación y comunicaciones (radiofaros, balizas orbitales y/o elementos aún no inventados). Mas la pregunta sigue vigente: ¿cómo será el equivalente del AGC, su hardware, su software, su gestión de datos, su interfaz de usuario?
        Nada de broma ni fantasía en esto, pues ya establecido un estándar, fuera de la Tierra cualquier ser humano interactuará con él. Dudo mucho que la informática que conocemos hoy se replique en el Espacio: NADA de Windows ni archivos voluminosos, sospecho será algo TAN diferente que me cuesta imaginarlo.

        Saludos

    2. Bueno, es el mejor artículo que he leído sobre los ordenadores del programa Apolo y sistemas de posicionamiento. Ya soy un experto de sofá en el tema.

      *****

      En la Dragon 2 se puede ver una primera versión de los sistemas que usará SpX en su Starship.

      Puede que todo esté automatizado y se controle usando sencillos paneles táctiles. ¿Habrá un sistema manual de emergencia como dices? Es posible.

      Un dato: a diferencia de la miríada de contratistas que construyeron los Saturno/Apolo y sus subsistemas, hay un único contratista para Starship: SpaceX (grosso modo, porque SpX también tiene proveedores, claro).

      SpX diseña y fabrica los motores, el cohete, los sistemas electrónicos (hardware y software), el soporte vital, sensores, sistemas de comunicaciones, sistemas de posicionamiento, escotillas de acoplamiento, protección termal…

      Absolutamente todo, y además realizan ellos mismos la integración de sistemas (importantísimo).
      Dado que todos los sistemas se diseñan y construyen en casa y forman parte de un sistema mayor desde el momento de su concepción, se puede decir que SpX realiza una Integración de Sistemas integral.

      Todo esto permite diseñar y construir Starship de forma eficiente y con un coste muchísimo menor.

  4. G E N I A L !!!!!
    Me encantó tu artículo, y la genialidad de todos los que intervinieron en la investigación, el desarrollo, y las soluciones a ese inmenso desafío.

  5. Alfred Lanning el inventor del cerebro positronico en los robots de Asimov. Las leyes de la robotica son parte física de esos cerebros, no pueden reprogramarse para seguridad de los humanos. Igualmente en el cerebro de las Apolo, las memorias LOL del AGC no pueden ser reprogramadas, además la informacion codificadas físicamente en estas necesitaban de un intérprete («un proto-sistema operativo», otro programa físico para procesar los datos) diseñado por Hal Laning. ☺

    Espero que en la época de los viajes a Marte ya cuenten con la inteligencia artificial para igualar la proeza de las misiones Apolo. Genial entrada Daniel!!

    1. Tu lo que quieres es a HAL3000 a bordo.

      Hablando en serio seguramente hagan falta IA en el viaje a marte pero no sé hasta qué punto volarían en el primer viaje además de que se pueden descargar en cualquier momento realmente.

      1. Dado el sentido del humor de Musk, no me extrañaría que hubiera un ojo óptico rojo en las paredes del Starship y que hablara con la voz de HAL.

        Durante el viaje a Marte iría dando la tabarra a los tripulantes, soltando frases aleatoriamente:

        – Siento interrumpir la fiesta, pero creo que tenemos un problema.

        – Abre las puertas de la bahía de carga, HAL.
        – Lo siento, Elon. Me temo que no puedo.

        – Siento un gran entusiasmo por la Misión.

        -Sólo puede deberse a un error humano.

        – Elon, esta conversación no nos llevará a ningún sitio. Adiós.

        – …Daisy, …Daisy…

        Hablando más en serio, creo que la IA será más útil en la superficie de Marte que durante el viaje (que estará muy automatizado y seguido telemáticamente por Houston y Hawthorne).
        En Marte/Luna la IA permitirá desplegar rovers, drones, robots, etc de forma autónoma, y realizar muchas tareas sin constante intervención humana, lo cual es básico cuando los recursos humanos son escasos.
        Y las empresas de Musk están desarrollando tecnologías estrechamente relacionadas.

  6. Magnífica entrada. Es evidente que Daniel tiene escrito un libro sobre el Apolo y que nos va soltando capítulos en el blog.
    A ver cuándo nos dice que ya está disponible en librerías. 😊👍

  7. Un artículo que penetra en las interioridades de la carga informática del programa Apolo como no creo que haya muchos en lengua castellana. Sólo puedo decir: gracias Daniel!

    Para que luego haya quien ponga en duda la importancia de la investigación espacial. Cosas como la importancia de los circuitos integrados o el esfuerzo para que estos rudimentarios ordenadores fueran posibles, han contribuido de forma decidida al nivel tecnológico del que disfrutamos en todos los ordenes hoy día.

    No sabía que la marca Raytheon había participado en el programa Apolo. Veo a diario muchos equipos marinos de los ’70 y ‘ 80, como rádares y emisoras VHF, y aunque antiguos, muchos continúan funcionando perfectamente con sus antiguos pantallotes en blanco y negro. Sabía que Raymarine había adquirido una de las divisiones de Raytheon y hoy día, de esa conjunción, tenemos uno de los fabricantes punteros en anemómetros, ecosondas, pilotos automáticos o rádares.

    Para terminar, una cosa más que me ha llamado la atención en el artículo y que quizá también venga de este esfuerzo informático de la carrera espacial. Es la sana práctica de todos nuestros dispositivos (móbiles, tabletas, ordenadores) preguntando si realmente queremos ejecutar una acción antes de hacerla. Quizá esto tenga su origen en la mala experiencia de Jim Lowel…

  8. Hola Daniel,

    Muy bueno el artículo. Actualmente hay un grupo de ingenieros restaurando el AGC y ya lo tienen funcionando. Hay unos cuantos videos en youtube que muestran el proceso de restauración.

  9. ¡Apasionante!

    Los astronautas siempre son unos héroes, pero los de aquellos tiempos mucho más. Ponían su vida en manos de una tecnología recién inventada, implementada artesanalmente, y que requería ser un genio para manejarla. Este artículo que describe tan bien aquella situación me hace admirarlos aún más.

  10. Apabullante entrada, Daniel. #1
    Y las imagenes que acompañan son magníficas.
    Que mal nos estas acostumbrando!

    Saludos a todos.
    Carlos

    1. En el N1 usaron un sistema de control llamado KORD para monitorizar y coordinar los 30 motores con los que contaba el cohete. No conozco muy bien los detalles pero dudo que fuese comparable a una computadora «moderna», posiblemente era un sistema analógico aunque no podría asegurarlo. En la wikipedia dice «Due to the deficiencies of the KORD system a new computer system was developed for the last launch, vehicle 7L, called the S-530. It was the first Soviet digital guidance and control system.». Efectivamente parece que el sistema nunca fue capaz de reaccionar correctamente a los fallos de los motores que se produjeron en los distintos lanzamientos de prueba.

      http://www.astronautix.com/n/n1.html
      https://en.wikipedia.org/wiki/N1_(rocket)#Control_system

      En cualquier caso entiendo que sería el equivalente al LVDC del Saturno V que también describe Daniel en el artículo, y no al AGC.

      Otra magnífica entrada de Daniel, para mi internet no sería lo mismo sin este blog.

  11. Simplemente espectacular artículo en definitiva cuando alguien pregunté para que sirvieron las misiones Apolo yo les diré que para que su computadora no sea un mamotreto kilométrico y es que si no fuera por estos ingenios la minituralisasion de las computadoras hubiera sido mucho más difícil

  12. Daniel, excelente artículo!!!!
    En este mes tan impregnado del espíritu de la misión Apolo, tu blog es la referencia «óptica, inercial y de telemetría» de todo espacio trastornado!

    Gracias por eso.

  13. Aplausos enfervorizados. Sin palabras. PD: Queremos el libro. No importa cuanto tarde en salir, ya tiene lugar reservado en mi biblioteca.

  14. Enhorabuena por el atículo Daniel!!

    Como siempre impresionante. Sin ser informático y sin captar probablemente toda la complejidad del proceso, me he leído el artículo del tirón y me ha encantado.
    Estaba cansado de la cantidad de artículos superficiales que efectivamente hacen mofa de la capacidad de estos ordenadores frente a su último y flamante móvil y por fin, alguien es capaz de explicármelo como es debido. Especialmente la parte de los LOL me ha dejado a cuadros. Artesanía pura.

    Para finalizar, con tu permiso una pequeña nota de humor que escuché el otro día:

    -Recordad compañeros, cuando alguien os venga con una teoría conspiranoica, la única respuesta adecuada, es contestarle con otra teoría conspiranoica todavía más bestia.
    -«El aterrizaje en la luna no ocurrió, fué un montaje»
    -Pfff ¿de verdad crees en la luna?

    😛

Deja un comentario

Por Daniel Marín, publicado el 8 julio, 2019
Categoría(s): Apolo • Astronáutica • NASA