Cómo los ordenadores de la NASA salvaron a los astronautas del Apolo 13

Homer Ahr había estado dormido durante 15 minutos cuando recibió una llamada de su jefe en el Centro Espacial Johnson.

"Todo lo que dijo fue, 'Homer, ve a control de misión lo más rápido que puedas'. No tenía idea de por qué iba ahí", dijo.

"En menos de 30 minutos, ya sabía que estaban verdaderamente en una situación de vida o muerte", dijo Ahr.

Horas antes, el astronauta del Apolo 13, Jack Swigert, había dejado sin palabras al control de misión de la NASA con su ahora famosa declaración: "Houston, tenemos un problema".

La nave del Apolo 13 estaba a más de 300 000 kilómetros de su viaje a la luna cuando una explosión destrozó la pequeña cápsula.

Ese día de abril de 1970, con la nave liberando su preciado suministro de oxígeno, la NASA sabía que tenía pocas opciones para traer de vuelta a salvo a los tres astronautas del Apolo en la nave averiada.

Son realistas las ambiciones de Tesla para su sistema Autopilot

"A partir de esa realización, todo lo que hicimos fue hacer todo lo posible para traerlos de vuelta", dijo Ahr.

"Es como estar en la sala de emergencias, ¿sabes? Si tienes que clavar una aguja en el pecho de alguien para reactivar su corazón, simplemente lo haces. No piensas en lo que estás haciendo. Solo lo haces".

Uno de los muchos problemas urgentes era cómo llevar a cabo un rescate sin encender los motores de la parte dañada de la nave. En el centro de control de la misión de la NASA en Houston, Texas, redujeron las opciones a una maniobra que nunca antes se había intentado. La supervivencia de los astronautas ahora dependía de usar los motores de descenso del módulo lunar para poner la nave en una trayectoria de regreso a casa.

El control de misión tenía un tiempo limitado para resolver cómo llevar a cabo la maniobra. Afortunadamente, solo unos meses antes de que la tripulación despegara desde el Cabo Cañaveral, dos programadores habían escrito el software para calcular precisamente ese movimiento.

Uno de esos programadores era Homer Ahr, de 22 años, un año después de graduarse de la universidad y trabajando para IBM como experto en planificación de maniobras en apoyo a los oficiales de vuelo de la NASA en el control de misión.

"Si lo que había ocurrido en el Apolo 13 hubiera ocurrido en el Apolo 12, habríamos tenido un verdadero problema", dijo Ahr, ya que los algoritmos para calcular esa maniobra acababan de ser agregados.

La importancia de los registros electrónicos de salud (EHR) en el ámbito médico

"Físicamente podrías hacerlo, pero computacionalmente y en el centro de control de la misión, habría sido extremadamente difícil saber cuándo hacer la maniobra y cómo hacerla", dijo.

El control de misión necesitaba asegurarse de que encender los motores de descenso funcionaría, y Ahr y un colega pasaron la noche ejecutando lo que se llamaba un análisis de dispersión, verificando todos los parámetros posibles para ver si la maniobra colocaría la nave en el rumbo correcto.

"Ni siquiera podría decirte el número de veces que realizamos cálculos", dijo Ahr, "pero hicimos el análisis de dispersión, y la conclusión fue: 'Adelante, haz la maniobra'".

Las computadoras como héroes

El regreso seguro eventual de los astronautas se debió a mucho más que solo una serie de cálculos, pero el recuerdo de Ahr ilustra lo crucial que eran las primeras computadoras para las misiones lunares.

Con su objetivo de poner un hombre en la luna, el programa Apolo de la NASA es quizás el proyecto técnico más ambicioso jamás emprendido. A lo largo de las 15 misiones del Apolo, que incluyen seis aterrizajes en la luna, la precisión necesaria, en términos de posicionamiento y velocidad, para colocar la nave en la trayectoria correcta en el viaje de ida y vuelta a la Tierra era exigente.

Todos los movimientos que llevaría a cabo la nave espacial fueron calculados de antemano por las computadoras de IBM en el Complejo Computacional en Tiempo Real (RTCC) del Centro Espacial Johnson, y verificados en comparación con los movimientos reales de la nave durante la misión.

Los 10 países más innovadores según el número de patentes emitidas por habitante

Igual de importante para el regreso del Apolo 13 y el éxito del programa en general fueron los sistemas informáticos que respaldaban los numerosos simuladores en el Centro Espacial Johnson y el Cabo Cañaveral. Los simuladores incluían copias de trabajo de los módulos de comando y luna de la nave espacial, y permitían a los astronautas de la NASA y a los controladores de vuelo en tierra practicar cada parte del viaje: desde el lanzamiento, hasta el aterrizaje lunar, hasta la reentrada en la Tierra, trabajando en conjunto como lo harían durante la misión.

Los simuladores replicaban no solo el funcionamiento de las computadoras a bordo, sino que también suministraban datos a los sistemas terrestres, recreando la experiencia de una misión real lo más cercana posible y preparando al personal para enfrentar una serie de problemas potenciales.

Jack Winters, quien supervisaba las pruebas de los simuladores y comenzó escribiendo software para los simuladores durante las primeras misiones Gemini, dijo que el entrenamiento para los controladores de vuelo fue invaluable para el Proyecto Apolo.

"Durante el Apolo 13, por ejemplo, fueron mucho, mucho mejores para detectar el problema y desarrollar soluciones alternativas gracias al entrenamiento", dijo.

Durante el Apolo 13, estos simuladores permitieron a los ingenieros y astronautas en tierra, trabajando junto con el astronauta Ken Mattingly, quien fue reemplazado en la tripulación del Apolo 13 en el último momento, descubrir cómo poner en funcionamiento los sistemas de la nave de comando con la energía limitada disponible, un paso crucial antes de reingresar a la atmósfera terrestre.

Merritt Jones trabajaba en el Centro Espacial Johnson como programador de computadoras y astrodinamicista, calculando la mecánica de cómo se mueve una nave espacial en órbita.

AR y VR: Un viaje en el tiempo y hacia el futuro

Resolver el orden correcto para restaurar los sistemas del módulo lunar fue increíblemente importante para el regreso seguro de la tripulación del Apolo 13, dijo.

"Tenían que reducir la energía requerida para la secuencia de inicio. La secuencia de inicio era crítica. Si no comenzabas en el orden correcto, los sistemas no funcionarían bien o simplemente no funcionarían en absoluto", dijo.

Descargue este artículo como PDF (se requiere registro gratuito)

Empujando los límites

Las computadoras utilizadas durante las misiones del Apolo eran increíblemente rudimentarias en comparación con los estándares modernos. Cada uno de los cinco mainframes IBM System/360 Model J75 del RTCC tenía alrededor de 1 MB de memoria principal, ni siquiera suficiente para cargar una página web típica en 2017.

"El software que controla lo que sucede cuando mueves el mouse en tu PC, el controlador del mouse para Windows, ocupa más memoria que todas las supercomputadoras de la NASA juntas para el Apolo", dijo Jones.

A pesar de llenar una sala entera de electrónica, los mainframes alcanzaban solo alrededor de un millón de instrucciones por segundo (MIPS), unas 30 000 veces más lentos que los procesadores más rápidos utilizados en las computadoras personales de hoy en día.

La impresión 3D: una revolución en el diseño y fabricación de productos

La NASA estaba llegando a los límites de lo que la tecnología de la época podía hacer, lo que a menudo significaba confiar en hardware y software de vanguardia, y a veces no probado. Y cuando la tecnología simplemente no existía, los socios comerciales de la NASA tenían que inventarla.

Un caso en cuestión fue la Computadora de Guiado del Apolo (AGC). Si bien los sistemas en tierra podrían parecer insuficientes, las computadoras a bordo eran mucho más simples. La computadora de guiado para la nave Apolo necesitaba ser lo suficientemente pequeña como para caber en una cápsula estrecha y lo suficientemente liviana como para que el cohete Saturno la llevara al espacio. Los mainframes de IBM del tamaño de un armario que la NASA usaba en tierra estaban fuera de discusión.

El Massachusetts Institute of Technology Instrumentation Laboratory (MIT-IL), que tenía el contrato para desarrollar la AGC, recurrió a una nueva tecnología, los circuitos integrados, que tenían el potencial de hacer que las computadoras fueran más rápidas y más pequeñas al grabar múltiples transistores en pequeños chips. En ese momento, en 1961, los circuitos integrados se habían inventado solo dos años antes y eran algo desconocido, pero para 1963, MIT-IL había ordenado alrededor del 60 por ciento de los circuitos integrados disponibles en el mundo.

"Mucho tenía que ver con la potencia y el peso", dijo Bob Zagrodnick, ingeniero que trabajó en la AGC en Raytheon, que construyó 43 de las computadoras durante el curso del programa Apolo.

"Estas son unidades pequeñas y no consumían mucha energía. Constantemente nos esforzábamos por minimizar el peso y el consumo de energía", dijo.

Más inusual fue la forma en que el software que se ejecutaba en la AGC estaba literalmente tejido. En la línea de producción de Raytheon en Waltham, Massachusetts, los tejedores pasaban el alambre a través de imanes circulares, creando una obra de arte metálica cuyo patrón correspondía a los unos y ceros digitales, que a su vez codificaban los programas que se ejecutaban en la computadora.

Las 10 carreras universitarias con más multimillonarios según Forbes

"En realidad, enhebraban la información del programa de vuelo en las memorias centrales", dijo Zagrodnick. "Fue una actividad muy intensa, por lo que principalmente las mujeres que eran buenas con la aguja e hilo eran las que tejían o ensamblaban las memorias centrales".

De regreso en el Centro Espacial Johnson, IBM se enfrentó a un desafío totalmente diferente. Como su nombre lo indica, las computadoras en el RTCC debían poder manejar nuevos trabajos y datos en tiempo real, para cumplir su función de monitorear las trayectorias de las naves espaciales y llevar a cabo simulaciones complejas de las misiones. El problema era que en ese momento, a principios de la década de 1960, no existían sistemas operativos en tiempo real.

Según Ahr: "Teníamos que obtener un sistema operativo multitarea y multinavegación en la década de 1960, antes de que IBM construyera un sistema operativo multitarea y multinavegación".

Entonces, IBM inventó uno, modificando el sistema operativo existente en su mainframe System/360, además de crear una base de datos en tiempo real llamada DataTables, "mucho antes de que existiera algo llamado base de datos relacional", dijo Ahr. Con reglas estrictas sobre qué datos se podían actualizar y cuándo, para garantizar que la información crítica relacionada con la nave espacial sea precisa y esté disponible cuando sea necesario.

Trabajar con un nuevo sistema operativo agregó un nuevo problema a una tarea que ya presentaba desafíos, ya que los cálculos arrojaban resultados inesperados no solo debido a errores en las aplicaciones, sino también a errores en el sistema operativo relativamente no probado.

Descargue este artículo como PDF (se requiere registro gratuito)

El Falcon: la nueva laptop convertible de 8 pulgadas con Windows 10 y pantalla táctil

Apuntando a la luna

La presión sobre los jóvenes programadores de IBM era intensa, con personas trabajando hasta 80 horas a la semana para cumplir con los plazos más difíciles.

Winters dijo: "La NASA tenía un horario. Iban a volar en ciertas fechas. Lo anunciaron al público y IBM seguramente no quería ser el responsable de retrasar el vuelo".

Ese impulso para trabajar sin descanso fue impulsado en parte por el cronograma agotador, pero también por la emoción de trabajar para poner a un hombre en la luna y el deseo de superar a los rusos en la carrera espacial.

"Estábamos tan emocionados", dijo Winters. "Éramos jóvenes. Creo que tenía 21 años cuando comencé. No sabíamos lo que no podíamos hacer. Simplemente pensamos que podíamos hacer cualquier cosa. Aquí estaba trabajando en software que iba a ir al espacio y, eventualmente, a la luna. El factor de adrenalina era tremendo".

Ser lo suficientemente joven como para no apreciar por completo lo que no se podía o no se debía hacer a veces resultaba muy gratificante, según Harry Hulen, quien trabajó principalmente en el software utilizado en los simuladores en Houston antes de supervisar el código de otras personas.

Hulen recuerda haber tenido dificultades para simular los tanques de propelente en el cohete no tripulado Agena durante las misiones Gemini, el proyecto estadounidense de vuelos tripulados en el espacio que precedió al Apolo, cuando fue a una tienda departamental local.

Realidad virtual: Cuál es su importancia y qué nos espera

"Allí, junto con los tipos habituales de libros que ves en una tienda, había un libro llamado Rocket Propellant and Pressurization Systems", dijo.

"Lo compré y resultó que ese libro me decía exactamente qué hacer con los requisitos que tenía. Simplemente ignoré totalmente los requisitos que había escrito la NASA y programé a partir de este libro que compré en Sakowitz", dijo Hulen. "Funcionó bien. Nadie me atrapó y los resultados funcionaron perfectamente. Pudieron simular ciertas cosas con un grado mayor de precisión que el requerido.

Lo importante es que yo tenía, tal vez, 22 años y no sabía que estaba haciendo lo incorrecto. Simplemente dije: 'Esto me parece lo que debo hacer'. Sospecho que hubo bastante de eso", dijo.

Eso no significa que siempre fuera fácil encontrar el equilibrio adecuado entre los compromisos personales y profesionales. Muchos de los jóvenes programadores estaban formando familias en ese momento, pero a menudo se veían obligados a trabajar hasta tarde para probar software, debido a que las máquinas estaban en uso constante durante el día.

"Gran parte de nuestro tiempo de desarrollo era por la medianoche", dijo Winters.

"Pasé muchas horas tarde en la sala de computadoras probando software y supervisando las pruebas de software. De hecho, mi primer divorcio probablemente fue causado por todas las horas que trabajé durante ese período", dijo.

Raspberry Pi 3 Model A+: Todo lo que necesitas saber sobre la nueva placa de $25

Al fondo de la mente de cada ingeniero no solo estaba el éxito de la misión, sino también las vidas de los astronautas que dependían de que el software hiciera su trabajo.

Desde el momento en que Tom Steele se unió a IBM en 1963, trabajando desde Huntsville, Alabama en software para los sistemas de guiado en los cohetes Saturno utilizados durante el Apolo, dijo que su equipo se dio cuenta de inmediato de lo que estaba en juego.

"Cada contratista tenía un programa de conciencia de vuelos tripulados. Esos programas estaban diseñados tanto para que hicieras las cosas mejor como para ayudarte a manejar la idea de que podrías matar a alguien si metías la pata", dijo.

Ahr sintió esa responsabilidad particularmente durante el Apolo 11, la misión de 1969 que llevó a los primeros hombres a la luna.

Su trabajo en ese momento era ejecutar software que calculaba las maniobras del cohete y la nave espacial en cada etapa de la misión y verificar la posición en tiempo real de la nave espacial en comparación con los resultados proyectados, trabajando para apoyar a los oficiales de vuelo en el control de misión.

El papel no fue en absoluto sencillo, ya que requería que Ahr se sentara en una consola escuchando alrededor de ocho líneas telefónicas diferentes a la vez, además de la transmisión de audio de los astronautas. Recuerda el miedo que sintió cuando esas líneas comenzaron a resonar con el sonido de una alarma mientras el módulo lunar del Apolo 11 descendía hacia la superficie de la luna.

AWS RoboMaker: Una guía rápida para expertos

"Cuando esas alarmas sonaron durante el primer descenso, fue aterrador, por decir lo menos", dijo Ahr. "Fue caótico escuchar todo eso a la vez y tratar de mantener la calma, mantener la cabeza en alto y no entrar en pánico.

"Era como si estuvieras sentado en un partido de fútbol, hay multitud de personas gritando, y levantando la voz, y gritando, además al mismo tiempo hay un incendio. Sabes, los camiones de bomberos llegan, las ambulancias llegan, la policía llega, y todas tienen sus sirenas encendidas", dijo. "Eso es lo que estás escuchando mientras tratas de mantener la calma y observar los datos en tiempo real que llegan".

Afortunadamente, el descenso a la superficie lunar fue casi perfecto: "Tan buen descenso como podríamos haber volado", dijo Ahr, gracias a los muchos sistemas de seguridad integrados en los sistemas del Apolo. En este caso, el radar de encuentro en el módulo se había encendido, sobrecargando la computadora de guiado del Apolo con tareas. Sin embargo, el sistema pudo priorizar las tareas necesarias para el descenso e ignorar las relacionadas con el radar.

Ahr atribuye su habilidad para mantener la calma y hacer su trabajo al extenso entrenamiento antes de la misión, donde se habían simulado todo tipo de problemas, y a la conciencia del importante papel que él y el resto del personal en tierra tenían.

"Cada acción que hiciste en la consola afectaba el éxito de la misión y podía afectar las vidas de los astronautas", dijo. "Debías tener una característica donde cuanto más presión había y más estrés había, mejor trabajabas".

Había un mutuo respeto entre los ingenieros de IBM y sus colegas de la NASA, resultado de su estrecha colaboración y las altas apuestas involucradas en hacer realidad los vuelos espaciales tripulados.

Sentíamos que éramos "una verdadera camarilla de hermanos", dijo Ahr. "Siempre estábamos comprometidos con el mismo objetivo: misiones exitosas".

Descargue este artículo como PDF (se requiere registro gratuito)

"Estoy asombrado de haberlo logrado"

Agregando a la presión estaban las limitaciones profundas de la tecnología primitiva en ese momento, ya sea la facilidad con la que los operadores de consola como Ahr podían cometer errores al escribir datos en una máquina de teletipo durante una misión o tener que escribir programas para los mainframes de IBM en tarjetas perforadas.

"En retrospectiva, estoy asombrado de haberlo logrado", dijo Winters.

Cada etapa del proceso de programación era increíblemente engorrosa. Los programas para los mainframes de IBM en Houston se escribían en bloques de códigos, que luego se entregaban a operadores de perforadoras que los perforaban en mazos de tarjetas.

Como la oficina principal de la División de Sistemas Federales de IBM estaba situada aproximadamente a una milla de las computadoras, a menudo era necesario que un mensajero entregara las bandejas con las tarjetas al Centro de Cómputo y devolviera los resultados, lo que limitaba la cantidad de veces que el software podía ejecutarse a un promedio de 1,2 veces por programador por día.

Hulen dijo: "Si tenías suerte, tenías un resultado al día siguiente. Lo que recibías era papel, y muchas veces, era un volcado de memoria", una señal de que el programa se había bloqueado. Depurar este código, principalmente en lenguaje ensamblador con algo de Fortran, para identificar la causa del problema no era nada parecido a lo que se hace hoy en día.

El volcado de memoria sería una pila de papel, "quizás de ocho o nueve pulgadas" de altura, sin una palabra de lenguaje humano en él.

"Todo estaría en hexadecimal, y tenías que aprender a leer eso y encontrar puntos clave dentro del volcado. Lo que necesitabas probablemente habría cabido en una sola página, pero no había una forma real de saber lo que realmente necesitabas, por lo que obtenías estos grandes volcados de memoria", dijo Hulen.

"Tenías que ser muy hábil en hexadecimal y ser capaz de reconocer tus instrucciones de lenguaje ensamblador literalmente en lenguaje de máquina", dijo. "Tenías que conocer a muchas personas para obtener ayuda. En un mal día, podría llevar dos o tres días resolverlo".

La documentación también era mínima, especialmente en las primeras misiones. Hulen recuerda haber trabajado en el software de telemetría relacionado con el cohete Agena utilizado en el Proyecto Gemini. Los programadores mantenían un desglose de bits por bit de cada uno de los componentes básicos de ese software, conocidos como palabras, que se escribían en una pieza de cartón llamada tablero de bits.

“La única documentación era este tablero de bits que habíamos creado. Funcionó bastante bien hasta que una noche el personal de limpieza lo tiró", dijo Hulen. "No teníamos una copia de seguridad para ello. Tuvimos una verdadera crisis allí, donde tuvimos que descubrir qué significaba cada uno de esos bits y tratar de recrear el tablero de bits, lo que nunca se logró totalmente".

A lo largo del tiempo, sin embargo, la escala sin precedentes de los programas en los que se trabajaba hizo que IBM desarrollara planes de gestión de proyectos sofisticados, técnicas que se utilizarían durante décadas.

"Estos eran programas de software extremadamente grandes. Había más de un millón de líneas de código de software de aplicación", dijo Winters. "Hubo muy pocos ejemplos exitosos de desarrollar esa cantidad de software con éxito".

Había alrededor de 500 programadores de IBM basados en el Centro Espacial Johnson en el área de Clear Lake en Houston, distribuidos en unos 10 edificios diferentes. Para coordinar eficazmente la fuerza laboral, IBM inventó un enfoque que consistía en dividir el software en módulos administrados por diferentes equipos y establecer fechas para cuando se completaría el diseño, la codificación, la integración y las pruebas del código.

Winters dijo que uno de los gerentes iniciales, Dick Hanrahan, "pionero de ese tipo de técnica de administración", y agregó que el enfoque se utilizaría para grandes proyectos en la División de Sistemas Federales de IBM.

El poder de los procesadores y la cantidad de memoria disponible era tan limitada que los programadores pasaban una cantidad extraordinaria de tiempo tratando de simplificar el código, especialmente si se ejecutaba una instrucción repetidamente.

"Pasaba meses tratando de poner la ecuación en una forma que ocupara menos memoria y se ejecutara más rápido y aún así se obtuviera una respuesta correcta aceptable. Y cuando digo meses, me refiero a meses", dijo Jones de su trabajo calculando las trayectorias de las naves espaciales en los mainframes de IBM.

"Pasaba un mes tratando de eliminar una instrucción de un bucle", dijo Jones. "Si quitaba una instrucción, podía ahorrar, digamos, 10 000 ejecuciones de instrucciones. Solo tenía 1 000 000 disponibles y el sistema operativo tomó algunas de ellas".

Otro caso vio a Jones escribir un código para manipular directamente los ceros y unos del código de máquina, usando "instrucciones de enmascaramiento" para obtener una forma mucho más eficiente de verificar si un número era mayor que otro.

"Si miraste el código, se vería horrible, pero sería rápido", dijo.

Según Jones, sin estas optimizaciones extremas, el software que llevaba a cabo cálculos en tiempo real, como la posición actual de la nave espacial, simplemente no habría podido ejecutarse en las computadoras disponibles.

Dado que los mainframes de IBM utilizados en el control de misión tenían miles de veces menos memoria que una máquina hoy en día, el software debía cargarse en secciones, cada una de las cuales se relacionaba con una fase diferente del viaje a la luna. Cada sección tomaría segundos en cargarse, complicando aún más el proceso de rastrear una nave espacial que podría estar moviéndose hasta a siete millas por segundo.

Los sistemas a bordo de la nave espacial eran enormemente más limitados que los presentes en tierra, con la computadora de la Unidad del Instrumento a bordo del cohete Saturno V capaz de realizar solo 15 000 operaciones por segundo y sin admitir matemáticas de punto flotante. "Ni siquiera podemos comenzar a comparar eso con hoy", dijo Jones.

La escasez de potencia informática significaba que el valor relativo del tiempo del programador frente al tiempo de la computadora era inverso a lo que es en 2017, dijo Jones.

"Hoy, puedes comprar la potencia informática que necesites si tienes el dinero para comprarla, y el tiempo del programador vale mucho más que la computadora. En esos días, una hora en un mainframe de IBM valía un mes del tiempo de una persona con un máster en matemáticas que realizaba este trabajo. Mi salario mensual era el mismo que una hora en el mainframe".

Sorprendentemente, Steele dijo que muchas de las técnicas de programación utilizadas hoy en día estaban disponibles en la década de 1960: "Simplemente no tenías ninguna computadora que pudiera aprovecharlas", dijo.

Las limitaciones de la tecnología eran tan numerosas y los cálculos tan complejos, que lo mejor que los ingenieros podían esperar era acercarse lo más posible a la certeza.

"No había respuestas absolutas de sí/no. [Pero] tenías que tomar la decisión como si las hubiera", dijo Steele.

Acercarse lo más posible a la certeza significaba probar todas las posibles situaciones. Sin embargo, ciertas cosas no se podían probar en tierra, como cómo el entorno de gravedad cero del espacio alteraría las burbujas de aire en las uniones soldadas de los circuitos electrónicos. Por lo tanto, igual de importante era aprender de cada misión anterior.

"Lo único que es cierto: nunca, nunca volamos una misión que no tuviera una falla. Nunca", dijo Steele.

A pesar de los desafíos aparentemente insuperables, el programa del Apolo no solo logró el objetivo enormemente ambicioso del presidente John F. Kennedy de poner a un estadounidense en la luna para fines de la década de 1960, sino que también lo siguió con múltiples viajes de regreso al satélite rocoso de la Tierra.

Décadas después, los programadores del Apolo describen una sensación de orgullo, pero aún más de tener una suerte increíble.

"Me siento muy bendecido de haber tenido la oportunidad de haber sido parte de eso. Creo que es probablemente una de las cosas más afortunadas que me ha sucedido en mi vida", dijo Winters.

Steele lo resume de manera aún más concisa: "No hubo un solo día, ni un solo día en el cual no hubiera un problema por resolver, y eso fue asombroso. Fue un paseo asombroso".

Descargue este artículo como PDF (se requiere registro gratuito).

Fuente de la imagen principal: NASA

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Conjunto de instrumentos, allí encontraras muchos artículos similares a Cómo los ordenadores de la NASA salvaron a los astronautas del Apolo 13 , tenemos lo ultimo en tecnología 2023.