informatique et high-tech (les meilleures news) %) - Page 1000

Je vais transmettre ça à mes collègues qui font de l'AOCS tiens
Ce qui est étrange, c'est que normalement ce genre de cas devrait être identifié lors de l'analyse FME(C)A et géré en FDIR. Le blocage d'un appareil de mesure en mode saturation fait typiquement partie des erreurs classiques que l'on simule. Peut-être même que cette erreur a été identifiée et que le comportement observé est celui qui avait été prévu...

Je pense que la phrase-clé est là :

squalyl (./29963) :
Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.

J'en comprends que le cas était prévu, mais qu'ils ne s'attendaient pas à ce que la défaillance soit si longue. Il est facile d'éliminer une ou quelques valeurs aberrantes isolées, mais savoir quoi faire quand il y a un "saut" mais que la nouvelle mesure est persistante est plus difficile :
- il y a pu avoir un brusque changement réel de la valeur à mesurer
- ça peut être le capteur qui est tombé en panne
- ça peut être au contraire un capteur qui déconnait et qui s'est remis à fonctionner correctement

Ca reste difficilement compréhensible car ils n'en sont pas à leur premier amarsissage.

Quand tu as une recette qui fonctionne, tu n'en change pas les ingrédients à chaque service.

Sauf modification majeure d'architecture (Ariane 4 to Ariane 5).

Et puis des enregistrements à rejouer, ils devaient aussi déjà en disposer.

Tron (./29974) :
Sauf modification majeure d'architecture (Ariane 4 to Ariane 5).

Non, là non plus, il n'avaient pas tout changé

Et en plus si, l'Europe est assez newb en amarsissage.

Zero> oui peut être, mais quand même c'est louche comme comportement par défaut. Et ça montre aussi que les estimation de l'enveloppe maximale de vitesse de rotation a été sous-estimée, ce qui est aussi inquiétant. Mais au moins toutes ces informations sont intégrables dans la future mission.

Ah mais je dis pas que c'était pas une boulette, hein ^^

ce qui me gêne c'est en effet la situation et je réalise qu'il y a deux cas:

-soit ils ont bêtement injecté la télémetrie recue et ca confirme le crash AVEC CES MESURES, mais de base le crash était pas prévisible;

-soit ils ont rejoué la simu du début et celle ci a prédit les mesures qui ont produit le crash. la c'est grave parce que la simu a totalement prévu le crash, et ils l'ont potentiellement pas vu

mais effectivement c'est pas précis.

Je pense qu'ils ont injecté les télémétries pour voir la réaction du logiciel de contrôle.

C'est quand même dommage qu'ils n'aient pas pensé à me demander mon avis

(Nan mais sérieusement, c'est comme quand mon GPS, alors que je suis sur une autoroute sans sortie depuis 100km, décide de me faire sauter sur la route d'à côté à cause d'un manque de précision... Je trouve qu'l manque quand même une ou deux vérifications basiques... )

(en tant qu'oiseau, tu n'as de toute façon pas besoin de GPS )

(Nan bien sûr, mais il y a les zones de... hum, les zones de dangers )

(et ton instinct, alors ?)

(ouais mais les léopards automatiques placés pour faire du chiffre, c'est traître )

()

(ztk )

Pourquoi ne pas s'entrainer à faire des aterrissages avant les amarsissages ? Quelle différence pour les systèmes de mesure ? Il n'y a pas que la chimie de l'atmosphère et la pesanteur qui changent ? C'est une question de coût démesuré par rapport aux simulations ?

les deux choses qui changent que tu mentionnes sont déja suffisamment différentes pour produire des résultats non reproductibles.

Déja la densité de l'arm martienne est largement plus faible que sur terre, donc ca freine moins, et en plus sa composition est très différente, donc on a pas les mêmes réactions chimiques a l'échauffement, qui arrive donc différemment, avec une dynamique différente.

Apparemment la le comportement saturé était prévu, mais ca a duré plus longtemps que prévu.

Ok, donc c'est simulation puis essais à balles réelles. Effectivement, ça fait cher de la prévision pas tout à fait parfaite

Oué, mon bout de code est brillant, mais quand même moins coûteux que leur crash.

Mais comme disait Zerosquare, il y a un moment où tu peut légitimement te demander si tu dois utiliser la dernière valeur valide de ta mesure, une valeur par défaut ou ignorer le tout... Et quand tu tombes à 3km/s t'as intérêt à ne pas te tromper de diagnostique

Oui mais passer d'une altitude à 7km quand tout est nominal à une altitude négative à la prochaine mesure, personnellement je pense que je ferai confiance à une estimation de l'altitude de 7km-epsilon
Bon, évidemment c'est sans doute un peu plus compliqué que ça, mais quand on lit l'article...

Il n'y a pas un contrôle de cohérence entre deux mesures, permettant de valider la nouvelle ? J'imagine que si ?

A moins que j'aie raté quelque chose et qu'il soit précisément question de ça

J'en discutais tout à l'heure avec un expert AOCS de l'ESA (mais pas de la même équipe), et il était d'accord pour dire qu'il y a eu gros foirage (il a aussi regretté que le crash de cet amarsisseur, qui n'était qu'un côté "bonus" d'exomars prenne plus de place dans les médias que la mission réelle qui se passe, elle, plutôt bien).

Folco (./29994) :
J'imagine que si ?

Je ne sais pas, mais vu l'article ça n'a pas l'air super évident

cross/Ximoon > j'espère que tu as pensé à lui parler des experts de yN !?

Ximoon (./29995) :
(il a aussi regretté que le crash de cet amarsisseur, qui n'était qu'un côté "bonus" d'exomars prenne plus de place dans les médias que la mission réelle qui se passe, elle, plutôt bien)

Ah OK, intéressant à savoir

()

High-tech: quelqu'un me demande de lui expliquer comment réaliser un satellite à ballon. Je suis confus.

J'ai bien une idee, mais Nhut serait plus a meme de t'aider!

J'ai pas dit en carton

edit