ExoMars  : Schiaparelli pensait avoir atterri alors qu'il était encore à 3,7 km  d'altitude

ExoMars : Schiaparelli pensait avoir atterri alors qu’il était encore à 3,7 km d’altitude

Ça fait beaucoup comme marge d'erreur

Avatar de l'auteur

Sébastien Gavois

Publié dansSciences et espace

28/11/2016
132
ExoMars  : Schiaparelli pensait avoir atterri alors qu'il était encore à 3,7 km  d'altitude

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.

SCHIAPARELLI

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.

132
Avatar de l'auteur

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

Vous cherchez le bastion ?

17:13 WebSécu 4
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

Tu me vois, tu ne me vois plus

16:45 IAWeb 2
IA Act

AI Act européen : un compromis de haute lutte, de rares interdictions

Un bon compromis, ça laisse tout le monde mécontent ?

16:35 DroitIA 0

Sommaire de l'article

Introduction

Une saturation des données plus longue que prévu...

... et Schiaparelli pensait être arrivée, alors qu'il était encore à 3,7 km

Quid d'ExoMars 2020 ? 

Guacamole sur un plateau

Guacamole sur un plateau (1/5) : on monte un bastion sécurisé

WebSécu 4
Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

Projet européen sur le cloud : OVHcloud s’est retirée au dernier moment et s’explique

IAWeb 2
IA Act

AI Act européen : un compromis de haute lutte, de rares interdictions

DroitIA 0
Panneau stop

Apple bloque Beeper, qui permettait d’utiliser iMessage sur Android

WebSoft 14

#LeBrief : faux avis sur Internet, enquêtes sur l’accord Microsoft et OpenAI, cybersécurité aux États-Unis

Un mélange entre une réunion d’Anonymous et de tête d’ampoules, pour le meilleur et le pire

652e édition des LIDD : Liens Intelligents Du Dimanche

Next 9
dessin de Flock

#Flock distribue des mandales tous azimuts

Flock 14
Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #11 et résumé de la semaine

Next 43
Carte graphique AMD GeForce

Cartes graphiques : 30 ans d’évolution des GPU

Hard 28

Google lance son opération de communications Gemini pour rivaliser avec OpenAI

IA 6
Ecran bleu de Windows

Linux : le composant systemd se dote d’un écran bleu de la mort

Soft 41
Une petite fille en train d'apprendre à programmer et hacker logiciels et appareils électroniques

Un roman graphique explique les logiciels libres aux enfants

SoftSociété 21
Nouveautés pour Messenger

Meta lance (enfin) le chiffrement de bout en bout de Messenger, entre autres

Socials 5

#LeBrief : cloud européen, OSIRIS-REx a frôlée la catastrophe, CPU AMD Ryzen 8040

Windows en 2024 : beaucoup d’IA, mais pas forcément un « 12 »

Soft 21
Einstein avec des qubits en arrière plan

Informatique quantique, qubits : avez-vous les bases ?

HardScience 9
Notifications iPhone

Surveillance des notifications : un sénateur américain demande la fin du secret

DroitSécu 18

En ligne, les promos foireuses restent d’actualité

DroitWeb 19

#LeBrief : modalité des amendes RGPD, cyberattaque agricole, hallucinations d’Amazon Q, 25 ans d’ISS

Logo Twitch

Citant des « coûts prohibitifs », Twitch quitte la Corée du Sud

ÉcoWeb 31
Formation aux cryptomonnaies par Binance à Pôle Emploi

Binance fait son marketing pendant des formations sur la blockchain destinées aux chômeurs

Éco 10
Consommation électrique du CERN

L’empreinte écologique CERN en 2022 : 1 215 GWh, 184 173 teqCO₂, 3 234 Ml…

Science 8
station électrique pour voitures

Voitures électriques : dans la jungle, terrible jungle, des bornes de recharge publiques

Société 78

#LeBrief : intelligence artificielle à tous les étages, fichier biométrique EURODAC

KDE Plasma 6

KDE Plasma 6 a sa première bêta, le tour des nouveautés

Soft 13
Un homme noir regarde la caméra. Sur son visage, des traits blancs suggèrent un traitement algorithmique.

AI Act et reconnaissance faciale : la France interpelée par 45 eurodéputés

DroitSociété 4
Api

La CNIL préconise l’utilisation des API pour le partage de données personnelles entre organismes

SécuSociété 3
Fouet de l’Arcep avec de la fibre

Orange sanctionnée sur la fibre : l’argumentaire de l’opérateur démonté par l’Arcep

DroitWeb 25
Bombes

Israël – Hamas : comment l’IA intensifie les attaques contre Gaza

IA 22

#LeBrief : bande-annonce GTA VI, guerre électronique, Spotify licencie massivement

Acheter sur Internet et payer avec sa carte bancaire

La DGCCRF traque les faux avis sur Internet avec son Polygraphe

ÉcoWeb 16

Logo OpenAI

Au Royaume-Uni et aux États-Unis, l’accord entre Microsoft et OpenAI à la loupe

Droit 4

Une main tenant de gros paquets de dollars

87 % des agences états-uniennes ne parviennent pas à respecter les normes de cybersécurité

DroitSécu 3

Florie Marie démissionne de la présidence du Parti Pirate International

Société 8

Commentaires (132)


Obidoub
Le 28/11/2016 à 13h19

 
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&nbsp;<img data-src=" />


H2O
Le 28/11/2016 à 13h22

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.


matroska
Le 28/11/2016 à 13h25

Y a bien de GPS qui amènent les gens dans un lac ou dans un ravin.

<img data-src=" />


Furanku Abonné
Le 28/11/2016 à 13h26

S’ils arrêtaient de foutre des processeurs de 200Mhz dans leur missions aussi <img data-src=" />


Amnesiac
Le 28/11/2016 à 13h29

Du coup la sonde a fait une coyote sur la surface de Mars.


freeman37
Le 28/11/2016 à 13h35

Et encore c’est beaucoup. Habituellement c’est plutôt 60MHz ce qui est déjà pas mal !


madoxav
Le 28/11/2016 à 13h36

ce comportement&nbsp;en réponse aux fausses informations récupérées par l’ordinateur de bord a été «&nbsp;clairement reproduit dans des simulations informatiques&nbsp;»
&nbsp;
&nbsp;C’est con, ça veut dire que ça aurait pu être anticipé.

Edit : p*tain de quotes :o


cyrano2 Abonné
Le 28/11/2016 à 13h37






H2O a écrit :

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.


C’est pas tout à fait ça. C’est un bout de code mort issue de ariane 4 dont il avait fait un reuse de la centrale inertiel. L’enveloppe de vol était différent, et une accélération latéral était différente et saturait un entier (8 ou 16 bits je ne sais plus) mais n’était pas utilisé ailleurs . En ada, un dépassement entraîne une exception… exception qui était branché sur… l’autotest. La central inertiel balance des 0x5555 et 0xAAAA sur le bus de données. Celle-ci est bien tripliqué pour gérer les pannes : 2 centrales, plus un modèle mathématique. Pas de bol, les 2 centrales ont logiquement fait la même chose. La navigation a donc braqué pour compenser ce qu’elle croyait être une déviation.

On note plein d’erreurs cumulés :




  • du code mort

  • un autotest mal placé

  • un système pas testé dans les conditions de vol

  • une exception avec un comportement mal géré

  • une triplication inefficace

  • pas de typage de l’information d’autotest, que le contrôleur n’aurait pas du interprété
    &nbsp;



cyrano2 Abonné
Le 28/11/2016 à 13h37

J’ai du mal à comprendre comment ils ont pu ne pas voir ce comportement en simulation…


t0FF
Le 28/11/2016 à 13h38

Le problème n’est pas vraiment le comportement, mais plutôt la mesure erronée.


ginuis
Le 28/11/2016 à 13h38

Voilà ce qu’il se passe quand on fait des referendum <img data-src=" />


Sandeman Abonné
Le 28/11/2016 à 13h39

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. &nbsp;dont la mesure serait utilisée pour corréler ou mitiger les décisions, ça pourrait sauver des M€ :)


cyrano2 Abonné
Le 28/11/2016 à 13h43






t0FF a écrit :

Le problème n’est pas vraiment le comportement, mais plutôt la mesure erronée.


C’était prévu. Ne pas gérer correctement la mauvaise mesure d’un capteur, c’est ça l’erreur. Un capteur, c’est toujours + ou - bourré d’erreur.



madoxav
Le 28/11/2016 à 13h46

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.&nbsp;


cyrano2 Abonné
Le 28/11/2016 à 13h48

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.


Tohrnoriac Abonné
Le 28/11/2016 à 13h53

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


t0FF
Le 28/11/2016 à 13h54

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…


Alkatrazze
Le 28/11/2016 à 13h54

&nbsp;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.

&nbsp;


djludo61
Le 28/11/2016 à 13h56

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. <img data-src=" />


gogo77
Le 28/11/2016 à 13h57

Euh il était pas au courant qu’il n’avait pas encore utilisé ses moteurs et donc pas atterri? <img data-src=" />

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.


XMalek
Le 28/11/2016 à 14h00

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”.

&nbsp;


JMGuillaume
Le 28/11/2016 à 14h00






Alkatrazze a écrit :

&nbsp;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.

&nbsp;


Ouais ben la station météo, faudra d’abord la faire atterrir&nbsp;sur mars, et c’est pas vraiment gagné au vu du dernier essai &nbsp;<img data-src=" />



JohnCaffey
Le 28/11/2016 à 14h01

Pfff… Avec Howard Wolowitz ça ne serait jamais arrivé… <img data-src=" />


Ellierys
Le 28/11/2016 à 14h01

“Ça passait sur KSP” <img data-src=" />


Alkatrazze
Le 28/11/2016 à 14h03






cyrano2 a écrit :

J’ai du mal à comprendre comment ils ont pu ne pas voir ce comportement en simulation…

&nbsp;

Si on voyait tout en simulation, il n’y aurait jamais d’accident.
Les simulations se basent sur ce qui s’est déjà passé et sur ce qu’il risque de se passer. Là, ils avaient estimé&nbsp;que les mouvements de nutation serait au maximum de 150°/seconde, donc ils avaient calibré le capteur pour qu’il aille jusqu’à 180°/s.
Manque de bol, ExoMars est arrivé aux taquets de 180°/s et en plus y est resté trop longtemps.

La prochaine fois, ils prendront ce paramètre en compte. Et manque de bol, au moment de l’atterrissage, il y aura un grand dragon vert qui se prendra la tête dans le parachute et ça personne&nbsp;ne l’avait prévu.

&nbsp;



Dedrak
Le 28/11/2016 à 14h07

Celui qui plante le rover dans un fossé ? Non merci, il aurait carrément oublier d’activer le parachute.


YohAsAkUrA
Le 28/11/2016 à 14h08

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!
&nbsp;


Alkatrazze
Le 28/11/2016 à 14h10






gogo77 a écrit :

Euh il était pas au courant qu’il n’avait pas encore utilisé ses moteurs et donc pas atterri? <img data-src=" /> 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.

La prochaine fois, on te mettra dans la capsule et comme ça tu seras sur place pour dire au logiciel qu’il n’est pas arrivé à destination.<img data-src=" />Suivant la position relative de la Terre et de Mars, il faut entre 3 et 20 minutes pour qu’un signal envoyé par Mars arrive sur la Terre. Donc au minimum 6 mn pour que la sonde dise “au fait, j’ai un souci, on est arrivé ou pas ?” et que la réponse lui revienne “non, tu es encore à 3 km de haut”.



RedWave
Le 28/11/2016 à 14h13

Ou les ingénieurs qui codent avec des Miles au lieu de Km… C’est à tout les coups un british le responsable :p


XMalek
Le 28/11/2016 à 14h21

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&nbsp; 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”)


plopzz
Le 28/11/2016 à 14h27

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 ;)


CryoGen Abonné
Le 28/11/2016 à 14h27


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” <img data-src=" />


gogo77
Le 28/11/2016 à 14h28

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…


Obidoub
Le 28/11/2016 à 14h31
luxian Abonné
Le 28/11/2016 à 14h31

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 …

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.

<img data-src=" /> Encore une bourde à X milliards de neurones


Industriality
Le 28/11/2016 à 14h34

Pareil, ça veut dire qu’a aucun moment ils n’ont simulé la saturation de ce capteur sur plus d’un seconde…

Honteux.


CryoGen Abonné
Le 28/11/2016 à 14h35






plopzz a écrit :

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 ;)


Pas des experts NASA <img data-src=" />, mais des experts en code. Étonnant d’en trouver sur un site d’informatique.

… surtout ne pas vérifier un simple résultat de calcul, c’est un peu la base dans un cas comme celui là. On parle quand même d’une erreur de plus de 5km tout de même avec un résultat négatif (valeur) : pour une solution qui doit être relativement précise pour calculer les phases atterrissages, et que justement, on ajoute ce truc pour améliorer la mesure… c’est balo de ne pas s’être dit : “ok, on ajoute tout çà parce que ca va remuer sévère, autant aussi prendre quelques précautions de base dans le code… comme éviter une valeur négative pour l’altitude”.
Parce que l’altitude étant LE point surveiller par le système de pilotage, autant éviter les merdes… comme un résultat clairement faux qui va donc donner clairement une décision erronée puisque pas filtrée.



yl
Le 28/11/2016 à 14h44






plopzz a écrit :

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 ;)


Ce qui n’est pas classe, c’est d’avoir sur une mission comme cela un soft digne d’une foreuse, pour avoir pris en compte une altitude négative. L’ESA devrait peut-être en débaucher certains avant d’en embaucher d’autres.

Sur un truc aussi complexe, le ratage est certes toujours possible. Mais aussi connement, franchement…



Tatsu-Kan
Le 28/11/2016 à 14h46

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.


YohAsAkUrA
Le 28/11/2016 à 14h50






Tatsu-Kan a écrit :

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.


sans deconner?



Tatsu-Kan
Le 28/11/2016 à 14h51

Calculs rapides complètement stupides :

ExoMars = 500 000 000 km
Erreur de 3,7 km
&nbsp;
Paris - Damas = 3280 km
Erreur équivalente = 2,43 cm…


seb2411
Le 28/11/2016 à 14h51






YohAsAkUrA a écrit :

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!


Déjà la question de dommage collatéral est plus souvent liée aux effets de l’explosion qu’au fait de rater sa cible et ensuite je vois pas vraiment le rapport entre une sonde et une bombe.



boogieplayer
Le 28/11/2016 à 15h02

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&nbsp;<img data-src=" />

Moi une fois j’ai planté pendant des des heures tout un site, ça sortait un ERR 500 server internal error,&nbsp;à 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…&nbsp;<img data-src=" />

Je donne la source pour ceux qui pensent qu’on n’y connait rien :
https://fr.wikipedia.org/wiki/Mars_Climate_Orbiter


Shaeis
Le 28/11/2016 à 15h03

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.


Obidoub
Le 28/11/2016 à 15h04

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).


anonyme_1239fd635f3ad0729220d37e3113ae29
Le 28/11/2016 à 15h06






CryoGen a écrit :

Pas des experts NASA <img data-src=" />, mais des experts en code. Étonnant d’en trouver sur un site d’informatique.


Perso, j’adhère au double sens ironique de sa tirade puisque réunir la meilleure brochette d’experts n’a jamais garanti le 0 défaut… déjà pas sur Terre alors encore moins là bas sur Mars.

Il semblerait après analyses que le problème provienne d’un truc vraiment bête mais, et l’histoire nous l’a montré, c’est toujours un truc vraiment bête qui est mis en lumière après analyse.
Le défi n’est pas tant de jouer les gros bras après la bataille que d’assurer avant qu’elle n’ait lieu.

C’est valable pour tous les domaines. Tu peux faire relire le truc à des milliers d’experts, il restera toujours un défaut simple pouvant compromettre le projet et dont les analyses à posteriori feront dire que ça n’aurait jamais dû passer.

La sécurité aérienne civile a progressé comme cela. Bon nombres d’éléments de sécurité sensés éviter des accidents en ont en fait été facteur et ont été corrigés ou modifiés.
La simulation c’est bien joli, tout aussi détaillée soit-elle, mais tant que ça n’a pas été validé en conditions réelles on est loin de la certitude.



tomcat
Le 28/11/2016 à 15h10

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…<img data-src=" />


coket Abonné
Le 28/11/2016 à 15h14

Ben faudra mettre un pilote dans le prochain&nbsp;<img data-src=" />

Faut envoyer Cooper, &nbsp;même s’il est vieux maintenant…
&nbsp;


Poppu78
Le 28/11/2016 à 15h21

Ben non, puisque justement ils t’expliquent que le comportement était attend mais sur beaucoup moins de temps…


kerrubin
Le 28/11/2016 à 15h29






tomcat a écrit :

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 !



https://fr.wikipedia.org/wiki/Mars_%28plan%C3%A8te%29#Traits_notables
Sur la carte topographique, on peut voir que sur Mars, il y a des altitudes négatives. Jusqu’à -8km.
Un peu comme sur Terre, quoi.

Tout dépend donc de où la sonde était larguée.



Firefly' Abonné
Le 28/11/2016 à 15h31

Des fois je me demandes comment les gens font pour ne pas remarquer la pêche à la dynamite &gt;&lt;‘


Texas Ranger
Le 28/11/2016 à 15h34






ginuis a écrit :

Voilà ce qu’il se passe quand on fait des referendum <img data-src=" />


<img data-src=" />



tazvld Abonné
Le 28/11/2016 à 15h39

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.


tazvld Abonné
Le 28/11/2016 à 15h41

Ha ben dans l’immédiat, la majorité de la sonde est maintenant elle aussi sous le niveau de la surface martienne.


kerrubin
Le 28/11/2016 à 15h44

Éparpillée façon puzzle.
Mais on peut pas comprendre, c’est de l’art.


Alkatrazze
Le 28/11/2016 à 15h51

&nbsp;&nbsp;




yl a écrit :

Ce qui n’est pas classe, c’est d’avoir sur une mission comme cela un soft digne d’une foreuse, pour avoir pris en compte une altitude négative. L’ESA devrait peut-être en débaucher certains avant d’en embaucher d’autres.

Sur un truc aussi complexe, le ratage est certes toujours possible. Mais aussi connement, franchement…

&nbsp;
Pour juger de la qualité du soft, je suppose que&nbsp;vous avez eu accès au code source ?
&nbsp;

Industriality a écrit :

Pareil, ça veut dire qu’a aucun moment ils n’ont simulé la saturation de ce capteur sur plus d’un seconde…

Honteux.

&nbsp;
Non, c’est saturation du capteur (ce qui n’était pas prévu) une seconde de trop.
&nbsp;
Postulez à l’ESA pour l’écriture du prochain soft : cela permettra d’effacer la honte



Texas Ranger
Le 28/11/2016 à 15h56

y aurait pas eu ce problème avec windows
mais non, il fallait utiliser linux


alex.d. Abonné
Le 28/11/2016 à 15h59






tomcat a écrit :

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…<img data-src=" />


On peut dire aussi que la mesure a une marge d’erreur, et que si la valeur donnée est négative, mais si en ajoutant la marge d’erreur, on arrive à zéro, alors on peut légitimement penser qu’on est posé.
Tout serait si simple avec des capteurs fiables. Le problème, c’est que les capteurs ne sont pas fiable, et quand ils marchent, ils ne sont pas précis. Les cas de mauvaises décisions prises suite à des informations erronées données par les capteurs, on en connaît à la pelle. Tout le monde a sa petite sur la façon dont il aurait fallu programmer le bouzin pour gérer ce cas a posteriori. Mais est-ce que votre “correction” n’aurait pas introduit un problème dans un autre cas ?&nbsp;



CryoGen Abonné
Le 28/11/2016 à 16h00






kerrubin a écrit :

https://fr.wikipedia.org/wiki/Mars_%28plan%C3%A8te%29#Traits_notables
Sur la carte topographique, on peut voir que sur Mars, il y a des altitudes négatives. Jusqu’à -8km.
Un peu comme sur Terre, quoi.

Tout dépend donc de où la sonde était larguée.



Je ne crois pas que celà rentre en compte ici. Le radar de la sonde mesurait la distance entre elle même et le sol. Il n’y a donc aucune raison d’avoir une valeur négative.



Alkatrazze
Le 28/11/2016 à 16h03






tomcat a écrit :

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…<img data-src=" />

&nbsp;

Et si le logiciel avait estimé que la sonde était à une&nbsp;altitude positive de&nbsp;+10m voire même +100m au dessus du sol&nbsp;au lieu d’une altitude négative, cela n’aurait strictement rien changé : il aurait considéré que&nbsp;le sol&nbsp;était proche, il aurait largué les parachutes et allumé les rétrofusées.

Cela n’aurait pas empêché la sonde d’être toujours à 3,7 km et de se crasher&nbsp;exactement de la même manière.

&nbsp;&nbsp;



CryoGen Abonné
Le 28/11/2016 à 16h10






alex.d. a écrit :

Tout le monde a sa petite sur la façon dont il aurait fallu programmer le bouzin pour gérer ce cas a posteriori. Mais est-ce que votre “correction” n’aurait pas introduit un problème dans un autre cas ?



Ah mais c’est clair. Mais il y a tout de même un soucis:




  • La valeur négative (donc clairement fausse) -&gt; 1er problème “facile” à éviter (on crache sur Microsoft pour moins que çà)

  • Aucun suivi de l’altitude : on passe de +3.6km à -2km en 1 seconde : tout va bien les mecs.

    En gros tout le monde sait que le capteur peut raconter n’importe quoi pendant un temps. Mais plutôt que de gérer la solution en hard et soft, on a préféré se baser sur une donnée fixée à l’avance : la sonde ne va pas mettre en défaut le capteur !

    J’imagine, ou plutôt l’espère, que les données des capteurs sont filtrées pour éviter les erreurs, mais là, manifestement il n’y avait ni le test de valeur négative (simple), ni de progression de descente (vitesse max, et oui ca pourrait être aussi un point de faille si mal réfléchi, on est d’accord).



levhieu
Le 28/11/2016 à 16h10
kerrubin
Le 28/11/2016 à 16h11

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.


Alexyu
Le 28/11/2016 à 16h18

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…


Alkatrazze
Le 28/11/2016 à 16h20






CryoGen a écrit :

Je ne crois pas que celà rentre en compte ici. Le radar de la sonde mesurait la distance entre elle même et le sol. Il n’y a donc aucune raison d’avoir une valeur négative.


Le radar Doppler ne peut donner des mesures exploitables et fiables que s’il est dirigé vers le bas et si l’angle de la sonde est&nbsp;à peu près stable par rapport&nbsp;au sol. Un capteur d’orientation est chargé de corriger les&nbsp;données brutes&nbsp;fournies par le radar.
Or, là, ce capteur d’orientation considère que la sonde est pratiquement sens dessus-dessous et que le radar est en train de regarder en l’air. Les valeurs deviennent donc complètement absurdes.

Après coup, c’est facile de dire “y z’avaient qu’à faire ça”.&nbsp;
Là, tu programmes un logiciel de prise de décision en temps réel :&nbsp;“si je trouve telle valeur et telle valeur, alors la situation la plus probable,&nbsp;c’est que la sonde est presque arrivée, donc je prends telle et telle décision”.&nbsp;On travaille&nbsp;au dixième de seconde&nbsp;près, on n’a pas le temps d’avoir un soft qui dit “si je trouve telle ou telle valeur, alors&nbsp;je vais&nbsp;lancer les&nbsp;rétrofusées pendant 5 secondes pour tenter une stabilisation, puis&nbsp;relancer&nbsp;des mesures et voir si les&nbsp;valeurs sont maintenant cohérentes et donc en tirer une nouvelle conclusion”, … Parce que de toute façon, ce serait quand même trop tard.

&nbsp;



YohAsAkUrA
Le 28/11/2016 à 16h25






Firefly’ a écrit :

Des fois je me demandes comment les gens font pour ne pas remarquer la pêche à la dynamite &gt;&lt;’


je me pose la même question….
je pense que je vais gentillement poster une photo de bazooka au même temps que mes commentaires a force.
&nbsp;



yl
Le 28/11/2016 à 16h59






Alkatrazze a écrit :

&nbsp;&nbsp;&nbsp;



Pour juger de la qualité du soft, je suppose que&nbsp;vous avez eu accès au code source ?     


&nbsp;&nbsp;



Non, c'est saturation du capteur (ce qui n'était pas prévu) une seconde de trop.     


&nbsp;
Postulez à l’ESA pour l’écriture du prochain soft : cela permettra d’effacer la honte


Un capteur qui sature un poil trop et 1 seconde qui pose pb à 3700m et déjà décéléré (sous parachute) à beaucoup moins que de l’ordre du millier de m/s (ou là il n’y aurait pas eu de solution à un pb qui “dure”), pas besoin d’avoir lu les sources pour donner mon avis (de contribuable): Un plantage con qui aurait pu être évité.



yl
Le 28/11/2016 à 17h01






Obidoub a écrit :

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).


Là, je me sens vraiment pas visé… Mais bon, entre Airbus qui empêche de remettre les gazs si des turbines sont mal calibrées et les sondes spatiales, je me dis que le soft critique n’est plus ce qu’il était.



JIMIZ
Le 28/11/2016 à 17h23

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&nbsp; il avait calculer en pieds&nbsp; sur un système métrique le péon.


_Beryl_
Le 28/11/2016 à 17h36






madoxav a écrit :

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.


&nbsp;Oui tout à fait d’accord. C’est une bonne pratique de prendre une marge de sécurité de 20% mais comme il s’agit d’une estimation (sur la base de quels éléments probants ???) et d’une nutation donc qui tourne, il me semble que le plus évident aurait été de considérer une valeur max de 360°/s&nbsp;
&nbsp;



CryoGen Abonné
Le 28/11/2016 à 17h36






Alkatrazze a écrit :

Le radar Doppler ne peut donner des mesures exploitables et fiables que s’il est dirigé vers le bas et si l’angle de la sonde est à peu près stable par rapport au sol. Un capteur d’orientation est chargé de corriger les données brutes fournies par le radar.
Or, là, ce capteur d’orientation considère que la sonde est pratiquement sens dessus-dessous et que le radar est en train de regarder en l’air. Les valeurs deviennent donc complètement absurdes.


J’ai bien compris. Et justement, valeur absurde = valeur à éjecter. Eux même savaient que la sonde allait tournoyer, d’où la centrale inertielle pour fournir un coef de correction.



Alkatrazze a écrit :

Après coup, c’est facile de dire “y z’avaient qu’à faire ça”. 
Là, tu programmes un logiciel de prise de décision en temps réel : ”si je trouve telle valeur et telle valeur, alors la situation la plus probable, c’est que la sonde est presque arrivée, donc je prends telle et telle décision”. On travaille au dixième de seconde près, on n’a pas le temps d’avoir un soft qui dit “si je trouve telle ou telle valeur, alors je vais lancer les rétrofusées pendant 5 secondes pour tenter une stabilisation, puis relancer des mesures et voir si les valeurs sont maintenant cohérentes et donc en tirer une nouvelle conclusion”, … Parce que de toute façon, ce serait quand même trop tard.



Après coup, c’est facile oui. Mais si le crash se résume à une mauvaise prédiction + l’oubli d’un simple test, il y a de quoi discuter tout de même. Là on est pas en train de parler de contrôle au poil de cul : on parle de lancer un parachute puis de freiner à l’aide de fusée… on est assez loin d’un d’un atterrissage façon Space X niveau calcul.



cesame
Le 28/11/2016 à 17h56

Moi je la connaissais sous cette forme “ce qu’une femme fait en 9 mois, 9 femmes ne le font pas en un mois”.


JohnCaffey
Le 28/11/2016 à 18h06

Oui, bon, c’est un détail… <img data-src=" />


Ricard
Le 28/11/2016 à 18h21






madoxav a écrit :

ce comportement&nbsp;en réponse aux fausses informations récupérées par l’ordinateur de bord a été «&nbsp;clairement reproduit dans des simulations informatiques&nbsp;»
&nbsp;
&nbsp;C’est con, ça veut dire que ça aurait pu être anticipé.

Edit : p*tain de quotes :o


Surtout que c’est déjà arrivé avec Mars Climat Orbiter qui s’est crashée en 1999. Je cite wikipedia:


Un logiciel développé par les ingénieurs de Lockheed, concepteurs de la sonde, communiquait la poussée des micro propulseurs en unités de mesure anglo-saxonnes (livre-force
· seconde), tandis que le logiciel de l’équipe de navigation du JPL qui
recevait ces données pour les calculs des corrections de trajectoire
attendait des données en unités du système métrique (newton · seconde).


<img data-src=" />Bravo les ingés de la Nasa.



Obidoub
Le 28/11/2016 à 18h24






Ricard a écrit :

<img data-src=" />Bravo les ingés de la Nasa.


Il ne s’agit pas de la NASA mais du JPL, ils utilisaient les bonnes unités normalisées.
C’est le constructeur (privé) qui était en tort.



Ricard
Le 28/11/2016 à 18h28






Obidoub a écrit :

Il ne s’agit pas de la NASA mais du JPL, ils utilisaient les bonnes unités normalisées.
C’est le constructeur (privé) qui était en tort.


On s’en fout. Juste pour dire que ce genre de trucs est déjà arrivé et qu’aucune leçon en est tirée.
Par exemple, Boeing utilise le métrique pour le carburant de leurs avions. Après avoir avoir échappé à eux trois catastrophes ils en ont tiré les leçons.<img data-src=" />



OlivierJ Abonné
Le 28/11/2016 à 19h04

&nbsp;





Obidoub a écrit :

La sonde avait un radar altimètre Doppler, source :https://fr.wikipedia.org/wiki/Schiaparelli_%28engin_spatial%29#Caract.C3.A9risti…


Il ne faut pas de moquer mais ça m’a fait marrer qu’il imagine un altimètre barométrique.
&nbsp;


plopzz a écrit :

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 ;)


<img data-src=" />
Et en plus les commentaires qui ont suivi le tien en ont remis une couche, fascinant… Rien que ceux-ci :



Industriality a écrit :

Pareil, ça veut dire qu’a aucun moment ils n’ont simulé la saturation de ce capteur sur plus d’un seconde…
Honteux.




CryoGen a écrit :

Pas des experts NASA <img data-src=" />, mais des experts en code. Étonnant d’en trouver sur un site d’informatique.

… surtout ne pas vérifier un simple résultat de calcul, c’est un peu la base dans un cas comme celui là.




yl a écrit :

Ce qui n’est pas classe, c’est d’avoir sur une mission comme cela un soft digne d’une foreuse, pour avoir pris en compte une altitude négative. L’ESA devrait peut-être en débaucher certains avant d’en embaucher d’autres.
Sur un truc aussi complexe, le ratage est certes toujours possible. Mais aussi connement, franchement…


<img data-src=" />



jb07 Abonné
Le 28/11/2016 à 19h10

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).


philanthropos
Le 28/11/2016 à 19h29






OlivierJ a écrit :

Il ne faut pas de moquer mais ça m’a fait marrer qu’il imagine un altimètre barométrique.
 
<img data-src=" />
Et en plus les commentaires qui ont suivi le tien en ont remis une couche, fascinant… Rien que ceux-ci :

<img data-src=" />


Grave.

On se croirait sur un forum de politique où tout le monde y va de son petit avis de doctorant en droit avec une maitrise en sciences sociales.

Et après, ils demandent à être écoutés, ils se font rire au nez et s’étonnent …



OlivierJ Abonné
Le 28/11/2016 à 19h39






Firefly’ a écrit :

Des fois je me demandes comment les gens font pour ne pas remarquer la pêche à la dynamite &gt;&lt;’


&nbsp;

YohAsAkUrA a écrit :

je me pose la même question….
je pense que je vais gentillement poster une photo de bazooka au même temps que mes commentaires a force.


Disons que pour ton commentaire j’avais perçu l’ironie et souri, mais il y en a capable de poster ça sérieusement, sans parler des champions du monde de programmation qui viennent se vanter de faire mieux que ceux qui se sont occupé de la sonde…



YohAsAkUrA
Le 28/11/2016 à 19h44






OlivierJ a écrit :

&nbsp;
Disons que pour ton commentaire j’avais perçu l’ironie et souri, mais il y en a capable de poster ça sérieusement, sans parler des champions du monde de programmation qui viennent se vanter de faire mieux que ceux qui se sont occupé de la sonde…


c’était effectivement de la pure ironie dans la mesure ou si même deja pour balancer un missile a 5000km de la france on est incapable d’être précis au Centimètre, il est normal que tout ne se passe pas comme prévu quand on lance un truc qui va atterir entre 60millions et 400millions de km selon l’orbite de la terre et de mars…

et je faisais justement allusion a tous ceux qui disent qu’a leur place ils auraient codé un truc pico bello sans soucis….
&nbsp;



sr17
Le 28/11/2016 à 21h04


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.






OlivierJ a écrit :

Disons que pour ton commentaire j’avais perçu l’ironie et souri, mais il y en a capable de poster ça sérieusement, sans parler des champions du monde de programmation qui viennent se vanter de faire mieux que ceux qui se sont occupé de la sonde…



Je suis d’accord qu’il est toujours plus facile de penser qu’on est meilleur que les autres que de l’être véritablement.

Cela étant dit, un bug dans le code ou des infos erronées d’un capteur, c’est un problème de base qui doit être anticipé.

Normalement, de bonnes méthodologies de validation devraient permettre de déverminer 99% de ces problèmes.

Reste à savoir s’il y a un problème de méthodologie ou si on se trouve dans les 1% d’impondérables que personne n’aurait pu prévoir.



linkin623 Abonné
Le 28/11/2016 à 21h06






Alkatrazze a écrit :

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.


Tu fais pas si bien dire. Les rovers US ont tout ce qui faut pour donner les infos ! C’était ptre une possibilité…



luxian Abonné
Le 28/11/2016 à 21h28

Ah oui c’est vrai qu’il est doté de rétrofusées … j’avais oublié.


Commentaire_supprime
Le 28/11/2016 à 21h55

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é…


Obidoub
Le 28/11/2016 à 22h33

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.


Obidoub
Le 28/11/2016 à 22h44

Il faut relativiser les choses en comprenant ces deux points :




  1. L’exploration de Mars, c’est pas simple. La NASA a plus de 50 ans d’expérience, et ils ont essuyé pas mal d’échecs. Et je ne parlerai même pas de l’URSS qui spammait les sondes et ne nommait que celles qui remplissaient leurs objectifs ou échouaient de manière pas trop misérable, des tas d’échecs ont été passés sous silence. Depuis les années 90, la russe n’arrive même plus à envoyer une sonde vers Mars (Mars 96, Phobos-Grunt). L’ESA n’a peut-être pas encore le savoir-faire pour atterrir sur Mars, ça viendra.


  2. Même quand les missions de la NASA, de l’ESA ou la JAXA réussissent, il y a toujours des tas de bugs et d’imprévus qui surviennent, mais la plupart du temps ils sont résolus à distance. Deux exemples : Akatsuki qui a raté son insertion en orbite autour de Venus et a finalement réussi 5 ans plus tard, et la sonde américaine Gallielo qui n’a pas réussi à déployer son antenne grand gain et a du faire transiter les données scientifiques par l’antenne à faible gain, beaucoup plus lente.

    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.


brazomyna
Le 28/11/2016 à 23h47

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é.


barlav Abonné
Le 29/11/2016 à 00h25

Je peux mépriser ton comm?
<img data-src=" />


alex.d. Abonné
Le 29/11/2016 à 01h14






CryoGen a écrit :

Ah mais c’est clair. Mais il y a tout de même un soucis:




  • La valeur négative (donc clairement fausse) -&gt; 1er problème “facile” à éviter (on crache sur Microsoft pour moins que çà)

  • Aucun suivi de l’altitude : on passe de +3.6km à -2km en 1 seconde : tout va bien les mecs.

    En gros tout le monde sait que le capteur peut raconter n’importe quoi pendant un temps. Mais plutôt que de gérer la solution en hard et soft, on a préféré se baser sur une donnée fixée à l’avance : la sonde ne va pas mettre en défaut le capteur !

    J’imagine, ou plutôt l’espère, que les données des capteurs sont filtrées pour éviter les erreurs, mais là, manifestement il n’y avait ni le test de valeur négative (simple), ni de progression de descente (vitesse max, et oui ca pourrait être aussi un point de faille si mal réfléchi, on est d’accord).

    Une valeur négative n’est pas forcément “clairement fausse”. Faut voir les marges d’erreur de l’instrument.
    Ensuite, ils ne font pas confiance aveuglément au capteur, mais si le capteur persiste pendant plus d’une seconde, c’est sans doute que ce n’est pas une valeur aberrante. Pas tip-top comme stratégie, tu es libre d’en proposer une meilleure.
    Après oui, normalement en avionique, l’un des systèmes redondants est une prédiction extrapolée à partir des valeurs passées et d’un modèle mathématique, qui aurait dû détecter le problème. Mais je ne sais pas quelle redondance il y a sur les sondes spatiales (le poids embarqué est vraiment critique).



Pogny
Le 29/11/2016 à 07h31

Y’avait le Black Frday sur steam… espérons qu’ils ont tous acheté Kerbal Space Program, ça pourrait leur servir <img data-src=" />


anonyme_9367dd1df7b3b0a51425cf91b324db64
Le 29/11/2016 à 07h51






cyrano2 a écrit :

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.


Il suffit d’un bouclier thermique qui se sépare pendant la deuxième phase de descente, devant le télémètre/laser et le tour est joué !
Messieurs de l’ESA, je vous envoi mon CV. quand vous voulez.



Drozo
Le 29/11/2016 à 08h00






Highmac87 a écrit :

Il suffit d’un bouclier thermique qui se sépare pendant la deuxième phase de descente, devant le télémètre/laser et le tour est joué !
Messieurs de l’ESA, je vous envoi mon CV. quand vous voulez.



Qui te dit que le bouclier sera toujours devant le télémètre/laser ?



nox64
Le 29/11/2016 à 08h11

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 ^^)


CryoGen Abonné
Le 29/11/2016 à 08h13






alex.d. a écrit :

Une valeur négative n’est pas forcément “clairement fausse”. Faut voir les marges d’erreur de l’instrument.



On parle quand même de -2km, Hors les trusters devaient s’allumer à 1.1km et s’arrêter à environ 2m du sol (vitesse 0). Là il faudrait accepter une marge d’erreur de plus de 5km, ce qui est énorme, même si on considère que la précision augmente quand l’altitude baisse (stabilisation).



alex.d. a écrit :

Ensuite, ils ne font pas confiance aveuglément au capteur, mais si le capteur persiste pendant plus d’une seconde, c’est sans doute que ce n’est pas une valeur aberrante. Pas tip-top comme stratégie, tu es libre d’en proposer une meilleure.


Il en lui font pas confiance ? Assez quand même pour sauter des étapes de la porcédure d’attérrisage, c’est un niveau de confiance assez elevé je trouve <img data-src=" />

[

alex.d. a écrit :

Après oui, normalement en avionique, l’un des systèmes redondants est une prédiction extrapolée à partir des valeurs passées et d’un modèle mathématique, qui aurait dû détecter le problème. Mais je ne sais pas quelle redondance il y a sur les sondes spatiales (le poids embarqué est vraiment critique).



Même si le poid à de l’importance, je ne suis pas sur qu’un peu plus de mémoire et puissance auraient pesé lourd… surtout pour l’énergie vu que le but de l’engin n’était pas de survivre longtemps une fois posé.



CryoGen Abonné
Le 29/11/2016 à 08h29






philanthropos a écrit :

Grave.

On se croirait sur un forum de politique où tout le monde y va de son petit avis de doctorant en droit avec une maitrise en sciences sociales.

Et après, ils demandent à être écoutés, ils se font rire au nez et s’étonnent …



Oui vous avez raison, on ne peut pas avoir d’avis. D’ailleurs, puisque vous faites le parallèle avec la politique, j’imagine que vous ne votez pas car vous n’avez pas les bagages nécessaires (donc ici un doctorat en voyance j’imagine) ?

Et, pour rappel, les gens bossant à l’ESA ne sont pas des surhommes. Oui ils en ont clairement dans la caboche, il y a des génies parmi eux, mais ca ne veut pas dire qu’ils sont forcement meilleurs que tout le monde et que donc nos avis ne servent à rien…

Alors après oui, donnez son avis sur NXi et débattre (plus ou moins <img data-src=" />) avec d’autres gens n’est pas hyper constructif… mais surement bien plus intéressant que vos commentaires désabusés.



levhieu
Le 29/11/2016 à 09h12

Et il y a plus de 50 ans, ça merdait grave aussi de temps en temps
&nbsp;
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


seb2411
Le 29/11/2016 à 09h35






nox64 a écrit :

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 ^^)


Compare le budget pour aller sur la Lune (~120Md$) a cette sonde (300 millions d’euros). Car c’est souvent un élément qu’on oublis: Le budget.

Car les ingénieurs voudraient sûrement avoir une sonde super pointue avec tous les tests possibles inimaginables. Les Scientifiques adoreraient lui coller toute sorte de capteurs et charge scientifique high-tech…

Mais le budget est en général limité et donc tout le monde doit faire avec des contraintes qu’on leurs donnent. Et dans le cas de cette sonde l’organisation et l’obtention des budgets a été chaotique et ils ont du prendre des raccourcis et sûrement ne pas faire tout ce qu’ils auraient aimer faire (test, redondances, etc.).



Alkatrazze
Le 29/11/2016 à 09h42






JIMIZ a écrit :

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&nbsp; il avait calculer en pieds&nbsp; sur un système métrique le péon.


Préviens vite les responsables : parce qu’eux, ils ne savent toujours pas pourquoi Beagle2 s’est écrasé.

aucune cause définitive de l’échec ne peut être identifiée en raison du manque de données - radio, télémétrie ou visuel



anonyme_1239fd635f3ad0729220d37e3113ae29
Le 29/11/2016 à 09h49

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é.


Alkatrazze
Le 29/11/2016 à 09h53






CryoGen a écrit :

J’ai bien compris. Et justement, valeur absurde = valeur à éjecter. Eux même savaient que la sonde allait tournoyer, d’où la centrale inertielle pour fournir un coef de correction.



Après coup, c’est facile oui. Mais si le crash se résume à une mauvaise prédiction + l’oubli d’un simple test, il y a de quoi discuter tout de même. Là on est pas en train de parler de contrôle au poil de cul : on parle de lancer un parachute puis de freiner à l’aide de fusée… on est assez loin d’un d’un atterrissage façon Space X niveau calcul.


Valeur absurde = valeur à éjecter.
Et si la valeur avait été +1000 mètres, la valeur n’aurait pas été absurde, non ?
Sauf que la sonde se serait crashé tout autant parce qu’elle était à 3,7 km.

Et une fois que tu as éjecté la valeur, tu fais quoi ?

Sinon :
Ouvrir un parachute : oui. Avec l’assurance de ne pas l’ouvrir trop tôt ou trop tard, avec l’assurance qu’il se déploie bien vers le haut, avec l’assurance qu’il doit être détaché avant que la sonde arrive sur le sol pour qu’elle ne soit pas emprisonnée dans le parachute.
Freinage avec des fusées : oui. Avec l’assurance de les déclencher exactement au bon moment, parce que tu as du carburant uniquement pour quelques secondes.

Quant à l’oubli d’un simple test, je repose la question que j’ai déjà posé : qui d’entre nous a eu accès au code source ? Parce qu’il n’y a qu’en analysant le code que l’on pourra décider si c’est une erreur de conception du soft, une erreur de codage, une erreur due à une mauvaise coordination entre les équipes hard et soft, … ou si simplement, c’était une situation absolument imprévisible.



Ricard
Le 29/11/2016 à 10h03






Obidoub a écrit :

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.


Prenons un autre exemple si tu préfères. Le 4 juin 1996, Ariane 5 explose en vol a cause du calculateur sous-dimensionné (hérité d’Ariane 4 beaucoup moins puissante).&nbsp; Les calculs saturent la mémoire, le calculateur du pilote automatique se coupe, et la fusée par en couille. Ca te convient mieux ? <img data-src=" />

&nbsp;



CryoGen Abonné
Le 29/11/2016 à 10h17






Alkatrazze a écrit :

Valeur absurde = valeur à éjecter.
Et si la valeur avait été +1000 mètres, la valeur n’aurait pas été absurde, non ?
Sauf que la sonde se serait crashé tout autant parce qu’elle était à 3,7 km.



Oui effectivement, et là j’aurai rien eu à redire… sur ce point. Logique.




Alkatrazze a écrit :

Et une fois que tu as éjecté la valeur, tu fais quoi ?


Et bien tu continues le cycle et tu relèves la nouvelle valeur. Et ainsi de suite. Si le système est définitivement coincé bah la sonde est perdue, mais si ca ce décoince (ce qui aurait été le cas ici) la procédure atterrissage continue “tranquillement”.



Alkatrazze a écrit :

Sinon :
Ouvrir un parachute : oui. Avec l’assurance de ne pas l’ouvrir trop tôt ou trop tard, avec l’assurance qu’il se déploie bien vers le haut, avec l’assurance qu’il doit être détaché avant que la sonde arrive sur le sol pour qu’elle ne soit pas emprisonnée dans le parachute.
Freinage avec des fusées : oui. Avec l’assurance de les déclencher exactement au bon moment, parce que tu as du carburant uniquement pour quelques secondes.


C’est justement pour çà que le contrôle d’altitude était là. On peut imaginer qu’il aurait pu être seconder par un modèle mathématique (calculé à l’avance pourquoi pas) pour voir si la progression est cohérente (et donc aider à filtrer les valeurs)



Alkatrazze a écrit :

Quant à l’oubli d’un simple test, je repose la question que j’ai déjà posé : qui d’entre nous a eu accès au code source ? Parce qu’il n’y a qu’en analysant le code que l’on pourra décider si c’est une erreur de conception du soft, une erreur de codage, une erreur due à une mauvaise coordination entre les équipes hard et soft, … ou si simplement, c’était une situation absolument imprévisible.



Code source ? non bien entendu, on extrapole tous par rapport à la com de l’ESA. “la sonde a cru être à -2km et a balancer toutes les étapes atterrissages d’un coup”.
Bref, on a fait rapidement le raccourci il est vrai, mais d’un autre coté on fait avec ce que l’on a. C’est d’ailleurs pour çà que personne ne râle sur le capteur “fautif” tu remarqueras ;)



Charly32 Abonné
Le 29/11/2016 à 10h27

&nbsp;





CryoGen a écrit :

Pas des experts NASA <img data-src=" />, mais des experts en code. Étonnant d’en trouver sur un site d’informatique.

… surtout ne pas vérifier un simple résultat de calcul, c’est un peu la base dans un cas comme celui là. On parle quand même d’une erreur de plus de 5km tout de même avec un résultat négatif (valeur) : pour une solution qui doit être relativement précise pour calculer les phases atterrissages, et que justement, on ajoute ce truc pour améliorer la mesure… c’est balo de ne pas s’être dit : “ok, on ajoute tout çà parce que ca va remuer sévère, autant aussi prendre quelques précautions de base dans le code… comme éviter une valeur négative pour l’altitude”.
Parce que l’altitude étant LE point surveiller par le système de pilotage, autant éviter les merdes… comme un résultat clairement faux qui va donc donner clairement une décision erronée puisque pas filtrée.





tomcat a écrit :

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…<img data-src=" />


Pourquoi il devraient s’interdire des valeurs négatives? Tu en trouve
déjà sur terre, et tout dépend de ta référence d’altitude zéro
également. Derrière ça, il y a un énorme taf de modélisation et de
construction de spec. Cf le commentaire de la news indiquant des valeurs pouvant descendre à -8km.
Même sur de la Centrale de Nav marine, les valeurs d’altitude négative (dans une certaine mesure et hors sous-marins ofc) ne sont pas un motif de panne.


XMalek a écrit :

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&nbsp; 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”)




alex.d. a écrit :

On peut dire aussi que la mesure a une marge d’erreur, et que si la
valeur donnée est négative, mais si en ajoutant la marge d’erreur, on
arrive à zéro, alors on peut légitimement penser qu’on est posé.

Tout serait si simple avec des capteurs fiables. Le problème, c’est que
les capteurs ne sont pas fiable, et quand ils marchent, ils ne sont pas
précis. Les cas de mauvaises décisions prises suite à des informations
erronées données par les capteurs, on en connaît à la pelle. Tout le
monde a sa petite sur la façon dont il aurait fallu programmer le bouzin
pour gérer ce cas a posteriori. Mais est-ce que votre “correction”
n’aurait pas introduit un problème dans un autre cas ?&nbsp;



1 - Il peut toujours y avoir une déviation du point d’atterrissage, pouvant se trouver à une altitude négative.
2 - Le capteur n’a pas dit de la merde, ou plutôt le signal était toujours bon. La valeur mesurée était en revanche fausse (ce qui d’ailleurs a probablement du être remonté au filtre de navigation).
Pour être plus clair, le capteur a mesuré un taux de rotation de 150°/s quand la sonde atteignait en réalité 180°/s.
3 - En effet, quel comportement adopter, en admettant que la centrale dise : Ok on a saturé une seconde, je sais plus ou j’en suis, ciao ? Je suis prêt à parier que le cas a été prévu, mais que c’est un sacré bordel à gérer.&nbsp;
&nbsp;


luxian a écrit :

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 …

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.

<img data-src=" /> Encore une bourde à X milliards de neurones


Comment un parachutiste aveugle sait quand il doit ouvrir son parachute?


Quand y’a du mou dans la laisse du chien <img data-src=" />
&nbsp;



CryoGen a écrit :

Ah mais c’est clair. Mais il y a tout de même un soucis:




  • La valeur négative (donc clairement fausse) -&gt; 1er problème “facile” à éviter (on crache sur Microsoft pour moins que çà)

  • Aucun suivi de l’altitude : on passe de +3.6km à -2km en 1 seconde : tout va bien les mecs.

    En gros tout le monde sait que le capteur peut raconter n’importe quoi pendant un temps. Mais plutôt que de gérer la solution en hard et soft, on a préféré se baser sur une donnée fixée à l’avance : la sonde ne va pas mettre en défaut le capteur !

    J’imagine, ou plutôt l’espère, que les données des capteurs sont filtrées pour éviter les erreurs, mais là, manifestement il n’y avait ni le test de valeur négative (simple), ni de progression de descente (vitesse max, et oui ca pourrait être aussi un point de faille si mal réfléchi, on est d’accord).


    1 - Non, la valeur d’altitude négative n’est pas une valeur fausse (cf mon commentaire ci-dessus)
    2 - Il n’a été précisé nulle part dans le communiqué ou l’article que l’altitude est passé de +3,6km à -2km en une fraction de seconde.
    3 - Et bien sûr, les données des capteurs sont filtrées. Quelques faits à propos du guidage inertiel :


  • Les données brutes issues de capteurs sont filtrées, à haute fréquence (i.e la fréquence à laquelle le capteur débite de la donnée). C’est là qu’on détecte des saturation ou des valeurs aberrantes. C’est aussi là qu’on compense des erreurs dues à la température et surtout, que l’on compense des erreurs de coning et sculling apparaissant lors du calcul de la solution de navigation effectuée à plus basse fréquence (car limité par la puissance de calcul). Ce phénomène est assimilable à de l’aliasing, bien connus des joueurs de JV.

  • La solution de navigation (i.e les taux de rotation, les vitesses, l’altitude etc…) est calculée via un filtre de Kalman. Le rôle de ce dernier est de comparer les données issues des différents capteurs inertiels, des références externes (i.e d’autres capteurs, comme le GPS ou ici le radar) et comparer tout ça à un modèle mathématique.&nbsp; C’est ici que l’on pourra agir si on voir une vitesse verticale trop élevée par exemple.
    Le filtre fourni également une estimation de la confiance de la solution fournie.
    Les principales limitations du filtre de Kalman pour la nav inertielle aujourd’hui sont :

  • la puissance de calcul, surtout dans l’aérospace. On ne peut pas avoir une infinité d’états (de variables) modélisés, sinon le calcul prendra trop de temps.

  • le stockage : oui, même de nos jour c’est encore un problème. Dans l’aérospatial on doit faire de nombreuses concession au profit de la masse et surtout de la fiabilité.

  • Kalman ne marchera que vis à vis de phénomènes linéaires. Autrement, la théorie est plutôt balbutiante et on retombe sur le problème du point 1 et 2

  • la modélisation de l’erreur : c’est le boulot des ingénieur. Ils ont parié sur le fait que la sonde ne pourrait tourner aussi vite aussi longtemps, ce qui a eu des répercussion sur la conception du filtre.
    Il y a probablement de nombreuses raisons qui ont poussé ces gens très compétent à faire ce compromis : retour d’expérience, simulations, gains de conception sur le filtre etc.
    C’est, rétrospectivement une erreur, mais certainement pas de débutant.

    &nbsp;- La voie verticale ne peut être calculée uniquement via des senseurs
    inertiels : l’erreur est divergente. Il faut une observation externe
    pour recaler la mesure.
    &nbsp;
    &nbsp;


    Mithrill a écrit :

    A ce niveau là c’est de la faute professionnelle ni plus ni moins, l’ESA a fait de la merde faudrait qu’ils pensent à embaucher de véritables ingénieurs… une erreur digne d’un stagiaire faut pas déconner non plus.


    &nbsp;<img data-src=" />


    CryoGen a écrit :

    J’ai bien compris. Et justement, valeur absurde = valeur à éjecter. Eux même savaient que la sonde allait tournoyer, d’où la centrale inertielle pour fournir un coef de correction.
    Après coup, c’est facile oui. Mais si le crash se résume à une mauvaise prédiction + l’oubli d’un simple test, il y a de quoi discuter tout de même. Là on est pas en train de parler de contrôle au poil de cul : on parle de lancer un parachute puis de freiner à l’aide de fusée… on est assez loin d’un d’un atterrissage façon Space X niveau calcul.


    Justement, il n’y avait aucune valeur absurde dans ce qui est remonté par les capteur. Simplement, la valeur indiquée par le capteur ne correspondait pas à la valeur réelle.
    Je me rappelle que sur une centrale de nav aéronautique, on remontait un flag quand on détectait un capteur saturé, par contre impossible de me rappeler comment c’était géré ensuite.
    Mais bon la navigation inertielle est un domaine très pointu, et ce qui peut sembler simple vu de l’extérieur se révéle être un vrai casse-tête. En particulier quand on commence à se poser des questions du genre “que faire si…” <img data-src=" />



CryoGen Abonné
Le 29/11/2016 à 10h38






Charly32 a écrit :

Pourquoi il devraient s’interdire des valeurs négatives? Tu en trouve
déjà sur terre, et tout dépend de ta référence d’altitude zéro
également. Derrière ça, il y a un énorme taf de modélisation et de
construction de spec. Cf le commentaire de la news indiquant des valeurs pouvant descendre à -8km.
Même sur de la Centrale de Nav marine, les valeurs d’altitude négative (dans une certaine mesure et hors sous-marins ofc) ne sont pas un motif de panne.



La valeur est relevée par un radar par rapport au sol. Pas de valeur négative possible, la sonde n’a que le sol comme point de repère. Le but du jeu étant d’atterrir, on s’en fout de la “vrai” altitude: ce qui importe c’est la distance sonde-sol, et c’est cela qui était relevé. Et comme çà, ca prend en compte toutes les dérives possible de trajectoire sans pour autant avoir besoin de calculer (en plus du reste !) la position géographique sur Mars. Donc non, pas de valeur négative à gérer, ca ajouterai une complexité supplémentaire dont on peut parfaitement se passer.



Charly32 Abonné
Le 29/11/2016 à 10h43

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.


CryoGen Abonné
Le 29/11/2016 à 10h44






Charly32 a écrit :

Justement, il n’y avait aucune valeur absurde dans ce qui est remonté par les capteur. Simplement, la valeur indiquée par le capteur ne correspondait pas à la valeur réelle.



Alors attention: la valeur relevée n’est effectivement pas absurde (le capteur est saturé) mais le résultat est lui absurde.



Charly32 a écrit :

Je me rappelle que sur une centrale de nav aéronautique, on remontait un flag quand on détectait un capteur saturé, par contre impossible de me rappeler comment c’était géré ensuite.
Mais bon la navigation inertielle est un domaine très pointu, et ce qui peut sembler simple vu de l’extérieur se révéle être un vrai casse-tête. En particulier quand on commence à se poser des questions du genre “que faire si…” <img data-src=" />



Évidemment que c’est pointu, mais là il n’y a de navigation, juste un contrôle de distance… ce qui n’est pas si simple que çà on est bien d’accord, mais pas aussi compliqué d’écarté de mauvaises informations.



CryoGen Abonné
Le 29/11/2016 à 10h54

É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:




  • dans le cadre du test, voir s’il est possible d’envisager un futur atterrisseur capable de viser un point atterrissage, ce qui ne semble par être la cas ici

  • une erreur très bête de conception.


mHelba
Le 29/11/2016 à 11h20

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.


levhieu
Le 29/11/2016 à 13h25






Mithrill a écrit :

[…]
&nbsp;Certainement proche de certains ingé voire clairement supérieur en gestion de problématique informatique de l’ESA.
[…]


Moi il me manque le bagage technique pour comprendre cette phrase …



PCychologue
Le 29/11/2016 à 13h52

On aime faire rêver les esprits qui croient sans croire mais le tout virer hélas souvent au cauchemar…


Charly32 Abonné
Le 29/11/2016 à 13h55






Mithrill a écrit :

C’est sûr que rire comme un âne ne va pas faire avancer le schmilblick… si tu avais un tant soit peu connaissance des bons process en informatique tu ne débiterais pas cette connerie.


Ah mince t’étais vraiment sérieux en fait <img data-src=" /> &nbsp;



levhieu
Le 29/11/2016 à 14h23

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.


wagaf Abonné
Le 29/11/2016 à 15h08






Mithrill a écrit :

+1000 encore heureux que l’on ait droit de donner notre avis, surtout que pas mal d’entre nous ici ont un bagage technique assez élevé pour se permettre de donner leur avis. Certainement proche de certains ingé voire clairement supérieur en gestion de problématique informatique de l’ESA.

C’est sûr que rire comme un âne ne va pas faire avancer le schmilblick… si tu avais un tant soit peu connaissance des bons process en informatique tu ne débiterais pas cette connerie.


Ceux qui jugent les ingénieurs et scientifiques de l’ESA de manière pédante sur la base de ce soucis en disent surtout très long sur eux même.

Et ils ne démontrent pas vraiment leur supériorité en “gestion de problématique informatique de l’ESA” (lol)



tontonCD
Le 29/11/2016 à 15h17

c’est donc un “overflow” (dépassement de valeur), on ne dira jamais assez aux débutants de se méfier…


luxian Abonné
Le 29/11/2016 à 18h43






Charly32 a écrit :

Comment un parachutiste aveugle sait quand il doit ouvrir son parachute?


Quand y’a du mou dans la laisse du chien <img data-src=" />



<img data-src=" />

Et le chien, il s’appelle Paf …



philanthropos
Le 29/11/2016 à 19h00






CryoGen a écrit :

Oui vous avez raison, on ne peut pas avoir d’avis. D’ailleurs, puisque vous faites le parallèle avec la politique, j’imagine que vous ne votez pas car vous n’avez pas les bagages nécessaires (donc ici un doctorat en voyance j’imagine) ?

Et, pour rappel, les gens bossant à l’ESA ne sont pas des surhommes. Oui ils en ont clairement dans la caboche, il y a des génies parmi eux, mais ca ne veut pas dire qu’ils sont forcement meilleurs que tout le monde et que donc nos avis ne servent à rien…

Alors après oui, donnez son avis sur NXi et débattre (plus ou moins <img data-src=" />) avec d’autres gens n’est pas hyper constructif… mais surement bien plus intéressant que vos commentaires désabusés.



Nan nan nan.

Ne me fais pas dire ce que je n’ai pas dis, c’est pas top comme procédé dans un débat.

Je ne râle pas après les gens qui en discutent, au contraire, c’est un fils de discussion, c’est fait pour <img data-src=" />

Je m’insurge juste contre les experts auto-proclamés qui auraient trouvés la faille comme des grands avant même que quelqu’un la code, et ce en étant au petit dej’ avec les pieds sur la table tout en lisant du Kant ecrit en Hébreu d’une main et en rédigeant leurs mémoire de l’autre.

Bref, j’espère que tu as compris ce que je voulais dire par là.



Cashiderme
Le 29/11/2016 à 21h02

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.


lateo
Le 29/11/2016 à 22h05

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 ? <img data-src=" />


cyrano2 Abonné
Le 30/11/2016 à 13h36






jb07 a écrit :

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).


Dans l’aéronautique et dans le ferroviaire, on fait de la redondance avec du matériel différent. c’est le même principe que pour le RAID de disque dure, si une carte tombe, l’autre carte ayant eu la même “vie” a la très haute probabilité de tomber aussi.



cyrano2 Abonné
Le 30/11/2016 à 13h41






Alkatrazze a écrit :

&nbsp;

Si on voyait tout en simulation, il n’y aurait jamais d’accident.
Les simulations se basent sur ce qui s’est déjà passé et sur ce qu’il risque de se passer. Là, ils avaient estimé&nbsp;que les mouvements de nutation serait au maximum de 150°/seconde, donc ils avaient calibré le capteur pour qu’il aille jusqu’à 180°/s.
Manque de bol, ExoMars est arrivé aux taquets de 180°/s et en plus y est resté trop longtemps.

La prochaine fois, ils prendront ce paramètre en compte. Et manque de bol, au moment de l’atterrissage, il y aura un grand dragon vert qui se prendra la tête dans le parachute et ça personne&nbsp;ne l’avait prévu.

&nbsp;


Je parle de simulation physique. Genre je balance la représentation 3D de la sonde, et je simule l’air autour et tout le comportement. Vu qu’un essaie réelle n’est pas possible sur terre, autant le simuler complètement ici. Vu ce que tu décris on dirait des simulations au doigt mouillé et non l’usage d’environnement complet qui simule tout (mécanique, thermique, fluide, magnétisme,…).
&nbsp;&nbsp;D’ailleurs, la prochaine fois, il devrait prévoir 2 sondes. Si la 1er crash, il auraient le temps de patcher la deuxième :/



jb07 Abonné
Le 30/11/2016 à 18h30






cyrano2 a écrit :

Dans l’aéronautique et dans le ferroviaire, on fait de la redondance avec du matériel différent. c’est le même principe que pour le RAID de disque dure, si une carte tombe, l’autre carte ayant eu la même “vie” a la très haute probabilité de tomber aussi.



Oui, mais Ariane V, c’est de l’usage unique, donc hardware identique pour les deux centrales. Durée de vie max 6 heures.



OlivierJ Abonné
Le 02/12/2016 à 12h49






nox64 a écrit :

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


Tu plaisantes, car nos smartphones actuels ont la puissance des ordinateurs lambdas d’il y a 10 ans, environ. A titre d’indication, les processeurs pour Apollo 11 tournaient autour de 1 MHz.
&nbsp;


levhieu a écrit :

Et il y a plus de 50 ans, ça merdait grave aussi de temps en temps




seb2411 a écrit :

Car les ingénieurs voudraient sûrement avoir une sonde super pointue avec tous les tests possibles inimaginables. Les Scientifiques adoreraient lui coller toute sorte de capteurs et charge scientifique high-tech…


Pour info ci-dessus.



OlivierJ Abonné
Le 02/12/2016 à 12h55






Mithrill a écrit :

+1000 encore heureux que l’on ait droit de donner notre avis, surtout que pas mal d’entre nous ici ont un bagage technique assez élevé pour se permettre de donner leur avis. Certainement proche de certains ingé voire clairement supérieur en gestion de problématique informatique de l’ESA.



C'est sûr que rire comme un âne ne va pas faire avancer le schmilblick... si tu avais un tant soit peu connaissance des bons process en informatique tu ne débiterais pas cette connerie.




Non mais t’es sérieuse là ? En plus Charly32 a écrit un long commentaire autrement plus pertinent que le tien. haha “supérieur en gestion de problématique informatique de l’ESA”, ben voyons.
C’est sûr qu’à l’ESA les types sont demeurés et n’ont aucune expérience en programmation embarquée, ni aucune culture technico-historique sur ce qui a fait planter d’autres sondes par le passé.
&nbsp;

Charly32 a écrit :

Ah mince t’étais vraiment sérieux en fait <img data-src=" /> &nbsp;


On dirait…
&nbsp;


philanthropos a écrit :

Je m’insurge juste contre les experts auto-proclamés qui auraient trouvés la faille comme des grands avant même que quelqu’un la code, et ce en étant au petit dej’ avec les pieds sur la table tout en lisant du Kant ecrit en Hébreu d’une main et en rédigeant leurs mémoire de l’autre.


<img data-src=" /> <img data-src=" />



Commentaire_supprime
Le 02/12/2016 à 16h33






OlivierJ a écrit :

Tu plaisantes, car nos smartphones actuels ont la puissance des ordinateurs lambdas d’il y a 10 ans, environ. A titre d’indication, les processeurs pour Apollo 11 tournaient autour de 1 MHz.



Pour le bouquin que je suis en train d’écrire, j’ai fait un calcul récemment qui a mis le Robotron K 1840 (copie est-allemande d’un DEC VAX-11 de 1978 fabriqué dix ans plus tard) largement en-dessous d’un smartphone actuel à 100 € pièce.

Pour équivalence, un ARM 7 a quarante fois la puissance brute, en Mips, d’un DEC VAX-11…



OlivierJ Abonné
Le 02/12/2016 à 16h45






Commentaire_supprime a écrit :

Pour le bouquin que je suis en train d’écrire, j’ai fait un calcul récemment qui a mis le Robotron K 1840 (copie est-allemande d’un DEC VAX-11 de 1978 fabriqué dix ans plus tard) largement en-dessous d’un smartphone actuel à 100 € pièce.


Je parlais des ordinateurs embarqués (forcément moins puissants), mais vu qu’un ordinateur (du milieu) des années 90 est déjà plus puissant qu’un VAX de 1978, et qu’un mobile actuel est beaucoup plus puissant qu’un ordinateur des années 90, c’est pas difficile :-) . Note qu’en 1992 j’ai connu VAX VMS (#dino).



Commentaire_supprime a écrit :

Pour équivalence, un ARM 7 a quarante fois la puissance brute, en Mips, d’un DEC VAX-11…


Attention les MIPS ne veulent pas dire grand chose (déjà il y a 20 ans), surtout si on compare ceux d’un VAX et d’un processeur comme un ARM.
En terme de calcul numérique, il y a au moins un indicateur indiscutable, les FLOPS (et le multiple MFLOPS en particulier).



fred42 Abonné
Le 02/12/2016 à 17h35






Commentaire_supprime a écrit :

Pour équivalence, un ARM 7 a quarante fois la puissance brute, en Mips, d’un DEC VAX-11…



Pour info, le MIPS (uniformisé pour comparer des processeurs différents) avait pour unité de base un VAX-11780.


OlivierJ a écrit :

Note qu’en 1992 j’ai connu VAX VMS (#dino).


Espèce de petit jeune ! J’ai commencé sur VAX VMS en 1985 pour faire de l’embarqué (cross-compilation..)

En 1992, j’étais sur des VAX sous ULTRIX, le UNIX assez spécial de DIGITAL !



Commentaire_supprime
Le 02/12/2016 à 18h17






OlivierJ a écrit :

Je parlais des ordinateurs embarqués (forcément moins puissants), mais vu qu’un ordinateur (du milieu) des années 90 est déjà plus puissant qu’un VAX de 1978, et qu’un mobile actuel est beaucoup plus puissant qu’un ordinateur des années 90, c’est pas difficile :-) . Note qu’en 1992 j’ai connu VAX VMS (#dino).



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Attention les MIPS ne veulent pas dire grand chose (déjà il y a 20 ans), surtout si on compare ceux d’un VAX et d’un processeur comme un ARM.
En terme de calcul numérique, il y a au moins un indicateur indiscutable, les FLOPS (et le multiple MFLOPS en particulier).


Merci pour l’info, je note soigneusement. Je ne suis pas du métier, et toute info de la part de quelqu’un qui s’y connaît est la bienvenue.



Charly32 Abonné
Le 02/12/2016 à 20h26






jb07 a écrit :

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).


J’imagine que ce modèle (ou son évolution) est toujours présent sur Ariane 5.
En revanche pour Ariane 6, c’est Sagem Safran Electronic and Defense qui place sa SpaceNaute, contenant des GRH <img data-src=" />