Histoires de l'ordinateur lunaire. 3e partie



Apollo 11 sur la lune

Cinq mois plus tard, Apollo 12 a survécu à un éclair pendant l'accélération et s'est assis sur la lune. Grâce au nouveau «nom 69» que nous avons ajouté au programme afin de permettre à l'équipe de changer de position en fonction des données de suivi au sol, les astronautes Pete Conrad et Alan Bean ont pu atterrir le module lunaire à distance de marche de l'homme sans pilote. le navire Surveyor, qui a atterri sur la lune en avril 1967. L'atterrissage précis d'Apollo 12 a ouvert la voie à des atterrissages sur un terrain plus complexe.

Ce n'est qu'après Apollo 12 que nous avons commencé à comprendre d'autres problèmes graves.

J'ai commencé lorsque Clint Tillman de Grumman Aerospace (la société de construction de modules lunaires) a remarqué des vibrations de l'accélérateur tout en simulant la phase finale d'atterrissage lorsque la poussée du moteur était d'environ 5%. Cela a incité Tilman à étudier les données de télémétrie d'Apollo 11 et 12, où il a remarqué des fluctuations dans la phase finale de l'atterrissage, ayant une amplitude de 25% de crête à crête (voir Fig.12). C'était une période où le commandant du navire pouvait simultanément utiliser l'interrupteur ROD pour contrôler la vitesse de descente et le joystick pour manœuvrer le navire. Étant donné que les graphiques de ces données ressemblaient aux murs et aux tours du château (ou écrou du château), ce problème était appelé la «forteresse des gaz».



Fig. 11: Premier rapport d'étranglement

Clamp à Cambridge a décrit une source d'excitation des oscillations vers un phénomène inconnu, qu'il a appelé "IMU bob" [18]. L'IMU était situé au-dessus et quatre pieds devant le centre de gravité du navire. Des manœuvres petites mais rapides, comme lors de l'atterrissage final, ont projeté le navire de sorte que les accéléromètres interprètent cela comme un changement de la vitesse verticale du navire. Ceci, à son tour, a influencé le calcul de la vitesse verticale et l'évaluation de la traction nécessaire.

Mais cette théorie n'explique que partiellement le comportement des gaz observé dans les données de vol.

Les moteurs de fusée étranglés étaient et restent une rareté, mais un moteur d'accélérateur était nécessaire pour un atterrissage en douceur sur la lune. Un moteur à poussée fixe et des équations de mouvement très simples peuvent faire atterrir un navire au-delà du point souhaité sur la surface lunaire. Mais afin de s'asseoir à l'envers, de se déplacer en douceur, de maintenir le site d'atterrissage dans la zone de visibilité, et avec la capacité de survoler le site d'atterrissage, nous avions besoin d'un moteur qui pourrait équilibrer la gravité lunaire, changer la traction à mesure que la masse de la voiture diminue et lorsque le vecteur de poussée change pendant les manœuvres et quand les astronautes ont voulu changer la vitesse de la descente.

Les équations du mouvement déterminent quelle accélération doit être donnée à l'appareil, avec quelle ampleur et dans quelle direction. Le pilote automatique effectue des manœuvres pour que la force de traction corresponde à une direction donnée. La tâche du programme de commande des gaz est de contrôler la traction. Le contrôle de l'étranglement commence par calculer la masse du module lunaire. Connaissant la masse, nous déterminons la quantité de correction de l'accélérateur requise pour changer l'accélération du navire par rapport à celle mesurée par les accéléromètres à la valeur nécessaire pour se conformer aux équations du mouvement, et convertir la valeur résultante en unités utilisées par l'ensemble de l'accélérateur (environ 2,8 livres par impulsion), et les envoyer à l'interface matérielle.

Les accéléromètres de l'IMU ne mesurent pas réellement l'accélération, ils mesurent l'incrément de vitesse par rapport à la dernière lecture. Étant donné que les changements d'étranglement au cours de l'itération précédente se produisent à un moment donné entre les lectures des accéléromètres, le delta-V mesuré ne montre pas le plein effet du changement le plus récent.



Fig. 12: Changements d'étranglement pendant la phase P66 du vol Apollo 12 [19]

La commande des gaz était censée compenser cet effet. Une série de compensations dépendait du moment où la commande d'accélérateur a été envoyée pendant la période, et dépendait également de la vitesse à laquelle le moteur exécute les commandes de limitation. Des études expérimentales ont établi que la limitation a un retard de 0,3 s.

Cela a permis à l'auteur de programmer et de tester le programme de commande des gaz. Dans les graphiques de simulation du modèle DPS exact utilisant un retard de 0,3 s, j'ai observé des oscillations de la poussée réelle qui se sont produites après un grand changement dans la position du papillon, sans compenser le retard du papillon. Lorsque j'ai activé la compensation pendant 0,1 s, j'ai vu comment les oscillations diminuaient. Lorsque j'ai réglé la compensation à 0,2 s, les oscillations ont presque disparu. C'était fini. Klump a rappelé comment j'ai dit: "c'est comme un médicament, vous n'avez pas à donner plus de compensation que nécessaire."

Klump savait que ce n'était pas «comme un remède», mais il n'a jamais insisté pour que je programme la bonne valeur. Expliquant sa motivation après 15 ans, Klump écrit:

«Je pensais qu'il était important de renforcer la confiance en soi, de permettre aux collègues de prendre des décisions sur de petits problèmes, même s'ils ne sont pas optimaux. Par conséquent, j'ai retenu mes pensées et confirmé la décision de Don en vigueur, au moins jusqu'à ce qu'il la révise de son propre chef »[20].

En expliquant mes propres motivations, je pense que j'ai été irrité par la compensation dans le programme de limitation déjà surchargé, et cela a peut-être conduit à vouloir rendre la compensation aussi petite que possible. Quoi qu'il en soit, Apollo 11 et Apollo 12 ont volé avec une compensation de 0,2 s avec un retard des gaz de 0,3 s.

Mais maintenant, l'analyse de Klump [21] et un rapport indépendant préparé par JA Sorensen à Bellcomm [22] ont conclu que «la nature oscillatoire de la commande d'étranglement P66 était évidemment due au fait que la valeur réelle la constante de temps du moteur à l'atterrissage est inférieure à celle attendue »(Sorensen). Klump a revérifié les données. Les paramètres du moteur d'atterrissage ont été améliorés, mais les modifications correspondantes n'ont pas été apportées à la documentation. Le retard réel pour le moteur d'atterrissage était d'environ 0,075 s. Il s'est avéré que nous l'avons même surcompensé. En conséquence, l'accélérateur était au bord de la stabilité.

L'analyse de Clampp a donné un résultat encore plus frappant. Il a montré que si le logiciel Apollo 11 compensait 0,3 s, l'accélérateur serait instable. Les vibrations des gaz, au lieu de se calmer, deviendraient plus importantes. Après avoir étranglé en P63 ou, éventuellement, en P66 lorsque l'IMU était sous tension, le moteur DPS oscillait rapidement entre la poussée minimale et la poussée maximale. Sans aucun doute, la commande de vol associerait logiquement le comportement de l'accélérateur aux alarmes 1202, qui avaient des causes complètement indépendantes.

Un accident serait inévitable. À mon humble avis, si l'auteur avait encodé la valeur «correcte» dans le programme de commande des gaz, Apollo 11 ne se serait jamais assis. J'invite quelqu'un qui n'a aucun intérêt personnel et qui connaît bien les mathématiques à revérifier cette théorie.


Atterrissage manuel sur la lune

* * *


Nous avons ajusté le retard des gaz et la simulation a montré que l'instabilité de la position des gaz avait disparu. Des modifications ont été apportées au logiciel de mission Apollo 13, mais cette mission n'a pas atterri sur la lune.

Il est curieux qu'un changement dans le logiciel Apollo 13 ait été effectué avant que le problème de l'accélérateur ne soit connu, pourrait fournir une option de sauvegarde si l'automatisation du contrôle de l'accélérateur ne fonctionnait pas. Un nouveau «nom 92» a été défini, que l'équipage a pu choisir pour voir le niveau des gaz produit par le système de contrôle. La logique qui arrêterait le contrôle automatique si l'accélérateur devait passer en mode MANUEL a été supprimée. Ces changements [23] permettent à l'astronaute de contrôler l'accélérateur pendant les phases P63 et P64, tandis que le système de contrôle continue de contrôler le mouvement du navire. Je ne sais pas si ces procédures complexes ont déjà été utilisées.

Les alarmes de surcharge des cadres ont été résolues à plusieurs reprises.

Le commutateur radar de proximité était en position LGC pendant le décollage. Dans les missions suivantes, la liste de contrôle a été modifiée. Nous avons ajouté une logique au LUMINARY pour vérifier le mode de fonctionnement du radar de proximité, et s'il ne s'agissait pas de LGC, les compteurs de radar de proximité ont été remis à zéro.

Alan Clump a étudié l'exécutif sous un angle différent. Il a constaté que lorsque le TLOSS d'un ordinateur se produit périodiquement, ou que le niveau d'activité de l'ordinateur change en présence de TLOSS, et que la tâche SERVICER n'était pas terminée, et qu'elle était interrompue lorsque les commandes de calcul de position étaient exécutées pour les envoyer au pilote automatique, elle n'était pas effacée par le redémarrage du logiciel afin de à restaurer ultérieurement - dans ces conditions, il y avait une possibilité de calcul de position incorrect pour le pilote automatique. Pour le vol d'Apollo 13, Klump a développé une solution dans laquelle tous les travaux SERVICER ont été réinitialisés pour rattraper si nécessaire.



Phases d'atterrissage sur la lune

Mais à l'avenir, aucun de ces changements ne nous a libérés des limites d'une période fixe de deux secondes du système d'orientation. Pour atterrir sur un terrain difficile, il a fallu ajouter un modèle de terrain au programme radar. Les modifications du système d'orientation ont été laissées pour plus tard. Nous n'avions pas le temps pour tout.

Nous avons développé un concept que nous avons appelé «variable SERVICER», dans lequel la période du programme d'orientation pourrait être prolongée si nécessaire. La crainte que l'intervalle de deux secondes soit intégré au logiciel se révèle être sans fondement. Il était seulement nécessaire de mesurer la période de fonctionnement du système d'orientation et d'utiliser cette valeur au lieu de la valeur de deux secondes, qui n'est utilisée que dans quelques formules. Nous avons implémenté la version de travail de SERVICER dans la version hors ligne de LUMINARY, et démontré sa très haute résistance à TLOSS [25].

L'absence de la limite de deux secondes a permis d'envisager d'autres idées. L'astronaute John Young a proposé une amélioration, que nous avons appelée P66 LPD. Mais à ce moment-là, le P66 était un programme beaucoup plus flexible que dans le vol Apollo d'Armstrong. L'une des nouvelles fonctionnalités était que si l'équipe passait le mode ATT HOLD en AUTO, le système d'orientation entraînerait une vitesse horizontale nulle. L'idée de Young était que le LGC affiche l'angle LPD (comme dans la phase visible), ce qui montrerait au commandant le point sur lequel le module lunaire vole si, à ce moment, le pilote automatique passe en AUTO [26].

Pour assurer la précision dans l'exécution de cette fonction, le logiciel a dû réagir instantanément lorsque l'astronaute est passé en AUTO, plus rapidement que deux secondes et même plus rapidement que la deuxième période autorisée, avec laquelle certaines parties de P66 ont fonctionné. Nous avons développé une version dans laquelle la tâche a été lancée tous les quarts de seconde, vérifié le changement de mode du pilote automatique, envoyé des commandes d'orientation et d'accélérateur, et répondu aussi rapidement et précisément que possible à l'entrée du commutateur ROD. Dans une simulation habitée exécutée sur le simulateur de module lunaire (LM Mission Simulator, LMS) à Cap Canaveral, avec ses fabuleux modèles de terrain visibles dans les fenêtres, nous avons montré que ce système facilite un atterrissage très précis.

Ni la «variable SERVICER» ni le LPD P66 n'ont jamais été corrigés. La NASA a décidé qu'Apollo 17 serait le dernier. Avec si peu de missions restantes, le conseil d'administration a pris une décision prudente - il ne devrait pas y avoir de changements importants au logiciel d'atterrissage. En synchronisant les données reçues du radar d'atterrissage avec la lecture des accéléromètres, Robert Covelli a libéré suffisamment de temps pour y presser le modèle de terrain pour Apollos 15, 16 et 17.



Module inertiel (IMU) au laboratoire MIT

Apollo 14 a apporté la renommée à court terme de l'auteur. L'interrupteur d'interruption du tableau de bord a envoyé un signal périodique qui a empêché Alan Shepard et Ed Mitchell de s'asseoir. J'ai écrit du code qui surveille ces cas. Cette «béquille» a simplement changé plusieurs registres, le premier pour faire croire au moniteur d'interruption de mission que l'interruption s'était déjà produite, puis se supprimer pour que l'atterrissage puisse se poursuivre sans conséquences. Le patch a été diffusé par voie hertzienne et mis en œuvre par les astronautes sans faute, cette procédure a inclus 61 frappes sur DSKY. La partie la plus intéressante de l'incident d'Apollo 14 était peut-être le nombre de versions différentes de cette histoire. Mais Apollo 14 est une autre histoire.

En décembre 1972, je suis allé à Cap Canaveral pour lancer le navire Apollo 17. Ce vol spatial était génial. L'écrivain Tom Wolfe, avec la photographe Annie Leibovitz, a écrit une courte histoire en quatre parties pour le magazine Rolling Stone, qui a été le précurseur de «The Right Stuff» [27]. C'était le seul lancement nocturne d'Apollo. Le ciel brumeux de la Floride brûle d'orange d'un horizon à l'autre lorsque l'énorme Saturne V s'élève vers le haut sur une colonne de flammes d'un quart de mile qui se balançait à la fin comme une flamme de chalumeau.

J'ai passé plusieurs jours à tester certaines des fonctions LMS que nous avons appelées «programmation de mémoire effaçable». Il s'agissait de correctifs qui étaient censés utiliser des VAC inutilisés et corriger certains bogues, héritage de l'incident avec Apollo 14. Ensuite, je me suis envolé pour Cambridge pour observer l'atterrissage.

Après cela, j'ai apprécié écouter Gene Cernan et Jack Schmitt, un géologue de formation, explorer la Lune dans un rover lunaire, après avoir parcouru plus de 5 km hors de vue du vaisseau spatial. Et c'était la dernière fois que quelqu'un marchait sur la lune.



Fig. 13: Certains des participants.

Superbe photo, au premier rang: Vince Megna, «Doc» Charles Stark Draper, auteur, Dave Moore, Tony Cook; rangée arrière: Phil Felleman, Larry Berman, Allan Klumpp, Bob Werner, Robert Lones, Sam Drake. Petite photo, au premier rang: Larry Berman, Peter Volante, l'auteur; rangée arrière: Sam Drake, Bruce McCoy. Ont également participé aux événements Steve Copps, Romilly Gilbert, Ken Goodwin et Russ Larson.

Les références
[1] Klumpp, AR; «Apollo Lunar Descent Guidance»; Laboratoire Charles Stark Draper du MIT, R-695; Juin 1971.
[2] Cerise, GW; «E-Guidance - A General Explicit, Optimizing Guidance Law for Rocket-Propelled Spacecraft»; Laboratoire d'instrumentation du MIT, R-456; Août 1964.
[3] Brooks, Courtney G. et al; "Chariots for Apollo, A History of Manned Lunar Spacecraft"; NASA 1979.
[4] Argent, George; communication privée; 2004.
[5] Hall, Eldon C.; Voyage vers la lune: l'histoire de l'ordinateur de guidage Apollo; AIAA, 1996.
[6] Blair-Smith, Hugh; «Instructions pour le bloc II»; Laboratoire d'instrumentation du MIT, AGC4 Memo 9; 1 juillet 1966.
[7] Muntz, Charles A.; «Guide de l'utilisateur de l'interpréteur AGC / LGC Block II»; Laboratoire d'instrumentation du MIT, R-489; Avril 1965.
[8] Données de liaison descendante d'Apollo 11.
[9] Débriefing de l'équipage technique d'Apollo 11; NASA, 31 juillet 1969 [Débriefing].
[10] Transcription technique de la voix air-sol d'Apollo 11; NASA, juillet 1969 [Voix].
[11] Voix.
[12] Débriefing.
[13] Rapport de mission d'Apollo 11; NASA, SP-238.
[14] Débriefing.
[15] Débriefing.
[16] Voix.
[17] Klumpp, A.; mémo sans titre concernant le tracé en temps réel pour surveiller l'activité de l'ordinateur; MIT Charles Stark Draper Laboratory, 9 avril 1970.
[18] Klumpp, A. et Kalan, G.; «Élimination du bruit et amélioration de la stabilité et de la réponse dynamique du programme de vitesse de descente Apollo LM»; MIT Charles Stark Draper Laboratory, E-2543, octobre 1970 [Bruit].
[19] Bruit.
[20] Klumpp, Allan; communication privée; 1985.
[21] Bruit.
[22] Sorensen, JA; «Analyse de stabilité linéaire des équations de guidage du taux de descente LM»; Bellcomm Inc., B70 06074, 25 juin 1970.
[23] Tindall, HW et Garman, Jack; «Supprimer la vérification de l'accélération automatique discrète»; LUMINARY 1C Program Change Request (PCR) 285, 30 septembre 1969.
[24] Eyles, D.; "Empêcher les ECDU RR de voler les cycles de mémoire LGC"; LUMINARY 1B PCR 848, 23 juillet 1969.
[25] Eyles, Don; "Description du service variable"; MIT Charles Stark Draper Laboratory, Luminary Memo 139, 3 mars 1970.
[26] Eyles, Don; «Apollo LM Guidance and Pilot-Assistance Pendant the Final Stage of Lunar Descent»; Laboratoire Charles Stark Draper du MIT, E-2581; Mai 1971.
[27] Wolfe, Tom; Remords post-orbitaux Pierre à rouler; 4 janvier 1973.

Source: https://habr.com/ru/post/fr471332/


All Articles