Schiaparelli s'est crashé et n'est plus qu'une trainée noire à la surface de Mars. Alors que l'enquête officielle suit son cours, les premiers éléments indiquent que le module a été dupé par des informations erronées. Il pensait être posé au sol alors qu'il était encore à 3,7 km d'altitude.
Le 19 octobre, l'Agence spatiale européenne (ESA) retenait son souffle. La mission ExoMars arrivait à proximité de la planète rouge et réalisait deux délicates manœuvres : placer en orbite la sonde TGO et poser Schiaparelli sur Mars. La première s'est déroulée sans problème, mais pas la seconde. Le module s'est en effet crashé sur la surface de la planète, probablement à plus de 300 km/h. Via un communiqué de presse, l'ESA a donné de plus amples informations sur le déroulement des opérations.
Une saturation des données plus longue que prévu...
Pour rappel, Schiaparelli dispose de trois dispositifs de freinage qui s'enclenchent successivement lors de la descente : un bouclier thermique pour son entrée dans l'atmosphère (cette première phase permet de réduire sa vitesse de 21 000 km/h à 1 700 km/h environ), un parachute (qui permet de descendre à 320 km/h) et enfin neuf moteurs pour ralentir la chute et poser en douceur le module sur Mars (la vitesse prévue au moment de l'impact est de 10 km/h), du moins en théorie.
La première phase s'est déroulée normalement : « L’altimètre radar fonctionnait correctement et les mesures étaient prises en compte par le système de guidage, de navigation et de contrôle » confirme l'ESA. Problème, juste après le déploiement du parachute, l'Inertial Measurement Unit (IMU) – qui mesure la vitesse de rotation – est arrivé à « saturation ». Si ce comportement avait été anticipé, cet événement a duré « plus longtemps que prévu » : une seconde environ, selon l'agence spatiale.
... et Schiaparelli pensait être arrivée, alors qu'il était encore à 3,7 km
Envoyées au système de navigation, « ces informations erronées ont généré une altitude estimée négative - c'est-à-dire au-dessous du niveau du sol ». L'ordinateur de bord a alors estimé alors qu'il s'était bien posé sur la planète rouge. Conformément au plan, il a alors décidé de détacher son parachute, de se séparer de carénage et d'actionner très brièvement les fusées. Problème, il n'était pas du tout là où il pensait être : « en réalité, le véhicule était encore à une altitude d'environ 3,7 km » explique l'ESA...
L'agence ajoute que ce comportement en réponse aux fausses informations récupérées par l'ordinateur de bord a été « clairement reproduit dans des simulations informatiques ». Reste maintenant à connaitre les raisons du bug dans la récupération des données de l'IMU.
Dans tous les cas, il s'agit d'une « conclusion très préliminaire de nos enquêtes techniques » indique David Parker, directeur des vols habités et de l'exploration robotique de l'ESA. Il faudra maintenant attendre l'année prochaine afin d'avoir de plus amples informations avec les conclusions définitives.
Quid d'ExoMars 2020 ?
Ce crash de Schiaparelli n'a normalement pas d'incidence sur la mission ExoMars 2020, même si l'agence spatiale explique que l'expérience Schiaparelli (les données recueillies et le crash) « contribuera directement à la deuxième mission ExoMars ».
Tous les voyants ne sont pour autant pas au vert et, comme le rapporte l'AFP, le directeur David Parker demande aux responsables une rallonge budgétaire « d'un peu plus de 400 millions d'euros pour le projet, pour tous les travaux techniques nécessaires pour amener le véhicule jusqu'à la phase de lancement ». Pour rappel, le coût total est actuellement estimé à 1,5 milliard d'euros.
Commentaires (132)
" />
Envoyées au système de navigation, « ces informations erronées ont généré une altitude estimée négative - c’est-à-dire au-dessous du niveau du sol ».
OMG on dirait un bug de type ‘Kraken’ sur KSP
On dirait surtout une redite du bug du premier lancement d’Ariane 5 en 1996 : un dépassement de capacité avait fait croire à la fusée que soudainement elle fonçait vers le sol, l’obligeant ainsi à braquer à fond et dépassant du coup la résistance de sa structure entrainant son auto-destruction.
Y a bien de GPS qui amènent les gens dans un lac ou dans un ravin.
" />
S’ils arrêtaient de foutre des processeurs de 200Mhz dans leur missions aussi
" />
Du coup la sonde a fait une coyote sur la surface de Mars.
Et encore c’est beaucoup. Habituellement c’est plutôt 60MHz ce qui est déjà pas mal !
ce comportement en réponse aux fausses informations récupérées par l’ordinateur de bord a été « clairement reproduit dans des simulations informatiques »
C’est con, ça veut dire que ça aurait pu être anticipé.
Edit : p*tain de quotes :o
J’ai du mal à comprendre comment ils ont pu ne pas voir ce comportement en simulation…
Le problème n’est pas vraiment le comportement, mais plutôt la mesure erronée.
Voilà ce qu’il se passe quand on fait des referendum
" />
je veux bien croire que c’est priorité à la compacité et à la limitation de poids, mais des bêtes altimètres par mesure de pression atmosphérique, télémétrie laser, etc. dont la mesure serait utilisée pour corréler ou mitiger les décisions, ça pourrait sauver des M€ :)
Effectivement, ce n’est pas clair, on peut se demander si c’est le capteur qui était en défaut, ou son interprétation.
Mais avec d’autres sources que NXi on peut voir que les constructeurs pensaient “que le mouvement de nutation ne dépasserait pas 150°/s alors qu’il était de 180°/s”. Ça ressemble quand même à une limite artificielle et/ou de conception, plutôt qu’à une limite physique d’un capteur.
En conséquence, lorsque les mouvements de la sonde ont dépassé les valeurs maximales prévues l’un des capteurs de la centrale inertielle est resté bloqué sur cette valeur.
mouais. Des télémètres qui résistent à l’échauffement dû à la rentrer dans l’atmosphère à 21 000 km/h, après 1 an de voyage dans l’espace, cela n’est pas courant.
Les calculs avaient estimé une rotation max se 120°/s et les capteurs (imu) ont une valeur max de 180°/s
La capsule a tourné beaucoup plus vite que dans les calculs, saturant l’imu pendant 1s et faussant le calcul d’altitude et enchaînant ce qui est arrivé
Ya un article assez bien détaillé sur s&a
Je suis pas sûr que se passer de cette mesure soit une option possible.
Si tu dois t’arrêter avant un mur, c’est compliqué si on ne te dis pas la distance avant ce mur…
Des altimètres sur Terre, cela a besoin d’être recalibré très fréquemment pour tenir compte de la température et de la pression à un instant T.
Là, il faudrait d’abord envoyer une station météo sur Mars afin qu’elle communique ces informations à la sonde afin que celle-ci puisse étalonner son altimètre.
A entendre (enfin à lire) certain, on dirait que vous vous croyez plus fort que des mecs qui ont des doctorats et je ne sais quelle années d’expériences.
" />
Euh il était pas au courant qu’il n’avait pas encore utilisé ses moteurs et donc pas atterri?
" />
C’est comme si je sortait de ma voiture parce que mon GPS me dit que je suis arrivé à destination alors que c’est pas le cas et que je n’ai même pas démarré. Bon je me moque mais j’imagine que la conception de ce genre de truc est atrocement complexe.
En langage programmeur : buffer under/overflow.
Alors ok y avait un capteur défectueux (shit happens) , mais le fait d’avoir une écriture sur la variable d’à côté prouve que ce genre de machines démontre l’archaïsme des systèmes.
Même en c++ il y a maintenant des gardes fous pour ce genre de comportement, bien sur il y a un poil de consommation supplémentaire mais cela tend de plus en plus à être négligeable (et c’était utilisé sur du 66mhz avec du real time : la nintendo DS). Alors soit ça a été catché et non traité soit ca n’a pas été catché du tout et le système considère qu’après une seconde d’altitude foireuse c’est que l’information est vraie.
En tout cas la raison surprend encore et quelque chose me dis qu’on est pas loin du “code spaghetti”.
Pfff… Avec Howard Wolowitz ça ne serait jamais arrivé…
" />
“Ça passait sur KSP”
" />
Celui qui plante le rover dans un fossé ? Non merci, il aurait carrément oublier d’activer le parachute.
Et Après ça on veut encore nous faire croire que quand des bombes sont envoyées sur un batiment en Syrie, il n’y a pas de dommages collatéraux…
Si on arrive deja pas a faire atterir un truc sur mars sans avoir une marge d’erreur de 3.6KM alors que c’est la porte a coté , je vois pas comment c’est possible d’être précis en Syrie qui se trouve a des milliers de km d’ici!
Ou les ingénieurs qui codent avec des Miles au lieu de Km… C’est à tout les coups un british le responsable :p
Sauf que bon, le point d’arrivé était à +XX mètres, son altitude avant problème était de +3700 mètres, le calcul avec le capteur donnait -XXX mètres.
Même au bout d’une seconde tu ne considère pas que le calcul est valide, il y aurait du avoir une estimation fait sur la “dernière position valide” et non sur “position certifiée fausse”.
Tout programmeur qui fait de l’i/o sait qu’un capteur peut décider de faire de la merde en barre d’un moment à l’autre (pas besoin d’être dans l’espace pour ça) et les procédures d’urgences doivent être déclenchées à ce moment là (exemple si un capteur de vitesse dans une fabrique agro alimentaire se met à te dire qu’un tapis se déplace à -XX cms/secondes alors qu’avant il était à +XX cms/seconde tu te dis qu’il y a un problème et tu ne fais pas accélérer le tapis au bout d’une seconde en considérant que la vitesse est “normale”)
La classe ici… Dans l’autre article on avait des experts en politique, maintenant des experts de la NASA..
La prochaine fois que je dois embaucher, je viens ici ;)
Car dans un atterrissage comme celui-ci, vous ne pouvez pas vous fier uniquement aux données de l’altimètre radar. Puisque la sonde est animée de secousses, l’altimètre n’est en effet pas tout le temps pointé exactement vers le sol. “Il faut donc apporter un coefficient de correction basé sur les données enregistrées par la centrale inertielle” poursuit M.Blancquaert. “Et en appliquant ce coefficient de correction erroné, l’ordinateur de bord a calculé que Schiaparelli était à une altitude négative de -2 kilomètres…”
-2km, et aucun test pour ce dire “ok la sonde est carrément à l’envers, attendons un peu avant de prendre une décision”
Oui je sais bien. Je faisais une remarque sur le fait que ne pas avoir utilisé les moteurs aurait du automatiquement impliquer pour le logiciel embarqué de réaliser que peu importe sa position il était impossible qu’il ait atterri. Et donc cette constatation aurait pu entraîner une rerere vérification de sa position. Après si le module est dans l’incapacité de déterminer cette information dans tous les cas il est cuit, c’est pas depuis la Terre qu’on va faire la mesure et effectivement pas vraiment le temps de patcher/relancer quoi que ce soit.
Et comme je l’ai précisé je me moque mais je sais bien qu’il ne s’agit pas d’un problème trivial à résoudre. Ça n’empêche pas d’en rire…
La sonde avait un radar altimètre Doppler, source :https://fr.wikipedia.org/wiki/Schiaparelli_%28engin_spatial%29#Caract.C3.A9risti…
S’ils avaient demandé conseil à un parachutiste, ils auraient juste ajouté un capteur dans les pieds pour informer le cerveau qu’ils n’ont pas touché le sol …
" /> Encore une bourde à X milliards de neurones
Z’avez vu un parachutiste lacher son parachute quand il a pas senti le sol avec ses pieds vous ?
Ah, non je suis si fort que je saute les yeux fermés : selon mes calculs je viens d’atterir alors j’ai plus besoin de ce bidule qui me fait pendre comme un coin.
Pareil, ça veut dire qu’a aucun moment ils n’ont simulé la saturation de ce capteur sur plus d’un seconde…
Honteux.
Ta logique est complètement erronée, puisque c’est l’inverse.
La syrie est à des milliers de Km.
Mars est à genre 80 millions de Km. Sans compter que la sonde, elle fait pas le voyage direct, elle a parcourue dans les 500 millions de Km pour atteindre Mars.
Calculs rapides complètement stupides :
ExoMars = 500 000 000 km
Erreur de 3,7 km
Paris - Damas = 3280 km
Erreur équivalente = 2,43 cm…
C’est comme cette sonde qui s’est vautrée en oribtant vers mars parce que dans le code y’a eu un mic mac entre les livres-force.s et les newton.secondes Et pourtant c’est testé, vérifié, bla bla bla…
" />
" />
C’est ballot
Moi une fois j’ai planté pendant des des heures tout un site, ça sortait un ERR 500 server internal error, à cause d’un emberlificotement de guillemets. Des plombes pour trouver. Oui je sais faut pas modifier le code direct en SSH d’un site en prod…
Je donne la source pour ceux qui pensent qu’on n’y connait rien :
https://fr.wikipedia.org/wiki/Mars_Climate_Orbiter
Capteur inertiel qui sature = navigation dans les choux.
C’est simple, suffit d’un seul point de mesure inertiel qui sature et c’est terminé l’orientation et la position vu par l’ordinateur de bord est erroné.
L’altimètre donne seulement l’altitude mais pas l’orientation de l’engin. À partir de la comment mettre l’engin dans la bonne orientation pour activer les rétro fusée ?
C’est impossible.
Ce n’est pas un question d’informatique mais d’automatique. Fallait bien dimensionner les capteurs et c’est tout.
Il n’y a qu’un chef de projet ou un commercial pour croire qu’on peut coder sans bugs (et faire un enfant en 3 mois avec 3 femmes, comme dit une citation dont j’ai perdu la source).
Si j’ai bien compris les explications officielle, un instrument est entré en saturation pendant une seconde et a injecté des mauvaises valeurs au programme gérant la descente de Schiaparelli…
" />
Ce que je ne comprend pas c’est qu’en en déduisant une altitude négative, le programme a mis en œuvre une série d’actions ayant mené à la perte de atterrisseur ! C’est clairement un défaut de conception du logiciel, qui aurait du conclure à un résultat aberrant et se caler provisoirement sur une altitude estimée (durée de descente par ex) et attendre de nouvelles valeurs pour confirmation.
Parce que de deux chose l’une, soit la valeur négative de l’altitude est fiable et on est crashé, soit on est pas crashé (puisque le programme continue) et on ne peut pas tenir compte de la mesure.
Bon, la critique est aisée, mais l’art est difficile…
Ben faudra mettre un pilote dans le prochain 
" />
Faut envoyer Cooper, même s’il est vieux maintenant…
Ben non, puisque justement ils t’expliquent que le comportement était attend mais sur beaucoup moins de temps…
Des fois je me demandes comment les gens font pour ne pas remarquer la pêche à la dynamite ><‘
Ce que j’ai compris, c’est que l’instrument a été saturé 1 seconde de plus que prévus, la saturation était prévu, mais pas aussi longtemps. 1s à 1 700 km/h c’est presque 500m, ce n’est pas négligeable.
Après, j’imagine que l’erreur est de partir sur l’assertion que l’instrument ne pouvait pas être saturé après cette période et de baser pratiquement tout le reste de la séquence d’atterrissage dessus.
Je pense que l’absence de vérification multiple est simplement une contrainte de simplicité. En effet, accumuler les tests pour passer à l’étape suivante, c’est augmenter aussi le risque d’erreur de test. On aurait par exemple pu imaginer que passer d’une étapes à l’autre nécessite de remplir des condition de délais minimal et forcé si dépassant le maximum, mais c’est risquer que ces délais soient faux, où qu’un système merde.
Ha ben dans l’immédiat, la majorité de la sonde est maintenant elle aussi sous le niveau de la surface martienne.
Éparpillée façon puzzle.
Mais on peut pas comprendre, c’est de l’art.
y aurait pas eu ce problème avec windows
mais non, il fallait utiliser linux
Là par exemple
C’était par rapport au commentaire cité que je disais ça.
Après, y a tellement de facteurs qui entrent en jeu (y compris la com’ entre les équipes de l’ESA, avec des supputations d’un côté ou de l’autre)…
Et puis ils sont bien moins rodés que la NASA et ont moins de budget…
Ça joue aussi.
Dans tous les cas il doit lâcher le parachute avant d’atterrir je pense, ça évite que le fameux parachute lui retombe dessus et l’empêche de bouger, transmettre, recharger ses batteries ou je ne sais quoi. D’ailleurs dans l’article il est dit que le parachute permet de descendre à 320km/h, surement à cause de la faible atmosphère, et à cette vitesse, parachute ou pas…
Ou comme Mars Express il y a quelques années qui c’était écrasée de la même manière .Le gars charger de programmer l attitude était américain il avait calculer en pieds sur un système métrique le péon.
Moi je la connaissais sous cette forme “ce qu’une femme fait en 9 mois, 9 femmes ne le font pas en un mois”.
Oui, bon, c’est un détail…
" />
Ce n’était pas du code mort, c’était la fonction d’alignement de la centrale. Elle tournait pendant 40s après l’allumage des moteurs, pour pouvoir reprendre le décompte très rapidement en cas de suspension de la séquence. Sur Ariane 5, l’allumage des EAP (une fois que c’est parti, c’est parti) rendait cette fonction inutile. Mais dans la série on ne change pas un système qui marche, il avait été jugé plus prudent de tout garder en l’état (autres temps, autres mœurs). Ironie du sort, c’est dans cette fonction d’alignement qu’une conversion flottant/entier a planté au bout de … 37s. C’est ballot.
Pour la redondance, c’était cohérent : le logiciel ne pouvant pas planter, il était inutile de faire mieux qu’une redondance matérielle, suffisante pour se prémunir d’une panne matérielle sur une des centrales. D’ailleurs, ce principe a été conservé sur la centrale utilisée à partir de 2002, une Quasar 3000 (un petit bijou à base de gyrolaser tri-axes) de chez Thales Avionics. Celle-là ne “tombera” pas en cas d’exception logicielle, la leçon a été retenue. J’ignore si elle est toujours en service (et j’aimerais bien le savoir).
L’agence ajoute que ce comportement en réponse aux fausses informations récupérées par l’ordinateur de bord a été « clairement reproduit dans des simulations informatiques ». Reste maintenant à connaitre les raisons du bug dans la récupération des données de l’IMU.
Je m’étonne qu’il n’aient pas réalisé ces simulations avant.
Ah oui c’est vrai qu’il est doté de rétrofusées … j’avais oublié.
Les erreurs grotesques, ça n’arrive pas qu’aux autres. J’en vois dans les jugements que je tape avec ma collègue, j’en fais en informatique, et j’en trouve dans mes écrits. Dernières du lot : un partage NFS que je crois inutilisable parce que je n’ai pas mis le bon chemin dans mon fstab…
Vous pensez toujours à tout ce qui est possible et imaginable comme merdes, vous ? si oui, dites-moi comment vous faites, je n’y suis jamais arrivé…
Qu’est-ce qui te fait dire qu’ils n’ont pas retenu la leçon ?
Ce souci d’unité ne s’est pas reproduit.
Il faut relativiser les choses en comprenant ces deux points :
Bref on voit que l’exploration de l’espace c’est quand même pas si simple, il y aura toujours des imprévus et des bugs.
j’adore tous ces commentaires “yAvaitKa” “sontTropCons” “saventPasProgrammer”.
Continuez les mecs: si ça peut vous convaincre au moins 30 secondes que vous êtes bien meilleurs que tous ces gens là réunis, c’est pas cher payé.
Je peux mépriser ton comm?
" />
Y’avait le Black Frday sur steam… espérons qu’ils ont tous acheté Kerbal Space Program, ça pourrait leur servir
" />
ce que je trouve incroyable (… juste une réflexion de curieux…) c’est qu’il y a + de 50 ans on arrivait à envoyer des fusees avec la puissance de calcul de l’un de nos smart phones actuels, et aujourd’hui on se retouve avec des systemes ultra-complexes utilisant les meilleurs technologies ce qui demande davantage de programmation donc plus de source de problème humain
peu etre qu’ une approche plus rustique faciliterai la chose (dit’ il assis devant son écran ^^)
Et il y a plus de 50 ans, ça merdait grave aussi de temps en temps
Aux US, il y a les astronautes morts grillés dans leur capsule Apollo avec atmosphère d’oxygène pur
En URSS, les photos satellites ont permis de savoir qu’une explosion de grosse fusée (le projet N1) a bien fait morfler la base (on n’a jamais su combien de victimes, mais ça a vraiment fait mal)
Rectification: L’explosion de la N1 durant des essais de remplissage, c’est environ en 1970, ça ne fait pas encore 50ans
On oublie un peu vite que les membres d’Apollo 11 ont eu très chaud aux fesses et que ça aurait été un échec si ce programme avait été entièrement robotisé.
Tu as la spec sous les yeux pour affirmer que c’est le cas?
Je veux dire, sur le principe, tu as raison, mais derrière, il faut parfois faire d’autres choix de conception pour prendre en compte d’autres éléments auxquels on a pas forcement pensé. En l’état actuel des choses, on ne peut rien déduire dans ce fil de commentaires.
Étant donnée que la sonde n’a apriori pas la capacité de se diriger ou d’évaluer sa position géographique sur Mars, je vois mal l’intérêt/nécessité de se prendre le choux avec l’altitude relative à Mars plutôt que la distance sol-sonde.
En fait je ne vois que deux cas dans lequel on pourrait s’embêter à le faire ici:
Tout le monde a l’air perturbé par le fait que la valeur de distance avec le sol soit subitement passé de 3,7km a -2km, entrainant le déclenchement de la séquence d’atterrissage, et effectivement si tout s’est passé ainsi on peut se poser des questions sur les vérifications / exclusions de mauvaises valeurs.
Mais personnellement je ne comprend pas le communiqué de l’ESA de cette manière, même si j’avoue qu’il n’est pas très clair …
Il me semble avoir lu que cette saturation du capteur a entrainé une accumulation d’erreur qui a fini par atteindre -2km, mais il ne me semble pas qu’il est dit que la séquence d’atterrissage a débuté une fois cette valeur de -2km atteinte. Pour moi ça s’est déroulé ainsi :
-On se trouve aux environs de 3.7km, le parachute vient d’être déployé et sa bouge bien plus que prévu et pendant bien trop longtemps.
-L’erreur commence à s’accumuler et fait croire à la sonde qu’elle tombe un peu plus vite que prévu.
-Elle atteint le stade critique de 1.1km dans ses calculs (alors qu’en réalité elle ne tombe pas si vite) et elle déclenche donc ses rétros fusées.
-L’erreur continu de s’accumuler et quelques secondes plus tard les calculs annoncent moins de 2 mètres, les retro fusées sont donc coupés et on attend que le choc soit amorti.
-En réalité la sonde n’a pas atterrit et l’erreur continu de s’accumuler, pour moi les -2km c’est la dernière valeur envoyé par l’atterrisseur avant perte de signal, mais il était déjà en chute libre depuis bien longtemps a ce moment la et il était de toute façon trop tard pour la moindre correction.
Ça reste une interprétation, mais elle me semble plus logique, elle entraine le même crash mais elle est bien plus compliqué à interpréter et donc à éviter.
On aime faire rêver les esprits qui croient sans croire mais le tout virer hélas souvent au cauchemar…
OK, merci de m’avoir expliqué. Généralement, j’arrive à deviner quand un mot saute, mais là je n’y arrivais pas.
J’en profite pour dire que je ne suis pas d’accord pour dire dès maintenant que le crash est un problème informatique. Autre possibilité: Les informaticients ont peut-être parfaitement modélisé ce que les ingénieurs de mécanique du vol et autres domaines leur ont dit, et qui s’est avéré faux. Et il y a tous les intermédiaires possibles, le tout en tenant compte effectivement d’un budget limité, et d’un temps limité aussi: Décaler la sortie d’un logiciel est plus délicat quand il doit être dans la mémoire de la sonde au jour du lancement qui ne pas être décalé pour cause de fenêtre de lancement.
c’est donc un “overflow” (dépassement de valeur), on ne dira jamais assez aux débutants de se méfier…
Je reste sur ma théorie du sniper envoyé en avance pour descendre la sonde avant qu’elle n’atterisse. Elle est presque aussi crédible et surtout beaucoup plus sexy.
TL;DR
" />
Si j’ai bien compris ils avaient estimé que les capteurs pèteraient les plombs à l’approche de la surface, disons pendant 5 secondes, mais que la faute à pas de bol ce «brouillard» a duré 6 secondes ?