[ExoMars 2016] Suivi de l'EDL de Schiaparelli et de l'insertion orbitale de TGO.

montmein69 a écrit:
C'est l'IMU qui n'a pas bien fonctionné* ... OK

C'est plus subtile que cela.
Dans le billet de l'ESA, ils parlent d'une saturation sur une des mesures pendant 1s.
Cette saturation peut-être due à une défaillance mais aussi à cause d'une grandeur physique réellement trop grande par rapport à ce que peut mesurer l'IMU, par exemple à cause du choc de l'ouverture du parachute ou un ballottement de la sonde trop important.

montmein69 a écrit:
sauf que je ne comprend pas comment cela marche.
C'est quoi dans cet engin, le "capteur" qui détecte une variation, et de quoi ?

L'IMU mesure des variations d'accélérations linéaire et en rotation sur plusieurs axes de l'espace grâce à plusieurs capteurs intégrés.

Je ne sais pas précisément quelles sont les technologies employé dans l'IMU de Schiparelli (plusieurs techno possibles). Plus d'info ici :https://fr.wikipedia.org/wiki/Centrale_%C3%A0_inertie

However, saturation -- maximum measurement -- of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rate of the vehicle.

Ce que je comprend c'est que la vitesse de rotation du véhicule sur lui-même (on ne sait pas suivant quel axe) à dépassé la capacité de mesure l'IMU.


Ça peut s'expliquer par une violente embardé du véhicule ou une défaillance du capteur en question (sachant que Schiaparelli embarquait 2 centrales inertielles).

montmein69 a écrit:
Quel rapport entre la rotation de l'engin et son altitude ?

Lors du début de l'entrée dans l'atmosphère martienne, on connaît la position est la vitesse de Schiparelli avec précision. Ces données sont chargées dans le calculateur de la sonde.
L'IMU mesure en permanence les accélération du véhicule, ce qui permet d'en déduire sa vitesse et sa position, et donc son altitude.
C'est le seul moyen de positionnement au début de la phase atmosphérique car le radar doppler est masqué par le bouclier avant et l’altimètre ne fonctionne qu'à faible altitude (si j'ai bien compris).
Ces données sont utilisées par le système de guidage et de navigation pour déclencher les différentes étapes de l'entrée atmosphérique et corriger la trajectoire si possible.

Donc il y a au moins un problème de traitement logiciel des données provenant de l'IMU. Problème qui donne une altitude évaluée négative.
Et éventuellement un problème côté IMU qui soit a défailli, soit est conçue comme trop limitée sur la mesure des accélérations en rotation.


Edit : L'article de France 24 avec l'interview de Thierry Blancquaert à l'AFP confirme que c'est un problème logiciel.

(je) commence à comprendre : c'est un ballottement de la sonde 
qui a tout perturbé : provoqué par l'ouverture du parachute ?
toujours est-il qu à ce moment le radar ne pouvait plus faire son travail  , et.....

Merci Jeep, pour tes compléments d'informations bien détaillées

Le logiciel n'avait effectivement pas été conçu pour anticiper et donc gérer un ballotement de si grande amplitude de l'atterrisseur sous son parachute. Et le logiciel a buggé.

Reste quelques années pour résoudre cela .... avec une collaboration étroite avec les russes qui gérent l'atterrisseur d'Exomars 2020.
Il faut y croire ... et en tout cas convaincre la ministérielle dans quelques jours :hot:

Correction suite aux remarques de Jeep sur la "rédaction"

montmein69 a écrit:

Le logiciel n'avait effectivement pas anticipé un ballotement de si grande amplitude de l'atterrisseur sous son parachute. Et le logiciel a buggé.

Reste quelques années pour résoudre cela .... avec une collaboration étroite avec les russes qui gérent l'atterrisseur d'Exomars 2020.

Ce sont surtout les ingénieurs chez Thales qui n'ont pas anticipé le ballottement je pense ;)

Vu de loin, le problème n'a pas l'air évident.
Sur Terre, les centrales inertielles accumulent aussi des erreurs au cours du temps. J'ai lu quelque part que pour un vol transatlantique par exemple, la dérive est de l'ordre de 50km pour une centrale inertielle de 747. Je ne sais pas si c'est vrai.
Mais ça ne pose pas de problème aujourd'hui car on peut recaler la centrale inertielle régulièrement grâce au GPS.

Sur Mars, pas de GPS.
Lors d'une descente nominale, je suppose que le temps de vol et la distance parcourue sont suffisamment courts pour que l'erreur accumulée (à cause de l’incertitude sur les mesures et de capteurs saturés pendant quelques millisecondes principalement), reste acceptable.

Par contre, dans le cas de Schiaparelli, une seconde avec un capteur saturé au lieu de quelque milliseconde veut dire une seconde pendant laquelle l'unité de guidage ne connaît pas l’accélération du véhicule sur l'axe de rotation concerné (donc ignore également la vitesse et la position associées). Impossible de savoir comment le véhicule s'est déplacé pendant cette seconde.
Du coup l'erreur devient énorme et pas moyen de se recaler.

Je me demande si MSL n'a pas évité ce genre de problème grâce à sa masse plus importante lui assurant une meilleur stabilité, à moins que ce ne soit de la chance...

Mais je ne doute pas qu'une solution sera rapidement trouvée. C'est plutôt le financement qui m'inquiète aujourd'hui.

A vous lire, cette affaire me laisse perplexe ! Je croyais que l'analyse de la descente en temps réel était un exercice ultra maîtrisé depuis 1973 ; et ben naôn  :down:

Astro-notes a écrit:A vous lire, cette affaire me laisse perplexe ! Je croyais que l'analyse de la descente en temps réel était un exercice ultra maîtrisé depuis 1973 ; et ben naôn  :down:

Les parachutes laissent toujours la possibilité à des surprises assez désagréables... J'y faisais allusion quand je parlais de coup de bélier plus haut, même si j'ai un peu détourné le sens de l’expression.

D'après ce que j'ai lu il y eu une impasse sur certains tests qui restent toujours indispensables même sur un système bien pensé.

J'ai lu quelque part que des journaux italiens avaient en effet, émis des doutes sur la qualité des simulations effectuées. Je rechercherai cela sans pour autant savoir si c'est justifié.

josé a écrit:(je) commence à comprendre : c'est un ballottement de la sonde 
qui a tout perturbé : provoqué par l'ouverture du parachute ?

oui provoqué par l'ouverture du parachute :

"La traction brutale du parachute et la décélération entrainent un fort mouvement d’oscillation du module. La centrale à inertie chargée de les mesurer sature le temps d’une seconde"

http://www.usinenouvelle.com/article/exomars-une-erreur-du-logiciel-de-navigation-en-cause-dans-le-crash-du-module-schiparelli.N468628

Je ne serai pas si affirmatif, puisque le parachute s'est ouvert vers 12 000 m, que Schiaparelli a pu descendre apparemment normalement jusqu'à environ 3700 m (altitude où a été donné l'ordre de largage du parachute et du bouclier).
D'un côté cette hypothèse que seule l'ouverture du parachute a joué, n'est pas impossible, mais cela suppose qu'entre le début de la descente sous parachute, et l'envoi des ordres "erronés" de largage, le calculateur a passé le temps à essayer de comprendre les données erratiques. :scratch:
D'un autre côté on peut aussi envisager que le balancement initial (acceptable à 12 000m) aurait pu se trouver amplifié par des perturbations atmosphériques à une altitude plus basse genre 5000 ou 4000 m ?????

Je ne sais pas s'ils pourront détailler cela ... avec les données qu'ils ont reçu.

La centrale à inertie chargée de les mesurer sature le temps d’une seconde. Le logiciel de navigation agrège la donnée erronée et calcule une altitude négative.


avouez que cela demande des éclaircissements et des explications.

il y a donc 2 problèmes :  parachute et centrale à inertie.

Oui, dit comme ça : enregistrer une altitude négative pendant que l'on est encore en vol, en pleine séquence parachute bouclier etc. ça me choque !

A n'en pas douter, c'est complexe.
Qu'un balancement soit provoqué par l'ouverture du parachute *, c'est probablement inévitable.

Le radar Doppler a lui pu entrer en fonctionnement (?) dès que  le bouclier thermique sous lequel il était masqué, a été largué (donc à 12 000 m)

As Schiaparelli descended under its parachute, its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system.

Le largage du parachute ayant été commandé à 3700 m .... le logiciel a-t'il toujours pris en compte pendant la descente sous parachute, les données du radar Doppler (qui étaient correctes) mais sans en tenir compte ? Donc pas de priorité entre radar Doppler et IMU pendant la durée de la descente 12 000m ---> 3 700 m ? Et à 3 700 m c'est l'IMU (donnant une valeur négative) qui l'emporte  :scratch:

Alors que si le logiciel bloque et ne peut prendre de décision (je pense à un robot d'Asimov ne pouvant satisfaire les lois et qui se tétanise) ... Schiaparelli aurait du finir son voyage en parachute jusqu'au sol ???

S'ils ont des éléments pour une analyse plus complète ... on aura peut-être des réponses plus tard.
C'est crucial pour ExoMars 2020.

*  Peut-être peut-on minimiser le phénomène en commençant par un parachute de plus petite taille (à très grande vitesse) suivi du grand parachute plus tard. Mais on peut supposer qu'ils ont pris cette décision à la conception (et en anticipant qu'il ne serait pas nécessaire de rajouter de la masse pour çà, au détriment d'autre chose) ????

Une IMU ne donne pas une altitude négative. Elle est un simple détecteur d'accélération et de rotation.
C'est le logiciel central qui trie les données IMU et les données radar et transforme le tout en altitude. Sachant qu'une IMU est (très) largement plus fiable qu'un radar Doppler, si les données radar et IMU entrent en contradiction il est normal qu'on croie davantage l'IMU que les radars. Et si une IMU tombe en carafe, même si le radar fonctionne bien il n'est pas possible d'atterrir. Sans IMU, point d'atterrissage possible.
Quant à avoir une altitude négative, il faut croire que le logiciel n'avait pas prévu ce cas pendant qu'il était encore sous parachute (avoir une altitude négative sous rétro-fusées peut être normal par contre). Auquel cas le logiciel de navigation avait un défaut et n'avait pas anticipé ce cas étrange. Mais pas sur qu'en restant sous parachute après avoir diagnostiqué une erreur IMU, la sonde eu pu survivre au crash. Elle allait bien trop vite sous parachute.

Space Opera a écrit:Une IMU ne donne pas une altitude négative. Elle est un simple détecteur d'accélération et de rotation.
C'est le logiciel central qui trie les données IMU et les données radar et transforme le tout en altitude. Sachant qu'une IMU est (très) largement plus fiable qu'un radar Doppler, si les données radar et IMU entrent en contradiction il est normal qu'on croie davantage l'IMU que les radars. Et si une IMU tombe en carafe, même si le radar fonctionne bien il n'est pas possible d'atterrir. Sans IMU, point d'atterrissage possible.

Pas tout à fait, surtout si l'IMU ne tombe en panne que dans la dernière phase de la descente.
Vous oubliez un capteur essentiel, qui s'appelle le chronomètre !
Si les données d'entrée sont connues avec précision, et sachant que dans le cas de Schiaparelli la descente était balistique donc
plus simple, il est possible de calculer l'altitude en fonction du temps. Les principales incertitudes proviennent de l'atmosphère.
Sans IMU et avec ces incertitudes, c'est compliqué, mais je pense qu'on peut raisonnablement espérer une ouverture du parachute
à une altitude proche de celle qui est attendue. Ensuite, on largue le bouclier. Ce qui est impossible, c'est d'être suffisamment
précis pour savoir quand larguer le parachute et allumer le moteur pour atterrir. Cependant, quand le bouclier est largué
le radar peut prendre la main ou un système de vision.

Oui Argyre, le chrono et la vitesse d'entrée dans l'atmosphère, plus la gravité martienne, on est pas en terrain inconnu pour faire de la balistique.

L'ASI accuse Arca Space, société roumaine qui était en charge des essais de l'EDL, de ne pas avoir conduit les essais comme il se devait.

http://www.romaniajournal.ro/esa-releases-preliminary-results-in-exomars-schiaparelli-crash-landing-after-italy-accused-romanian-corporation/

Arca Space rétorque que les essais devaient avoir lieu près de la frontière avec la Crimée, ce qui a généré des tensions.

Ici, on voit la petite fusée pour les essais d'ExoMars :

http://www.arcaspace.com/en/exomars.htm

Roscosmos publie un communiqué qui cite le DG de l'ESA disant que la partie russe n'a rien à se reprocher :

http://www.roscosmos.ru/22969/

nikolai39 a écrit:L'ASI accuse Arca Space, société roumaine qui était en charge des essais de l'EDL, de ne pas avoir conduit les essais comme il se devait.

http://www.romaniajournal.ro/esa-releases-preliminary-results-in-exomars-schiaparelli-crash-landing-after-italy-accused-romanian-corporation/

Arca Space rétorque que les essais devaient avoir lieu près de la frontière avec la Crimée, ce qui a généré des tensions.

Ici, on voit la petite fusée pour les essais d'ExoMars :

http://www.arcaspace.com/en/exomars.htm

Roscosmos publie un communiqué qui cite le DG de l'ESA disant que la partie russe n'a rien à se reprocher :

http://www.roscosmos.ru/22969/

Tellement pitoyable  :suspect:

On commence seulement à comprendre ce qu'il c'est passé et tous le monde se montre déjà du doigt en s'accusant !
A aucun moment Arca Space à t-il informé l'esa de l'impossibilité de réaliser ce "test" a la frontière de la Crimée ??
Personne à l'esa n'a vérifié que les test on bien été effectué ???, Et peut importe l'esa porte la responsabilité de l'ensemble du projet.
Je ne comprend même pas comment on en est arrivé à faire des test par une société roumaine (pour que chaque pays ai sa part industrielle ?)

Well a écrit:Je ne comprend même pas comment on en est arrivé à faire des test par une société roumaine (pour que chaque pays ai sa part industrielle ?)

La Roumanie étant l'un des Etats membres, je ne comprends pas ta remarque. :scratch:

Je me demandais pourquoi des tests critique étais confié à la Roumanie, qui n'a pas a ma connaissance une expertise réputé dans ce domaine.
Même si je le reconnais, ma réaction est maladroite puisque au final je me rend compte que je ne connais rien de leur compétence spatial et industriel.

Je me demandais si justement on ne leur avais pas confié pour partager la charge industrielle entre tous les état membres ?

Argyre a écrit:

Pas tout à fait, surtout si l'IMU ne tombe en panne que dans la dernière phase de la descente.
Vous oubliez un capteur essentiel, qui s'appelle le chronomètre !

Je me trompe peut-être, mais il me semble que les rétro-fusées sont asservies pour conserver la stabilités du véhicule et suivre la trajectoire prévue.
Dans ce cas, il est impossible de réaliser la phase propulsée de la descente sans centrale inertielle. A la moindre perturbation, le véhicule se retournerait et ensuite, c'est le crash assuré.

Il y a deux ou trois petites choses qui m'échappent dans les explications fournies: en synthèse, une mesure de vitesse de rotation erronée sur un axe conduit le logiciel GNC à s'imaginer sous terre si l'on peut dire. Bon. Soit. En général on n'utilise pas les mesures directement mais à travers un filtre de Kalman dont le boulot est justement, entre autre, de filtrer les mesures erronées. 1s d'erreur ne suffit pas en règle générale à envoyer un Kalman aux fraises, et de plus, si il est bien fait il indique quand l'estimée est un peu trop loin de ce que l'on attend. Par ailleurs, il est de bon ton avant de déclencher une manoeuvre décisive de vérifier la vraisemblance des mesures. En clair si mon GNC me dit que je suis à 1500m et la seconde d'après à -20m je peux déduire qu'il y a un bug ou une sacrée accélération que l'on aurait du voir sur les accéléromètres. Si ce n'est pas le cas, on réfléchit, c'est à dire qu'on passe sur la voie redondante et si c'est toujours incohérent on passe en boucle ouverte en mesurant le temps et en utilisant un modèle de la descente. Cela pose donc des questions sur l'architecture du soft. Par ailleurs les explications vaseuses du test non réalisé à cause de la proximité de la Crimée me font un peu sourire. A moins que le coin de Sebastopol n'ait une furieuse ressemblance avec Mars on ne voit pas bien en quoi il était absolument nécessaire de se trouver là pour tester. Par ailleurs il y a eu moultes revues d'essais conduites par le Maître d'Oeuvre et l'ESA pour s'apercevoir qu'un est avait foiré ou n'avait pas été fait. C'est d'ailleurs une partie du boulot du MO de s'assurer que les sous-contractants ne déconnent pas trop. Roumains ou pas. C'est ma deuxième question. Enfin, comme les dates de tir vers Mars ne sont pas changeables à volonté, n'y a t'il pas eu un peu de précipitation histoire de tenir la date de tir et espérer (je ne sais pas si c'est possible) recharger le soft du lander en vol si l'on trouvait des erreurs tardives (encore faut  il les cherche...). J'oubliais un détail, dans une phase non propulsée, une rotation pure change l'attitude du véhicule mais pas son altitude. J'ai donc plus d'interrogations que de réponses ;-)

Bons Vols.

Bonnes remarques DeepThroat, je plussois. Maintenant avec toutes vos réflexions et les dernières info je commence à me demander si cette affaire était bien sérieusement pensée, même si l'EDL n'était qu'un détail de la mission Exomars 2016. En tous cas je me souviens du petit ton méprisant de l'ESA lors du crash du petit lander britannique, regardez où nous en sommes tant d'années après. Voilà pourquoi il faut rester modeste dans sa posture et mesuré dans ses propos. Bonne leçon.

Astro-notes a écrit:Bonnes remarques DeepThroat, je plussois. Maintenant avec toutes vos réflexions et les dernières info je commence à me demander si cette affaire était bien sérieusement pensée, même si l'EDL n'était qu'un détail de la mission Exomars 2016. En tous cas je me souviens du petit ton méprisant de l'ESA lors du crash du petit lander britannique, regardez où nous en sommes tant d'années après. Voilà pourquoi il faut rester modeste dans sa posture et mesuré dans ses propos. Bonne leçon.

Espérons que cela va nous IMUniser pour ExoMars 2020 ! Bon, d'accord, c'est nul et  :iout:

DeepThroat a écrit:
En général on n'utilise pas les mesures directement mais à travers un filtre de Kalman dont le boulot est justement, entre autre, de filtrer les mesures erronées. 1s d'erreur ne suffit pas en règle générale à envoyer un Kalman aux fraises, et de plus, si il est bien fait il indique quand l'estimée est un peu trop loin de ce que l'on attend. Par ailleurs, il est de bon ton avant de déclencher une manoeuvre décisive de vérifier la vraisemblance des mesures.

Un algorithme de filtrage type kalman ou autre permet de réduire l'influence du bruit et de gérer les incertitudes. Mais en cas de saturation d'un capteur, ce n'est plus un problème de bruit, c'est toute une partie de l'information qui disparaît.
Une seconde de saturation provoque l'accumulation d'une erreur beaucoup plus importante que quelques millisecondes.

DeepThroat a écrit:
En clair si mon GNC me dit que je suis à 1500m et la seconde d'après à -20m je peux déduire qu'il y a un bug ou une sacrée accélération que l'on aurait du voir sur les accéléromètres. Si ce n'est pas le cas, on réfléchit, c'est à dire qu'on passe sur la voie redondante et si c'est toujours incohérent on passe en boucle ouverte en mesurant le temps et en utilisant un modèle de la descente. Cela pose donc des questions sur l'architecture du soft.

Avec les gyroscopes saturés, je ne vois pas bien à quelle redondance on pourrait se fier.
Le problème est vraiment dans la prise en compte de cette saturation dans le logiciel, il n'a jamais été prévu de traiter une saturation aussi longue.

DeepThroat a écrit:
Par ailleurs les explications vaseuses du test non réalisé à cause de la proximité de la Crimée me font un peu sourire. A moins que le coin de Sebastopol n'ait une furieuse ressemblance avec Mars on ne voit pas bien en quoi il était absolument nécessaire de se trouver là pour tester.

La ressemblance avec Mars n'est certainement pas le critère de choix. Par contre l’existence et la disponibilité au bon moment d'installations de tests spécifiques peuvent expliquer qu'il n'y avait pas beaucoup d'autres choix.