Aggiornamenti su Schiaparelli: individuata la causa dell’incidente

In pratica la imu buonmiele aveva dichiarato nel datasheet che in caso di saturazione a 180 gradi sarebbe rimasta bloccata su quel valore per un secondo, ma nelle millemila simulazioni fatte a terra la condizione 180 non si era mai verificata e quindi il software non aveva previsto il dato 180 non reale per un continuo di 1 secondo 180+180+180 etc etc ha sballato tutti i dati…
Noto questo comportamento della IMU e quindi ora facilmente aggirabile via software si è quindi deciso, per la prossima missione, di usare una IMU di un altro fornitore per trovare nuovi glitch di funzionamento e debuggare anche questa… :badmood:

pazzesco… e buonmiele mi ha fatto morire :censored:

come previsto si è trattato soprattutto di un baco software.
beh…possono sistemarlo ottimamente anche lavorando sul divano di casa loro e facendo tutti i test del caso.

il problema della IMU invece è più specifico e probabilmente andrà verificato con test sperimentali approfonditi e tempi lunghi.

Ma per prima cosa che sistemino il software! E’ sempre colpa dei programmatori, alla fine… :agree:

Sicuramente il software va rivisto ma anche le simulazioni -_-
Si fanno apposta per vedere che succede in condizioni non nominali e se in tutte le simulazioni non hanno mai avuto valori “errati” dalla IMU vuol dire che non ne hanno fatte abbastanza vuoi per mancanza di fondi o vuoi proprio perchè non pensavano potesse succedere.

Forse non si fidano più del fornitore?

Il software non sbaglia mai fa esattamente quello che gli è stato detto di fare (Cit. Hoffman)
Qui più che dei programmatori io direi che la “colpa” è di chi ha scritto le specifiche e di chi ha scritto\eseguito i test e simulazioni varie
Il tutto IMHHHO ovviamente :slight_smile:

Poi bisognerebbe sapere esattamente come è andata, col senno di poi siamo bravi tutti.

io ho provato a scriverlo come è andata…
nelle simulazioni non si è mai andati oltre i 180 gradi e quindi non serviva considerare quel caso, poi qualcosa è andato storto e si sono raggiunti.
Nel datasheet era correttamente indicato questo problema del lock di 180 per un secondo, ma non è stato gestito per i motivi sopra detti…
Mi immagino la scena negli scorsi giorni del tizio che con i dati di 180 gradi raggiunti in mano sfoglia le decine di pagine di datasheet ed arrivato alla pagina in cui si spiega il lock esclama con calma “perdindirindina cosa non abbiamo considerato” :stuck_out_tongue_winking_eye:
Trovo comunque assurdo cambiare IMU ora che si saprebbe come gestirla… ma visto che cambia anche chi costruirà l’elettronica… cercheranno un fornitore di IMU francese invece che americano… :rage:

Allora non ho capito :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye:
Provo a ricapitolare:
Alla prima lettura avevo capito che

  • Fornitore dice che il valore MAX è 180 e che se si raggiunge quel valore questo rimane bloccato per 1 sec
  • Simulazioni con valore 180 non eseguite
  • Situazione reale valore raggiunto 180°
  • Crash :stuck_out_tongue_winking_eye:

Invece era:

  • Fornitore dice che il valore MAX è 180 e che se si raggiunge quel valore questo rimane bloccato per 1 sec
  • Simulazioni con valore 180 — > tutto ok
  • Situazione reale valore raggiunto >180°
    -Crash

Stai dicendo questo?

*****edit *******
leggendo l’articolo orginale dire che è successo questo:
-Fornitore dice che il valore MAX è 180 e che se si raggiunge quel valore questo rimane bloccato per 1 sec

  • Simulazioni con valore 180 non eseguite
  • Situazione reale valore raggiunto 180° per + di un secondo <— situazione non gestita
  • Crash :stuck_out_tongue_winking_eye:

ehm isa, avevi capito al primo giro…

buonmiele dice che a 180 locka per un secondo, ma nessuno l’ha mai letto perchè non si pensa di arrivarci secondo le simulazioni, quindi la cosa non è nota e non viene gestita dal software in quanto comunque, sempre secondo le simulazioni, questo non può accadere.

lanciano e crash…

indagine: cosa è andato storto?

siamo andati a oltre 180 gradi! ma non era previsto! eppure è successo… ok vediamo che dice il manuale della imu se andiamo oltre i 180: oh perdindirindina, va in lock per 1 secondo… ecco cosa è successo…

ciau…

comunque solo lo zio ha colto la mia battuta, sigh sono troppo ermetico mi sa… :flushed:

Ok, ma chi ha scelto la IMU buonmiele era a conoscenza del limite ma lo ha considerato non raggiungibile nel profilo di volo oppure non si conoscevano proprio le specifiche di quella IMU? Stessa cosa per chi lo ha testato, il profilo di test per la certificazione prevedeva il superamento di tale valore o le specifiche date al fornitore della simulazione prevedevano solo profili più “tranquilli”?
Oppure ancora, buonmiele con quella IMU rispondeva ai requisiti del cliente?

Ci siamo scritti uno sull’altro :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye:
:agree: :agree:

Se avevo capito alla prima :nerd: :nerd: :nerd: è ancora più “colpa” di chi ha scritto le specifiche :rtfm: :rtfm: :rtfm: :rtfm:
Per quanto riguarda la battuta dici :

?
:stuck_out_tongue_winking_eye:

E simulazioni a parte se ho una variabile nel mio codice che può assumere un certo valore che non la provo? :badmood: :badmood: :skull: :skull:

Da quanto ho capito non erano a conoscenza del limite o comunque non avevano dato peso all’informazione, ma il limite era correttamente indicato nel DataSheet, e comunque lo hanno considerato non raggiungibile nel profilo di volo, cosa che però è avvenuta in disaccordo con tutte le simulazioni fatte. Il test non ne prevedeva il superamente perchè il profilo di volo non lo prevedeva, senno se ne sarebbero accorti durante i test…
per i requisiti cliente non ne ho invece idea, le mie info ricevute davanti ad una birra si sono fermate a ciò che vi ho scritto…

resta da capire perchè il profilo di volo non prevedeva una situazione come quella che poi si è in effetti verificata…
durante la discesa, dove c’è stata la deviazione da quanto ci si attendeva? cosa l’ha causata?

Ma non lo sai, può darsi, come dice Albyz, che la IMU rispondesse alla specifica, e il SW pure. Insomma, senza avere sottomano tutta la documentazione e tutta la storia non se ne esce. Direi che è un classico, purtroppo; ognuno nel suo cubicolo e si perde la visione d’insieme.

Forse perché pensavano che, se la IMU avesse fornito quei valori, non sarebbe stato in ogni caso possibile recuperare l’assetto vista la disposizione e le caratteristiche dei thruster.

Si ovviamente non sappiamo tutto… potrebbe anche essere che l’IMU non ha funzionato come previsto perchè qualcuno non aveva tolto un “remove before flight” :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye:
ma visto che quel valore era indicato nei datasheet, confessa, tu l’avresti provato :wink:

Isa, forse sì. E bisogna vedere come e dove era indicato. Dall’alto di tanti anni di esperienza posso solo dire che nei data sheet bisogna sempre cercare il dato non dichiarato, perchè lì è l’inghippo. Bisogna conoscere la materia almeno bene quanto il costruttore, e scavare nei dati… a volte punteggiatura, zeri e errori di stampa sono significativi, altre volte le semplici omissioni. Non sto dicendo che buonmiele ometta dati, eh. Solo che ho visto tanti casi di dati mancanti, contrastanti o erronei nelle specifiche dei prodotti.

Ma, IMHO, se IMU e SW rispondevano alle specifiche e questo limite dei 180 era riportato nei Datasheet perché non lo gestisco? non ne avevo dato peso? non si doveva verificare? Ma scherziamo!!
Io lavoro indirettamente con impianti a PLC e se non gestisci una probabile situazione nella migliore delle ipotesi ti si blocca tutto altrimenti assisti a delle belle collisioni tra gruppi, solo che qui posso tranquillamente capire cosa manca per andare avanti ma su Marte non posso mica aspettare la grazia divina devo prevedere quasi l’impossibile.
Scusate lo sfogo ma non concepisco una cosa del genere.

Io non ho capito perché cambiare la IMU, che ha fornito valori corretti.

per poter dare la colpa al fornitore