Dados los pequeños recursos computacionales, ¿cómo se implementó la navegación? (No son muestras de software de guía antiguo)

En muchas de las primeras sondas, hasta cerca de Apolo, no había verdaderas computadoras en las sondas espaciales. Toda la computación se realizó en la Tierra y la electrónica a bordo se conocía como secuenciador, para Pioneer 10 tenía 222 comandos posibles, 5 de los cuales podían prepararse. Las primeras sondas de Venus enviaban datos cambiando mecánicamente diferentes sensores para modular un transmisor de CW a su vez y clasificándolo todo en la Tierra.

Esto también se aplicó a gran parte del proceso de lanzamiento de Apollo, donde el hardware en la plataforma de lanzamiento no ejecutó un verdadero software sino una secuencia (desde aquí ) de 'espera, activa esto, espera, mide eso y si está fuera de los límites, espera, continúa'. .

Junto con el enlace de código AGC de Ludo, puede ver el controlador de cancelación como un ejemplo a menor escala de cómo se hicieron las cosas (bucle fijo de pasos y tiempos conocidos).

Incluso hoy en día, es muy raro enviar un código a una nave espacial que no se reduzca a una secuencia de instrucciones muy específicas que deben ejecutarse en orden. Curiosity tiene cierta capacidad de navegación autónoma y toma de fotografías, pero generalmente el código de bifurcación está ahí para desencadenar un retroceso/a prueba de fallas 'ups, detener, resolver el problema de orientación de la antena y llamar a casa para obtener instrucciones' en lugar de IA o código de aprendizaje.

En términos generales, el código se hizo para adaptarse a la misma forma en que la gente programa hoy en día para los microcontroladores:

No tener ningún tipo de interfaz de usuario en código (Apollo DSKY era en gran parte hardware)

Usando aproximación o matemáticas enteras sobre punto flotante (muchas cosas son posibles donde pi = 3) o precalcule constantes en la Tierra y cárguelas cuando sea necesario (por ejemplo, gravedad o rendimiento del motor)

Diseño personalizado de hardware de soporte como rastreadores de estrellas para ser precargados con constantes de la Tierra y para generar una salida preformateada y encuadernada verificada para el siguiente paso de procesamiento. De hecho, los límites verifican solo una vez, dónde se obtienen los datos y aseguran que ningún paso siguiente pueda desbordarlos.

Diseñe algoritmos para trabajar en registros en lugar de ubicaciones de memoria (lo que hace que la fuente sea horrible ya que no tiene variables), pero significa que puede evitar muchos valores móviles dentro y fuera de la memoria.

Evite los problemas generales para lo específico, para las naves espaciales se trataba de navegación, informes de estados de sensores/instrumentos y orientación. Todos estos podrían tener un código cuidadosamente elaborado que funcionó bien en un rango específico de entradas ( Aunque ver ).

Confíe en sus datos (en sentido de seguridad) ( aunque la naturaleza aún puede atraparlo )

(respondido originalmente a "Ejemplos de software de guía antiguo")

Lo primero que me viene a la mente es el repositorio Github de la Computadora de Orientación (AGC) del Apolo 11 . El repositorio tiene el software Command Module y Lunar Module, pero tenga en cuenta que se transcribe de copias impresas, por lo que es posible que no esté completamente completo (todavía). Puede encontrar un simulador de AGC en el sitio web de Virtual AGC (también hay muchas otras referencias).

Soy desarrollador de software y con todos los recursos disponibles en la actualidad, no puedo imaginar dónde se podría siquiera comenzar con tal esfuerzo.

Hay muchos sistemas basados ​​en computadora hasta el día de hoy que tienen que vivir con tales limitaciones. Hay muchos sistemas integrados en los que 2^16 (65536) bytes de memoria siguen siendo un lujo. Después de todo, en las máquinas que usan direcciones de memoria de 16 bits (muchas de las cuales todavía existen y todavía se fabrican hasta el día de hoy), no tiene sentido tener más de 65636 bytes de memoria. Y así como no hay problema con una computadora con direcciones de 64 bits que tienen menos de 18+ exabytes de memoria, no hay problema con una computadora que usa direcciones de 16 bits que tienen menos de 2^16 bytes de memoria.

Hay muchas maneras de comenzar con tal esfuerzo. La regla número uno es evitar el uso de un sistema operativo. Muchos (¿la mayoría?) de los sistemas integrados son máquinas desnudas . No hay sistema operativo, y solo hay un programa ejecutándose, siempre. Su horno de microondas tiene una computadora que funciona como un sistema integrado y no tiene sistema operativo. Si su automóvil se fabricó en los últimos 25 años o más, tiene muchos sistemas integrados ejecutándose. Si su automóvil se parece a lo moderno, tiene varias docenas de microcontroladores que, en conjunto, ejecutan varios millones de líneas de código.

Muchos de los microcontroladores de un automóvil moderno no están sujetos al límite de direcciones de 64K (2^16 o 65536). En el pasado, ese era un límite muy común e inherentemente limitaba el tamaño de la memoria. Pero no limitó el almacenamiento. El problema de que el tamaño del disco supere las limitaciones de direcciones se resolvió en las décadas de 1950 y 1960. Una solución común era utilizar superposiciones de memoria . Esta técnica, que me alegro de haber olvidado (en su mayoría), sigue siendo común hasta el día de hoy en la programación de sistemas integrados.

Otra técnica ampliamente utilizada fue y es hacer que la máquina integrada siga una arquitectura de Harvard en oposición a una arquitectura de von Neumann . No hay distinción entre código y datos en una máquina de Von Neumann. El código y los datos son cosas muy diferentes en una máquina de arquitectura Harvard, posiblemente con diferentes tamaños de palabra. Lo más probable es que su computadora portátil o de escritorio sea una máquina de arquitectura von Neumann, al menos en la superficie. En el fondo, se parece más a una máquina de Harvard, con cachés separados para código y datos.

La forma en que se implementó en el mundo ICBM fue que había seis personas sentadas alrededor de una mesa que diseñaban las rutinas matemáticas y la arquitectura general, la codificación detallada del componente del programa y el hardware de la computadora, todo al mismo tiempo. Cinco líneas de código por día se consideraban un buen día de trabajo. La mayor parte del tiempo se dedicó a discutir si hacer algo con hardware o software. Los circuitos integrados habían avanzado hasta el punto de disponer de registros de cuatro bits. Fueron utilizados para los dos registros de la CPU.

No había memoria direccionable en el sistema en el que trabajé. Solo un disco con un montón de cabezales fijos. El código fue registrado en el disco. Había un bus superior e inferior y dos registros de una palabra de longitud, pero era una palabra grande.

Terminó habiendo cuatro programas que podrían intercambiarse mediante el cambio de datos remoto. Solo uno era para vuelo, los otros eran programas terrestres.

El hardware hizo la mayor parte del trabajo, cosas como matemáticas de matriz de 3 x 3 se realizaron con algunas instrucciones de microcódigo que dieron como resultado que una nueva matriz reemplazara a una anterior en la misma ubicación en el disco.

La CPU a menudo tenía áreas que no se usaban durante estas instrucciones más largas, por lo que podían colar pequeñas sumas, restas, multiplicaciones y divisiones en el medio. Estas instrucciones solo cambiaron pequeñas partes de la CPU, y había MUCHAS instrucciones disponibles. Solo tenía que asegurarse de que todo estuviera en el lugar correcto en el disco para que estuviera disponible cuando hubiera un poco de tiempo libre. Tenían cinco instrucciones diferentes para dividir dos números, difiriendo solo en la ruta y el tiempo del proceso dentro de la CPU para evitar colisiones con otros cálculos en curso. Muchas de las funciones de contabilidad se realizaron de esta manera.

La parte realmente divertida era que podías comenzar una instrucción larga antes de tener todos los números para completarla. Mientras molía en la parte delantera, podía iniciar una operación de suma y dejarla en un registro para que la instrucción larga la encontrara más tarde. Incluso podría escribirlo en el disco. Estos fueron un verdadero placer para rastrear y depurar.

La computadora de navegación tuvo que manejar tres señales de salida para dirigir el cohete. No sabía nada de puesta en escena ni nada más. Tenía una tabla que decía que debería ver los conteos del acelerómetro de x, y, z en el tiempo t (los pulsos acumulados igualaban la velocidad del eje del acelerómetro). Comparó los conteos reales con la tabla preprogramada y calculó nuevas señales de dirección.

La conclusión es que los programadores tenían un objetivo bastante limitado y tenían un mapa completo de la CPU en su cabeza y podían seguir toda la operación de la CPU en su cabeza a medida que se ejecutaban los componentes del programa.

No estuve en la fase de diseño, pero uno de los muchachos que estaban sentados en la mesa me entrenó en la CPU y el microcódigo.

Echa un vistazo al idioma FORTH. No hace distinción entre el código de usuario y el código en el (pequeño) núcleo del sistema operativo. Se utilizó en el firmware de los primeros satélites. Una buena descripción está aquí: https://en.wikipedia.org/wiki/Forth_(programming_language)

Es posible que desee leer este libro: https://www.goodreads.com/book/show/7754526-the-apollo-guidance-computer

La primera mitad es una descripción detallada de la arquitectura de hardware de la computadora de guía Apollo y el software que se ejecuta en ella. Hay algunas discusiones fascinantes sobre las limitaciones del hardware y lo que hicieron los diseñadores para superar esas limitaciones.