Back to main menu


LE BIZARRE PROGRAMME DE GUIDAGE DU MODULE LUNAIRE










Cette partie traite d'un document du MIT sur Apollo, "APOLLO GUIDANCE, NAVIGATION AND CONTROL".
Lien vers ce documentt
J'ai trouvé ce document dans le Virtual AGC Home Page de la NASA.
Il montre que le programme de guidage du module lunaire contient de nombreuses aberrations, et toutes ces aberrations sont intentionnelles.









Les schémas électroniques qui sont montrés dans ce document m'apparaissent dénués de sens.
Leurs anomalies ne sont pas aisées à expliquer, mais j'en ai sélectionné quelques unes pour lesquelles je pense que l'explication est compréhensible.









Ceci est le Schéma de l'IMU turn on mode.
Il y a des choses étranges sur ce schéma.









Les extrémités de bobines que j'ai cerclées ne sont connectées à rien.
Et l'entrée COS du bloc 1X n'est connectée à rien.









Ceci est le bloc diagramme fonctionnel de l'électronique de l'antenne micro ondes.









Le bloc que j'ai entouré de vert est un modulateur de phase.
Un modulateur de phase module en phase un signal de haute fréquence avec un signal variable.
Le signal variable vient de la gauche du bloc.
Il y a trois signaux arrivant sur la gauche du bloc DRIVER (entouré d'orange); ils ont tous une fréquence fixe spécifiée.
le bloc DRIVER combine ces trois signaux pour en faire un signal commun qui mélange les trois fréquences fixes, et ce signal devrait rentrer dans le bloc PHASE MODULATOR pour être modulé en phase par le signal variable entrant.
Mais, au lieu d'un signal unique sortant du bloc DRIVER, il y a trois signaux qui en sortent, et qui rentrent dans le bloc PHASE MODULATOR.









Ceci est ce que nous aurions dû voir sur ce schéma corrigé; Un signal unique sortant du bloc DRIVER, combinant les trois signaux de fréquence fixe, et qui doit être modulé par le signal variable entrant sur la gauche.









Ceci est le bloc diagramme fonctionnel du Self Test Assembly.









Il y a trois signaux de fréquence fixe, que j'ai cerclés de bleu, qui rentrent dans le bloc "PHASE SHIFTED", que j'ai entouré d'orange.
Le signal que j'ai surligné en rouge, et qui sort de ce bloc, est donc aussi nécessairement un signal de fréquence fixe.
Ce signal rentre dans un bloc "PHASE MOD", qui est un modulateur de phase qui module en phase le signal de haute fréquence qui est produit par le bloc "XTAL OSC" (qui est un oscillateur cristal), que j'ai entouré de vert, avec le signal entrant sur la droite, le signal sortant du bloc "PHASE SHIFTED", qui, comme expliqué, a une fréquence fixe.
Mais cela n'a pas de sens de moduler le signal de haute fréquence avec un signal de fréquence fixe; le signal haute fréquence est toujours modulé par un signal variable.









Ceci est le bloc diagramme du processeur central.









C'est le bloc memory buffer qui a le bit de parité, et qui devrait le donner au bloc parity logic de sorte qu'il puisse le vérifier.
La flèche du bit de parité devrait donc aller du bloc memory buffer vers le bloc parity logic, et être orientée comme la flèche que j'ai représentée en rouge.
Et c'est le bloc parity logic qui vérifie la parité et donne le résultat au bloc memory buffer, et donc le parity check devrait être orienté depuis le bloc parity logic vers le bloc memory buffer, et être orienté comme la flèche que j'ai représentée en orange.
Nous avons donc sur ce schéma deux flèches qui sont orientées dans la mauvaise direction.









Ceci est le diagramme logique du Caution and Warning Indicator.









L'indicateur "NO ATTITUDE" est connecté à "Coarse alignment" (alignement grossier).
Quel est le rapport entre cet indicateur et "Coarse alignment" qui n'a rien à voir avec l'attitude du module lunaire?









Nous allons maintenant voir les diagrammes fonctionnels de l'AGC.









Il y a deux manières de faire le rendez-vous; normalement le véhicule actif est celui qui gère le rendez-vous; il vole en dessous du véhicule passif (parce qu'il doit voler plus vite que le véhicule passif pour pouvoir le rattraper), le dépasse, et arrive sur l'orbite du véhicule passif un peu devant celui-ci, et s'y arrime.
Normalement c'est le module lunaire qui est le véhicule actif, car il part de la surface lunaire alors que le module de commande orbite la lune.









Mais, dans certains cas, cela peut être le module de commande qui est le véhicule actif; dans ce cas, le module lunaire va sur une orbite au-dessus de celle du module de commande, et c'est le module de commande qui gère le rendez-vous, et il le fait de la même manière que le fait le module lunaire quand il est le véhicule actif.









Le document dit que le module lunaire met à jour son propre vecteur d'état quand il est le véhicule actif, et gère le rendez-vous.
Mais, quand c'est le module de commande qui est le véhicule actif, le document dit que le programme du module lunaire met à jour le vecteur d'état du module de commande à la place...









...Et envoie le vecteur d'état du module de commande mis à jour au module de commande sur la liaison de communication de la voix de sorte que le module de commande puisse l'utiliser pour gérer le rendez-vous.
Mais c'est absurde pour deux raisons.









La première absurdité est que c'est au module de commande de mettre à jour son propre vecteur d'état quand il est le véhicule actif, et gére le rendez-vous, car il a aussi son propre système de guidage, et n'a pas besoin du module lunaire pour le faire à sa place.









La seconde absurdité est que le module lunaire ne devrait pas envoyer le vecteur d'état mis à jour au module de commande sur la liaison de communication de la voix (que j'ai colorée en rouge sur ce schéma de GRUMMAN), mais sur la liaison de communication des données (que j'ai colorée en vert sur le schéma), qui est adaptée pour ce faire, contrairement à la liaison de communication de la voix.









Dans ce test du programme 20, le programme demande à l'astronaute s'il veut attendre que la distance au module de commande soit moins de 400 milles nautiques; un mille nautique fait 1,852 kilomètre; 400 milles nautiques font donc 740 kilomètres.
Mais le module de commande orbite à 110 kilomètres au-dessus de la surface lunaire, et le module de commande et le module lunaire orbitent la lune dans la même direction.
Bien sûr le module de commande n'est pas exactement à la verticale du module lunaire, mais même en dépit de cela, la distance entre le module lunaire et le module de commande ne pourrait pas représenter autant; par exemple, si le module lunaire voyait le module de commande sous un angle de 45°, ce qui est plus que la réalité, la distance entre les deux ne serait que de 156 kilomètres, bien moins que la distance correspondant à 400 milles nautiques.
Ce test n'a donc aucun sens, la distance entre les deux vaisseaux spatiaux sera toujours nettement inférieure à 400 milles nautiques.









La partie de l'organigramme que j'ai entourée est exécutée si le bit TRACK FLAG n'est pas positionné; mais ce bit est positionné au début du programme et n'est remis à zéro nulle part dans le programme; cette partie ne devrait donc jamais logiquement être exécutée, et apparaît donc inutile.









Et la boucle d'attente que j'ai entourée sera exécutée, car elle est dans la branche qui est exécutée quand TRACK FLAG n'est pas positionné.
Elle attend aussi longtemps que TRACK FLAG n'est pas positionné.
Mais cette boucle d'attente est inutile, car il n'y a rien pour positionner TRACK FLAG dans cette boucle.









Le verbe 73 permet de fournir un incrément octal à l'horloge du LGC.
Mais un incrément octal ne signifie rien, car l'incrément se fait bit à bit.









Le verbe 70 fournit un incrément octal à la fois pour l'horloge du LGC et le TEPHEM.
Mais comment peut-on incrémenter le TEPHEM sans incrémenter l'horloge du LGC en même temps?









Une mise à jour du LGC permet de fournir une capacité de chargement pour un bloc séquentiel d'emplacements dans la mémoire dynamique.
Mais il est possible de lire ou écrire dans n'importe quel emplacement de la mémoire dynamique à tout moment sans avoir à rendre la lecture ou écriture possible.









Dans le programme 25, les drapeaux P25 et TRACK sont initialement positionnés.
Les branches "YES" (OUI) seront donc exécutées dans le test de ces deux drapeaux.









Et ensuite le programme donne le choix à l'astronaute de terminer le programme ou non.
S'il choisit de ne pas terminer le programme, la boucle complète est exécutée à nouveau avec les drapeaux P25 et TRACK toujours positionnés.
Cela signifie que le programme n'a pas de porte de sortie automatique; l'astronaute peut le bloquer indéfiniment s'il le veut...ou s'il omet de répondre à la question.
N'est-ce pas un peu dangereux?









Dans le test qui est entouré de rouge (dans le programme 27), une variable "INDEX" est testée, et il n'y a de sortie du programme que si cette variable est en dehors d'une plage donnée.
Le problème est que cette variable n'est définie nulle part, sauf dans une branche qui n'est éxécutée qu'en sortie du programme, mais pas avant le test de INDEX.
Donc, au moment où la variable "INDEX" est testée, elle n'a pas de valeur définie, elle peut avoir toute valeur aléatoire, ce qui signifie que ce test n'a pas de sens.









Dans le feuillet 2 du programme 27, il y a une adresse de stockage qui est calculée pour chaque donnée chargée.
Mais, si une donnée est déjà mémorisée quelque part en mémoire, pourquoi la stocker aussi ailleurs en mémoire, et ne pas directement l'utiliser là où elle est mémorisée?
Et, si les adresses stockées sont consécutives, le calcul de chaque adresse n'est pas bien compliqué.









L'astronaute a la possibilité de terminer la mise à jour avant le transfert de toutes les données.
Mais pourquoi ferait-il cela?
Et, s'il termine avant le transfert de toutes les données, il n'a pas la possibilité de les corriger.









L'astronaute peut aussi terminer la mise à jour après que toutes les données aient été transférées, mais, dans cette branche, il a la possibilité de mettre à jour n'importe laquelle des données transférées, contrairement au cas où il terminerait la mise à jour avant le transfert de toutes les données.
La conclusion est que l'astronaute ne devrait pas se voir proposer l'option de terminer la mise à jour avant le transfert de toutes les données.
La première option de terminaison ne devrait pas exister.









Dans cette partie de l'organigramme (dans P30), le drapeau UPDATE est remis à zéro avant un traitement, et remis à 1 immédiatement après; mais pourquoi faire ceci puisque ce traitement n'utilise pas le drapeau UPDATE? C'est complètement inutile.









Cette partie de l'organigramme du programme 32 est plutôt tordue.
Il y a un traitement qui est appelé depuis le feuillet 2 à travers le point 2 (cerclé de rouge); lorsque le feuillet 2 appelle cette partie du feuillet 1, le drapeau TERMINATE est déjà positionné.
Après le traitement, qui remet à zéro le drapeau UPDATE, dans le cas où il n'y a pas d'alarme (ce qui est le cas normal), la branche gauche est exécutée, dans laquelle le drapeau UPDATE n'est pas positionné parce que le drapeau TERMINATE est couramment positionné, et le feuillet 2 est à nouveau appelé; cette fois le feuillet 2 provoque une sortie de programme parce que le drapeau TERMINATE est positionné...avec le drapeau UPDATE couramment à zéro!









Le document dit (traduit):
"Il (le programme du RCS) calcule et affiche aussi les angles des gyroscopes qui résulteraient de l'orientation présente de l'IMU si le véhicule est maneuvré vers l'attitude préférée du module lunaire pour faire la poussée."
Je vais expliquer pourquoi cela n'a pas de sens.
Les angles de l'IMU ne sont pas directement les angles de l'attitude du module lunaire.









De manière à utiliser l'IMU, il doit d'abord être initialisé, de manière à initialiser les angles mesurés.
Comme nous sommes dans un système tridimensionnel, l'initialisation est faite en pointant un réticule vers trois différentes étoiles.









Dans le cas où le vaisseau spatial est près d'une planète (dans ce cas la lune), la troisième étoile peut être remplacée par la gravité locale qui donne la direction du centre de la planète.









Après l'initialisation des angles mesurés, ils sont constamment mis à jour par l'IMU qui envoie au guidage non des angles, mais des variations d'angle qui permettent au guidage de mettre à jour les angles mesurés.









Quand le programme du RCS veut donner au module lunaire une attitude définie, il commande les réacteurs latéraux jusqu'à ce que les angles mesurés (mis à jour à partir des données de l'IMU) concordent avec les angles désirés.









Ce ne sont donc pas les angles de l'IMU qui devraient être affichés sur l'AGC, lesquels ne sont pas significatifs (et dont d'ailleurs l'AGC n'a pas la connaissance), mais les angles mesurés qui sont mis à jour à partir des variations d'angle envoyées par l'IMU.









Dans le programme 70, une variable TG est testée (elle est aussi testée en d'autres endroits), mais elle n'est définie nulle part dans aucun programme.
Bien sûr, elle pourrait être explicitement définie par l'astronaute, mais, dans ce cas, il devrait y avoir un noun permettant à l'astronaute de la rentrer.









Le noun 68 contient un paramètre qui correspond à cette variable TG.
(il y a aussi le noun 61, mais ce noun n'est jamais appelé).









Dans le programme, ce noun est seulement utilisé avec le verbe 06.









Mais le verbe 06 n'est pas un verbe pour rentrer des données, mais un verbe pour afficher des informations.
Cela signifie que la variable n'est jamais définie par l'astronaute non plus.









Nous avons donc ici une variable TG qui n'est définie nulle part dans tout le programme de guidage, et qui n'est pas spécifiée par l'astronaute non plus, et qui contient donc une valeur aléatoire inconnue, et qui est pourtant testée comme si elle contenait une valeur bien définie.









Dans ce test (du programme 70), H DOT signifie vitesse verticale (telle que définie par la NASA elle-même).
Ce test dit donc que, si la vitesse verticale est plus grande qu'une certaine valeur (40 pieds par seconde), alors le drapeau de rotation est remis à zéro.
Mais quel rapport y a-t-il entre une vitesse verticale et une rotation?









Et maintenant, la cerise sur le gâteau, le gag le plus savoureux du programme de guidage.
Le test montré peut exécuter deux possibilités différentes, l'une d'elle mettant une donnée MGA à -00002, et une autre qui met cette donnée à -00001.
Ce genre de test est répété à plusieurs endroits du programme de guidage, comme si les ingénieurs voulaient porter notre attention dessus...et vous allez comprendre pourquoi.









En fait MGA est un angle de gyroscope que j'ai cerclé sur ce schéma.









Cet angle est spécifié en centièmes de degré, ce qui signifie qu'une branche du test le met à -0,02°, et l'autre le met à -0,01°.
Il y a 0,01° de différence entre ces deux angles.
Cela signifie que le programme de guidage devrait être capable de définir cet angle avec une précision de 0,01° au moins.









La circuiterie de l'IMU reçoit des commandes analogiques.
Le programme de guidage utilise une représentation digitale, et de manière à envoyer une variation d'angle à l'IMU, il utilise un convertisseur digital vers analogique.









Mais le bit de poids le plus faible de ce convertisseur correspond à une variation d'angle de 0,044°.
Cela signifie que le programme de guidage peut changer les angles de l'IMU, et cela inclut l'angle MGA, avec une précision qui n'est pas meilleure que 0,044°.









Donc, alors que le programme de guidage devrait pouvoir définir l'angle MGA avec une précision d'au moins 0,01° pour exécuter correctement les deux branches du test, il ne peut en fait même pas le définir avec une précision de 0,04°!









Voyez vous l'ironie?









Le document n'est donc qu'une accumulation d'aberrations, et ces aberrations ne peuvent être qu'intentionnelles.









Ces aberrations sont donc autant d'indices que les ingénieurs nous donnent pour nous faire comprendre que l'AGC n'a jamais aidé un module lunaire à se poser sur la lune.









Ce qui est drôle est, que dans tous les programmes, l'astronaute est sollicité pour fournir des informations:
- Le programme lui demande s'il veut sortir du programme ou non.
- Le programme lui demande s'il veut sortir d'une boucle ou non.
- Le programme lui demande s'il veut mettre à jour des données.









Donc l'astronaute qui avait la charge de taper les commandes sur le clavier de l'ordinateur aurait dû constamment interagir avec les programmes de l'AGC dans la descente motorisée.









Mais, si on interrogeait Buzz Aldrin sur toutes les interactions qu'il devait logiquement faire avec l'AGC pendant la descente motorisée, il dirait:
"Mais qu'est-ce que vous racontez? je regardais simplement l'ordinateur faire son travail!".









Définitivement, Apollo n'est qu'un conte de fée pour des adultes qui ont oublié de grandir.

Site hosted by Angelfire.com: Build your free website today!