Jump to content

SAS e Gravity Turn


tea_bag97

Recommended Posts

Ciao a tutti :D

Documentandomi su Realism Overhaul ho letto su una pagina di GitHub scritta da Ferram (in persona) che per avere la massima efficienza in un lancio sarebbe meglio lasciare che sia soltanto la forza di gravità a far deviare il razzo, dando soltanto un input iniziale ridotto. Al contrario, mod come MechJeb alterano il pitch a seconda della quota alla quale si trova il veicolo usando reaction wheels e winglets, intervenendo in maniera innaturale e quindi presumibilmente sprecando prezioso carburante.

Quindi ho fatto vari tentativi seguendo le istruzioni di Ferram. Nei casi in cui mantenevo l'SAS attivo, il razzo rimaneva troppo stabile e non veniva deviato naturalmente, mentre nei casi in cui spegnevo l'SAS cominciava a ruotare e cambiare direzione fuori controllo. Sono sicuro di aver posizionato tutte le parti simmetricamente, dunque immagino si tratti delle famose forze fantasma provocate da FAR. Perciò la mia domanda è: è possibile compiere un gravity turn senza perdere il controllo del mezzo? L'unica soluzione verosimile che mi viene in mente è fare in modo che l'autopilota controlli soltanto roll e yaw, tralasciando temporaneamente il pitch.

Fonte:

https://github.com/KSP-RO/RealismOverhaul/wiki/False-KSP-Lessons

https://github.com/KSP-RO/RealismOverhaul/wiki/Ferram-on-Ascent-Profile-and-TWR

Link to comment
Share on other sites

Dunque, ferram è un maestro per quanto riguarda la stabilità dei velivoli, razzi inclusi. Quanto ha scritto è perfettamente vero, il lancio più efficiente si ottiene con un VERO gravity turn, che significa non dover esercitare alcuna azione di controllo sull'assetto del razzo mentre questi segue una traiettoria che va arcuandosi progressivamente per il solo effetto della rotazione impressa dalla gravità. MechJeb al contrario esercita un controllo attivo sull'assetto, che è preprogrammato in modo che l'angolo di pitch vari con l'altitudine.

Occorre dire che, se il profilo di ascesa è impostato correttamente, le azioni di controllo esercitate da Mechjeb saranno minime. Minori le azioni di controllo, e minori le perdite di energia (tipo, attrito delle superfici di controllo, angolazione del gimbal (per cui parte della spinta è spesa per il controllo dell'assetto, invece che per accelerare il razzo)). E in particolare, nessun cambio di direzione repentino (equivalente ad andare a zig-zag, invece che seguire la strada più breve, per metterla in termini molto semplicistici).

Il problema, dunque, ricade nel costruire razzi sufficientemente stabili da mantenere l'assetto anche senza SAS (e quindi senza le azioni di controllo che esso eserciterebbe). La simmetria è importante, certo, ma occorre anche qualche accorgimento circa la statica e gli effetti dinamici di portanza e attrito, nonchè circa il modo in cui la distribuzione del peso varia durante l'ascesa (e quindi come si sposta il centro di massa).

Spero di non annoiare con quanto segue:

1) staticamente, i razzi sono instabili, il loro centro di massa (CoM) è sempre avanti rispetto al centro di spinta (CoT). Quindi, ogni minima variazione di assetto rispetto alla direzione "prograde", comporta un aumento della rotazione ad accentuare l'errore. Questo effetto è in realtà quello che permette la rotazione del gravity turn.

2) dinamicamente, i razzi sono tanto più stabili quanto più il CoM è avanti rispetto al centro di pressione (CoP, praticamente corrisponde col CoL per quanto riguarda le superfici portanti). Se troppo avanti, anzi, il razzo diventa "rigido" e si comporta come una freccia, quasi impossibile da far deviare. Pertanto, la distanza CoM-CoP deve essere scelta adeguatamente.

3) quanto precede si modifica durante il volo con il consumo dei combustibili ed il distacco degli stadi usati. La stabilità deve essere garantita durante tutto il volo, e questo comporta scelte per quanto riguarda la conformazione del razzo e le parti da usare.

Se si è costruito un razzo stabile secondo i punti precedenti, non sarà necessario il ricorso al SAS per mentenerlo in traiettoria, tenderà naturalmente a tenere il naso in direzione prograde a meno di un eventuale piccolo errore. In tal caso, basterà applicare una lieve rotazione nella direzione voluta (in genere Est, heading 090) poco dopo il lancio, per vederla aumentare progressivamente mentre il razzo accelera a sale in quota. Nel caso "teorico" di una rotazione esattamente pari a quanto necessario, il razzo arriverà in posizione orizzontale proprio quando raggiunge la quota orbitale stabilita e la velocità orbitale. Se la rotazione fosse insufficiente, è in genere possibile ridurre o temporaneamente annullare la spinta, per riprenderla quando opportuno (con un poco di pratica, si nota quando meglio dare "gas", ovvero quando la direzione prograde è abbastanza prossima all'orizzonte per aumentare la velocità di quanto necessario, ma sempre prima di raggiungere l'Apoapside. Se la rotazione è eccessiva, l'unica è usare sistemi di controllo per cercare di ridurla. Ovviamente, dare alla traiettoria l'inclinazione corretta (tipo esattamente 0° con Heading 090) può richiedere qualche correzione, perchè un piccolo errore sarebbe anch'esso progressivamente aumentato.

Ora, i "professionisti" delle agenzie aerospaziali programmano precisamente il profilo di ascesa, quindi la rotazione che il razzo deve aver assunto ad ogni punto della traiettoria è calcolata in anticipo ed usata come parametro di controllo (per l'autopilota). L'approccio in pratica è senz'altro quanto usa MechJeb, solo che con un profilo di volo preciso, le correzioni saranno talmente ridotte da avere pochissima differenza rispetto ad un volo con "gravity turn" puro.

Link to comment
Share on other sites

Non mi hai assolutamente annoiato, anzi apprezzo veramente lo sforzo che hai fatto per cercare di rispondermi in maniera così approfondita. Quindi credo di aver capito che il segreto per avere un razzo aerodinamicamente stabile (con FAR) è trovare la giusta distanza tra CoM e CoL. Il problema è che ogni mio razzo, se lanciato senza SAS, tende a deviare irrimediabilmente, variando non soltanto l'angolo di pitch e yaw, ma anche quello di roll, ed è questo fatto in particolare ad incuriosirmi. Non riesco proprio a capire come calcolare i valori correttamente per avere un razzo stabile.

Link to comment
Share on other sites

Beh, se hai problemi, puoi provare a farmi avere il file .craft del razzo che usi. Giusto per provare, vedi cosa succede con questo, è intrinsecamente stabile e (con FAR) si riesce a fargli fare un bel gravity turn impartendogli una rotazione di circa 1,5° appena dopo il lancio (ovviamente, senza SAS). Come potrai notare, non ha sistemi di controllo a parte la reaction wheel interna al pod di comando, quindi anche volendo non potrebbe essere corretto di molto. A seconda della velocità di rotazione impressa con la manovra iniziale, ti puoi accorgere di come proceda il turn. Per me dà ottimi risultati appunto facendolo ruotare a 88,5° di pitch (-1,5° di rotazione) subito, dovresti vederlo ruotare a 80° a circa 600m di quota, a 70° a circa 2700m, a 60° circa a 7800m, a 50° intorno a 18000m. Successivamente guardo l'apoapside, per cui riduco spinta se ci sta arrivando troppo in fretta, per ridarla prima di raggiungerlo comunque con pitch ancora sopra a 0°, a quel punto la spinta è praticamente orizzontale e serve ad ottenere la velocità orbitale (Nota). Come potrai notare, non eseguo alcuna correzione alla direzione del razzo durante il volo, dopo la rotazione iniziale (tuttavia potrebbe essere necessaria una piccola correzione in yaw per correggere l'inclinazione della traiettoria, se l'heading non è quello desiderato). Non ruota in yaw da solo (essendo perfettamente simmetrico non risente di forze che possano causare cambiamenti in yaw, ovvero creare angoli "sideslip" laterali rispetto all'orientazione prograde); talvolta può prendere una piccola rotazione in roll (facilissima da correggere, e non influisce sull'efficienza del lancio), la cui causa è sconosciuta (possibile sia dovuta ad errori di arrotondamento nel calcolo delle forze agenti sulle superfici alari).

Consiglio prima di provarlo in volo, per farsi un'idea di come si comporta. Quindi, di caricarlo nell'editor (VAB), per vedere come sono posizionati CoM e CoL su ciascuno degli stadi: questo dovrebbe darti un'idea di cosa dovresti cercare di ottenere. Per quanto riguarda il CoM, sarebbe opportuno visualizzarlo non solo a serbatoi pieni, ma anche con serbatoi vuoti per ogni stadio: molti velivoli sembrano stabili a pieno carico ma diventano instabili coi serbatoi vuoti.

Nota: con circa 2°-2,5° di rotazione iniziale, si otterrebbe un profilo talmente arcuato da non dover ridurrre spinta prima di raggiungere la velocità orbitale. Tuttavia, in tal modo la velocità diventa molto elevata quando il razzo si trova ancora ad altitudine ridotta (quindi, atmosfera densa), per cui l'attrito diventa troppo elevato. Usando KSP 0.90 e l'add-on "Deadly Re-Entry" (oltre a FAR), quell'attrito è anche sufficiente a far disintegrare il razzo.

P.S.: per vedere meglio l'angolo di pitch, invece di usare la NavBall standard in KSP, si può ricorrere ad alcuni add-on. Io trovo molto utile usare lo HUD di SteamGauges.

Link to comment
Share on other sites

  • 2 weeks later...

Ho provato il tuo razzo ed è stato fondamentale per farmi un'idea sulla distanza ottimale tra CoL e CoM. Quindi ne ho costruito uno tutto mio, e funziona a meraviglia: senza toccare i comandi, senza SAS, dopo i 5km di quota, ho ottenuto un'orbita inclinata di soli 1,9°, conservando a fine circolarizzazione più carburante di quanto avesse fatto MJ con lo stesso razzo, con i parametri consigliati da ferram (TWR: 1,25; turn shape: 50%; turn start: 1.4km). Veramente fantastico. Soltanto che per avere una stabilità ottimale è stato necessario mettere winglets (fisse) anche sul secondo stadio, che esteticamente non sono proprio il massimo. Anche perché non mi viene in mente nessun razzo IRL che abbia un design del genere. Come fanno le grandi agenzie spaziali a ottenere la stabilità ottimale senza? E poi, da quello che ricordo, lo SMAP lanciato a fine gennaio non ne aveva nemmeno una...

Link to comment
Share on other sites

Ho provato il tuo razzo ed è stato fondamentale per farmi un'idea sulla distanza ottimale tra CoL e CoM. Quindi ne ho costruito uno tutto mio, e funziona a meraviglia: senza toccare i comandi, senza SAS, dopo i 5km di quota, ho ottenuto un'orbita inclinata di soli 1,9°, conservando a fine circolarizzazione più carburante di quanto avesse fatto MJ con lo stesso razzo, con i parametri consigliati da ferram (TWR: 1,25; turn shape: 50%; turn start: 1.4km). Veramente fantastico. Soltanto che per avere una stabilità ottimale è stato necessario mettere winglets (fisse) anche sul secondo stadio, che esteticamente non sono proprio il massimo. Anche perché non mi viene in mente nessun razzo IRL che abbia un design del genere. Come fanno le grandi agenzie spaziali a ottenere la stabilità ottimale senza? E poi, da quello che ricordo, lo SMAP lanciato a fine gennaio non ne aveva nemmeno una...

Bene, sono felice che ora ti riesca di realizzare il gravity turn come previsto. Era questo l'obiettivo, ed una volta acquisita l'idea di come rendere stabile un razzo, la si può applicare per ogni veicolo.

Circa la domanda, perchè i veicoli spaziali "veri" non hanno alette sul secondo stadio? In realtà in KSP l'atmosfera è ancora troppo densa alla quota a cui avviene la separazione del primo stadio col razzo che ho usato come esempio (non che sia sbagliata la densità dell'atmosfera, ma lo è l'efficienza dei motori ed il rapporto peso massimo/peso vuoto degli stadi). Con atmosfera densa, l'effetto stabilizzante delle alette è predominante su altri (come pure l'effetto di deportanza dovuto all'angolo di attacco, che farebbe ribaltare il razzo se non stabile). I veicoli "veri" invece separano il primo stadio ad una quota alla quale la densità atmosferica ha ormai un effetto minore, e per stabilizzare il veicolo conviene usare razzi vernieri. Naturalmente, è una tecnica che si può benissimo usare anche in KSP, ma sarebbe da valutare bene se il peso addizionale dei vernieri ed il consumo di combustibile do loro usato sia conveniente rispetto all'uso delle alette.

(Nota: queste valutazioni andranno riviste con KSP 1.0, ci si aspetta una nuova aerodinamica e comportamento dei motori più realistici di quanto ottenuto fino a KSP 0.90, per cui l'uso appropriato di alette e razzi potrebbe rispecchiare meglio la realtà).

Link to comment
Share on other sites

Ah, quindi nella realtà si usano espedienti analoghi all'RCS in game? E io che pensavo che fosse da niubbi...

Comunque, adesso che ho capito almeno in minima parte come avviene il gravity turn vorrei provare ad applicarlo a kOS, più per essere preciso nella manovra che per automatizzare il lancio. Ho già fatto svariati tentativi, il mio programma consiste in un "wait until velocity > 100m/s, lock steering to heading (90, 85-88.5), wait 5" e l'esito è sempre lo stesso: non appena l'autopilota di kOS si disattiva, il razzo sussulta in maniera innaturale (o forse soprannaturale con la magia delle reaction wheels di KSP) e ottengo heading e rotation assurdi, completamente deviati. Secondo te è possibile automatizzare la manovra, creando ogni volta un programma apposito per veicolo?

Link to comment
Share on other sites

Ovviamente, l'uso di qualsiasi autopilota comporta correzioni all'assetto in volo, pertanto non si può più parlare di gravity turn (in cui l'assetto è solo dovuto alle forze di gravità ed aerodinamiche). Tuttavia, un controllo d'assetto è fondamentale almeno per correggere le deviazioni rispetto al profilo di volo desiderato. Un profilo di volo ideale deve essere simile a quanto si avrebbe col gravity turn, questo profilo ideale deve essere precalcolato ed usato come riferimento per applicare le correzioni (ossibilmente minime) durante il volo.

La maggior difficoltà è stabilire il profilo ideale, generalmente espresso come successione di valori di pitch e throttle a diverse altitudini e tempi di volo. Dato che usi anche MechJeb, conosci sicuramente i profili di volo dell'Ascent Guidance. In realtà però, il profilo corretto è dipendente dal valore di TWR in ogni momento del volo (TWR elevato comporta maggiore velocità ed altitudine in ogni istante di volo, la maggior velocità significa maggiori effetti aerodinamici e quindi rigidità del veicolo se aerodinamicamente stabile), e come già visto dalla distanza CoM-CoP (per dirla tutta, CoM-CoP è uno dei fattori del momento d'inerzia longitudinale (J), e l'accelerazione istantanea in pitch è dovuta alle forze agenti (gravità sul CoM, drag sul CoP) diviso J). In breve, il profilo di volo ideale dipende da come cambiano nel tempo e nello spazio TWR e J, che sono legate allo specifico veicolo.

Premetto che la determinazione teorica del profilo ideale è sicuramente possibile in KSP (viene fatta in realtà), usando sistemi di calcolo che integrano nel tempo i risultati di una serie di equazioni. Purtroppo, sebbene conosca alcuni programmi che calcolano profili di volo in KSP (ma non con FAR!), non ne ho visto alcuno che realizzi il profilo ideale.

L'alternativa alla determinazione teorica del profilo è l'uso della simulazione. Dovresti lanciare il tuo veicolo diverse volte, lasciandogli fare il gravity turn naturale, ogni volta registrando il volo. E' opportuno usare un add-on che consenta facilmente di visualizzare parametri di volo istantanei (ce ne sono molti, es. KER, VOID). I parametri fondamentali sono l'angolo di pitch e l'altitudine; ma è opportuno anche registrare velocità, tempo di volo.

Dato che il veicolo non viene guidato, non si otterrà esattamente il profilo di volo voluto in alcuno dei lanci simulati. Ma quando si abbiano almeno 2 lanci che approssimano abbastanza bene cosa si vuole ottenere, si possono usare i parametri di questi, e per interpolazione trovare i parametri che corrisponderebbero al profilo ideale (es. di interpolazione, se con il lancio 1 il veicolo arriva ad apoapside = 70Km, con il lancio 2 arriva a 90Km, e voglio ottenere 80Km, userò valori di pitch ad ogni altitudine che siano la media tra quelli del lancio 1 e quelli del lancio 2).

L'uso di KoS a quel punto è "banale". Basta programmare uno script che includa i valori di riferimento nel loop di controllo. Qui uno scritto molto tempo fa (e molte versioni di KoS fa, funzionava con KSP 0.23), giusto come esempio (l'obiettivo allora era di realizzare un profilo non ideale, ma prestabilito, per la verifica di un programma che calcolava le prestazioni massime nell'ascesa di razzi). In quello script, nelle prime linee, sono riportati i valori prestabiliti di pitch (P1..P5), altitudine (H1..H5), throttle (T1..T5), per 5 punti "di riferimento". Nella tratta tra ciascuna coppia di punti, il programma interpola continuamente il valore di pitch in base all'altitudine istantanea, basandosi sui valori dei punti di riferimento. Il valore istantaneo di pitch è quindi applicato (insieme all'heading) all'autopilota. Sicuramente alcune parti non funzionano più, ma spero tu possa cogliere l'idea in generale.

Link to comment
Share on other sites

  • 2 weeks later...

Seguendo i tuoi consigli, per la prima volta sono riuscito a mandare in orbita un razzo con equipaggio in Realism Overhaul. Il gravity turn sicuramente permette di risparmiare tantissimo carburante. Grazie mille! :D

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...