le code de guidage de la capsule Apollo a été publié en Open Source

http://www.01net.com/telecharger/windows/Loisirs/astronomie_et_espace/fiches/100929.html

gratuitement
A l'occasion du 40ème anniversaire de la mission Apollo 11 et du premier pas sur la Lune, le code de guidage de la capsule a été publié en Open Source. Les développeurs ont numérisé les images du code exposé au musée du MIT afin de créer cet émulateur open source de l'AGC d'Apollo 11. Sans être vraiment un simulateur de vol, il donne une bonne idée de ce dont disposait à l'époque les astronautes pour se diriger avec leur capsule. Et par la publication en Open Source, ce code pourra être intégré dans de futurs vrais simulateur de vol. Cet émulateur vous permet aussi de voir les lignes de code utilisées à l'époque accompagné par les commentaires de l'époque des développeurs.

Version :
1.0

Taille :
21.46 Mo

Configuration minimale :
Windows 9x/2000/XP/Vista

Licence :
Logiciel libre

Date de sortie :
21/07/2009

Langue :
Francais et Anglais

http://www.01net.com/telecharger/windows/Loisirs/astronomie_et_espace/fiches/100929.html

Merci pour le lien

J'ai de tres sérieux doutes la ! c'est un projet qui a pris naissance en 2003 !!!

http://www.ibiblio.org/apollo/index.html

j'ai connu ce site quand je faisai des recherhce sur l'addon nassp pour orbiter.... c'est pas du tout nouveau !

Peut-être y'a-t-il confusion avec le projet de reconstruction du hardware Block I ( http://agcreplica.outel.org/ ) ? Le problème, c'est que le code source de Colossus 249 qui est diffusé ainsi est pour la génération Block II. On a donc, d'un côté un hardware sans software et de l'autre un software ne tournant que sur un émulateur.

C'est bien d'avoir un émulateur mais c'est encore mieux d'avoir un clavier et un affichage qui ressemblent au vrai. :bounce1:

Si quelqu'un connaît, un projet équivalent (hardware !) ayant abouti pour la génération Block II, je suis intéressé (j'en connais un en cours mais il n'a pas [encore] abouti).

Konstantin

P.S.: Le block I devait voler sur Apollo 1 8-) et 2 (limité au tir du lanceur AS-203 sans CSM et avant l'AS-202 dont le CSM était en retard) donc n'est pas la version des Apollo 7 à 17 qui sont réellement partis vers la lune ainsi que sur les missions dérivés Skylab et Apollo -Soyouz.

J'ai un liens qui pointe directement sur le code :
http://code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM_BODY_ATTITUDE.s?spec=svn156&r=156

Apparemment c'est le contrôle d'attitude du module de commande (CM_BODY_ATTITUDE) :eeks:

Etant moi même informaticien, je suis tout chose de lire ça !

Vous pouvez remonter dans l'arborescence pour trouver d'autres fichiers. Par contre, d'après les commentaires d'en-têtes des fichiers, ce n'est qu'une publication partielle du code de l'ordinateur de guidage du module de commande :)

It is part of the source code for the Command Module's (CM) Apollo Guidance Computer (AGC), Apollo 11.

Commander Ham a écrit:J'ai un liens qui pointe directement sur le code :
http://code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM_BODY_ATTITUDE.s?spec=svn156&r=156

Apparemment c'est le contrôle d'attitude du module de commande (CM_BODY_ATTITUDE) :eeks:

Etant moi même informaticien, je suis tout chose de lire ça !

Vous pouvez remonter dans l'arborescence pour trouver d'autres fichiers. Par contre, d'après les commentaires d'en-têtes des fichiers, ce n'est qu'une publication partielle du code de l'ordinateur de guidage du module de commande :)

It is part of the source code for the Command Module's (CM) Apollo Guidance Computer (AGC), Apollo 11.

L'ensemble apparaît au premier abord bien structuré et pourrait donner lieu sans difficulté à un peu de rétro-ingénierie (Luminaris 131 n'occupe que 43 pages de 4Ko chacune car l'AGC semble n'addressait que 4Ko de RAM=2Kmots de 16bits). Je serais curieux de connaître ses métriques Logiscope pour avoir un vague idée de la complexité: il ne semble pas y avoir plus de 3 niveaux hiérarchiques, ce qui est sain.

Cela dit, la légende qui dit que l'AGC avait moins de mémoire qu'une calculette est fausse: il disposait en 1969 de plus de mémoire vive que les premiers micro-ordinateurs disponibles bien plus tard sur le marché (la première version du PET de Commodore ne disposait que de 4ko de mémoire vive) et une ROM somme toute confortable de 64Ko (pas moins que le satellite SPOT1 mis en orbite bien longtemps après le programme Apollo !). Donc qu'on cesse de nous rebattre les oreilles en prétendant que les robots sont plus sophistiqués que ce qui est fait sur les vols habités, c'est exactement le contraire comme le démontre le cas d'Apollo et pourraient le démontrer d'autres cas plus proches de nous.

Konstantin

P.S.: On mesure l'effort que devait représenter le développement de ce logiciel quand on sait qu'à l'époque, il n'avait pas de linker et que tout a donc du être assemblé par inclusion pour former les 1742 pages de code de l'ensemble.

Petite précision pour les erreurs de l'ordinateur d'Apollo 11 (1202 et 1201)
Elles ont été causées par une procédure écrite et testée avec succès en simulation sur Terre : le switch du radar a été basculé sur la position AUTO pour qu'en cas de procédure d'annulation d'alunissage, le radar de rendez-vous (avec le CSM) soit déjà fonctionnel.

Le radar de rendez-vous et l'interface avec l'ordinateur de bord utilisent tous les deux des alimentations alternatives différentes. Sur Terre ils avaient des alimentations issues d'une même source (le secteur) et donc en phase. Là haut, il s'est avéré que ces alimentations n'avaient pas les mêmes sources (batteries) et donc étaient déphasées. Cela à créé un défaut de synchronisation de l'interface qui a envoyé une flopée d'alternances de 0 et 1 à l'ordinateur. Et là, je dirais que le soft était bien blindé puisqu'il a su interpréter cette arrivée de données incohérentes et à produit une erreur sur l'écran de l'ordinateur (DSKY).

Sur Terre, un informaticien lors du développement de l'ordinateur d'Apollo, avait pris soin de créer une liste d'erreurs qu'il a nommé "cheat sheet" , ce qui a permis au Capcom de confirmer le "Go for landing".

fredB a écrit:Petite précision pour les erreurs de l'ordinateur d'Apollo 11 (1202 et 1201)
Elles ont été causées par une procédure écrite et testée avec succès en simulation sur Terre : le switch du radar a été basculé sur la position AUTO pour qu'en cas de procédure d'annulation d'alunissage, le radar de rendez-vous (avec le CSM) soit déjà fonctionnel.

Le radar de rendez-vous et l'interface avec l'ordinateur de bord utilisent tous les deux des alimentations alternatives différentes. Sur Terre ils avaient des alimentations issues d'une même source (le secteur) et donc en phase. Là haut, il s'est avéré que ces alimentations n'avaient pas les mêmes sources (batteries) et donc étaient déphasées. Cela à créé un défaut de synchronisation de l'interface qui a envoyé une flopée d'alternances de 0 et 1 à l'ordinateur. Et là, je dirais que le soft était bien blindé puisqu'il a su interpréter cette arrivée de données incohérentes et à produit une erreur sur l'écran de l'ordinateur (DSKY).

Sur Terre, un informaticien lors du développement de l'ordinateur d'Apollo, avait pris soin de créer une liste d'erreurs qu'il a nommé "cheat sheet" , ce qui a permis au Capcom de confirmer le "Go for landing".

D'où provient ta source fredb?? Cela m'intéresse...

fredB a écrit:Petite précision pour les erreurs de l'ordinateur d'Apollo 11 (1202 et 1201)
Elles ont été causées par une procédure écrite et testée avec succès en simulation sur Terre : le switch du radar a été basculé sur la position AUTO pour qu'en cas de procédure d'annulation d'alunissage, le radar de rendez-vous (avec le CSM) soit déjà fonctionnel.

Le radar de rendez-vous et l'interface avec l'ordinateur de bord utilisent tous les deux des alimentations alternatives différentes. Sur Terre ils avaient des alimentations issues d'une même source (le secteur) et donc en phase. Là haut, il s'est avéré que ces alimentations n'avaient pas les mêmes sources (batteries) et donc étaient déphasées. Cela à créé un défaut de synchronisation de l'interface qui a envoyé une flopée d'alternances de 0 et 1 à l'ordinateur. Et là, je dirais que le soft était bien blindé puisqu'il a su interpréter cette arrivée de données incohérentes et à produit une erreur sur l'écran de l'ordinateur (DSKY).

Sur Terre, un informaticien lors du développement de l'ordinateur d'Apollo, avait pris soin de créer une liste d'erreurs qu'il a nommé "cheat sheet" , ce qui a permis au Capcom de confirmer le "Go for landing".

Qu'est-ce qu'ils ont modifié donc entre Apollo 11/12 et les suivants ? Le fait de corriger la désynchronisation en question aurait eu un impact sur le "logiciel déjà blindé" (qui au demeurant ne semble plus contenir dans ces sources de référence à la "cheat sheet" => un utilitaire du site permet de rechercher dans tout le source par mot-clé) ou bien était-ce ce bout de code qui a justement été supprimé ?

Je m'étonne par contre que les tests au sol aient été faits à partir de l'alimentation secteur (n'est-ce pas plutôt le simulateur d'entrainement qui était alimenté par le secteur ?), ce n'est pas du tout représentatif (comment ont bien pu être validé les convertisseurs batterie-alternatif ? Au niveau équipement ? Si c'est le cas, c'est encore un syndrôme A501 qui a frappé...) et il aurait pu le détecter avant, non ?

Konstantin
P.S.: le LGC est alimenté en AC 800Hz, c'est pas tout à fait ce qu'on trouve sur le secteur.

Heureusement qu'aujourd'hui on ne programme plus en assembleur.
Je crois savoir que l'ARD a été aussi réalisé avec le code d'Apollo qui était déja en open source.

Bon cela dit l'utilité de rendre public ce code est nul, vu qu'aujourd'hui n'importe quel programmeur pro utilise un langage plus intuituf et souple comme le C++ ou autre variante. C'est le compilateur qui faitle travers de conversion en asembleur.

Mustard a écrit:Heureusement qu'aujourd'hui on ne programme plus en assembleur.
Je crois savoir que l'ARD a été aussi réalisé avec le code d'Apollo qui était déja en open source.

Bon cela dit l'utilité de rendre public ce code est nul, vu qu'aujourd'hui n'importe quel programmeur pro utilise un langage plus intuituf et souple comme le C++ ou autre variante. C'est le compilateur qui faitle travers de conversion en asembleur.

Il me semble bizarre que le logiciel de guidage de l'ARD ai été conçu à partir de celui d'Apollo, avec autant d'année d'écart et la volonté de construire l'industrie européenne ? :suspect:

Et je ne suis pas du tout d'accord avec toi, je trouve que ça a un côté sentimental pour quelqu'un comme moi de voir ce code source. Personne n'en a besoin pour faire voler quoi que ce soit, mais c'est intéressant avec une valeure historique.

Commander Ham a écrit:
Et je ne suis pas du tout d'accord avec toi, je trouve que ça a un côté sentimental pour quelqu'un comme moi de voir ce code source. Personne n'en a besoin pour faire voler quoi que ce soit, mais c'est intéressant avec une valeure historique.

Oui c'est interessant du point de vue élément historique, c'est tout. Mais un code ça reste quelque chose d'assez abstrait.

Commander Ham a écrit:

Mustard a écrit:Heureusement qu'aujourd'hui on ne programme plus en assembleur.
Je crois savoir que l'ARD a été aussi réalisé avec le code d'Apollo qui était déja en open source.

Bon cela dit l'utilité de rendre public ce code est nul, vu qu'aujourd'hui n'importe quel programmeur pro utilise un langage plus intuituf et souple comme le C++ ou autre variante. C'est le compilateur qui faitle travers de conversion en asembleur.

Il me semble bizarre que le logiciel de guidage de l'ARD ai été conçu à partir de celui d'Apollo, avec autant d'année d'écart et la volonté de construire l'industrie européenne ? :suspect:

Et je ne suis pas du tout d'accord avec toi, je trouve que ça a un côté sentimental pour quelqu'un comme moi de voir ce code source. Personne n'en a besoin pour faire voler quoi que ce soit, mais c'est intéressant avec une valeure historique.

Valeur historique indéniable (je n'irai pas jusqu'à dire "sentimental" car comme l'écrit Mustard, cela reste quand même assez abstrait contrairement à un bon vieux DSKY qui parle à chacun n'entre nous car on l'aperçoit sur toutes les photos des postes de pilotage d'Apollo) mais sans faire de l'archéologie informatique, on peut se demander ce qu'apporte un langage plus intuitif par rapport à un code aussi "propre" que celui-ci. Il introduit au contraire une couche d'abstraction supplémentaire qui éloigne les concepteurs des mécanismes de bas niveau où se loge parfois les problèmes. Ce qui fait qu'aujourd'hui, lorsqu'un compilateur a un bug et s'il n'est pas utilisé par des milliers de programmeurs (comme c'est le cas fort heureusement de la plupart des compilateurs C vers les cibles les plus courantes) et bien il peut arriver de tourner en rond pendant un moment avant de détecter le bug. Transposer ça à un langage moins répandu mais encore utilisé dans le domaine (e.g. Ada) et sur des cibles exotiques (les contraintes environnementales du spatial ne permettent que rarement de pouvoir s'appuyer sur du matériel disponible chez Surcouf => le seul exemple sur l'ISS sont les Laptops... et encore débarrassés des matériaux interdits sur une station !) et on comprend mieux pourquoi il faut souvent des années avant de débugger correctement des programmes remplissant de plus en plus de fonctions complexes autrefois dévolues au segment sol (le prix de l'autonomie !).

Pour l'ARD, il faut bien lire "à partir de" (la cible n'était pas la même, fort heureusement) et la raison: petit moyen (je ne serais pas étonné que le facteur d'échelle entre les équipes de l'AGS et celle de l'ARD soit de 100 pour 1) et gain de temps de développement (10 ans, ça paraît court pour Apollo mais l'ARD n'a pas duré autant).

Konstantin
P.S.: Si on ne programme plus en assembleur aujourd'hui, ce n'est pas à cauise du logiciel lui même mais plutôt des mécanismes des processeurs devenus trop complexes pour tout un chacun puisse les maitriser. Seuls les concepteurs de compilateurs et de noyau d'OS continuent à avoir la visibilité sur ce niveau et encore avec beaucoup d'outils fournis par les constrcuteurs du matériel et qui leur simplifient la tâche.

Un programme en assembleur est très difficile à lir eou comprendre. Alors qu'un programme en C++ un bon programmeur arrive à le lire et comprendre ce qu'il fait. C'est plus facile de trouver un bug dans un code C++ que dans un assembleur.

Bon autreois la place mémoire était très limité donc l'assembleur était primordial. Il prenait moins de place et il était limité en taille. C'était généralement du 8 bits donc beaucoup plus simple aussi. Faire de l'assembleur en 32 ou 64 bits c'est déja plus complexe.
Aujourd'hui plus aucun industriel ne programme en assembleur, ingérable, trop complexe et forcément sujet à de nombreuses erreurs.

Aujourd'hui les programmes, beaucoup plus complexe par la taille sont testé dans toutes les sens. Et meme s'il peut existé encore des buts la miniaturisation et lesprogrès font qu'on multiplie les sécurité. Par exemple j'avais lu une fois que sur les airbus, les calculateurs de bords étaient triplés. chacun étant fait avec un logiciel différent et une équipe différente pour éviter qu'un bug qui serait passé à travers ne se retrouve sur un autre.
A l'époque d'apollo, cela était impensable. Il n'y avait qu'un calculateur, qu'un langage. Cela a suffit pour saturer le calculateur d'Eagle lors d'apollo11.

Les compilateurs sont aujourd'hui très stable, meme si aucun programme n'est débuggé à 100% mais ça reste relativement stable pour les programmes de l'aéronautique et de l'espace, qui sont testé dans tous les sens.

Mustard a écrit:Un programme en assembleur est très difficile à lir eou comprendre. Alors qu'un programme en C++ un bon programmeur arrive à le lire et comprendre ce qu'il fait. C'est plus facile de trouver un bug dans un code C++ que dans un assembleur.

Bon autreois la place mémoire était très limité donc l'assembleur était primordial. Il prenait moins de place et il était limité en taille. C'était généralement du 8 bits donc beaucoup plus simple aussi. Faire de l'assembleur en 32 ou 64 bits c'est déja plus complexe.

...

Le facteur déterminant est aussi l'architecture (RISC, processeur pipeliné...) car alors la maitrise de l'exécution de chaque instruction est livrée au micro-code du processeur. Non, vive les langages de haut niveau mais dire que les compilateurs sont plus stables, ça n'est vrai que pour ce qui concerne les plus répandus. Pour les autres, on a toujours de mauvaises surprises qui obligent parfois à brider le pouvoir d'expression du source pour limiter le langage évolué à un sous-ensemble bien traduit par le compilateur. Tu cites souvent C++ qui est un bon langage (pas de gueguerre de religion entre softeux ici, tu devrais l'ajouter au réglement FCS ;) ) et très répandu de surcroit mais, encore une fois, une excursion vers des langages plus exotiques imposés par l'architecture de certains processeurs (OCCAM par exemple pour les transputeurs) t'inciterait à ajouter un bémol.

Pour les Airbus, c'est plutôt HS du fil mais ce que tu as retenu est proche de la réalité: les chaines fonctionnelles critiques sont toutes tripliquées mais aussi internement redondées (une partie commande et une partie monitoring + un mécanisme de type maître-esclave qui bascule sur la chaîne esclave lorsque le maître commence à déconner). Par contre, il n'y a pas trois types de calculateurs développés par des équipes différentes mais seulement deux (les "primaires" et les "secondaires"). On est loin néanmoins de la sophistication du STS avec ces 4 chaînes en redondance chaude (imposé au début du programme où les spécifications devaient permettre un retour sur Terre complètement automatique en cas d'incapacité de l'équipage => sur les Airbus, on prend l'hypothèse que si tout est planté, les pilotes se souviennent encore comment piloter un avion sans toutes les protections qu'on leur offre en nominal jouant ainsi un peu le rôle de la redondance froide) plus une cinquième en redondance froide ou même de l'ATV qui distingue, comme cela avait été pensé pour Hermès, des couches de criticités différentes (dont la plus critique fait quand même 30000 lignes de code !) => principe repris aussi sur l'A380 avec l'introduction de l'avionique modulaire sur réseau AFDX et la conservation des paramètres les plus critiques sur ARINC429 voire liens directes point-à-point.

Mais on est pas sur aéro-forum mais sur astro-forum ;)

Edit: Pardon, FCS !

Konstantin

Apolloman a écrit:

fredB a écrit:
Petite précision pour les erreurs de l'ordinateur d'Apollo 11 (1202 et 1201)
Elles ont été causées par une procédure écrite et testée avec succès en simulation sur Terre : le switch du radar a été basculé sur la position AUTO pour qu'en cas de procédure d'annulation d'alunissage, le radar de rendez-vous (avec le CSM) soit déjà fonctionnel.

Le radar de rendez-vous et l'interface avec l'ordinateur de bord utilisent tous les deux des alimentations alternatives différentes. Sur Terre ils avaient des alimentations issues d'une même source (le secteur) et donc en phase. Là haut, il s'est avéré que ces alimentations n'avaient pas les mêmes sources (batteries) et donc étaient déphasées. Cela à créé un défaut de synchronisation de l'interface qui a envoyé une flopée d'alternances de 0 et 1 à l'ordinateur. Et là, je dirais que le soft était bien blindé puisqu'il a su interpréter cette arrivée de données incohérentes et à produit une erreur sur l'écran de l'ordinateur (DSKY).

Sur Terre, un informaticien lors du développement de l'ordinateur d'Apollo, avait pris soin de créer une liste d'erreurs qu'il a nommé "cheat sheet" , ce qui a permis au Capcom de confirmer le "Go for landing".

D'où provient ta source fredb?? Cela m'intéresse...

Ma source est dans "Digital Apollo" de David A.Mindell pages 227 à 231.
On peut en lire aussi un peu en bas de la page 253 de "How Apollo flew to the Moon" de David Woods

fredB a écrit:

Apolloman a écrit:

D'où provient ta source fredb?? Cela m'intéresse...

Ma source est dans "Digital Apollo" de David A.Mindell pages 227 à 231.
On peut en lire aussi un peu en bas de la page 253 de "How Apollo flew to the Moon" de David Woods

Don Eyles (qui a travaillé aux Draper Labs de 1966 à 1998 et donc dans l'équipe du Luminaris => c'est le moustachu au milieu du premier rang sur la photo apparaissant à la fin de l'article) en donne une explication très détaillée là (voir en particulier la figure 17 et le texte associé): Apollo Alarms

et mentionne aussi pourquoi Luminaris a subi une révision majeure pour Apollo13 (jamais utilisée) car il y avait un problème latent beaucoup plus sérieux (PCR 285) que le traitement des alarmes 1201 et 1202 (PCR 848) et qui n'est pas mentionné dans le rapport de mission Apollo 11 aux pages 190 à 192 qui traite du problème des alarmes: Rapport de Mission Apollo 11

Hal Laning, concepteur de l'exécutif, (gérant jusqu'à 8 tâches en simultanée et implémentant du load shedding) est peut-être le softeux évoqué par Mindell dans son ouvrage ??

Apparemment, il y a encore plusieurs hypothèses qui circulent (d'ailleurs Eyles lui-même a changé d'avis plusieurs fois sur les causes du problème). Il y avait effectivement un oubli dans la spécification de l'interface électrique (c'est là l'erreur initiale qui a été détectée lors des tests au sol du LM-1 mais non corrigée) mais il n'est dit que le logiciel sauve la mise que pendant la phase P63 (grâce à l'algorithme très ingénieux de "load shedding" et non de "cheat sheet" qu'on trouve plutôt pour les jeux d'arcade...). Au contraire en phase P64, il est expliqué clairement vers la fin que les alarmes 1201 et 1202 ont provoqué à chaque fois le redémarrage de l'exécutif car la marge de la charge CPU était plus faible (10% au lieu de 15%) et les alarmes en consommaient 13% (à raison de 3 alarmes en 40 secondes). C'est uniquement grâce au fait que Neil est passé alors (aux alentours de 650ft d'altitude) en mode semi-manuel (ATT HOLD) pour éviter les rochers qu'ils ont pu continuer (c'est ce qui est expliqué le plus souvent concernant le scénario des alarmes 1201 et 1202) sinon le soft serait encore en train de boucler.

Plus tard dans la descente (430ft), il passe en mode d'entrée manuelle (P66) annulant la vitesse horizontale et maintenant un taux de descente constant.

D'ailleurs, bien que le soft ait été fait pour cela et testé au sol dans ces conditions, pas un seul des alunissages n'a eu lieu en full-automatique, tous les commandants ont repris la main à un moment en manuel pour finir la manœuvre.

Le Capcom n'a en fait donné le GO que parce que les télémétries étaient nominales et que rien n'indiquait à Houston que le LM déviait de sa trajectoire malgré les alarmes, ce n'est que bien plus tard (2004 !) que l'analyse a conduit à l'article d'Eyles ci-dessus.

Dans le source, on doit pouvoir retrouver les codes indiqués dans l'article mais il est tard et il faut que j'aille récupérer de cette semaine pleine d'émotions.

Konstantin :sage:

dans le premier chapitre de "Magnificent Desolation", Aldrin explique clairement que c'est la mise sur ON du radar de rendez-vous qui est responsable de la "surcharge" de l'ordinateur

il semble en assumer la responsabilité, puisqu'il explique (en substance) "je décide de maintenir le radar de rendez-vous sur ON afin d'être prêt dans la situation d'urgence éventuelle où nous devrions annuler l'alunnissage et repartir vers Columbia"

un peu plus loin, il reprend en disant "Neil et moi" avons décidé de ..... (p17)

Konstantin a écrit:(grâce au mécanisme très ingénieux de "load shedding" et non de "cheat sheet" qu'on trouve plutôt pour les jeux d'arcade...).

Tu parles de mécanisme... logiciel ?
Parce la "cheat sheet", c'est pas du code, c'est juste l'équivalent d'un post-it que le gars avait collé sur le bord de sa console :

Source : "Digital Apollo" de Mindell

On y lit effectivement que si rien n'est fait, il pouvait y avoir un blocage de DSKY :eeks: Neil est passé au P66 à temps...

fredB a écrit:
...
On y lit effectivement que si rien n'est fait, il pouvait y avoir un blocage de DSKY :eeks: Neil est passé au P66 à temps...

Plus un bouclage qu'un blocage mais c'est bien là l'avantage d'avoir un être humain à bord. La NASA a perdu assez de sondes martiennes pour enfin comprendre (on aimerait bien que d'autres plus proches de nous en prennent conscience) que rien ne remplace dans ces phases là le pouvoir de décision de l'être humain à bord (et non à des millions de kilomètres qui se rendent compte trop tard qu'ils auraient du intervenir). Comme en aviation, s'il est vrai que de nos jours, 80% des accidents ont pour partie pour origine une erreur humaine (100% si l'on tient compte que les machines sont conçues et fabriquées par des êtres humains), 100% de ceux qui ont été évité (on parle jamais des trains qui arrivent à l'heure), l'ont été grâce à l'intervention de l'homme.

Le "post-it" vient du bouquin de Mindell ?

En passant, j'ai noté dans le très bon article d'Eyles qu'il précise que la technologie utilisée par l'AGC n'était même pas mûre quand elle a été choisie au début des années 60, ce qui démontre à nouveau l'énorme différence avec les technologies utilisées sur les satellites ou les sondes qui sont l'état de l'art d'il y a 20 ans. Le cycle d'introduction dans la pratique est souvent dans cet ordre chronologique:

1) applications militaires
2) applications spatiales habitées
3) applications aéronautiques civiles
4) applications sur les sondes spatiales
5) applications sur les satellites de télécoms

Alors quand on a entendu il y a quelques années un Ministre de la recherche, pourtant scientifique respecté, affirmait que les missions robotiques faisaient plus avancer la technologie que les vols habités, c'est que réellement, il avait été très mal conseillé par son entourage: de toute façon quand ce genre de messages arrive à ce niveau de l'Etat, c'est plutôt le résultat d'un lobbying fort (en France, très lié au nucléaire où les robots sont rois) de personnes très intéressées pour récupérer des marchés que via des conseillers scientifiques ayant réellement une compétence technique leur permettant de prouver ce qu'ils affirment. :wall:

Dernier cas en date, l'avionique modulaire connue depuis près de 20 ans en aviation militaire est passée fin des années 1990 dans les applications spatiales habitées puis, avec l'A380 en aviation civile (et encore, pas son volet refroidissement liquide qui devra attendre le 787). On commence juste à en parler pour les autres applications (40 ans après, il y a des applications mises en orbite en 2009 qui ne fonctionnent pas mieux ni réellement différemment que l'AGC) mais il va falloir attendre 10 ans que la techno du début du siècle soit devenue obsolete pour qu'ils puissent l'utiliser. :megalol:

:bounce: Vive la conquête de l'Espace ! :bounce:

Konstantin

Konstantin a écrit:
Cela dit, la légende qui dit que l'AGC avait moins de mémoire qu'une calculette est fausse: il disposait en 1969 de plus de mémoire vive que les premiers micro-ordinateurs disponibles bien plus tard sur le marché (le PET de Commodore ne disposait que de 2ko de mémoire vive) et une ROM somme toute confortable de 64Ko ...

Quelques petites questions:
1) Es tu d’accord avec cette description donnée par Morice (Cf: le fil, Série sur la course à la Lune sur agoravox)

Pour relier toutes les fonctions et les analyser en temps réel, le LEM possède un ordinateur de bord : le même que celui du module de commande. Il dévore 70 watts et marche en 28 volts. La capacité totale de mémoire pour chacun est de ... 36K sur 14 bits. Oui, vous avez bien lu. Aucun méga, même pas la taille de la plus petite clé USB existante, loin de là. C’est la puissance d’un Commodore 64 de 1982... L’engin tournait à 2,048 Mhz (et calcule à 1 Mhz seulement) alors que le premier IBM PC de 1983 tournera à 4,77 Mhz déjà... et qu’aujourd’hui on est chez soi à 3 gigahertz. Sa mémoire est en tore de ferrites : elle offrait 12K pour le programme et 4K de mémoire-vive (RAM) utilisable : oui, vous avez bien lu : quatre kilo-octets de RAM (4K !), la plus petite barrette aujourd’hui étant d’1gigaoctet... Pas de disque dur, pas de lecteur de disquette, pour gérer toutes les commandes de l’appareil... le responsable de la merveille s’appelait Eldon Hall. Sans lui, c’eût été un fiasco que de tenter la Lune. Bref, les hommes sont allés sur la Lune avec une simple calculatrice, mais qui était à l’époque très en avance!

2) Le LK russe a-t-il aussi un ordinateur de bord similaire ?

Mustard a écrit:
...Effectivement il est impossible de savoir si l'age donné dans un profil est vrai. Là on doit s'en remettre à l'honnetteté des gens. Mais il est vrai que parfois il y a des doutes. J'estime de connaitre l'age d'une personne dans une discussion est important car à mon sens ça joue un role dans le ton qu'on peut utiliser.
Cela dit pour éviter que certains ne mettent n'importe quoi pour ne pas dévoiler leur age je viens de rendre l'age optionnel.

As tu testé le Commodore 64, vu ton âge réel, au moins dix ans inferieur au mien, d’après mes estimations, tu ne devrais pas le tester. Il a été ma première machine que je garde dans le grenier, comme pièce de collection, sans le moniteur puisque il peut marcher avec TV, le listing de l'alunissage en basic devrait être effacé de la casette et même du disque souple:
:D

Firnas2 a écrit:
...
Quelques petites questions:
1) Es tu d’accord avec cette description donnée par Morice (Cf: le fil, Série sur la course à la Lune sur agoravox)

Pour relier toutes les fonctions et les analyser en temps réel, le LEM possède un ordinateur de bord : le même que celui du module de commande. Il dévore 70 watts et marche en 28 volts. La capacité totale de mémoire pour chacun est de ... 36K sur 14 bits. Oui, vous avez bien lu. Aucun méga, même pas la taille de la plus petite clé USB existante, loin de là. C’est la puissance d’un Commodore 64 de 1982... L’engin tournait à 2,048 Mhz (et calcule à 1 Mhz seulement) alors que le premier IBM PC de 1983 tournera à 4,77 Mhz déjà... et qu’aujourd’hui on est chez soi à 3 gigahertz. Sa mémoire est en tore de ferrites : elle offrait 12K pour le programme et 4K de mémoire-vive (RAM) utilisable : oui, vous avez bien lu : quatre kilo-octets de RAM (4K !), la plus petite barrette aujourd’hui étant d’1gigaoctet... Pas de disque dur, pas de lecteur de disquette, pour gérer toutes les commandes de l’appareil... le responsable de la merveille s’appelait Eldon Hall. Sans lui, c’eût été un fiasco que de tenter la Lune. Bref, les hommes sont allés sur la Lune avec une simple calculatrice, mais qui était à l’époque très en avance!

Il y a quelques erreurs faciles à vérifier (l'info vient de "Journey to the Moon: The History of the Apollo Guidance Compurter"; AIAA, 1996 par Eldon Hall lui-même):

- l'AGC ne consommait probablement que 55W (28V AC 800Hz => la différence pourrait venir d'une confusion entre W et VA, il y a exactement un facteur racine(2) entre les deux => 28V sur 2,75A, ça fait pas 77W en alternatif) et avait un cycle mémoire de 11,7microsec donc la fréquence de l'executif est plutôt 85,47 Khz (1Mhz, c'est beaucoup trop rapide pour des mémoires à ferrites). Il fallait le double pour faire un simple addition soit 23,4 microsec. A moins qu'il ne soit question ci-dessus de l'horloge de base qui fonctionnait bien autour de 1Mhz (même 2MHz pour ce qui est du quartz) mais était divisée en multiples sous-horloges pour être distribuée sur les cartes ?

- le binaire du LUMINARIS disponible sur le net indique que le LGC fonctionnait en 16bits (certains mots approche les 65535) dont un bit de parité et non en 14bits

- il y a bien 4 Ko de RAM mais un peu plus de ROM car 36Kmots de 16bits, ça fait 72Ko: Eyles indique que compte-tenu qu'Apollo comprenait 2 AGC identiques sur LM et sur CM, l'ensemble de la mission a été réalisée avec 152 Ko de logiciel (en plus des AGCs, il y avait des calculateurs de secours conçus par TRW et qui comportait 6144 mots, les AGS), c'est beaucoup plus qu'une simple calculette (la TI-59 commercialisé 10 ans plus tard ne fonctionnait que sur 4 bits avec au maximum 16Ko et c'était le haut de gamme avec la HP-67, elle a tenu cette place encore longtemps au moins jusqu'en 1980 et la sortie de la HP-41) et très en avance sur les technologies spatiales des années qui suivirent:

Firnas2 a écrit:
...
2) Le LK russe a-t-il aussi un ordinateur de bord similaire ?

As tu testé le Commodore 64, vu ton âge réel, au moins dix ans inferieur au mien, d’après mes estimations, tu ne devrais pas le tester. Il a été ma première machine que je garde dans le grenier, comme pièce de collection, sans le moniteur puisque il peut marcher avec TV, le listing de l'alunissage en basic devrait être effacé de la casette et même du disque souple:[center]
...
:D

Personnellement, j'ai fait mes premières armes sur une calculette TI-59 puis j'ai eu la chance de programmer en MU-Basic et en Macro-Assembler sur PDP11 et le premier micro que j'ai jamais connu fut l'Olivetti P6060 qui parlait aussi Basic:



Ensuite, j'ai bricolé un peu sur le PET 2001 (une opération du ministère de l'Education Nationale en avait mis dans certaines écoles et je squattais de temps en temps celui du Palais de la Découverte):



Jamais eu de Commodore64 néanmoins, j'avais opté pour le ZX81 qui était moins cher mais que j'ai du revendre peu après pour m'acheter mon ATARI ST.

Je ne sais rien du LK dont les spécifications sont restées très longtemps secrètes (contrairement aux Draper Labs, les Russes n'ont jamais publié sur ses caractéristiques) mais, d'une manière générale, l'informatique des Russes était très en retard sur celles des Américains et il y a fort à parier que le LK n'était pas doté d'un calculateur numérique mais plutôt analogique. C'était d'ailleurs le cas du Concorde dont la conception remonte aussi aux années 60. Quant on lit que l'AGC était très en avance sur son temps, ce n'est pas faux puisqu'ailleurs dans le monde, on utilisait même pas encore les circuits intégrés (une série de 5600 portes NOR à 3 entrées pour ce qui est de l'AGC).

Mustard a écrit:
...Effectivement il est impossible de savoir si l'age donné dans un profil est vrai. Là on doit s'en remettre à l'honnetteté des gens. Mais il est vrai que parfois il y a des doutes. J'estime de connaitre l'age d'une personne dans une discussion est important car à mon sens ça joue un role dans le ton qu'on peut utiliser.
Cela dit pour éviter que certains ne mettent n'importe quoi pour ne pas dévoiler leur age je viens de rendre l'age optionnel.

Dans mon profil, cela ne semble pas optionnel sinon il y a longtemps que je l'aurais supprimé justement par honnêteté car celui qui s'affiche n'est ni l'âge de mon avatar (né en 1857), ni le mien (celui de mes artères). Mais surtout que cela ne joue aucun rôle dans le ton entre nous car on est ici entre passionnés. De toute façon, l'âge des artères n'a souvent rien à voir avec celui du cerveau: il y a des octogénaires qui ont su garder une âme de gamin et des trentenaires qui ont déjà abandonné leurs rêves d'enfant. J'ai déjà cité Cocteau sur FCS mais c'est aussi réellement ce que je ressens.

Konstantin :sage:

Wah ! merci pour toutes ces précisions sur l'AGC ! J'avoue que je n'en connaissais pas les détails.

Konstantin a écrit: Quant on lit que l'AGC était très en avance sur son temps, ce n'est pas faux puisqu'ailleurs dans le monde, on utilisait même pas encore les circuits intégrés (une série de 5600 portes NOR à 3 entrées pour ce qui est de l'AGC).

Donc le processeur de l’AGC est à base de transistors et non de circuits intégrés, ce qui n’empêche pas les russes d’avoir un ordinateur de bord similaire.
Je connais quelqu’un au forum qui ne va pas être d’accord avec toi, il me semble:

Astro-notes a écrit:Non, Non, et NAÔN
....
D'autre part aujourd'hui cet extraordinaire bobard du gap
informatique Russe devrait être à ranger aux oubliettes
comme le Hoax "du non vol Apollo sur la Lune".
Comment croyez vous que les physiciens Russe pouvaient
tenir une place d'excellence en physique nucléaire et en
contrôle de faisceaux de particules ? avec des bouliers ?
Ils disposaient des mêmes ordinateurs que les USA. Les
publications du CNRS à ce sujet sont claires.

Qu'est ce qu'ils disent, les publications du CNRS à ce sujet, I dont know?

Ps: Je pense qu'il vaut mieux afficher son âge réel, pour discuter des expériences vécues, comme celle avec le C2F et Albert Ducrocq. En suivant ton raisonnement, mon avatar est né en 247 av. J.-C. Donc je dois afficher Age:2256 ans.

Firnas2 a écrit:

Konstantin a écrit: Quant on lit que l'AGC était très en avance sur son temps, ce n'est pas faux puisqu'ailleurs dans le monde, on utilisait même pas encore les circuits intégrés (une série de 5600 portes NOR à 3 entrées pour ce qui est de l'AGC).

Donc le processeur de l’AGC est à base de transistors et non de circuits intégrés, ce qui n’empêche pas les russes d’avoir un ordinateur de bord similaire.

Tous les ordinateurs les plus courants y compris de nos jours sont à base de transistors. Tout dépend à quelle échelle on se situe...
Un circuit intégré, comme son nom l'indique commence dés qu'on INTEGRE plusieurs transistors dans un même chip. Un ampli-op est une circuit intégré, très basique mais intégré quand même.

Les photos des composants de l'AGC disponibles sur Internet montrent qu'il s'agissait bien de circuits intégrés:



C'est encore plus explicite là: http://klabs.org/history/ech/ic_packages/64-41.pdf

J'avoue que je n'ai aucune idée si les Russes maitrisaient déjà dans les années 60 la gravure sur substrat semi-conducteur. N'oublions pas que le transistor lui n'avait été inventé par l'équipe de Bell qu'à peine plus d'une décennie plus tôt (leur prix Nobel datait de 1956): soit à peu près le temps qu'il faut pour passer du labo au cycle industriel commercial (l'AGC lui est passé directement du labo à Apollo d'où un cycle plus court). Le 4004 qui ne contenait que 2300 transistors a été conçu en même temps que le programme Apollo qui n'a donc pu l'utiliser mais le design du STS commencé dans les années 70 utilisait déjà les micro-processeurs quand les autres projets spatiaux ailleurs dans le monde (les nôtres y compris => je partage quelque chose de très personnel avec la SEREB donc cela m'intéresse aussi) faisait tout juste le pas vers le numérique et on oubliait déjà des clés d'assemblage dans nos satellites...

Firnas2 a écrit:
Je connais quelqu’un au forum qui ne va pas être d’accord avec toi, il me semble:

Astro-notes a écrit:Non, Non, et NAÔN
....
D'autre part aujourd'hui cet extraordinaire bobard du gap
informatique Russe devrait être à ranger aux oubliettes
comme le Hoax "du non vol Apollo sur la Lune".
Comment croyez vous que les physiciens Russe pouvaient
tenir une place d'excellence en physique nucléaire et en
contrôle de faisceaux de particules ? avec des bouliers ?
Ils disposaient des mêmes ordinateurs que les USA. Les
publications du CNRS à ce sujet sont claires.

Qu'est ce qu'ils disent, les publications du CNRS à ce sujet, I dont know ?

Moi non plus, concernant le spatial, je ne fais confiance qu'aux publications de première main pas l'homme qui a vu l'homme qui a vu l'ours (je ne savais pas que TRW et le Draper Labs fabriquaient aussi les ordinateurs du programme spatial russe par exemple mais on en apprend tous les jours: comment ont-ils fait avec l'embargo strict sur les composants pendant la guerre froide ?). N'ayant pas accès à la langue de Tolstoi et ayant très peu travaillé avec les Russes, je connais bien moins bien que le spatial américain (je n'ai même jamais approché le LK contrairement à d'anciens collègues qui sont allés à Moscou ou Baikonour mais à voir l'intérêt évident que ceux-ci portaient à nos technologies quand on a commencé à travailler pour eux, je dirais, à première vue, qu'ils sortaient quand même d'une sorte de "disette" qui est aujourd'hui du passé). Cela dit, il y a de très grands spécialistes de l'un et de l'autre sur FCS et il est souvent possible d'obtenir des précisions sur tel ou tel point y compris de première main. Ducrocq avait beaucoup publié sur le spatial russe mais presque pas sur le spatial américain donc je m'en remets aussi à ses livres (pas de première main mais j'avais une confiance aveugle en ce qu'il écrivait car il vérifiait tout plusieurs fois avant de le publier) sur ces sujets que je connais peu. On ne peut pas être d'accord avec tout le monde. :sage:

Firnas2 a écrit:
Ps: Je pense qu'il vaut mieux afficher son âge réel, pour discuter des expériences vécues, comme celle avec le C2F et Albert Ducrocq. En suivant ton raisonnement, mon avatar est né en 247 av. J.-C. Donc je dois afficher Age:2256 ans.
...

Hélas, les âges sont limités à deux chiffres donc ça le fait pas. :wall:

Hors sujet mais pour compléter: On choisit son avatar comme on le souhaite. Personnellement, je suis né le même jour que mon avatar (tout le monde connait donc ma date de naissance mais pas l'année et encore...en lisant bien) donc j'ai pas vraiment eu le choix sinon j'aurais pu prendre Capt. Kirk ou Cmdt Koenig, c'est plus de mon époque. Comme le signale Mustard, il n'y a aucune règle obligeant à afficher son âge réel ni même sa localisation réelle mais chacun sait en lisant les messages des uns et des autres où il se trouve exactement et dans quelle fourchette d'âge il se trouve (peu m'importe de savoir si une dame a 38 ou 42 ans, c'est d'ailleurs dommage que les dames soient contraintes d'afficher leur âge car peut-être y'en aurait-il plus sur FCS ?

Firnas2 a écrit:... si j’ai bien compris tu veux connaître l’age du Professor Théodose, mais s’il est de sexe féminin, on ne peut pas lui
poser cette question et à ce moment là (et puisqu’il a l’air sympa) je lui proposerais d’utiliser la photo de Cléopâtre comme Avatar, c’est plus parlant.

). Je ne connais personne en Tunisie (et pourtant, j'ai des amis dans le monde entier mais pas au pays d'Hannibal) donc je pense pas que nous nous soyons croisé aux conférences du C²F mais vu que presque personne n'affiche là aussi son vrai visage, c'est difficile d'en être sûr (de nom, je connais Firnas-142 mais pas Firnas2 ). Par contre, il y a une règle de FCS que j'ai respecté en ce qui me concerne (c'est pas le cas de tout le monde et certains, y compris parmi les modérateurs, se sont même contenté d'un simple "Salut, me voilà !"), je me suis présenté sur "Présentation des membres" (je ne suis pas aussi célèbre que ceux qui écrivent "C'est moi, vous me reconnaissez ?" pour simplement écrire "Salut") et avant de savoir si on peut partager des choses très personnelles (donc pas sur le forum mais en mp) avec tel ou tel membre, c'est aussi très important de constater ou non si l'on a un vécu commun (j'en ai avec certains membres et ceux-là le savent déjà). De toute façon, appartenir à la communauté FCS fait que tous ceux qui sont ici font un bout de chemin ensemble maintenant. :lol!: