Multistage2015

Grazie mille!

Sinceramente con Velcro non mi sono mai trovato a mio agio, per cui ci conto che questo diventi il sistema piu' usato :-)

Venendo alle tue richieste:
1) se mettiamo un solo parametro per tutti i motori, tipo eng_dir=(x,y,z) e' molto semplice da aggiungere, consideralo fatto! Sul fatto che anche la spinta stessa sia disallineata pero' non ho idea di che effetto abbia, poi con la combinazione di altre spinte tipo booster e col funzionamento dell'auotpilota etc non vorrei che poi diventasse un'opzione difficile da usare, io direi di fare per ora solo rotazione degli scarichi, e per il futuro faremo un po' di prove per vedere che succede, che dici?
2) anche questo richiede un filo piu' di lavoro ma e' fattibile velocemente. C'e' da pensare un attimo a come codificare i tempi e i modi dell'accensione di questi motori. Quanti pensi sia il caso di aggiungere? Io direi max 4 per ogni stadio.
3) fattibile e' fattibile, pero' significa aggiungere un'infinita' di voci al file ini per ogni stadio: ogni scarico deve avere posizione, direzione, dimensioni e texture. Quanti tra i developer lo farebbero? Anche come programmazione questo sarebbe un lavoraccio, non so se vale la pena. Un'ideuzza che mi e' venuta mentre scrivo pero' e' questa: far si che tutti i dati dell'rcs di una dato stadio siano in un unico lunghissimo vettore, tutto in una lunghissima riga. A quel punto non ci metterei troppo a fare il lavoro, pensi che per gli utenti sarebbe fattibile?

Edit:
Ho riguardato il codice nella sezione motori ed in effetti anche implementare la spinta applicata nel punto giusto con l'angolo giusto e' abbastanza facile, per cui direi di aggiungere due parametri opzionali per ogni stadio: eng_dir=(x,y,z) e thrust_real_pos=1 che se presente applica la spinta al punto corretto con l'angolo definito da eng_dir.

Devo pensare un attimo a come modificare il controllo di assetto relativo a pitch e yaw se la spinta non e' rivolta in avanti pero'

Ripensando alle mie richieste in effetti forse la spinta disassata non è così fondamentale da realizzare, perlomeno nei nostri vettori non c'è bisogno di questa funzione. Magari si può inserire solo come opzione a livello grafico, evitando complicazioni inutili, ma vedi tu.

Per i motori di ullage, dovrebbero accendersi un paio di secondi prima dei motori principali ma senza bisogno di aggiungere la chiamata nel file di guida (tra l'altro non ricordo se nel nuovo file di guida la chiamata dei vari staging sia ancora manuale o se faccia tutto l'autoguida da sola). L'ideale sarebbe che, se nell'autoguida arriva per dire la chiamata di accensione del motore dello stadio a T+100, a quel secondo si accenda in realtà l'ullage e dopo un paio di secondi il motore principale, con spegnimento del motore di ullage immediatamente dopo. Tra l'altro la stessa procedura sarebbe necessaria in caso di riaccensioni ora che ci penso... forse è troppo complicato, magari si può soprassedere.

Per gli RCS forse si può soprassedere per il momento...

Allora,

per quanto riguarda la spinta disassata secondo me è un'opzione semplice da ottenere e da' un bel realismo, la implementerei.

per i motori di ullage: diciamo che aggiungerli non è un problema, farli funzionare è un po' più complicato. l'autoguida accende gli stadi etc automaticamente, sarebbe realistico se l'utente dovesse impostare nel file ini un valore minimo di accelerazione al di sotto del quale i motori non si accendono, però devo pensare un attimo a come fare perché non è banale: bisogna intercettare il comando di accensione dei motori e dirgli di "aspettare che l'accelerazione si almeno la corretta"... devo pensarci un attimo su, era una cosa che mi era già venuta in mente sul Jarvis DLL ma allora non la implementai perché non mi erano venute idee giuste, vedo se stavolta qualcosa di buono viene.


per gli RCS sono d'accordo di soprassedere, è davvero una grande complicazione: sono 8 parametri a motore (due vettori più lunghezza e larghezza) per un minimo di due motori per gruppo per 6 gruppi... fa 96 parametri da inserire in più... magari in futuro ci viene qualche idea su come ottimizzare la cosa, ma per questa release direi di non metterli

Solo una nota per gli RCS: non credo sia necessario specificare lunghezza e larghezza di ogni getto, ne basterebbe una sola da applicare per tutti i getti... però si, rimane complicato, lasciamo perdere per ora! Io con spacecraft impazzisco ogni volta che devo impostare gli RCS (e li c'è pure la traslazione!).

Per il resto ci affidiamo alla tua competenza e al tuo buonsenso!

Hai ragione, comunque come dici tu è un delirio, lo terrei per il futuro...


Intanto visto che in questo periodo ho parecchio tempo libero sto continuando a lavorare sul progetto e ho un paio di news importanti:

Parametro eng_dir aggiunto e perfettamente funzionate, sia con i booster che con gli stadi, con lo shuttle ad esempio bello da vedersi:


Però non è solo estetica, se nella sezione MISC del file ini si mette THRUST_REAL_POS=1 tutte le spinte dei motori di booster e stadi sono applicate nei rispettivi offset e con le rispettive direzioni, l'autopilota PEG è stato corretto in modo che tenga conto anche della direzione della spinta. Questa è una bella botta di realismo per i bravi addon developers

Altro punto importante fatto oggi: schermo di gestione guidance dell'MFD, c'è una grandissima novità (secondo me).

Si possono infatti aggiungere o eliminare gli step del programma di guida direttamente dall'MFD! e non solo: una volta che abbiamo scritto gli step di guida che ci paiono soddisfacenti basta premere il tasto "SAV" per salvare il file di guida in un file txt dentro la cartella di orbiter che dopo potremo tranquillamente andare a prenderci ed a copiare / incollare negli scenari che preferiamo!



Questa secondo me è davvero una cosa utile!

Veramente utilissimo!!!

Stavo pensando a una cosa, ma prendila come ragionamento libero.
Pensavo a configurazioni come ad esempio Eridanus. Qui abbiamo un payload che è lo spazioplano, sistemato in posizione disassata, quindi lo stack non è simmetrico, il baricentro è disassato rispetto ai propulsori. A differenza dello Shuttle, Eridanus non contribuisce con la spinta dei propri motori ma, come Buran, è un payload inerte fino all'orbita. Quindi i propulsori del lanciatore devono spingere in modo leggermente asimmetrico, con una asimmetria inizialmente molto bassa (avevamo calcolato qualcosa come mezzo grado o meno), ma che aumenta via via che i serbatoi si svuotano e il centro di massa si sposta lateralmente.
Immagino che fare in modo che MSG2015 tenga conto di un payload disassato sia facile per te; come conseguenza il vettore dovrebbe modificare il suo assetto di volo in modo che la spinta sia sempre centrata col baricentro (nel caso di Eridanus, vedremmo il vettore inclinarsi sempre di più verso l'alto - quando è capovolto, e verso il basso - quando ritorna a testa in su).
Il problema è che anche il getto dei motori dovrebbe riorientarsi e le mesh sono statiche - gli ugelli non si spostano - quindi l'effetto sarebbe brutto. Quindi graficamente i getti non dovrebbero spostarsi ma solo la direzione di applicazione della spinta.

Mi sono spiegato? ;-)
In realtà non c'è nessun reale bisogno di una cosa del genere; era solo per chiacchierare

Buondì!

il tema è molto interessante: spinta disassata dal baricentro + controllo complesso del sistema di guida sono cose con cui è molto divertente cimentarsi.

In realtà con orbiter2010 non è possibile simularle perché orbiter riferisce ogni coordinata al baricentro: posizioni degli esausti, animazioni etc, per cui spostare il baricentro significherebbe traslare tutto. Infatti il comando che in c++ sposta il baricentro "ShiftCG" è praticamente l'unico che anche a detta di Martin è pieno di bug e da usare con cautela perché, detto in gergo puramente tecnico, scasina tutto :-) .

Con la nuova versione di orbiter ancora in beta però le cose cambiano: si può avere dei mezzi "docked" anche a terra, ed il baricentro si sposterà automaticamente di continuo al consumarsi del carburante. Questo apre la porta a nuove idee di sviluppo e ad un maggiore realismo. Ci sarà da ripensare la struttura anche di multistage eventualmente, anche se al momento mi viene male a pensarci

Ho letto che hai aggiunto una funzione sulla durata delle batterie di alimentazione degli stadi ma vorrei capire esattamente come funziona e dove vanno specificati questi dati, se nel file di guida o nell'ini del razzo. In alcuni nostri razzi, tipo il Jarvis M, ricorderai che alcune versioni dello stadio superiore avevano pannelli solari per un supporto prolungato in orbita. Quindi sarebbe utile poter simulare una durata di "vita" che arrivi fino all'ordine dei giorni o settimane, se possibile...

Nel file ini, in ogni stadio si puo' scrivere "battery" ed il numero indicato in ore. Per avere uno stadio con la durata di una settimana bastera' indicare battery=168 ad esempio. E' importante che sia per ogni stadio perche' per esempio e' piu' utile definire questo parametro per gli upper stages piuttosto che per il primo stadio. Se per esempio nel primo stadio non scrivi niente e nel secondo metti battery=168 il primo stadio avra' batteria infinita e il secondo 1 settimana, e cosi via.

Capito, ottimo! Mi chiedevo se si potesse simulare a richiesta anche il boil off dei criogenici (solo idrogeno liquido) una volta che il razzo è in orbita. Ci sono tabelle che dicono a quanto ammonta per unità di tempo. Sarebbe importante poter specificare anche un boil off pari a zero o quasi nel caso in cui lo stadio sia equipaggiato per lunga autonomia in orbita - per esempio lo stadio HES-5 del Jarvis.

beh sì, è abbastanza semplice:

cosi come il parametro battery, in ogni stadio si potrà scrivere il parametro boiloff=1 e a quel punto il carburante di quello stadio pian piano si consumerà anche senza motori accesi. Per aumentare il realismo direi inoltre che per consumarsi non deve necessariamente essere lo stadio attivo: ad es. se sto in orbita di parcheggio con uno stadio inferiore, nello stadio superiore con il boiloff il carburante si deve consumare cmq. Ripeto cmq: è abbastanza semplice da fare.

Se mi dai un'indicazione sul parametro da utilizzare lo implemento oggi. Considera che in orbiter il propellente è un'unica grandezza, per cui bisogna farlo diminuire di un tot che tiene conto delle differenti proporzioni di combustibile e comburente.

Devo fare qualche ricerca in proposito... appena posso ti do delle cifre!

Non ho trovato riferimenti sicuri. Su Nasaspaceflight ho trovato questo:

LOX/LH2:   0.35% per day.
LOX/CH4:   0.20% per day.
LOX/RP1:   0.20% per day.

Che mi sembra un po' sballato perché mi sembra che ci sia troppo poca differenza tra idrogeno e altri propellenti.

Altrove per il Centaur ho trovato un valore pari a 0,1% al giorno (con alcune modifiche attualmente in programma). Io direi di fare una media.
Se oltre al solo ON/OFF vuoi aggiungere una opzione intermedia per simulare propellenti mediamente criogenici come gli altri due qui sopra citati, vedi tu... L'importante per me se voglio simulare lo stadio HES-5 è di poter disattivare l'opzione boil off nella configurazione del razzo!

Dunque, per il centaur viene un valore di circa 0,87 kg/h. Io farei per questa prima release un valore unico di 1kg/h tondo. Ovviamente si potra' scegliere se avere il boiloff o meno modificando il file .ini.

Andrew ha scritto:

...
Che mi sembra un po' sballato perché mi sembra che ci sia troppo poca differenza tra idrogeno e altri propellenti.
...

Sei nel vuoto a 270° sotto zero ... La perdita sicuramente c'è a causa del vuoto, ma proprio il vuoto fa sì che a causa della bassissima temperatura il boil off sia ridotto, non avendo conduzione di calore per trasmissione fisica ma solo per irraggiamento. Io terrei buoni quei valori.

Intendevo dire che essendo l'idrogeno la molecola più piccola in natura, è enormemente più volatile di qualsiasi altro elemento, e in forma di gas è difficile da contenere: passa dappertutto. Un recipiente chiuso ermeticamente può contenere ossigeno o altri gas, ma l'idrogeno tende a passare lo stesso da qualsiasi microscopico pertugio. Infatti è difficilissimo, quasi impossibile per ora ottenere un sistema a idrogeno a boil-off zero.

Quindi i valori di boiloff medi dovrebbero essere molto più elevati rispetto a quelli dell'ossigeno o del metano liquido che sono molto più densi. Almeno così ho sempre letto... comunque teniamoli pure buoni! Se li hanno scritti un motivo ci sarà ;-)

fred18 ha scritto:

Dunque, per il centaur viene un valore di circa 0,87 kg/h. Io farei per questa prima release un valore unico di 1kg/h tondo. Ovviamente si potra' scegliere se avere il boiloff o meno modificando il file .ini.

Io l'accenderei.

EDIT
ho capito il perché di quei valori.

Se prendiamo un sistema LOX/LH2, la maggior parte della massa del propellente è data dall'ossigeno: l'idrogeno in realtà è solo un settimo in peso (anche se la stragrande maggioranza in volume). Quindi anche se l'idrogeno evapora e scappa via molto più degli altri elementi, essendo meno in quantità, "contribuisce" solo in parte modesta al bilancio finale della percentuale. Ecco quindi i valori complessivi che si discostano meno di quanto pensassi da quelli degli altri due tipi di propellenti liquidi. Va da sé che se anche mi sono tenuto tutto l'ossigeno e l'idrogeno me lo sono perso, il mio motore non funzionerà lo stesso
Ricordiamo infine che i propellenti ipergolici non subiscono boil-off e infatti si chiamano "storabili" (non a caso sono quelli impiegati per le sonde spaziali che devono durare anni).

ho fatto una prova.

con 1kg/h ci vogliono settimane prima che in uno stadio criogenico ci si accorga che sta succedendo qualcosa....

un esempio: l'HES5 ha 86.430 kg di propellente, 1kg/h -> 3600 giorni perché si consumi tutto, 10 anni... c'è qualcosa che non quadra...

d'altronde riguardando i numeri: 0.1% al giorno significa 10 giorni per fare l'1% e 1000 giorni (3 anni) per fare il 100%...

se l'effetto è così poco influente non vale davvero la pena implementarlo secondo me... consumo di più a schiacciare una volta di più il killrot...

Intanto ho pensato alla struttura degli ullage, ci vogliono parecchie voci purtroppo, per ogni stadio.

ecco la struttura:

Codice:

[STAGE_X]
...
...
ullage_thrust=xxx        spinta totale dei motori di ullage
ullage_anticipation=xxx anticipo rispetto all'accensione dei motori dello stadio
ullage_overlap=xxx      tempo di sovrapposizione tra i motori dello stadio e l'ullage (se non impostato appena si accendono i motori dello stadio si spegne l'ullage)
ullage_N=xxx              numero dei motori di ullage dello stadio
ullage_angle=xxx          angolo di rotazione del primo motore
ullage_pos=(x,y,z)        posizione del primo motore di ullage
ullage_dir=(x,y,z)        direzione del getto del primo motore di ullage
ullage_tex=abc            texture del getto
ullage_length=xxx        lunghezza del getto
ullage_width=xxx          diametro del getto

una volta definito il primo motore ne vengono poi creati N-1 ruotando tutte le caratteristiche attorno all'asse longitudinale del veicolo.

Il processo è analogo a quello di creazione dei booster.
Purtroppo sono tanti parametri ma non saprei come fare a ridurli...

Penso si possa soprassedere.. non complichiamoci troppo la vita...

Per il boil off in realtà l'effetto aumenta esponenzialmente man mano che il propellente si riduce. Forse è più difficile da simulare realisticamente di quanto si pensasse..

Andrew ha scritto:

Penso si possa soprassedere.. non complichiamoci troppo la vita...

too late... è già inserito nel codice e funziona

Andrew ha scritto:

Per il boil off in realtà l'effetto aumenta esponenzialmente man mano che il propellente si riduce. Forse è più difficile da simulare realisticamente di quanto si pensasse..

non capisco però: dire ad esempio che se ne va lo 0.1% ogni ora significa che la prima ora andra via un tot, la seconda un po' meno, la terza ancora un po' meno e cosi via, senza mai arrivare a zero.

Se invece l'effetto deve aumentare al passare del tempo bisogna trovare dei numeri che rappresentino esattamente l'opposto.

Sul saturn V ho trovato che a terra l'SIVB "perdeva" circa 25kg al minuto!

bisogna scavare ancora un po' per trovare il numero giusto.

fred18 ha scritto:

una volta definito il primo motore ne vengono poi creati N-1 ruotando tutte le caratteristiche attorno all'asse longitudinale del veicolo.

Un momento, questo presuppone che gli ullage siano definiti esclusivamente secondo un pattern quadrato? E nei casi in cui siano sistemati a schema rettangolare (per esempio raggruppati due a due al lati)? Devo quindi modificare le mesh per farle corrispondere?

eh in effetti sì, avevo pensato solo a distribuzioni circolari simmetriche.

Non avevo pensato che ci potessero essere soluzioni rettangolari. Il vantaggio del sistema simmetrico è che si possono mettere quanti ugelli si vogliono in una sola chiamata, ieri sera per fine di test ho fatto questo semplicemente mettendo ullage_N=50:




Se invece vogliamo definire distribuzioni asimmetriche bisogna definire le posizioni degli ullage una ad una, il che vuol dire aggiungere moltissime righe...

vedo se si può aggiungere un parametro opzionale che definisce quanto "rettangolarizzare" la distribuzione, è questione di un po' di trigonometria, ti faccio sapere

Fatto, aggiunto

Codice:

ullage_rectfactor=xxx

più è grande, più la distribuzione si "schiaccia"

ecco un esempio con ullage_N=4 e ullage_rectfactor=4


ed un altro con ullage_rectfactor=2



nella documentazione spiegherò per bene come utilizzare questo parametro