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

Le 28/11/2016 à 16h59

Alkatrazze a écrit :

   
Pour juger de la qualité du soft, je suppose que&nbsp;vous avez eu accès au code source ?     
  
Non, c'est saturation du capteur (ce qui n'était pas prévu) une seconde de trop.     
 

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  il avait calculer en pieds  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.

 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 

 

CryoGen

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… " />

Ricard

Le 28/11/2016 à 18h21

madoxav a écrit :

ce comportement en réponse aux fausses informations récupérées par l’ordinateur de bord a été « clairement reproduit dans des simulations informatiques »

 

 C’est con, ça veut dire que ça aurait pu être anticipé.

Edit : p*tain de quotes :o

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

" />Bravo les ingés de la Nasa.

Obidoub

Le 28/11/2016 à 18h24

Ricard a écrit :

" />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." />

OlivierJ Abonné

Le 28/11/2016 à 19h04

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.

 

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

" />

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 " />, 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…

" />

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.

" />

Et en plus les commentaires qui ont suivi le tien en ont remis une couche, fascinant… Rien que ceux-ci :

" />

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 ><’

 

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 :

 

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

 

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 :

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.

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?

" />

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) -> 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 " />

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

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 " />

[

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

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 " />) 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

 

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

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.

" /> 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

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 " />, 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

 

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 " />

Moi une fois j’ai planté pendant des des heures tout un site, ça sortait un ERR 500 server internal error, à cause d’un emberlificotement de guillemets. Des plombes pour trouver. Oui je sais faut pas modifier le code direct en SSH d’un site en prod… " />

Je donne la source pour ceux qui pensent qu’on n’y connait rien :

Wikipedia

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 " />, 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…" />

coket

Le 28/11/2016 à 15h14

Ben faudra mettre un pilote dans le prochain " />

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

 

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 !

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

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 " />

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.

" />

Furanku Abonné

Le 28/11/2016 à 13h26

S’ils arrêtaient de foutre des processeurs de 200Mhz dans leur missions aussi " />

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 en réponse aux fausses informations récupérées par l’ordinateur de bord a été « clairement reproduit dans des simulations informatiques »

 

 C’est con, ça veut dire que ça aurait pu être anticipé.

Edit : p*tain de quotes :o

cyrano2

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é

 

cyrano2

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 " />

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

cyrano2

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. 

cyrano2

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

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

 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.

 

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 ><‘

Texas Ranger

Le 28/11/2016 à 15h34

ginuis a écrit :

Voilà ce qu’il se passe quand on fait des referendum " />

" />

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

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…

 

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

 

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.

 

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

 

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…" />

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 ? 

CryoGen

Le 28/11/2016 à 16h00

kerrubin a écrit :

WikipediaSur 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…" />

 

Et si le logiciel avait estimé que la sonde était à une altitude positive de +10m voire même +100m au dessus du sol au lieu d’une altitude négative, cela n’aurait strictement rien changé : il aurait considéré que le sol é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 exactement de la même manière.

  

CryoGen

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

Là par exemple

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

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.

 

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 ><’

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.

 

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  il avait calculer en pieds  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).  Les calculs saturent la mémoire, le calculateur du pilote automatique se coupe, et la fusée par en couille. Ca te convient mieux ? " />

 

CryoGen

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

Le 29/11/2016 à 10h27

CryoGen a écrit :

Pas des experts NASA " />, 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…" />

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  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 ? 

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. 

 

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.

" /> 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 " />

 

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

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

 

 

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.

 " />

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…” " />

CryoGen

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

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

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…” " />

É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

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 :

[…]

 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…

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

" />" />" />" />" />

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

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 " />

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. " />

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? " />

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

 

JMGuillaume

Le 28/11/2016 à 14h00

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.

 

Ouais ben la station météo, faudra d’abord la faire atterrir sur mars, et c’est pas vraiment gagné au vu du dernier essai  " />

JohnCaffey

Le 28/11/2016 à 14h01

Pfff… Avec Howard Wolowitz ça ne serait jamais arrivé… " />

Ellierys

Le 28/11/2016 à 14h01

“Ça passait sur KSP” " />

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…

 

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é 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 ne l’avait prévu.

 

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!

 

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? " /> 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." />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  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

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” " />

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

La sonde avait un radar altimètre Doppler, source : Wikipedia

Charly32

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 " />  

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 " />

" />

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 " />) 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 " />

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 ? " />

cyrano2

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

Le 30/11/2016 à 13h41

Alkatrazze a écrit :

 

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é 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 ne l’avait prévu.

 

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

  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.

 

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

 

Charly32 a écrit :

Ah mince t’étais vraiment sérieux en fait " />  

On dirait…

 

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.

" /> " />

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-¹¹⁄₇₈₀.

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 !

Catégories

Nous Suivre

À propos

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

Ça fait beaucoup comme marge d'erreur

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 ?

Commentaires (129)