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

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.

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