sviluppo e realizzazione di un simulatore di volo per la ricerca

Saggiani, Liverani
Pag. 1 di 20
SVILUPPO E REALIZZAZIONE DI UN SIMULATORE DI
VOLO PER LA RICERCA
Gian Marco Saggiani
Alfredo Liverani
DIEM
Università degli studi di Bologna
Bologna, Italia
RIASSUNTO
Nel presente articoli viene riportato lo studio e lo sviluppo del simulatore di volo realizzato presso il
laboratorio del Corso Studi di Ingegneria Aerospaziale dell’Università di Bologna sede di Forlì. Il
simulatore è stato realizzato utilizzando la tecnica della “clustering elaboration”, con una
configurazione di cinque calcolatori. I software necessario è stato in parte sviluppato utilizzando
programmazione ad oggetti C++, in particolare per lo sviluppo della dinamica, ed in parte
programmato con l’utilizzo del sistema “LabView” che permette d’interfacciare la strumentazione
ed i sistemi dei comandi di volo. Una prima ricerca effettuata ha riguardato la possibilità di simulare
un sistema di controllo “fly-by-wire” sul simulatore. Una seconda ha riguardato la possibilità di
impiego delle tecniche di Realtà virtuale per migliorare la sensazione del pilota.
1
INTRODUZIONE
Nella presente lavoro si riporta l’attività di ricerca attualmente in atto presso i laboratori del Corso
Studi in Ingegneria Aerospaziale di Forlì per la realizzazione di un simulatore di ricerca. È
intendimento del gruppo di lavoro di poter utilizzare il simulatore in sviluppo non solo per attività
di ricerca, ma anche per attività didattiche all’interno di alcune materie che si svolgono presso il
Corso di Ingegneria Aerospaziale di Forlì.
Il simulatore è stato realizzato attraverso un insieme di PC della classe Pentium, attualmente sono 5,
con sistema operativo WindowsNT e DOS. Il software necessario è stato realizzato o in linguaggio
C++ o utilizzando il programma “LabView” particolarmente adatto alla gestione dell’acquisizione
dati e della strumentazione. Il cockpit è stato semplificato rappresentando buona parte della
strumentazione di bordo da un insieme di tre monitor, comandati da altrettanti Pc, mentre solo le
parti che richiedono un contatto fisico, ma comuni alla maggior parte degli aeromobili, quale la
pulsantiera o il volantino, sono state fisicamente realizzate. Tale sistema permette di poter simulare
un buon numero di velivoli, con la semplicemente riprogrammazione della strumentazione dei
monitor.
In Fig. 1 si ha la rappresentazione della attuale versione del simulatore.
Saggiani, Liverani
Pag. 2 di 20
Fig. 1: foto del simulatore
Sul simulatore realizzato sono state effettuate delle ricerche, di cui una prima ha visto la possibilità
di simulare un sistema “Fly-by-Wire”. In particolare, sono state sviluppate alcune routine scritte in
linguaggio LabView per simulare il comportamento di un FBW. Tale lavoro è stato preliminare ad
altri successive ricerche fra cui [Saggiani 2000].
In una seconda attività di ricerca, in collaborazione con una primaria ditta aeronautica, si è
verificato la possibilità di utilizzare tecniche derivate dalla Realtà Virtuale al fine di ridurre il costo
totale (acquisto e mantenimento) di un simulatore di volo completo. Due sono state le soluzioni
provate: una di tipo totalmente immersivo, nella quale un operatore può muoversi all’interno di un
cockpit virtuale, ed una di tipo semi-immersivo che permette di mantenere una elevata sensazione
di “presenza” pur riducendone i costi rispetto al primo tipo, grazie alla sua maggiore semplicità di
realizzazione.
Nella prima configurazione è stato realizzato un simulatore di volo composto da un casco,
opportuni guanti ed il cockpit consisteva semplicemente in un sedile: il resto del veniva simulato
via software. L’uso dei guanti dava al pilota la sensazione del contatto con la strumentazione (ad
esempio il contatto con una manopola o bottone). In tal modo il costo della costruzione del cockpit
viene minimizzato ed, inoltre, semplicemente per via software si potevano rappresentare diversi
aeromobili.
Nella seconda configurazione di tipo semi-immersivo viene ripristinata una configurazione parziale
del cockpit con realizzazione della cloche e degli altri sistemi fisici (pulsanteria, leve, ed altro). La
strumentazione di bordo viene realizzata via software e visualizzata con una serie di tre monitor. Il
casco viene sostituito con degli occhialini stereoscopici al fine di dare la sensazione della tridimensionalità del sistema.
2
HARDWARE E SOFTWARE DEL SIMULATORE
2.1
Layout generale del simulatore di volo
Il simulatore di volo realizzato presso i laboratori di Ingegneria Aerospaziale di Forlì segue la
configurazione ormai consolidata di molti simulatori di addestramento tipo FNTP II. Questo
simulatore, pur essendo stato progettato per sostenere un sistema per il full motion (simulazione dei
Saggiani, Liverani
Pag. 3 di 20
movimenti della cabina mediante sistema ad attuatori idraulici o elettrici), attualmente non dispone
di tale attrezzatura. È stato invece realizzato un sistema di “Force fedd-back” per il controllo sui
pedali e sullo stick.
A/C Model
(Look-up Table)
FORCE
FEED-BACK
Fig. 2. Schema a blocchi del simulatore di volo.
Come è visibile dalla Fig. 2, il pilota agisce su un set di comandi standard (throttle, stick, pedals e
trim) che forniscono, mediante scheda di acquisizione analogica/digitale, i dati di ingresso ai moduli
software dell’integratore delle equazioni di volo. Agenti esterni, quali wind shear,
malfunzionamenti simulati, informazioni accessorie, vengono programmati al pilota da una stazione
di controllo non rappresentata in figura. Un sistema audio si occupa di elaborare e diffondere i suoni
dei motori, dei fruscii aerodinamici, ed altro. Un modulo hardware sviluppato appositamente si
occupa infine di gestire gli interruttori e le manopole collegandosi ad un PC dedicato alla
acquisizione mediante connessione RS232.
2.2
Il “clustering elaboration”
Un simulatore di volo deve gestire in tempo reale numerose attività che risultano tutte onerose dal
punto di vista della potenza di calcolo:
1) integrazione delle equazioni della dinamica del volo e della dinamica dei propulsori
e sistemi (cicli iterati almeno 30 volte al secondo o più);
2) visualizzazione dello scenario esterno ad almeno 20 frames al secondo (questo
significa che il calcolatore è chiamato a renderizzare lo scenario 20 volte al secondo,
con un trasferimento di dati tra CPU e scheda grafica che può raggiungere i 6 Gb al
secondo per scenari ad alta risoluzione);
3) visualizzazione ad almeno 20 frames al secondo della strumentazione: 3 pannelli
frontali ed eventuali pannelli sul tunnel o laterali;
4) acquisizione degli input da stick, throttle e pedali;
Saggiani, Liverani
Pag. 4 di 20
5) retroazione analogica di forza su stick, throttle e pedali;
6) retroazione digitale sulle spie, sui display luminosi;
7) retroazione audio.
Secondo un noto ed apprezzato approccio all’high performance computing, che vede la sostituzione
del cosiddetto clustering all’impiego del supercalcolatore, il simulatore che è stato sviluppato presso
l’Università di Bologna, nei laboratori di Ingegneria Aerospaziale di Forlì, ha sistematicamente
impiegato tecniche di clustering per aumentare la potenza di calcolo e al tempo stesso contenere i
costi dell’hardware. Infatti un cluster è un sistema parallelo o distribuito all’interno del quale si
interconnette una serie di computer separati in una singola risorsa di elaborazione unificata. Nel
caso in questione si è scelto di impiegare una sistema basato su PC connessi tramite rete Ethernet al
fine di distribuire le risorse di calcolo. Nella attuale versione il simulatore è composto da 5 Personal
Computer della classe Pentium ognuno con un preciso compito:
•
•
•
•
un Pc dedicato alla integrazione della dinamica denominato “server” a cui è demandato anche il
compito dell’acquisizione dati dal cockpit, la retroazione con i cockpit, e la gestione e
smistamento dei dati che i vari Pc devono scambiarsi;
un Pc dedicato alla generazione delle immagini del volo denominato “visual”;
tre Pc dedicati alla generazioni delle immagini della strumentazione (prossimamente verranno
compattati in un unico sistema);
un Pc dedicato alla consolle istruttore.
Una grande attenzione dunque è stata posta nella programmazione del software che ha dovuto
rispettare le ovvie esigenze di “message passing”, ovvero di sincronizzazione dei vari tasks
distribuiti mediante l’invio in rete di pacchetti TCP/IP contenenti le informazioni necessarie al
funzionamento dei singoli processi (150 variabili di stato del sistema). Tale sequenza di pacchetti
permette di condividere tra le varie applicazioni i dati di volo, noti o calcolati. In appendice I si
trova la lista delle variabili scambiate tra i clusters.
La tecnica del “message passing”, nonostante richieda connessioni di rete estremamente veloci,
equivale dunque alla cosiddetta “shared memory” dei sistemi di calcolo dedicati, ma permette una
grande scalabilità e semplifica di molto la programmazione dei singoli tasks. Infatti il
programmatore non è più costretto alla programmazione di tipo multi-threading per ottimizzare le
prestazioni dei super-sistemi multiprocessore, ma deve più semplicemente progettare accuratamente
il set di variabili scambiate per ridurre il carico dell’I/O e può dedicarsi al perfezionamento dei
singoli applicativi. In figura 3 è riportato il layout del simulatore nella configurazione finale
prevista nella quale la strumentazione di bordo sarà gestita da un unico Pc e verrà implementata la
stazione instruttore.
La tecnica del “message passing” è stata usata per la visualizzazione della strumentazione di bordo,
che vengono rappresentati con l’utilizzo del programma “LabView”. Alla facilità della
realizzazione degli strumenti, si contrappone il basso “frame rate” delle immagini, con conseguente
mancanza di fluidità delle immagini. Questo problema è stato superato utilizzando il “message
passing”.
Saggiani, Liverani
Pag. 5 di 20
Visual
Distributed
DistributedSimulator
Simulatorlayout
layout
SimServer
Flight
Simulator
hardware
architecture
Instrument Panel
Data
item
Instructor Console
Fig 3: layout finale del simulatore
3
EQUAZIONI DELLA DINAMICA
Le routine per la simulazione della dinamica del volo sono state generate a partire dal programma
LaRCsim sviluppato internamente alla NASA, poi ampiamente modificato e ottimizzato
nell’implementazione specifica. Queste routine, scritte ora in linguaggio C++, implementano un set
di equazioni che descrivono il moto rigido di un aeromobile nell’atmosfera e per quote non elevate.
Il corpo rigido è rappresentato attraverso i sei gradi di libertà che lo rappresentano. I moduli di
calcolo tengono conto anche della geometria della terra, modellata come una sfera perfetta, della
gravità e dell’atmosfera.
Fin da subito si è fatta la scelta di semplificare il modello di calcolo del sistema imponendo le
ipotesi di Terra piatta e fissa, ovvero utilizzando come sistema principale d’inerzia un sistema di
riferimento Terra, di cui in Appendice II si riporta la definizione. Tale ipotesi è basata sulla scelta di
simulare attualmente voli le cui distanze siano contenute, tipo voli su campo, in quanto al momento
attuale non la simulazione di un volo da aeroporto ad aeroporto che interessa, ma la dinamica del
volo in sé. Al momento attuale si utilizzano in specialmodo voli attorno all’aeroporto di Forlì.
Essendo, comunque, possibile partire da qualunque punto della terra, è prevista la possibilità di
modellare la terra come sferica.
Il primo metodo utilizzato per l’integratore della dinamica utilizzava gli angoli di Eulero, ed in
Appendice II vengono riportate le equazioni utilizzate. Tale metodo presenta l’inconveniente che
per angoli di “Elevation” di ±90°, gli angoli di “Azimuth” e “Bank” non sono calcolabili. Tale
inconveniente non è significativo se si devono simulare degli aeroplani di tipo commerciali, nei
quali tali valori dell’angolo di Elevation sono praticamente impossibili.
Essendo, però, il simulatore realizzato a fini di ricerca, si è attuata la capacità di simulare anche
aeroplani acrobatici o militari e, pertanto, il metodo di Eulero non era adeguato. Si è, così,
modificato le routine della dinamica per incorporare il metodo dei quaternioni, di cui in Appendice
III si riportano le equazioni utilizzate.
Saggiani, Liverani
Pag. 6 di 20
In Figura 4 è riportato uno schema a blocchi del funzionamento del risolutore della dinamica
attualmente utilizzato. In Figura 5 è riportato uno schema parziale che evidenzia le variabili
considerate nell’integrazione..
Main
Initializations
SimTime = 0
false
tru
e
Sim Time < Flight Time
Calc. linear vel.
Calc. angular vel.
Calc. quat. rates
End
Calc. Euler
angles
Upd. Transf. matrix
Calc. External. F.
Calc.
accelerations.
Visual
Figura 4: schema dell’inetgratore della dinamica e del suo intefacciamento col programma di
visualizzazione
Tempo n-1
U,V,W,P,Q,R
Aerod. Forces
Tempo n
Y, Q,F
Eq. Delle Forze
U’
U
V’
V
W’
W
P’
P
Q’
Q
Engine Forces
P,Q,R
Aerod. Mom.
Engine Mom.
Y, Q,F
P,Q,R
U,V,W
Eq. Dei MOmenti
R’
Eq. cinematiche
Time integrator
R
Y’
Y
Q’
Q
F’
F
X’
X
Y’
Y
Z’
Z
Figura 5: schema del risolutore della dinamica.
Saggiani, Liverani
Pag. 7 di 20
L’algoritmo utilizzato per l’integratore nel tempo è quello di Adams-Bashford del 2° ordine
riportato nell’equazione seguente [McFarland 1975]:
Yn+1 = Yn +
4
(3Y&
n
− Y&n −1 ) ∆t
2
GLI STRUMENTI DI BORDO
La necessità di realizzare un modulo software per la visualizzazione degli strumenti di volo che
garantisse la massima flessibilità e semplicità di riconfigurazione, caratteristiche indispensabili in
un simulatore di volo per la ricerca e il training, ha portato all’impiego del programma Labview
della National Instruments, il quale implementa un ambiente di sviluppo di strumenti virtuali.
La programmazione di tipo completamente visuale, la facilità di implementazione di strumenti di
qualsiasi tipo, la disponibilità di strumenti già pronti, nonché l’integrazione con schede di
analogiche/digitali per l’acquisizione dalle periferiche di controllo (trasduttori potenziometrici
collegati alla manetta, ai pedali, ecc.) hanno consentito lo sviluppo di un set completo di strumenti
di volo accurato e funzionale.
Nel caso specifico i principali vantaggi di LabView sono stati:
• la semplicità d’uso in quanto, a differenza di altri linguaggi di programmazione, si
programma in modo grafico;
• la flessibilità nel disegno degli strumenti;
• il programma è espressamente studiato per gestire dati acquisiti dall’esterno sia attraverso
specifiche schede sia attraverso le porte seriali ed ethernet;
• la facilità d’integrazione con il tipo di comunicazione usato nel restante software presente
sul simulatore (comunicazioni tramite rete ethernet).
Questo tipo di programmazione, rispetto ad una basata sul testo, semplifica notevolmente il lavoro
del programmatore, ma di contro aumenta la richiesta di prestazioni del computer.
Accanto a questi vantaggi esistono, però, alcuni svantaggi che si possono così riassumere:
• gestisce bene la grafica 2D, ma meno bene la grafica 3D.
• richiede molte risorse hardware.
Tali svantaggi possono portare ad un basso frame-rate di generazione delle immagini della
strumentazione, con conseguente movimento a scatti delle immagini. Tale problema è stato risolto
con l’utilizzo di schede grafiche di ultima generazione.
Pilot
Co-pilot
Fig 6: “Instrument panel”
Saggiani, Liverani
Pag. 8 di 20
In figura 6 si ha l’“Instrument panel”, ovvero l’insieme degli strumenti che compongono il
cruscotto del simulatore.
Essi si dividono essenzialmente in due parti:
• strumenti di navigazione che danno la possibilità al pilota (o all’autopilota) di individuare
esattamente la posizione attuale dell’aeroplano e permettono la percorrenza di determinate
rotte; questi strumenti sono rappresentati negli schermi laterali, uno di fronte al pilota l’altro
di fronte al co-pilota;
• strumenti motore, con cui s’intende (forse in modo un po’ improprio), l’insieme degli
strumenti che monitorizzano il funzionamento dei motori, e sono rappresentati sullo
schermo centrale.
Ovviamente negli aerei sono presenti molti altri strumenti come ad esempio quelli per le condizioni
ambientali interne ed esterne all’aereo, che per semplicità non sono stati attualmente realizzati .
Come sugli aeroplani, gli strumenti di navigazione sono sdoppiati su i due pannelli posti ai lati
esterni del pannello strumenti: questo fa sì che entrambi i piloti abbiano sia la migliore visuale degli
strumenti, che la possibilità di regolare i propri strumenti in modo indipendente. Gli strumenti
motore, invece, posti centralmente e sono comuni ad entrambi i piloti.
Attualmente ogni singolo pannello è guidato da un Pc. È attualmente in studio la possibilità di usare
un unico computer per tutti e tre i monitor, utilizzando una scheda video multi–output oppure una
soluzione con più singole schede video. È altresì possibile introdurre la simulazione di strumenti
tipo “EFIS”.
5
SIMULAZIONE DI SISTEMI “FLY-BY-WIRE”
Una prima ricerca effettuata utilizzando il simulatore sviluppato, è stata relativa alla simulazione di
un sistema “Fly-by-wire”. Poiché il simulatore ottenuto è completamente aperto, è stato possibile
inserire un modulo di controllo FBW. Prima di ogni nuovo passo d’integrazione, il modulo FBW
acquisisce in input i dati provenienti dal volantino e dalle manette e altri dati che provengono dalla
simulazione dei sensori e degli strumenti giroscopici. In seguito elabora i comandi impartiti dal
pilota, depurandoli dai rumori, e invia i segnali alle routine che simulano gli attuatori delle superfici
di controllo. L’integratore, poi, procedere ad un ulteriore passo di calcolo.
La simulazione di un sistema FBW è comunemente impiegate per la progettazione e messa a punto
[Rogers 1999], ma richiede comunque alcune cautele. Innanzitutto l’integratore deve operare ad una
frequenza almeno di un ordine di grandezza superiore alla frequenza di funzionamento del FBW.
Nel nostro caso l’integratore funziona a circa 100 Hz, mentre l’FBW funziona a 20 Hz. Inoltre è
necessario simulare la risposta degli attuatori con i relativi ritardi e il rumore di misura dei sensori.
Quest’ultimo argomento è particolarmente delicato, in quando esistono dei sensori molto rumorosi e
dei sensori quasi esenti da rumori. Nel caso del controllo del pitch, le retroazioni che provengono
dall’integratore (e quindi dall’aeroplano simulato) sono il fattore di carico verticale (Nz o g), la
velocità di pitch (qdot), l’angolo di pitch (q) e l’angolo di incidenza (α o alfa). Questo approccio è
comune per il controllo del pitch nel FBW [Stowe 2000] e risale alle prime prove sul FBW [NASA
Report 1994].
In questo caso i dati relativi all’angolo di attacco o di incidenza sono ricavati dalle routines che
simulano la piattaforma inerziale, così come l’angolo di pitch e il carico verticale. Si tratta di
segnali quindi che nella realtà hanno il disturbo generato dalla “piattaforma inerziale”. Nel caso
invece del dato relativo all’inclinazione della barra o alla forza sul joystick il dato è molto “pulito”
in quanto la soppressione del rumore è facile già a livello del sensore.
Nei sistemi a multipla ridondanza, inoltre, è consigliabile che la ridondanza non si limiti ai soli
canali di controllo (di solito tre nei sistemi commerciali e quattro in quelli militari), ma anche nel
numero dei di sensori utilizzati. È bene che per ciascun canale gli input siano separati, ovvero
Saggiani, Liverani
Pag. 9 di 20
provengano cioè da sensori diversi, diverse piattaforme inerziali, in alcune casi anche di tecnologia
differente con rumore differenziato. In questo caso nel simulatore è necessario simulare il tipo di
sensore. Nel essendo disponibili sufficienti dati su questo tipo di problematica nella simulazione
conviene generare dei comuni rumori random di ampiezza regolabile.
Oltre a questi rumori, vi sono disturbi di altro genere, come ad esempio completa assenza di segnale
dovuta a una breve interruzione nelle comunicazioni tra sensore e computer di volo nel caso di
sensori dotati di convertitore DA (Digitale/Analogico) residente, a causa di falsi contatti, di
overflow del sensore o di guasto momentaneo. Vi sono inoltre i disturbi EM (ElettroMagnetici) il
cui livello varia in funzione di molteplici fattori interni ed esterni all’aeroplano e ai suoi impianti.
Grazie al simulatore è possibile rappresentare assai bene queste problematiche, piuttosto critiche nei
sistemi FBW [Ladkin 1998].
L’implementazione software di un FWB è realizzato mediante il programma LabView, in quanto
questo dispone di un “modulo PID” piuttosto efficiente. Per quanto riguarda il Flight Computer, nel
nostro caso, si tratta di un programma “ad hoc” realizzato come modulo “personalizzato” di
LabView. Nel lavoro [Saggiani 2000] viene presentata una ricerca relativa all’applicazione della
logica Fuzzy per migliorare la stima delle bande di oscillazione di accettabilità dei segnali
provenienti dai sensori.
6
LA VISUALIZZAZIONE IN REALTA’ VIRTUALE
In questo paragrafo viene illustrato lo sviluppo di ricerche sulla applicazione di tecniche di Realtà
Virtuale (VR) alla simulazione del volo per esplorarne le potenzialità. Tali ricerche sono condotte in
collaborazione con primarie aziende aeronautiche e si sviluppano in tre fasi:
1. Utilizzazione di un ambiente VR quasi totalmente immersivo per la simulazione del
combattimento aereo;
2. Utilizzazione di tecniche di visualizzazione stereoscopiche per lo sviluppo di cockpit per triner
di ultima generazione;
3. Utilizzazione della tecnica “CAVE” per la simulazione del volo (visual).
Queste tematiche di ricerca hanno in comune la dinamica del volo come riportato nel capitolo 3.
6.1
A m b i e n t i i m m e r s i v i e s e m i- i m m e r s i v i
Esistono sul mercato numerose attrezzature per la VR, ciascuna con caratteristiche e particolarità
interessanti. Normalmente i sistemi di VR vengono suddivisi partendo dal livello di immersività
che sono in grado di produrre: si intende per immersività la sensazione di presenza nell’ambiente
virtuale che l’operatore prova durante una sessione di lavoro. In particolare esistono sistemi
immersivi che rappresentano il livello più alto di coinvolgimento dell'utente nella realtà artificiale.
L’operatore viene isolato completamente dalla realtà fisica indossando un Casco con dispaly
incorporato (Head Mounted Display) o un monitor binoculare orientabile (come il BOOM della
Fakespace) che producono a brevissima distanza dagli occhi le immagini dell’ambiente virtual con
focali poste all’infinito. Questi dispositivi sono dotati solitamente di due mini-schermi, uno per
ciascun occhio, dotati di speciali ottiche per focalizzare e allargare il campo visivo percepito. Le
realizzazioni più economiche sono dotate di LCD displays, mentre altre usano i più prestanti, in
termini di risoluzione, CRT (tubi catodici).
Problemi di sicurezza, di costo, e di elevata potenza computazionale richiesta, hanno sicuramente
limitato lo sviluppo di questo tipo di applicazioni.
Lo sviluppo di sistemi di sistemi semi-immersivi ha avuto grande impulso soprattutto per la
necessità di ridurre le esigenze di elaborazione in tempo reale: gli elementi che appartengono alla
realtà fisica esterna all’operatore devono essere completamente “ricostruiti” nell’ambiente virtuale
Saggiani, Liverani
Pag. 10 di 20
con grande dispendio di risorse di calcolo (si pensi ad esempio alla rappresentazione delle mani).
Lavorare in un ambiente naturale (cioè reale) permette non solo di evitare una serie di
controindicazioni (nausea, perdita dell'equilibrio) tipiche dei sistemi immersivi attuali, ma permette
la collaborazione nel lavoro di più persone, pur avendo a disposizione una scena virtuale comune su
cui lavorare. In questi sistemi il metodo di visualizzazione tridimensionale comunemente adottato è
basato sulla stereoscopia attiva, ovvero vengono indossati occhiali dotati di otturatori a cristalli
liquidi opportunamente sincronizzati con il proiettore tramite comando a segnale infrarosso. La
posizione degli occhiali nello spazio è rilevata da un tracciatore 3D affinché il software riesca a
visualizzare le due immagini correttamente. In figura 7 nella prima fotografia viene rappresentato
un tipo caso di sistema semi-immersivo con uso di occhialini, mentre nella seconda figura si ha una
applicazione nota con il nome di CAVE.
Fig. 7. Sistemi semi-immersivi: tavolo virtuale e CAVE.
6.2
C o n f r o n t o t r a s i m u l a t o r e d i v o l o i m m e r s i v o e s e m i- im m e r s i v o
La simulazione dell’ambiente che circonda il pilota è forse uno degli aspetti che colpisce
l’attenzione del pilota prima ancora dell’accuratezza delle risposte ai comandi di volo. Un ambiente
sintetico di buon livello deve ricostruire completamente e in modo fedele le percezioni visive, tattili
e uditive che il pilota affronta nel volo. Si prospettano numerose soluzioni e implementazioni
finalizzate all’ottenimento del massimo livello di realismo possibile, tra le quali sono state
sperimentate due soluzioni completamente diverse e, per certi versi, opposte come impostazione:
1) il simulatore di volo completamente in Realtà Virtuale (“full immersive”), ovvero privo
di qualsiasi ausilio di componenti reali (stick, pannelli illuminati, …);
2) il simulatore che sfrutta l’uso di componenti reali, tangibili, per parti non riconfigurabili
del sistema e impiega tecniche di Realtà Virtuale semi-immersive per rendere le parti
aggiornate in continuazione dalla simulazione di volo (scenario esterno, strumenti …).
Nel primo caso il simulatore risulta composto da un sedile semplificato, nessuno stick, né pedali; il
pilota indossa il casco virtuale che gli impedisce qualsiasi contatto con la realtà esterna. Il software
di visualizzazione, oltre a generare lo scenario esterno e gli strumenti di volo, deve ricostruire anche
tutto ciò che il pilota tocca, come i pulsanti, le manopole, lo stick, la manetta, ecc…
La soluzione di tipo semi-immersivo invece punta ad impiegare un sedile, una manetta, uno stick e
una pedaliera reali in modo che il pilota ricavi, fin dal primo istante (quello in cui si siede a
Saggiani, Liverani
Pag. 11 di 20
simulazione ferma) una percezione positiva, corrispondente a quella di salire sull’aeromobile.
Scenario e strumentazione invece vengono retroproiettati stereoscopicamente mediante proiettori ad
alta definizione su schermi translucidi come mostrato in Fig. 8. Ogni videoproiettore gestisce uno
degli schermi posti a 90° l’uno dall’altro in modo da garantire un FOV (Field of View) di oltre
200°.
La posizione del capo del pilota viene rilevata tridimensionalmente mediante un sistema di tracking
che consente di adeguare la visualizzazione esterna al punto di vista momentaneo dell’operatore.
Crystal Eyes
(stereo vision)
Pilot
Seat, stick,
throttle,
pedals.
Fig. 8. La visualizzazione in Realtà Virtuale mediante sistema CAVE-like.
A parità di costo dell’attrezzatura, è stato scelto come criterio di valutazione non tanto il livello di
immersività, come è consuetudine nella considerazione degli ambienti virtuali, ma il livello di
realismo soggettivo, ricavato dalle impressioni di alcuni piloti e istruttori.
È stato possibile identificare in primo luogo che l’alienazione completa del pilota dalla realtà
esterna non è stato un fattore positivo, ma al contrario negativo. Probabilmente tale dato non è da
ritenersi valido di per sé, ma importante alla luce di altre considerazioni. Infatti la risoluzione
effettiva di un casco non supera i 1024x768 pixels in stereo, comportando un decadimento della
percezione visiva non trascurabile. Nel sistema basato sulla Realtà Virtuale semi-immersiva, invece,
la qualità visiva è almeno 3 volte superiore, poiché ciascun videoproiettore è in grado di proiettare a
1024x768 pixels e oltre sul proprio schermo, fornendo un livello di definizione decisamente
superiore. Inoltre la scarsa risoluzione grafica del sistema immersivo influenza negativamente anche
la lettura degli strumenti, fattore determinante nel giudizio complessivo dell’ambiente da parte di un
pilota. Infine è stato possibile identificare come concausa del successo della Realtà Virtuale semiimmersiva su quella immersiva, l’insufficienza della percezione tattile, proveniente
dall’impugnatura dello stick e della manetta e il posizionamento dei piedi sui pedali.
Saggiani, Liverani
Pag. 12 di 20
In Fig. 9 si ha un disegno CAD della versione attualmente in sviluppo del cockpit per lo sviluppo di
trainer di nuova generazione. Utilizzando tecniche di visualizzazione stereoscopiche semiimmersive, si può modificare la configurazione degli EFIS fino ad ottenere una soluzione ritenuta
ottimale. Il vantaggio di tale tecnica risiede nella definizione software dei pannelli EFIS, che
possono essere riconfigurati velocemente. Il cockpit è intefacciato con il simulatore della dinamica,
per cui è possibile effettuare un volo di prova.
Fig. 9: disegno CAD del simulatore semi-immersivo
7
RISULTATI E CONCLUSIONI
Nel presente articolo è stato descritto lo sviluppo del simulatore di volo realizzato presso il
laboratorio di Ingegneria Aerospaziale di Forlì. La scelta di utilizzare tecniche di “clustering
elaboration”, con utilizzo di 5 Personal Computer della classe Pentium, e con utilizzo di software
internamente realizzato ha permesso di contenerne i costi di sviluppo. Una prima ricerca effettuata
utilizzando il simulatore ottenuto, ha riguardato la possibilità di simulare un sistema FBW. Tale
ricerca è stata propedeutica per altre. Una seconda ricerca effettuata ha riguardato l’applicazione
della Realtà Virtuale ai simulatori di volo. Da questa si è derivato che le sensazioni di tipo visivo
garantite dai sistemi di Realtà Virtuale semi-immersiva sono superiori a quelli fondati sulla Realtà
Virtuale immersiva grazie ad una maggiore risoluzione grafica della visualizzazione a videoproiettore. Di fatto i piloti che hanno provato il simulatore si sono trovati unanimemente concordi
sulla validità della presenza di componenti hardware reali, quali lo stick, i pedali, il throttle, poiché
trasmettono all’individuo sensazioni tattili che migliorano sostanzialmente il realismo della
simulazione.
8
RINGRAZIAMENTI
Gli autori intendono ringraziare il Prof. Franco Persiani e il Prof. Luca Piancastelli la collaborazione
fornita nello sviluppo del progetto, L’Ing. Tiziano Bombardi per l’aiuto nella modifica e scrittura
delle routine della dinamica e l’Ing. Giuseppe Sarubbi per l’aiuto e la collaborazione nella
implementazione della strumentazione di bordo.
Saggiani, Liverani
9
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Pag. 13 di 20
BIBLIOGRAFIA
Antinucci, F., Dalla mente simbolica a quella sensomotoria, Realtà Virtuale, pp1,6, Nov. Dic
1993.
Boiffeir , JL., The dynamics of flight-The equations, John Wiley & Sons, 1998
Calori, L., Guidazzoli, A., Persiani, F., Piancastelli, L., Alcune considerazioni sui Sistemi di
visualizzazione di un Simulatore Virtuale, Pixel, October 1996, Il Rostro, Milano.
CAT, Civil Aviation Training, Vol. 5 issue 5, 1994.
Cooke, J. M., Zyda, M. J., Pratt, D. R., McGhee, R. B., NPSNET: flight simulation dynamic
modeling using quaternions, Presence, Vol. 1, No. 4, pp 404-420, January 1994
Cook, M.V., Flight dynamics principles, Arnold, 1997
Degani, A., and Wiener, E. L., Design and operational aspects of flight-deck procedures,
Proceeding of the International air Transport association, (IATA) Human Factors 98
Conference. Bangkok, Thailand (April 20-22), 1998.
Degani, A., and Wiener, E. L., Procedures in complex systems: The airline cockpit, IEEE
Transactions on Systems, Man, and Cybernetics, 27(3), 302-312, 1998.
Degani, A., and Wiener, E. L., Designing Coherent Flight-deck Procedures for Use in
Advanced Technology Aircraft,. ICAO Journal, 50(2) , 23-25, 1995.
Degani, A., and Wiener, E. L., On the Design of Flight-Deck Procedures, (NASA Contractor
Report 177642). Moffett Field, CA: NASA Ames Research Center, 1994.
Degani, A., and Wiener, E. L., Cockpit checklists: Concepts, design, and use, Human Factors,
35(2), 345-359, 1993.
Dannenberg, K., Sanders, P., New directions in modeling simulation, Aerospace America,
January 1997.
Earnshaw, R.A., Watson, D. , Animation and Scientific Visualization-Tools & Application,
Academic Press, 1993, ISBN 0-12-227745-7
Etkin, B., Dynamics of atmosferic flight, John Wiley & Sons, 1972
Foley, J. D. , Van Dam, A. , Feiner, S. K. and Hughes, J. F. , Computer Graphics, Principles
and Practice, Addison-Wesley Publishing second edition, 1992,
Gonzalez, R., Wintz, P., Digital Image Processing, Addison Wesley Pub. Co, 1977.
Kalawsky, R.S. , The Science of Virtual Reality and Virtual Environments”, Addison Wesley,
1994, ISBN 0-201-63171-7.
Jackson, E. B., Manual for a workstation-based generic flight simulator program (LaRCsim).
Version 1.4, NASA Technical Memorandum 110164, April 1995
Ladkin, P.B., Computer-Related Incidents with Commercial Aircraft. A Compendium of
Resources, Reports, Research, Discussion and Commentary, http://www.rvs.unibielefeld.de/publications/Incidents/, May 1998
Mangiacasale, L., Meccanica del volo atmosferico, Levrotto & Bella, Torino,1992
McCauley, S. G., Nagati, M. G., PC-based expandable/affordable flight simulation for
education and entertainment”, (Wichita State Univ., KS). In: AIAA Flight Simulation
Technologies Conference, Baltimore, MD, Technical Papers (A95-39235 10-01), Washington
DC, American Institute of Aeronautics and Astronautics, Aug. 1995, AIAA Paper 95-3396
A95-39245.
McCormick, B. H., DeFanti,T.A., Brown, M.D., Visualization in Scientific Computing,
Computer Graphics,Vol.21 , N. 6, 1987 November.
McFarland, R. E., A standard Kinematic model for flight simulation at NASA-Ames, NASA
Contractor Report 2497, NASA Ames Research Center, 1975
NASA Report, F-8 Digital Fly-By-Wire, Report in “Facts” NASA Dryden Flight Research
Center Edwards, CA 93523, February 2, 1994
Saggiani, Liverani
•
•
•
•
•
•
•
•
•
•
Pag. 14 di 20
Newman, W.M., Sproull, R. F., Principles of Interactive Computer Graphics, McGraw-Hill,
1979.
Nielson, G.M., Shiver, G., Rosemblum, L.J., , Visualization in Scientific Computing, IEEE
Computer Society Press, Los Alamitos, California, August 1990.
Rogers, Capt. R., Flight test results of the controlled flight into terrain avoidance maneuvre in
fly-by-wire transports, ALPA, March, 1999
Rolfe, J.M. , Flight Simulation, Cambridge Aerospace Series, Cambridge University, June 1988,
Press, ISBN: 0521357519.
Rolfe, J.M., Staples, K. J., flight simulation, Candbrige University Press 1986.
Roskam, J., Airplane flight dynamics and automatic flight controls, DARcorporation, 1995
Saggiani, G. M., Piancastelli, L.,Applicazioni della logica dell’indeterminazione ai sistemi di
controllo digitali dei comandi volo, DIEM internal publication n° 110, August 99
Stowe, S., Fly-By-Wire: A Primer for Aviation Accident Investigators, ALPA, February 2000
Watson , M., Al Agents in Virtual Reality Worlds : Programming Intelligent Vr in C++,
Book&Cd Edition, John Wiley & Sons, 1996, ISBN: 0471127086.
Watt A., Watt M., Advanced Animation and Rendering Techniques – Theory and Practice,
Addison-Wesley, 1993, ISBN 0-201-54412-1.
Saggiani, Liverani
Pag. 15 di 20
APPENDICE I
Tabelle del message passing
Tab.1. Variabili di stato scambiate fra
Labview Manager ed integratore all’interno
del server
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Elevator
Aileron
Rudder
Flaps
Throttle_1
Throttle_2
Throttle_3
Throttle_4
Propeller_1
Propeller_2
Propeller_3
Propeller_4
Qnh_sel
Gear_onoff
Brake_sx
Brake_dx
Cmd_pause
Cmd_stop
Null
Null
Left_Boolean _archive_1
Left_Booleanl_archive_2
Crossfeed_sel
Null
Voltage_sel
Electrical_test
Lh_gen
Battery
Rh_gen
Avionic_1
Avionic_2
Pilot_static
W_s_bleed
W_s_Alchool
Eng_lh
Eng_rh
Surface_all
Flood_lts
Left_lts
Center_lts
Right_lts
El_lts
Bytes_Read_Input
Null
Null
Null
Null
Null
Null
Null
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Null
Horn_silence
Antiskid
COM1
COM2
NAV1
NAV2
XPDR_Status
XPDR_Freq
CAB_FAN
CAB_FAN_Temp
Auto_temp_Select
Pressurization_sorce
Pressurization_Emer_Dump
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
NAV_1
NAV_2
NAV_3
NAV_4
NAV_5
NAV_6
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Tab.2 Variabili di stato scambiate fra
l’integratore e Labview Manager all’interno
del server
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Altitude
V_IAS
Pitch
Roll
Yaw
V-Climb
NX
NY
NZ
Angle_Of_Attack
MSG_Stallo
Pressione_Pz
Mach_Number
AMP_RH
Volt
TSK Level
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Stall Adviser
Null
Crossfeed
Igniters
Byte Read Output
Flag_1_Bandiera
Latitude Out
Longitude Out
Altezza Suolo
Landing Touch
Null
Null
Null
fan rpm 1
fan rpm 2
fan rpm 3
fan rpm 4
itt 1
itt 2
itt 3
itt 4
Turbine rpm 1
Turbine rpm 2
Tab.3 Variabili di stato scambiate fra “server” e “visual”
0
1
2
3
4
5
6
Altitude
x
y
z
Pitch
Roll
Yaw
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Turbine rpm 3
Turbine rpm 4
fuel flow 1
fuel flow 2
fuel flow 3
fuel flow 4
fuel qty 1
fuel qty 2
fuel qty 3
fuel qty 4
oil temp 1
oil temp 2
oil temp 3
oil temp 4
oil temp2 1
oil temp2 2
oil temp2 3
oil temp2 4
oil press 1
oil press 2
oil press 3
oil press 4
oil press2 1
oil press2 2
oil press2 3
oil press2 4
eng warns
gear instruments
fligh dir
panel adv 1
panel adv 2
panel adv 3
panel adv 4
cab alt
cab diff press
cab rate
xpdr relay
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Null
Saggiani, Liverani
Pag. 16 di 20
APPENDICE II
Fin da subito si è fatta la scelta di semplificare il modello del sistema imponendo le ipotesi di Terra
piatta e fissa, ovvero utilizzando come sistema principale d’inerzia un sistema di riferimento
destrorsa FE solidale con il centro della terra e avente asse Z diretto verso il polo nord e asse X
passante per il meridiano di Greenwich. Pertanto un punto può essere espresso da:
PE = {XE, YE, ZE}
(A2.1)
Un secondo sistema di riferimento FL è stato posto sull’aeromobile avente centro nel suo baricentro,
asse X diretto verso nord, asse Y diretto verso est ed asse Z diretto in basso verso il centro della
terra. Pertanto un punto può essere espresso da:
PL = {XL, YL, ZL}
(A2.2)
Esiste una matrice di relazione τEL fra i due sistemi definita attraverso gli angoli di longitudine e
latitudine (McFarland 1975).
In fine si considera un sistema corpo FB centrato nel baricentro dell’aeromobile avente gli assi tipici
della meccanica del volo con asse X lungo l’asse longitudinale del velivolo e rivolto verso la punta,
asse Y perpendicolare al piano di simmetria assiale e diretto verso destra, asse z diretto verso il
basso. Pertanto un punto può essere espresso da:
PB = {XB, YB, ZB}
(A2.3)
Esiste una matrice di relazione τLB fra i sistemi locale e corpo definita attraverso gli angoli di Eulero
(ψ, θ, φ) (McFarland 1975).
È stata fatta la scelta di calcolare correttamente sia il raggio della terra Rt che l’accelerazione di
gravità in funzione della quota di volo h:
g=
ς mt
(Rt + h)
(A2.4)
Dall’equazioni del moto del baricentro di corpo rigido si derivano le velocità lineari rispetto agli
assi corpo (Cooke 1994, Roskam 1995):
Fx
&
U = V R − W Q − g sinθ + m

Fy
&
V = W P − U R + g sinφ cosθ +
m

W& = U Q − V P + g cos φ cosθ + Fz

m
(A2.5)
Dall’equazione del moto attorno al baricentro di corpo rigido, posto Ixy = Iyx = 0 per la simmetria
dell’aeromobile lungo l’asse longitudinale, si derivano le velocità angolari rispetto agli assi corpo
(Cooke 1994, Roskam 1995):
Saggiani, Liverani
Pag. 17 di 20
 & L' ' I z − N ' ' I xz
P =
I x I z − I xz2

 & M − (I x − I z ) P R − I xz P 2 − R 2
Q =
Iy

 & N ' ' I x + L' ' I xz
R =
I x I z − I xz2

(
)
(A2.6)
Si rimanda all’appendice IV per la definizione delle variabili.
Integrando nel tempo le equazioni (A2.5) e (A2.6) si ottengono rispettivamente le velocità lineari e
le velocità angolari rispetto agli assi corpo al passo d’integrazione successivo.
La relazione che trasforma le velocità lineari calcolate rispetto al sistema corpo, nel sistema terra []E
è la seguente (Cook 1997):
cosθ cosψ

U 
V  =  sinφ sinθ cosψ − cosφ sinψ

 
W  E  cosφ sinθ cosψ + sinφ sinψ
cosθ sinψ
sinφ sinψ sinθ + cosφ cosψ
cosφ sinθ sinψ − sinφ cosψ
− sinθ 
sinφ cosθ 

cosφ cosθ 
−1
U 
V  (A2.7)
 
W 
Infine definita la relazione che lega la velocità di variazione degli angoli di Eulero secondo la
seguente (Cook 1997):
φ& = P + Q sinφ tan θ + R cos φ cosθ
&
θ = Q cos φ − R sinΦ
ψ& = Q sinφ sec θ + R cosφ sec θ

L’integrazione nel tempo della (A2.8) permette di calcolare i nuovi angoli di Eulero.
(A2.8)
Saggiani, Liverani
Pag. 18 di 20
APPENDICE III
L’uso degli angoli di Eulero per risolvere il problema dell’assetto dell’aeromobile presenta il
problema di un punto di singolarità della matrice di trasformazione nell’equazione che lega le
velocità angolari attorno agli assi corpo alle velocità di variazione degli angoli di Eulero (A3.1).

 φ&  1 sinφ tanθ
 & 
cosφ
θ  = 0
sinφ
ψ&  0
 
cosθ


cosφ cosθ   P 
− sinφ  Q 
cosφ   R 
 
cosθ 
(A3.1)
In particolare per angoli di elevation (θ) di ±Π/2 gli angoli di bank (φ) e azimuth (ψ) diventano
indeterminati poiché φ& ⇒ ∞ e ψ& ⇒ ∞ .
È possibile evitare questo punto di singolarità utilizzando il metodo dei quaternioni, la cui
matematica si deve a Hamilton (1843). Si rimanda a testi specifici per la trattazione matematica dei
quaternioni (Mangiacasale 1992)
Un quaternione è un numero immaginario formato da quattro elementi:
q=S+ia+jb+kc
(A3.2)
L’assetto e posizione dell’aeromobile può essere espressa per mezzo dei quaternioni, ovvero si
passa da una trattazione a tre parametri (Eulero) ad una a quattro parametri.
Per poter effettuare una simulazione del volo è necessario inizializzare il quartazione, ovvero
definire le sue variabili (S, a, b , c) nell’istante t=0. Essendo noti gli angoli di Eulero al tempo
considerato, l’inizializzazione può avvenire semplicemente secondo la seguente relazione:

S

a


b


c

ψ   θ   φ 
φ 
θ 
ψ 
= cos   cos   cos   + sin   sin   sin  
 2  2 2
2
2
2
ψ 
θ  φ 
ψ  θ 
φ 
= cos   cos   sin   − sin   sin   cos  
2
 2 2
 2  2
2
ψ   θ 
φ 
ψ 
θ  φ 
= cos   sin   cos   + sin   cos   sin  
 2  2
2
2
 2 2
ψ 
θ 
φ 
ψ   θ   φ 
= sin   cos   cos   − cos   sin   sin  
2
2
2
 2  2 2
(A3.3)
Noto il quaternione dell’aeromobile in un certo istante (A3.3) il quaternione nell’istante successivo
è espresso dalla seguente relazione:
 S&   0
R
Q
P  S 
  
P − Q   a 
 a&  =  − R 0
 b&  − Q − P 0
R  b 
  
 
 c&   − P Q − R 0   c 
(A3.4)
Se all’istante n-1 l’aeromobile era caratterizzato dalla posizione [x,y,z]n-1, la sua posizione
all’istante n è rappresentata da:
Saggiani, Liverani
Pag. 19 di 20
 x
 x
 y  = [ A]  y 
 
 
 z  n−1
 z  n
(A3.5)
ove la matrice [A] viene espressa in funzione del quaternione:
S 2 + a 2 − b 2 − c 2
[A] =  2 (a b − cS )
 2 (a c + S b )

2 (c S + a b )
S −a +b −c
2 (b c − S a )
2
2
2
2
2 (a c − S b ) 

2 (a S + c b ) 
S 2 − a 2 − b 2 + c 2 
(A3.6)
Come si denota dalle equazioni sopra riportate l’assetto e posizione dell’aeromobile durante il volo
simulato può essere espresso attraverso i quaternioni, che non presentano punti di singolarità come
gli angoli di Eulero.
Per visualizzare l’assetto dell’aeromobile, gli angoli di Eulero sono molto più utili dei quaternioni, e
pertanto è necessario estrarre gli angoli per ogni passo d’integrazione. Questo può esser fatto
secondo la seguente relazione:


−1
θ = sin (− A1,3 )

 A1, 2 

−1

ψ = tan 


 A1,1 

A 
φ = tan −1  2, 3 
A 

 3, 3 
(A3.7)
Con l’uso delle equazioni da (A3.1) a (A3.7) la risoluzione dell’assetto e posizione è risolto senza
problemi di singolarità. Avendo a disposizione i quaternioni dell’aeromobile per ogni istante di
volo, si possono utilizzare anche per risolvere l’equazione delle forze, anche se non sarebbe
strettamente necessario. Pertanto l’equazione (A2.5) si modifica nella seguente:

F
U& = V R − W Q − g A1, 3 + x
m

Fy
A1, 2
&
+
V = W P − U R + g
A1,1
m

A2,3
&
F
+ z
W = U Q − V P + g
A3,3
m

L’equazione delle rotazioni rimane invariata.
(A3.8)
Saggiani, Liverani
Pag. 20 di 20
APPENDICE IV
NOMENCLATURA UTILIZZATA
FE = Sistema di riferimento inerziale ovvero sistema terra
FL = Sistema di riferimento locale sull’a/m
FB = Sistema di riferimento corpo (body) dell’a/m
ψ , θ, ϕ = angoli di eulero (azimuth, elevation, bank)
g = accelerazione dovuta all’attrazione gravitazionale (tiene conto della quota di volo)
ς = costante gravitazionale della terra (= 6.664 x 10-11 m/kg sec2)
mt = massa della terra (5.983 x 1024 kg)
Rt = raggio locale della terra
h = quota di volo in metri
U,V,W = velocità lineari dell’a/m nel sistema FB rispettivamente lungo asse XB, asse YB, asse ZB
P,Q,R = velocità angolari dell’a/m nel sistema FB rispettivamente attorno asse XB (rollio), asse YB
(beccheggio), asse ZB (imbardata)
m = massa dell’a/m
F = {FX, Fy, Fz } = forze esterne applicate all’a/m (quale propulsiva, aerodinamica ..)
Equazioni per il calcolo delle accelerazioni angolari (Roskam 1995) :
 L' ' = L + I xz P Q − (I z − I y ) R Q

 N ' ' = N − (I y − I x ) P Q − I xz R Q

 L = I x P& − I xz ( R& + PQ ) + (I z − I y ) R Q
 M = I Q& + (I − I ) P R + I P 2 − R 2
y
x
z
xz


&
&
 N = I z R − I xz ( P − QR ) + (I y − I x ) P Q
(
)
Ix , Iy , Iz , Ixz = momenti d’inerzia dell’a/m rispetto al sistema FB