Acquisizione e Controllo Dati per il Testing del Primo Motore a Razzo Bi-Liquido Italiano

Il Team Skyward Experimental Rocketry ha sviluppato e testato con successo Aeneas, il primo motore a razzo bi-liquido in Italia sviluppato e realizzato da studenti. Sfruttando la piattaforma IOLITE di Dewesoft, il team ha costruito un avanzato sistema di acquisizione e controllo dati per gestire le operazioni critiche di test del motore a razzo con precisione e sicurezza. Questo traguardo segna un passo significativo nell'educazione pratica alla propulsione a razzo e apre la strada a futuri progetti di motori stampati in 3D e raffreddati rigenerativamente.

Skyward Experimental Rocketry è un'associazione studentesca fondata nel 2012 presso il Politecnico di Milano (PoliMi), in Italia. Permette agli studenti di approfondire argomenti trattati in classe competendo anche a livello internazionale. Skyward conta circa 170 membri e consulenti esterni, di cui poco meno di 100 lavorano attivamente a progetti in corso.

Ogni anno, il team partecipa ad EuRoC, una competizione europea annuale di razzistica sperimentale. È organizzata dall'Agenzia Spaziale Portoghese in collaborazione con diverse industrie private del mercato aerospaziale.

Forte di due primi posti e vari premi, il team Skyward non si è mai tirato indietro di fronte a nuove sfide. Quest'ultimo progetto simboleggia la volontà dell'associazione e del dipartimento di propulsione nell'affrontare un nuovo tipo di motore e una nuova tecnologia.

Il Motore a Razzo Bi-Liquido

I motori a razzo chimici operano convertendo l'energia chimica immagazzinata in un combustibile e in un ossidante in un gas di scarico ad alta velocità che viene espulso dal sistema, creando spinta.

La differenza tra motori solidi, ibridi e bi-liquidi risiede principalmente nel modo in cui il combustibile e l'ossidante sono immagazzinati:

• Motori Solidi: Presentano una carica solida dove combustibile e ossidante sono pre-miscelati. Una volta che accendiamo questa carica, è quasi impossibile spegnerla e non possiamo eseguire la regolazione della spinta (throttling).

• Motori Ibridi: Rappresentando un passo avanti in termini di flessibilità, questi motori immagazzinano o il combustibile o l'ossidante in un serbatoio in forma liquida o gassosa, mentre l'altro componente è in forma solida all'interno della camera. Di conseguenza, possono essere spenti e riaccesi. Anche la regolazione della spinta è possibile.

• Motori Bi-liquidi: Come suggerisce il nome, immagazzinano sia l'ossidante che il combustibile in forma liquida. Offrono la massima flessibilità operativa, combinando tutte le convenienti caratteristiche della propulsione ibrida (riaccensione, controllo di spinta) con le migliori performance in termini di efficienza e spinta massima.

Quindi, perché costruire un motore a razzo bi-liquido? Sebbene un motore così avanzato non sia necessario per i modesti requisiti di apogeo della competizione, l'obiettivo di Skyward è sempre stato quello di permettere agli studenti di mettere in pratica le loro conoscenze. Questa missione, unita a un efficace trasferimento di conoscenze tra membri senior e junior, si traduce in progetti che avanzano costantemente nel loro livello tecnico.

Il motore Aeneas opera con protossido di azoto come ossidante ed etanolo come combustibile. Entrambi sono immagazzinati in serbatoi di alluminio SRAD (Student Researched and Developed) che, dopo la fase di rifornimento, sono pressurizzati con azoto immagazzinato in un serbatoio commerciale.

In termini generali, le fasi che compongono un test sono:

• Assemblaggio e preparazione del banco prova

• Integrazione del motore e dell'elettronica: Il motore e tutti i componenti correlati sono integrati nel banco prova, e l'hardware per il controllo e l'acquisizione è integrato e verificato.

• Rifornimento: Dopo che tutto è stato montato e controllato, si procede con il rifornimento di etanolo e protossido di azoto, seguito dalla pressurizzazione dei serbatoi tramite azoto.

• Sparo: Quando tutte le verifiche e le operazioni precedenti sono state completate, si accende il motore.

• Messa in sicurezza: Dopo lo sparo, tutti i sistemi sono depressurizzati e i serbatoi di stoccaggio sono disconnessi.

• Valutazione delle performance: I dati acquisiti sono analizzati per valutare le metriche di performance.

Di queste fasi, cinque su sei richiedono un qualche sistema di acquisizione e controllo. È qui che entra in gioco Dewesoft. Tutto l'hardware e il software responsabili di queste operazioni rientrano sotto il nome di "Avionica di terra" (Ground segment avionics).

Avionica di Terra (Ground Segment Avionics)

L'avionica di terra è usata per interfacciare tutti i vari sottosistemi tra di loro. È di primaria importanza in quanto abilita l'acquisizione dati ed il controllo durante test di ogni tipo.

Tipicamente, Skyward sviluppa il proprio sistema avionico, dal software all'hardware; questo progetto rappresenta un'eccezione.

Requisiti di Sistema

Innanzitutto, vengono elencati i requisiti per il sottosistema dell'avionica di terra:

Funzionali

• In grado di attuare otto valvole pneumatiche

• In grado di alimentare l'accenditore

• In grado di campionare 11 trasmettitori di pressione

• In grado di campionare una cella di carico

• In grado di campionare otto termocoppie

• In grado di campionare una misura di corrente

Sistema

• Operabile da remoto

Performance

• In grado di acquisire tutti i canali disponibili allo stesso tempo, con una frequenza di almeno 100 Hz (o minore quando limitata dal trasduttore stesso)

Scelta della Piattaforma

Si può soddisfarre l'intera lista dei requisiti utilizzando un controllore logico programmabile (PLC) e un sistema di acquisizione dati (DAQ). Dopo una breve revisione delle soluzioni più comuni disponibili sul mercato, quella che si è distinta è stata la piattaforma IOLITE MODULAR DAQ.

Le ragioni dietro a questa scelta sono molteplici, ma possono essere riassunte in due categorie: 1) le capacità hardware e software del sistema e 2) la previa esperienza e le relazioni con Dewesoft.

Dewesoft has been the DAQ of choice for propulsion ground testing measurements in Skyward since 2022. During this period, the team gained extensive experience with both hardware and software and had the opportunity to verify the high quality of the devices.

Dewesoft è la scelta per le misure e test a terra della propulsione in Skyward dal 2022. Durante questo periodo, il team ha acquisito una vasta esperienza sia con l'hardware che con il software ed ha avuto l'opportunità di verificare l'alta qualità dei dispositivi.

I dispositivi usati fino ad ora, Dewesoft IOLITE 6xSTG e IOLITE 8xTH, erano stati però solo usati per acquisizione dati passiva, mentre per il progetto in atto, anche il controllo è un requisito. Fortunatamente, la linea IOLITE presenta moduli di output digitale.

In conclusione, il rapporto in corso e gli anni di utilizzo di successo dei dispositivi Dewesoft l'hanno resa la scelta più logica.

Architettura del Sistema di Test del Razzo

Dopo aver revisionato i vari dispositivi disponibili ed essersi confrontati con il team Dewesoft, abbiamo selezionato lo IOLITE R8 chassis, equipaggiato con:

• Modulo IOLITEir-8xTH

• Modulo IOLITEr-16xLV

• Modulo IOLITEir-32xDO

Questi moduli permettono al dispositivo di effettuare tutte le misure elencate nei requisiti e, allo stesso tempo, fornire un interfaccia di output digitale per affrontare le esigenze di controllo. I moduli IOLITE offrono anche alte frequenze di campionamento fino a 20 kHz per canale.

Le valvole pneumatiche in uso nel banco prova richiedono, come suggerisce il nome, aria compressa per essere operate. Questa operazione può essere gestita utilizzando valvole solenoidali per chiudere ed aprire un circuito di aria compressa alimentato da un compressore esterno.

Infine, l'accenditore richiede una corrente continua (DC) per alimentare un filo di nichel-cromo che, per l'effetto Joule, accenderà la carica pirotecnica.

Il sistema mostrato si compone di:

• Un PC con DewesoftX per controllare l'IOLITE R8,

• L'unità IOLITE R8,

• Una scatola di pneumatica per contenere tutte le valvole solenoidali che, una volta attivate, forniscono aria compressa alle valvole pneumatiche (incluse all'interno della "test facility"); questa scatola contiene anche l'alimentazione e uno shunt per la misura di corrente dell'accenditore, e

• Il banco prova (test facility) che include il motore, le linee di fluidica e tutti i dispositivi necessari ad operarli.

Scheda di Espansione

Nonostante il modulo 16xLV fornisca abbastanza input da accomodare tutti i trasmettitori elencati nei requisiti, non è direttamente compatibile con i trasmettitori utilizzati.

Questo modulo specifico è in grado di leggere tensioni nei range 10 V e 200 V, mentre i trasmettitori di pressione impiegati hanno un output nel range 4-20 mA e richiedono alimentazione (eccitazione) esterna.

Inoltre, mentre il modulo 32xDO può assorbire fino a 0.5 A in modalità "switch", può fornire solo 2 A in uscita all'utente. Fare riferimento al Manuale Utente del Software DewesoftX per le istruzioni sulla configurazione Digital Out in DewesoftX. Questa corrente non è sufficiente per alimentare tutte le valvole contemporaneamente.

Per fornire più potenza, è necessario un alimentatore esterno. A meno che l'IOLITE e l'alimentatore esterno non siano connessi alla stessa terra, saranno necessari relè di qualche tipo per controllare le valvole solenoidali.

Infine, l'accenditore stesso dovrebbe assorbire tra 2 A e 5 A, rendendo necessario un relè.

È quindi chiaro che è necessaria una qualche scheda di espansione esterna per interfacciare i moduli IOLITE con il resto dell'avionica. Abbiamo compilato una breve lista di requisiti che questa scheda deve soddisfare. 

La scheda di espansione deve:

Funzionali

• Essere in grado di fornire alimentazione a 11 trasmettitori di pressione

• Essere in grado di leggere l'output in corrente da 11 trasmettitori di pressione

• Essere in grado di controllare 8 (valvole) + 1 (accenditore) carichi esterni

• Essere alimentata con l'uscita disponibile fornita dai moduli IOLITE

• Fornire alimentazione alla cella di carico

Sistema

• Integrarsi fisicamente ed elettricamente con i moduli IOLITE

• Implementare connettori di facile utilizzo

• Non interferire elettricamente con la scocca dell' IOLITE

Performance

• Massimizzare il range di input in tensione per ogni trasmettitore

Abbiamo quindi progettato la scheda seguendo i requisiti, ottenendo una PCB con quattro sezioni principali:

1. L'alimentazione a 24V è fornita dai moduli IOLITE (con il relativo condensatore di disaccoppiamento), e questa tensione è fornita direttamente ai trasmettitori di pressione. La corrente richiesta dal trasmettitore passa poi attraverso il resistore di shunt da 499 Ω. Questo valore è selezionato per massimizzare il range di 10 V dell'input analogico sull'IOLITE. Sebbene tecnicamente lo shunt dovrebbe essere da 500 Ω, la variante da 499 Ω costa significativamente meno quando è richiesta un'accuratezza dello 0.01%. Questa sezione copre 12 dei 16 canali di input del 16xLV; gli altri quattro sono lasciati come semplici letture di tensione.

2. Ancora una volta, i 24V forniti dai moduli IOLITE sono instradati per alimentare una serie di relè allo stato solido. Questa alimentazione è poi scaricata nei pin di output digitale del modulo 32xDO. Ogni volta che un canale di questo modulo è attivato, il relè è attivato ed il circuito dall'altra parte, ad esempio le valvole solenoidali, è chiuso. Resistori da 1 kΩ sono posti in serie con i relè per garantire una corretta tensione di alimentazione (per abbassare la tensione in entrata a quella da specifica).

3. Qui, in modo analogo alla seconda sezione, i relè sono connessi al modulo 32xDO. La Figura 2 mostra che ne abbiamo montato solo uno. Questa volta, il relè è meccanico e richiede quindi un diodo tra i suoi input; inoltre, lo alimentiamo direttamente a 24V. Abbiamo utilizzato questo componente per commutare la potenza che guida l'accenditore al posto della controparte a stato solido a causa del suo limite di corrente più elevato. 

4. La sezione finale presenta una pompa di carica (charge pump) e relativi componenti. Qui, la tensione di alimentazione principale è ridotta a 5V utilizzando un regolatore LDO, che alimenta poi la pompa di carica che emette ±5V per alimentare la cella di carico.

La Campagna di Test

L'obiettivo finale del progetto è testare e validare il motore, cosa che eseguiamo effettuando i cosiddetti Static Fire Tests (SFTs). La Figura 5 mostra il banco prova, che ospita i serbatoi dei propellenti, il motore e tutte le tubazioni richieste sia per le fasi di rifornimento che di sparo. Inoltre, contiene tutto l'hardware di acquisizione e controllo descritto finora.

Setup di Acquisizione e Controllo Dati

Il setup DewesoftX impiegato riflette le due fasi principali del test: rifornimento e sparo. Abbiamo progettato due diverse schermate (display), entrambe accessibili simultaneamente, utilizzando una configurazione a monitor multipli.

La Figura 6 mostra la prima schermata che presenta i widget "Recorder", "Digital meter" ed "Input control" affiancati da caselle di testo per aumentare la chiarezza durante le operazioni. 

The input controls directly link to the digital output channels on the 32xDO module, which, in turn, operate the relays present on the expansion board. We set some input controls to the “Switch” type, while others to “Push button”; this choice reflects the nature of the operation control. 

I controlli di input si collegano direttamente ai canali di output digitale sul modulo 32xDO che, a sua volta, operano i relè presenti sulla scheda di espansione. Abbiamo impostato alcuni controlli di input sul tipo “Switch”, mentre altri su “Push button”; questa scelta riflette la natura del controllo operato.

I comandi operati tramite push button sono quelli di venting dei serbatoi del combustibile e dell'ossidante; queste valvole necessitano spesso di essere operate in brevi raffiche, un compito che è più facilmente realizzabile con l'interfaccia push-button. Ciononostante, anche durante l'acquisizione, possiamo cambiarli per accomodare switch o altri tipi di input se necessario.

Una volta che uno di questi input è attivato, il circuito che alimenta i relè sulla scheda di espansione si chiude, attivando così il dispositivo connesso.

La Figura 7 mostra la seconda schermata utilizzata durante le operazioni di test di sparo. Non è dissimile dall'altra; aggiunge “Lamps” per monitorare facilmente lo stato di valvole critiche che dobbiamo osservare durante il test, insieme a un “Digital meter” per il monitoraggio delle temperature.

Infine, per ottenere una corretta accensione, dobbiamo aprire la valvola dell'ossidante circa 250 millisecondi dopo quella del combustibile. Se questa sequenza non è rispettata o se la temporizzazione è significativamente errata, c'è il rischio che l'ossidante raggiunga la camera prima del combustibile, permettendo al protossido di azoto di iniziare a decomporsi esotermicamente e potenzialmente portare ad un esplosione (detonazione). Questa sequenza è quindi di estrema importanza.

È chiaro che un operatore non può eseguire tale operazione in modo affidabile. Pertanto, viene automatizzata.

La Figura 8 mostra un "User inputs" custom, nominato “FIRE”; useremo questo controllo per l'automazione della sequenza di accensione.

Di conseguenza, un canale nominato “FIRE_DELAYED” è creato usando il modulo “Math”; questo canale non è altro che il segnale FIRE ritardato di 250 millisecondi.

Infine, la sequenza di automazione vera e propria è programmata usando il modulo “Alarms”. Ogni volta che l'operatore attiva il canale FIRE tramite uno switch, la valvola MAIN_FUEL viene attivata. 250 millisecondi dopo, anche il canale FIRE_DELAYED e quindi la valvola MAIN_OX vengono attivati. 

Entrambe le valvole vengono poi chiuse automaticamente dopo un tempo prestabilito.

Risultati dei Test e Post-Processing dei Dati

Dopo alcuni test iniziali ed il debug, il team è riuscito a testare con successo il motore ed i suoi sistemi di supporto. I sistemi di acquisizione dati e controllo hanno funzionato come previsto, registrando tutti i dati correttamente entro le specifiche.

Come menzionato in precedenza, l'obiettivo principale di questa campagna di test era valutare le performance del motore, e la maggior parte dei parametri in merito possono essere derivati dalla pressione in camera, dalle portate massiche di ossidante e combustibile e dalla spinta.

Per prima cosa, abbiamo esportato i dati grezzi in un formato idoneo usando DewesoftX. Successivamente, selezioniamo il periodo di interesse i dati sono filtrati.

Infine, i dati filtrati sono usati per calcolare i suddetti parametri di interesse (le portate massiche, per esempio, sono calcolate usando le misure di pressione e temperatura campionate su un tubo di Venturi appositamente sviluppato dal team).

Uno dei principali vantaggi di un motore bi-liquido pressurizzato è che, se operato correttamente, può mantenere una pressione in camera quasi costante, fornendo così una spinta approssimativamente costante. Le Figure 12 e 13 lo illustrano; dopo un transitorio iniziale (deliberatamente prolungato per scopi di accensione), la pressione e la spinta rimangono pressoché costanti.

Dopo aver calcolato le portate massiche di ossidante e combustibile, calcoliamo l'OF (Oxidizer-to-Fuel ratio - rapporto ossidante/combustibile). Questo parametro è di estrema importanza per valutare il corretto design degli iniettori e per valutare le efficienze del motore; la Figura 14 lo illustra.

Infine, l'efficienza di combustione può essere derivata; è definita come:

Dove $\eta_{cs}$ è l'efficienza della velocità caratteristica, $P_c$ è la pressione in camera di combustione, $A_t$ è l'area di gola dell'ugello, m è la portata massica totale (ossidante e combustibile) e $c^*$ è la velocità caratteristica teorica, ed è calcolata tramite risolutori di equilibrio chimico — la Figura 15 presenta quindi l'unica incognita dell'equazione, $\eta_{cs}$.

Il valore medio, non considerando il transitorio iniziale, è leggermente inferiore all' 80%, sul lato inferiore del range atteso per questo parametro. Questo potrebbe essere dovuto a un miscelamento non ottimale tra ossidante e combustibile, ma anche una leggera sovrastima della portata massica può ridurre drasticamente questa efficienza. 

Alla luce del fatto che spinta e pressione corrispondono perfettamente ai valori di progetto, è probabile che errori di modello e varie assunzioni abbiano portato a una sovrastima della portata massica.

Conclusione e Sviluppi Futuri

Nonostante i problemi ed i contrattempi, siamo riusciti a condurre con successo test di sparo statico nominali ed a validare il design da diversi punti di vista.

L'implementazione e l'uso di Dewesoft come sistema di acquisizione e controllo dati sono stati di grande successo, consentendo test sicuri e affidabili.

Al momento della stesura di questo caso di studio, il team sta già implementando un'altra iterazione del motore, questa volta completamente stampato in 3D e raffreddato rigenerativamente.

Dewesoft sarà ancora una volta la scelta per l'avionica. Questa volta, puntiamo ad implementare algoritmi di controllo più complessi utilizzando le funzionalità di scripting C++ incluse in DewesoftX. Tuttavia, al momento della stesura, non è ancora possibile controllare direttamente i canali di output digitale tramite i plugin custom.

Un profondo ringraziamento è dovuto al team Dewesoft Italia, che, come sempre, si è dimostrato incredibilmente disponibile nel supportarci nei nostri sforzi. Senza di loro, questo progetto non sarebbe stato possibile.

Basato su lavoro originale di (in ordine alfabetico): 

• Chiara Conte, Team Member, Master's degree in Space Engineering 

• Gabriele Del Pelo, Team Member, Bachelor's degree in Aerospace Engineering 

• Daniele Fabbris, Project Manager, Bachelor's degree in Aerospace Engineering

• Christian Ferracane, Team Member, Bachelor's degree in Aerospace Engineering 

• Lorenzo Giaretta, Team Member, Bachelor's degree in Aerospace Engineering  

• Lorenzo Loria, Team Member, Bachelor's degree in Aerospace Engineering 

• Francesco Miccoli, Integrated Project Team Leader, Master's degree in Space Engineering

• Simone Modelli, Team Member, Master's degree in Space Engineering 

• Simone Nannetti, Team Member, Bachelor's degree in Aerospace Engineering

• Edoardo Nistri, Team Member and Advisor, Master's degree in Materials Engineering

• Marco Sangiorgi, Team Member, Bachelor's degree in Aerospace Engineering