Missione ER-004

Tento sempre di prendemi qualche contratto extra

Comunque si parlava di brutto colpo per la SpaceX se fosse andato male il lancio di Dargon, dopo i problemi avuti, alla fine tutto quello che è stato detto è stato riflesso verso Eridanus
Brutto brutto colpo per Eridanus.

Certo che questa emergenza ha scatenato un bel vespaio ...

Sono andato a leggere il doc della versione 1.1 (l'ultima su Orbit Hangar) e non c'è nessuna indicazione riguardo al tempo entro il quale si devono aprire i pannelli solari, o comunque quale è l'autonomia senza pannelli solari.
Ma d'altronde mi sembra che i pannelli solari contribuiscano ad aumentare l'autonomia e basta, non che siano indispensabili (come su Antares).

Fausto ha scritto:

Ora la conseguenza più ovvia mi pare l'annullamento della missione ER-005 destinata a Gaia e l'utilizzo di questa per una "return to flight", magari a giugno.

A questo punto si apre un duplice scenario per il "return to flight": se dobbiamo testare solo il razzo con il sistema di autospegnimento, Eridanus non è necessario visto che il problema di ieri non è imputabile allo spazioplano. Quindi si può fare un semplice lancio del Quasar, magari in configurazione "E" ma con un boilerplate al posto di Eridanus.

Se invece intendiamo testare di nuovo un volo intero anche alla luce dell'autoFCS, è necessaria una missione con lo spazioplano, ma chiaramente senza equipaggio.

Dopo 30 minuti dal mancato dispiegamento si accende un allarme, e se i pannelli rimangono chiusi Eridanus diventa ingovernabile. Quindi è da escludere una chiusura prima della derobit burn.

Una missione per far rientrare il Quasar è sconsigliabile per me.. non è progettato per ricevere il servizio di un mule ed è completamente fuori assetto. Quando rientrerà o farà da sola!

Sto seguendo il replay ora... effettivamente il "return to Flight" sarebbe da fare senza Eridanus, per il motivo detto da Andrew, a soprattutto, se si dovesse ripresentare il problema?

Per il recupero del Quasar non avevo pensato al fatto che al momento fosse in rotazione, diventa troppo impossibile.

Io invece dico RTF ma anche con Eridanus.. il sistema è da testare nel suo insieme secondo me

Ho finito il Replay, un vero peccato per la conclusione. Questo ha dimostrato che nulla è veramente routine nei voli spaziali... neppure quelli simulati!!

Fausto ha scritto:

Dopo 30 minuti dal mancato dispiegamento si accende un allarme, e se i pannelli rimangono chiusi Eridanus diventa ingovernabile. Quindi è da escludere una chiusura prima della derobit burn.

Perché no? basta farlo poco prima dell'accensione. Penso che sul realismo sia un punto importante.

L'accensione va fatta agli antipodi del punto di atterraggio, quindi a quel punto c'è ancora una mezza orbita da compiere; ciò significa che dopo l'accensione devono passare almeno 40 o 50 minuti prima di toccare terra. Poi oh, naturalmente basta correggere l'impostazione nella dll in modo da coprire questo lasso di tempo, ma allo stato attuale della stessa, la procedura non è modificabile...

C'è comunque da considerare una cosa: il retroburn è tipicamente di soli 50 m/sec, non è una accensione "importante" per le riserve di carburante e i motori di cui dispone Eridanus. Se si dovessero verificare problemi subito dopo il retroburn, è relativamente facile fare una nuova accensione prograda e riportare su l'orbita.

[quote="fred1]Perché no? basta farlo poco prima dell'accensione. Penso che sul realismo sia un punto importante.[/quote]
Perché il tempo di rientro (tra il deorbit burn e l'atterraggio) é di gran lunga superiore ai 30 minuti. Quindi o si mantiene la procedura attuale o si modifica (aumenta) l'autonomia di Eridanus senza pannelli solari. Non vedo altre soluzioni

Fausto ha scritto:

Io invece dico RTF ma anche con Eridanus.. il sistema è da testare nel suo insieme secondo me

Una cosa interessante sarebbe: replicare il problema. E cioè: provare il tutto e quindi l'autospegnimento eccetera, ma impostare volutamente un apogeo di 1200 km e in seguito, provare a recuperare la missione raggiungendo comunque la ISS. Sarebbe un bel test delle capacità di Eridanus. Certo ci sarebbe un margine di rischio di perdita dello spazioplano...

Scusate credevo che Eridanus avesse una APU per il rientro. Le superfici mobili tipo coda, alettoni etc. di solito sono mosse da circuiti idraulici che necessitano di una fonte di potenza con spunto molto maggiore delle batterie, ma non conosco Eridanus nel dettaglio, sorry

Mi sono guardato il video del rientro: peccato per il crash della simulazione, però se può consolare, ha evitato un altro crash ben più drammatico e cioé quello di Eridanus
Ho controllato attentamente i parametri di Eridanus dopo il sorvolo di Edwards: lo spazioplano ha continuato la sua discesa per diverse miglia con rotta est, allontanandosi troppo dal sito di atterraggio. Al momento del crash della simulazione Eridanus era di gran lunga troppo basso di quota e di velocità per poter virare verso Edwards e raggiungere qualsiasi pista; data la quota e la velocità in quel momento Eridanus avrebbe dovuto trovarsi sul HAC, grosso modo a 180° dall'allineamento con las pista (quindi appena prima della virata base): quello che probabilmente sarebbe successo se la simulazione fosse continuata (mi è capitato molte volte testando AutoFCS) è che il sistema di autoguida avrebbe cercato di mantenere il profilo di discesa a discapito della velocità con conseguente stallo e perdita di controllo: Eridanus si sarebbe schiantato diverse miglia a est di Edwards
Unica cosa da fare in un caso del genere è disinserire l'autopilota appena ci si accorge che non sta performando secondo i parametri nominali ed effettuare avvicinamento e atterraggio in manuale (in questo l'uso di GPC MFD aiuta tantissimo, OPS3 e OPS4 sono utilizzabili su qualunque nave e quindi anche Eridanus...)
Sia chiaro che questa non è in alcun modo una critica a Fausto che ha fatto di tutto per "salvare" la missione e al quale faccio comunque i complimenti

Comunque buone notizie: Ho ricontrollato i parametri di AutoFCS e credo di averlo reso più stabile. Ho tentato un rientro completo sia ad Edwars che a Capo passero a velocità di simulazione 10x, sottoponendo quindi il PC a uno stress simile a quando è attivo livestream ed in entrambi i casi la manovra è stata perfetta. In ogni caso stasera farò una diretta non commentata in cui ripartirò con lo scenario di ieri da un'altezza di 150 km circa. Sono fiducioso che questa volta andrà bene, almeno spero.. se così fosse avremo finalmente un profilo di rientro affidabile per le prossime missioni

La diretta (ripeto non commentata) inizia stasera alle 09:15

Poi rivolgerò le attenzioni al modulo di spegnimento del Quasar

Fausto ha scritto:

...

La diretta (ripeto non commentata) inizia stasera alle 09:15

...

21:15 in orario non secondo i canoni americani ...
Se la moglie non mi reclama me la guardo in diretta, altrimenti in registrata.

Bene! in bocca al lupo per stasera
PS una domanda che volevo farti già ieri: come mai non usi AutoFCS anche per il deorbit burn? E' per via del perigeo "anomalo" da ottenere per Eridanus?

Perchè stranamente Autofcs non riconosce i motori principali di Eridanus, dunque non accende nulla

Mhh.. strano perché a me non da problemi: effettua orientamento e accensione in maniera corretta (con perigeo standard di 59Km)...

wolf ha scritto:

Mhh.. strano perché a me non da problemi: effettua orientamento e accensione in maniera corretta (con perigeo standard di 59Km)...

Ma con Eridanus o con lo Shuttle?

Con Eridanus!
AutoFCS non ha problemi a riconoscere i motori e ad effettuare l'accensione e lo spegnimento correttamente. L'unico problema è che poi durante il rientro non riesce a smaltire la velocità e resta un pelo alto sul profilo di discesa overshoottando la base di atterraggio (peggio di quanto è successo a voi ieri) ma credo che questo sia appunto il motivo per cui Fausto ha aggiornato i parametri aerodinamici di Eridanus e i settaggi di AutoFCS.
Potrebbe essere che le modifiche apportate creino problemi per l'accensione motori al momento del deorbit.
A questo proposito sarebbe interessante sapere se almeno AutoFCS riesce a comandare l'accensione degli RCS per ottenere l'assetto voluto prima del deorbit.
Fausto se vuoi posso provare a vedere cosa succede sulla mia installazione a modifiche effettuate (se vuoi mandarmi i file modificati)
PS domanda a proposito di ausili per il rientro: se ho letto bene sul manuale per estrarre gli aerofreni bisogna premere CTRL+B però quando provo a farlo non succede nulla.. per lo meno a livello visivo gli aerofreni restano chiusi e non mi pare comunque di notare alcun effetto sulle prestazioni (rateo do discesa e decelerazione restano invariati..)

wolf ha scritto:

...se ho letto bene sul manuale per estrarre gli aerofreni bisogna premere CTRL+B però quando provo a farlo non succede nulla.. per lo meno a livello visivo gli aerofreni restano chiusi e non mi pare comunque di notare alcun effetto sulle prestazioni...

Gli arofreni (almeno il comando standard di Orbiter) si aprono con la "B".

Wolf, stasera ti passo iil pacchetto, ma non funziona senza le modifiche della dll di Eridanus.. sarebbe meglio aspettare fino a quando non rilascerò la nuova versione entro la fine della settimana.

Gli aerofreni si attivano con CTRL-B ma solo dopo il touchdown!

ma alla fine come siamo rimasti con l'atterraggio di emergenza alla base di Edwards???
Ci sarà un'altra diretta a breve???
Poi volevo fare una domanda che riguarda gli abort Quasar-Eridanus durante il lancio:

Abort on Launchpad: Quando all'accensione dei motori, il computer di bordo rileva un problema e gli spegne automaticamente.

Launch Escape System Abort: Durante l'ascesa uno o più motori falliscono e la parte superiore dello spazioplano (Flight Deck e Mid-Deck) vengono catapultati lontani dal vettore.

TAL Abort (Trans-African-Abort): uno o più motori falliscono e si esegue un'atterraggio di emergenza a Nairobi.

AOA (Abort Once Around): è valido anche per Eridanus???

ATO: Abort To Orbit: a causa della perdita di uno o più motori non si riesce a raggiungere l'orbita prestabilita, ma un'orbita stabile più bassa.

La domanda principale è: CHE TIPO DI ABORT ABBIAMO ESEGUITO NELLA SIMULAZIONE??
Una Specie di AOA e ATO messi insieme???

Fausto ha scritto:

...Gli aerofreni si attivano con CTRL-B ma solo dopo il touchdown!

DOPO il touchdown? Allora quasi non sono più aerofreni!! C'è un motivo particolare?


Intanto ho cercato come lo faceva lo Shuttle...ma voi già lo sapete di sicuro.

Da http://wiki.ssm-fans.info/landing

The Final Approach phase in the Space Shuttle landing is somewhat similar to a normal commercial jet landing......The actual approach consists of two distinct stages:

During the first stage, the Shuttle lines up with the runway at 10,000ft, 6.9 NM from the runway, flying a 17 to 19 degrees glide slope to a point 0.89 NM short of the runway. Approach speed is controlled by speed brakes (air brakes). At 3000ft the speed brake is set to a calculated position to allow touchdown at a point 2500ft down the runway......

apollo 18 ha scritto:

La domanda principale è: CHE TIPO DI ABORT ABBIAMO ESEGUITO NELLA SIMULAZIONE??

Se parliamo strettamente di modalità di abort di lancio, nessuno.
In realtà non si è trattato di un abort del lancio, ma di un abort della missione.

La differenza è sottile ma consistente: nonostante il problema che tutti sappiamo, il lancio è stato eseguito e lo spazioplano non ha fallito l'inserimento in orbita, né ha raggiunto un'orbita più bassa. Ha raggiunto un'orbita più alta. Peraltro, il rientro non è avvenuto dopo un'orbita ma dopo ben mezza giornata nello spazio, nella quale sono state eseguite diverse orbite. Entro poche ore dal problema al lancio, l'orbita era già stata riportata a quota normale.

Quindi Eridanus era in orbita e senza problemi. Il rientro di emergenza è stato eseguito perché a causa della dispendiosa manovra di ricircolarizzazione e del tempo perso, non sarebbe stato più possibile raggiungere in sicurezza la ISS col carburante rimanente (probabilmente in realtà si sarebbe potuto, ma nella concitazione del momento sembrava confermato il contrario) e si è preferito riportare giù in tutta fretta il veicolo intanto che tutto sembrava funzionare correttamente.