Jarvis - versione dll

D'accordo anche io ma sará un super lavoro!

Si, magari se vien fuori che è una cosa complessa, si potrebbe tenere da parte per successivi aggiornamenti, limitandosi per ora alle funzionalità base di cui abbiamo discusso in precedenza.

Ciao a tutti,

sto ricominciando a giocherellare un po' con orbiter e a sviluppare un po' i progetti che avevo lasciato in sospeso.  

A tal proposito in prima fila ovviamente c'è il Jarvis in versione dll

La situazione in pratica è la seguente:

il Jarvis S è praticamente finito, manca solo un'autoguida universale.  

Ho provato di tutto, ho anche implementato in maniera rigorosa il PEG, rispolverando le equazioni differenziali studiate all'università ormai un po' di anni fa, ma non c'è nulla da fare, perché la parte finale del core stage "spinge" come una cannonata e non riesco a contenere i parametri di apogeo, perigeo in maniera corretta. Anche diminuendo un po' il "gas". In pratica è come se l'accensione del core stage fosse troppo lunga.

Ho provato un paio di addon in giro, ad esempio l'HCLV LINK
e ho visto che utilizza un sistema un filo più semplice con cutoff iniziale in traiettoria balistica e poi seconda accensione per correzione degli apsidi.

Diciamo che se per voi questo sistema andasse bene non avrei problemi a completare in tempi brevi il lavoro, e penso di poter fare qualcosa comunque di più preciso dell'autoguida dell HCLV  . Vi lascio quindi questo quesito per le vacanze, sappiatemi poi dire che ne pensate.  

Ciao a presto!

Ma ti riferisci al core stage? Quindi al primo stadio? Se si, non si può far spegnere e riaccendere in volo un motore F1... anche uno modernizzato come quelli ipotizzati da noi per il Jarvis. Non sarebbe realistico. L'unica è parzializzare la spinta. Comunque la durata dell'accensione e la spinta sono corrette... sei sicuro di aver riportato correttamente i vari valori, pesi ecc. nella dll? A volte magari basta un piccolo errore di battitura e si ottengono risultati strani...

Penso di aver scoperto qualcosa di interessante e allo stesso tempo importante per l'aspetto del realismo delle missioni riguardo al Jarvis.

Ho provato a mettere a stretto confronto le fasi di ascesa del Jarvis con multistage che ho scaricato da OH e quella della versione in dll di cui sto cercando di sviluppare il sistema di guida e mi sono accorto di una importante differenza.

Come tutti sappiamo nella primissima fase le pressioni dinamiche dovute all'atmosfera sulla struttura del vettore sono estreme e un angolo di attacco sbagliato può portare facilmente alla distruzione del veicolo, come si vede in questo filmato, mi pare ad esempio che per i delta 2 il limite di AOA sia 6 gradi.

Ecco nella versione con mulitstage, l'autoguida porta il jarvis s ad avere angoli di AOA nella fase bassissima del volo addirittura a 12 gradi, con il drag al punto di max Q di ben 1.93 MN sui 7.7 di spinta totali.  

Il sistema di guida della dll tiene conto di questa cosa e mantiene l'aoa entro un massimo di 3 gradi per la fase atmosferica bassa, ottenendo un drag al punto di max Q di soli 235 kN.

Oltre al realismo, si ottiene di avere parecchio carburante e dV in più a disposizione (ed ecco svelato perché a parità di parametri arrivavo sempre alto e veloce).

Secondo me bisognerebbe tenerne conto, voi che dite?

per quanto riguarda infine l'autoguida, in realtà a me basterebbe poter ri-accendere un paio di volte l'upper stage, se mi è concesso il jarvis dll sarà realtà entro il 2013  

ciao ciao

Fred

probabilmente le mie vecchie autoguide pagano qualche ingenuita' comunque giustificata dal fatto che le prestazioni finali corrispondevano sempre bene ai calcoli. C'è da dire che il modello aerodinamico di multistage e' un po' semplificato. Tu che modello hai usato? Ad ogni modo qui: http://www.braeunig.us/apollo/saturnV.htm si riporta x il saturn v un valore massimo di resistenza aerodinamica pari a 460.000 pounds, che fatti i debiti calcoli corrispondono a 2,03 MN, in buon accordo coi dati da te rilevati. Consideriamo che il saturn v ha una cross section molto più ampia, ma e' anche un vettore cosiddetto "ad ascesa lenta" pertanto sottoposto a meno stress nella fase iniziale, mentre il nostro jarvis ha un profilo di volo più brutale e più assimilabile a quello di un ariane 5. Te ne accorgerai soprattutto col jarvis L! ad ogni modo ci sono diversi aspetti tecnici che mi piacerebbe discutere. Con te quando torno dalle vacanze! Scusa il post un po' così ma sto scrivendo dalla spiaggia con un iPod... Un casino! :-) 

Ah dimenticavo: i motori vinci dell'upper stage sono ovviamente riavviabili come sara' nella realtà. Tuttavia la feature della riaccensione serve per i cambi di orbita e solitamente non va sprecata per il solo raggiungimento della LEO, in quanto teoricamente ogni motore si può riaccendere per un numero limitato di volte. ecco perché difficilmente vedrai un lanciatore che si spegne eriaccende in volo solo nella fase LEO. più realistico in questa fase ricorrere alla parzializzazione della spinta, IMHO.

Il modello aerodinamico che uso è quello nativo di orbiter, che è quello utilizzato anche da multistage, sicuramente molto semplificato, ma crearne uno ex-novo sarebbe un lavorone.  

grazie mille per il sito sul saturn, interessantissimo e utilissimo!!!

Per gli aspetti tecnici a settembre direi che ci mettiamo lì e iniziamo a chiacchierare di cose interessanti  Tanto anche io sono rientrato solo un paio di giorni ma tra poco riparto per fare ancora una settimana lontano dal pc  

Per la riaccensione dei Vinci ok, ieri sera mi sono accorto che sull'autoguida ho ancora del margine di miglioramento che non ricordavo di avere, vedrai che ci riusciamo  

buon mare  

Mi piace assai cotanto ottimismo sul Jarvis DLL!
Devo assolutamente riprendere il lavoro sul rover lunare per le nostre future missioni  

Fausto ha scritto:

Devo assolutamente riprendere il lavoro sul rover lunare per le nostre future missioni  

che bello che bello    

UDITE UDITE!!!!!!

dopo una quantità innumerevole di tentativi che risalgono ai tempi dell'Elis e dopo aver studiato e ristudiato un miliardo di pagine e di equazioni.... sono riuscito a implementare e a far funzionare il sistema di guida PEG, lo stesso di shuttle, Saturn etc etc...

quasi per caso ho trovato un documento dove veniva riportato che nella documentazione ufficiale NASA c'era un errore in un'equazione (che avevo sempre preso per buona...  ), l'ho corretto e ora... funziona!!!!  

Ed il Jarvis-S (per ora ho sviluppato solo quello perché non riuscivo a venire a capo del sistema di guida) va nell'orbita desiderata che è un piacere, preciso come un orologio svizzero!!!  

Ecco qui sotto un estratto del launchreport che viene salvato in automatico e fa vedere la precisione del sistema!

Codice:

--------------------------------------------------------------------
MET [s] = 508.757
Remaining Burning Time [s] = 40.8454
Remaining Fuel Mass [kg] = 4809.63
Target Apogee [m] = 250.000
Current Apogee [m] = 250.055
Target Perigee [m] = 250.000
Current Perigee [m] = 249.984
--------------------------------------------------------------------
MET [s] = 505.537
Remaining Burning Time [s] = 44.0817
Remaining Fuel Mass [kg] = 5190.71
Target Apogee [m] = 185.000
Current Apogee [m] = 185.053
Target Perigee [m] = 185.000
Current Perigee [m] = 184.956
-------------------------------------------------------------------
MET [s] = 510.269
Remaining Burning Time [s] = 39.36
Remaining Fuel Mass [kg] = 4634.72
Target Apogee [m] = 320.000
Current Apogee [m] = 320.172
Target Perigee [m] = 260.000
Current Perigee [m] = 260.000
--------------------------------------------------------------------
MET [s] = 505.258
Remaining Burning Time [s] = 44.3471
Remaining Fuel Mass [kg] = 5221.96
Target Apogee [m] = 369.200
Current Apogee [m] = 369.216
Target Perigee [m] = 255.100
Current Perigee [m] = 255.100
--------------------------------------------------------------------
MET [s] = 501.805
Remaining Burning Time [s] = 44.1202
Remaining Fuel Mass [kg] = 5195.24
Target Apogee [m] = 160.000
Current Apogee [m] = 160.139
Target Perigee [m] = 160.000
Current Perigee [m] = 159.971
--------------------------------------------------------------------
MET [s] = 537.05
Remaining Burning Time [s] = 26.7379
Remaining Fuel Mass [kg] = 3148.44
Target Apogee [m] = 350.000
Current Apogee [m] = 350.009
Target Perigee [m] = 260.000
Current Perigee [m] = 260.000

 

Le attuali limitazioni sono sulla convergenza del sistema di guida, se si danno absidi troppo alti il PEG tende a non convergere durante le iterazioni (ricordate gli apollo "your guidance has converged" ?  )

per ora il limite che ho riscontrato è dunque questo: uno dei due absidi dev'essere inferiore o uguale a 260km, altrimenti il programma non trova soluzioni per il sistema di guida. Contemporaneamente l'altro abside dev'essere circa inferiore a circa 320-350 km. Come vedete dai numeri sopra il sistema funziona anche con orbite 255x370 e 260x320, e credo che questi siano i valori limite.

Funziona perfettamente per tutte le orbite standard, tipo la circolare da 185km o da 250km o anche oltre.

Credo che siano valori accettabili, anche perché una volta raggiunta una LEO così "alta" riaccendere i Vinci una volta per regolarizzare l'orbita penso sia prassi.

Altra cosa fondamentale: il PEG è universale! quindi ora che funziona sul Jarvis-S, si può prendere pari pari e portare nelle dll di tutta la famiglia!

Ah già che c'ero ho aggiunto il controllo della spinta del primo stadio affinché tenga un'accelerazione mai superiore ai 5G, e funziona con precisione ma è un numero che ho scelto così per provare, poi decideremo come impostarlo.

come regalo di fine estate vi posto quindi una primissima alpha della dll (molto molto alpha, quindi non me ne vogliate per errori o imprecisioni  ).

Tenete presente che una parte del lavoro visivo è ancora da impostare, ma ora che il sistema di guida funziona il resto sarà veramente un gioco da ragazzi!

per gli stadi che si separano non ho ancora impostato nessuna dll apposita, per ora prende lo stage.dll che usa il multistage, più avanti si metterà a posto.

per l'utilizzo funziona pari pari come l'elis.

ah per ora se uno degli absidi è superiore a 260 km bisogna che inseriate apogeo e perigeo alla rovescia, cioè per esempio target apogee=220 target perigee=300, più avanti farò in modo che il sistema faccia tutto in automatico

Potete scaricarla QUI

Ciaoooooooooooooo

grande! pero io non la metterei in scaricamento libero una cosa così importante se non vogliamo che ce la freghino subito! questo forum attira molti visitatori! sarebbe meglio una condivisione privata tramite dropbox o altri sistemi. sentiamo Fausto!

ho messo solo la dll, senza codice sorgente, quello poi lo condivideremo in privato. comunque ditemi come preferite fare che modifico subito!

Ah... Io da qui non riesco a scaricare niente :-P
cmq x me il range di orbite possibili e' più che adeguato! volendo fare i pignoli sarebbe ottimo poter impostare orbite ancora più basse fino a circa 160 km, ideali per i brevi parcheggi in attesa della TLI! il fattore g che hai impostato mi pare corretto! per i lanci manned sarebbe buona cosa abbassarlo fino a 3,5 g ma se ne discuterà in fase di rifinitura!

Ottimo, sono contento che il range sia corretto! Finalmente questo grande scoglio dell'autoguida e' superato! Per il range basso non c'e' problema, il limite e' solo superiore, in basso si puo' andare quanto si vuole perche' il dv richiesto e' inferiore e il sistema converge sempre!
Ci sentiamo presto per iniziare a parlare finalmente di rifniture e altri aspetti :-)

Fred, davvero ottimo lavoro!      Ho provato diversi absidi nei limiti da te indicati e funziona perfettamente!
Io credo che nel futuro si potrebbero unire gli sforzi miei per quanto riguarda la gestione delle rampe, e tuoi per il jarvis dll per creare un codice che vada ad aggiungere automaticamente il pad giusto sotto il razzo e muova tutti i bracci alla data indicata ma senza dover utilizzare il vascello fantasma come accade ora.. ne riparleremo in seguito

Aggiungo i miei complimenti a fred!!
 

Ciao Ragazzi,

allora ho ritoccato il sistema di guida ed ora secondo me è ancora migliorato, con la possibilità di non avere problemi di convergenza del sistema anche per orbite più alte di prima.

Più tardi posterò la dll aggiornata, e mi chiedevo se ci fosse qualche volontario per testare quali siano i limiti del sistema di guida così da inserirli in futuro nella documentazione  

A questo punto il Jarvis-S è praticamente finito, mancano i desiderata di FOI:

che cosa vorreste aggiungere? vi dico le mie idee:

- da file scenario si potrà decidere: limite G per l'accelerazione e un parametro di forma per la prima parte del volo (il gravity turn, molto semplice, poi vi spiego bene cosa intendo).

- fausto io vorrei aggiungere i venting che al momento sono sulla rampa direttamente al vettore (come correttamente suggerivi tu), che si chiudono automaticamente a T-XX dal lancio. Se sei d'accordo ci passiamo le informazioni relative appena possibile.

Per il resto attendo vostri input: effetti di staging tipo ullage? altre idee?

ciao ciao

Fred

Da mettere sicuramente:

- max-Q
- venting
- motori di ullage
- retromotori di separazione, quelli che spingono indietro gli stadi staccati, o lateralmente i boosters
- bulloni esplosivi

eventualmente la scia di condensazione ma per il momento eviterei (se non altro perché sul mio vecchio PC mi rallenterebbe la simulazione  ).

le posizioni dei motori di ullage e dei bulloni esplosivi le dovrei però fornire io.

Ho una domanda: i payloads come si gestiscono adesso?

EDIT

la DLL una volta impostata sarà veloce da adattare agli altri vettori?

Oki, allora

-max q (che poi sarebbe mach1) c'e' gia'.

-venting (attendo dati da fausto)

-ullage e retro (ci sono gia' ma non si vedono xke non ho messo exhaust, attendo posizione degli exhaust da andrew)

-scia di condensazione e' pronta ma non aggiunta ancora, ditemi voi come procedere

I payload si gestiscono con un file ini del tutto analogo a multistage/spacecraft. Funziona esattamente come l'elis (ho riportato pari pari la stessa architettura). Anche su questo argomento ditemi voi se avete preferenze.

Andrew ha scritto:

EDIT

la DLL una volta impostata sarà veloce da adattare agli altri vettori?

Si, ora che il sistema di guida e' a posto sara' davvero un attimo, per questo chiedo ora cosa aggiungere, cosi lo faccio per il jarvis-s e poi me lo ritrovo quasi gia' pronto per tutti gli altri  

fred18 ha scritto:

-max q (che poi sarebbe mach1) c'e' gia'.

In realtà il max Q non corrisponde esattamente (o non sempre) al passaggio di mach 1. A volte è leggermente prima, a volte leggermente dopo (affare di secondi), dipende anche dal profilo di accelerazione del veicolo. Dovrebbe essere impostato in modo da apparire nella fase di massima pressione dinamica sul veicolo, diciamo nei 10 secondi a cavallo di quel momento.

Citazione :

-ullage e retro (ci sono gia' ma non si vedono xke non ho messo exhaust, attendo posizione degli exhaust da andrew)

Ti fornisco al più presto le coordinate.

Citazione :

-scia di condensazione e' pronta ma non aggiunta ancora, ditemi voi come procedere

La scia appare quando il vapore acqueo si condensa in cristalli; ciò dipende da fattori come quota, temperatura, pressione dell'aria attorno al veicolo. Bisognerebbe capire all'incirca a quale quota, in media, compare e a quale quota scompare. Va fatta qualche ricerca, oppure possiamo stabilire empiricamente di farla apparire a T+X secondi e di farla scomparire a T+Y secondi. Questo dato si potrebbe ricavare abbstanza facilmente da un lancio reale.
Se vogliamo visualizzarla, farei però qualcosa di molto blando e che scompaia in fretta, per non caricare la simulazione. Ricordiamoci inoltre che nelle versioni che usano booster solidi (tipo Jarvis H) la scia di condensazione non andrebbe visualizzata perché è comunque mascherata dalla scia dei boosters solidi.

Ah, dimenticavo: è possibile fare in modo visualizzare max-Q e scia in modo appena percettibile, solo nei lanci notturni? In quei casi si vedrebbero appena o non si vedrebbero proprio!

Citazione :

I payload si gestiscono con un file ini del tutto analogo a multistage/spacecraft. Funziona esattamente come l'elis (ho riportato pari pari la stessa architettura). Anche su questo argomento ditemi voi se avete preferenze.

Per come la vedo io, questo è il modo più pratico. Si potrebbe implementare qualcosa per caricare i payloads direttametne dalla simulazione (come nel razzo Energia di Kulch), ma credo che la priorità sia unicamente l'autoguida, e vorrei limitare un po' questi automatismi.
Sarebbe però interessante far si che, impostando un payloads, il sistema lo posizioni automaticamente nella giusta posizione rispetto al vettore, in modo che non sia troppo spostato in alto (fluttuante nell'aria) o al contrario compenetrato alla mesh del razzo, ma non so se questo si può fare. Va da sé che per payloads particolari deve essere possibile aggiungere adattatori specifici. Ah, importante: far si che la mesh del payload non venga visualizzata fino a quando non si aprono le ogive (come su Multistage), per alleggerire la simulazione.

Per quanto riguarda maxQ e' corretto quanto dici che non corrisponde sempre a mach1, pero' la nuvola bianca attorno al veicolo si forma per il passaggio a mach1, la corrispondenza con maxQ e' pura coincidenza. Infatti succede anche agli aerei supersonici, tipo caccia etc., al momento la nuvola bianca compare quindi a cavallo di mach1.

Per la nuvola di condensa non metterei una condizione sul tempo ma sulle condizioni reali (tipo velocita', altitudine etc) in modo che sia sempre realistico. Faro' qualche ricerca.

Per i lanci in notturna mi sa che e' un po' complicato, pero' ci posso provare.

Al momento la posizione del payload e' data dalle coordinate a mano nel file ini del payload, e' il modo che piu' mi tranquillizza per evitare appunto di avere payload fluttuanti e cose simili, come dici giustamente tu. Se volete si puo' automatizzare, ma ho paura che sia un rischio.

Corretto che devo aggiungere gli adattatori, prendo nota!

Corretta anche la richiesta della mesh del payload. Piu' complicata, ma fattibile!

Stasera mi metto al lavoro :-)

fred18 ha scritto:

Per quanto riguarda maxQ e' corretto quanto dici che non corrisponde sempre a mach1, pero' la nuvola bianca attorno al veicolo si forma per il passaggio a mach1, la corrispondenza con maxQ e' pura coincidenza. Infatti succede anche agli aerei supersonici, tipo caccia etc., al momento la nuvola bianca compare quindi a cavallo di mach1.

Hai ragione, ho invertito le cose!

Citazione :

Per i lanci in notturna mi sa che e' un po' complicato, pero' ci posso provare.

Non diventare matto, non c'è problema! Va bene così!

Citazione :

Al momento la posizione del payload e' data dalle coordinate a mano nel file ini del payload, e' il modo che piu' mi tranquillizza per evitare appunto di avere payload fluttuanti e cose simili, come dici giustamente tu. Se volete si puo' automatizzare, ma ho paura che sia un rischio.

Io terrei così per il momento! Per quanto mi riguarda, quando carico un nostro payload, provo prima le coordinate su Anim8or, quindi quando vado a impostarle per Orbiter, vado sempre a colpo sicuro...

Citazione :

Corretta anche la richiesta della mesh del payload. Piu' complicata, ma fattibile!

Si, secondo me questo è un aspetto importante.
Bisognerà anche fare in modo che la mesh appaia sempre, nel caso in cui non ci sia ogiva (ad esempio è il caso di Eridanus, che lanciamo con il vettore Quasar che però funzionerà nello stesso modo del Jarvis)

Domanda. Le coordinate degli esausti degli ullage e dei bulloni esplosivi come le vuoi? Riferite a ciascuno stadio o al vettore totale?