Design and development of the new generation of a flight test instrumentation system for ultra light machines

(1)

POLITECNICO DI MILANO

Scuola di Ingegneria Industriale

Corso di Laurea Magistrale in Ingegneria Aeronautica

Design and Development

of the new generation of a

Flight Test Instrumentation system

for Ultra Light Machines

Relatore: prof. Alberto ROLANDO

Tesi di Laurea di:

Tommaso CASTELLETTI

Matr. 797120

(2)

(3)

Acknowledgements

I would like to express my sincere gratitude to professor Alberto Rolando for giving me the opportunity to contribute to this important project and for supporting and encouraging me during these past months. A special thanks goes to Federico Rossi who patiently helped and advised me in all the phases of this work. Without their support and wise guidance this thesis would not exist.

I acknowledge my fellows, especially Patrick, Luca and Silvia who were always willing to listen to me while providing their helpful recommendations. I would like to thank Jacopo to have directed me and to be an anchor during all my university career. To all the members of the Exoco team, not only partners in an important project but also now new friends of mine, go a special acknowledgement. No doubts that I may forget someone and so I stop here citing all the fellows that went along with me in these several years of university; but all of them deserve my gratitude as I have learned something from each of them.

A special thought to all my friends who have stayed close to me, supported and stimulated me to always do my best. Last but not least, I would like to hug my parents Carlo and Luciana, my brother Marco and my sister Soa, my aunt Gabriella and my girlfriend Rossella who have always trusted me and whose demonstration of aection has always given to me the strength to overcome every dicult moment.

(4)

(5)

3.5.2 Performance test . . . 30 3.5.2.1 Results . . . 32 3.6 Threads descriptions . . . 35 3.6.1 Main . . . 35 3.6.2 Time scheduler . . . 35 3.6.3 SD thread . . . 36 3.6.3.1 Process housekeeping . . . 38 3.6.3.2 Process command . . . 38 3.6.3.3 Process telegram . . . 39 3.6.4 Telemetry thread . . . 40 3.6.5 Ethernet thread . . . 40 3.6.6 ADC thread . . . 41 3.6.6.1 Filter design . . . 43 3.6.7 IMU thread . . . 45 3.6.8 CAN thread . . . 48

3.6.8.1 CAN receiver thread . . . 51

3.6.8.2 CAN dispatcher thread . . . 53

3.6.9 GPS thread . . . 53

3.6.10 Engine thread . . . 56

3.6.10.1 RPM counter thread . . . 57

3.6.10.2 Engine dispatcher thread . . . 57

3.6.11 Stick force thread . . . 57

3.6.12 Kneepad thread . . . 58

3.6.13 UI thread . . . 61

3.7 Air Data System . . . 62

3.7.1 Pressure thread . . . 62

3.7.2 Temperature thread . . . 63

3.7.3 Wind angles thread . . . 63

3.7.4 CAN thread . . . 64

3.7.5 Calibration thread . . . 64

4 Field test and future development 65 4.1 Sample data . . . 69

4.2 Future development . . . 72

5 Conclusion 73

(7)

List of Figures

1.1 Airborne systems scheme . . . 6

1.2 System Block Diagram of Mnemosine MkIII . . . 9

1.3 Mnemosine MkIV . . . 11

2.1 Mnemosine MkV block diagram . . . 13

2.2 Olimex STM32-E407 development board . . . 15

2.3 Power supply diagram . . . 16

2.4 Futek MU300 . . . 17

2.5 Mnemosine MkV Masterboard connectors . . . 20

2.6 Mnemosine MkV Slaveboard connectors . . . 20

3.1 Main architecture scheme of Mnemosine MkV . . . 25

3.2 CAFFE telegram type . . . 26

3.3 Time management scheme . . . 28

3.4 Time-stamp scheme . . . 28

3.5 Files and directories management . . . 30

3.6 Class 4 micro Secure Digital (microSD) card performances test . . . 32

3.7 UHS-I microSD rst card performances test . . . 33

3.8 UHS-I microSD second card performances test . . . 34

3.9 Event ags . . . 36

3.10 SD thread logical scheme . . . 37

3.11 Secure Digital Card driver . . . 38

3.12 Writing scheme . . . 39

3.13 ADC driver implementation . . . 42

3.14 Finite Impulse Response (FIR) lter logical structure . . . 43

3.15 Analog to Digital Converter payload structure . . . 45

3.16 XSENS MTi overview . . . 46

3.17 XSENS MTi sensor-xed co-ordinate system . . . 46

3.18 Serial driver implementation . . . 47

3.19 Xsens MTi payload structure . . . 48

3.20 CAN driver implementation . . . 49

3.21 CAN bit timing . . . 50

3.22 CAN frame . . . 50

3.23 Extended IDentier frame . . . 50

3.24 Controller Area Network (CAN) receiver scheme . . . 52

3.25 Air Data System payload structure . . . 53

3.26 UBX protocol frame . . . 53

(8)

3.28 Input Capture Unit driver implementation . . . 56

3.29 Propulsion system payload structure . . . 57

3.30 Knee-pad . . . 59

3.31 Knee-pad answer scheme . . . 60

3.32 Mnemosine state payload structure . . . 60

3.33 Command unit . . . 61

3.34 Inter-Integrated Circuit driver implementation . . . 62

3.35 Serial Peripheral Interface driver implementation . . . 63

4.1 Folder by Nando Groppo s.r.l. . . 65

4.2 Mnemosine MkV installed on board . . . 66

4.3 Air Data System installed on right wing . . . 67

4.4 Folder cockpit . . . 67

4.5 Meteorological station and antenna tracker . . . 68

4.6 Telemetry monitor . . . 68

4.7 Folder Take-o performances . . . 69

4.8 Folder's response to a stick command exciting phugoid . . . 70

(9)

List of Tables

2.1 Pressure transducers features . . . 17

2.2 Xsens MTi calibrated data full scale . . . 18

2.3 LEA-6N GPS/GLONASS performance . . . 19

3.1 Possible scenarios for CAFFE telegram . . . 26

3.2 Simulated scenarios for CAFFE telegram . . . 27

3.3 FAT le system types and limits . . . 29

3.4 Micro SD speed class . . . 31

3.5 Final microSD settings . . . 35

3.6 CAN settings . . . 50

3.7 NAV-SOL payload contents . . . 55

3.8 NAV-TIMEUTC payload contents . . . 55

(10)

(11)

List of Acronyms

ADC Analog to Digital Converter ADS Air Data System

AHRS Attitude Heading Reference System API Application Programming Interface

CAFFE Controller Area Network For Flight-test Equipment CAN Controller Area Network

CAS Calibrated Air Speed CCM Core Coupled Memory CPU Central Processing Unit

CS-LSA Certication Specications for Light Sport Aeroplanes CS-VLA Certication Specications for Very Light Aircraft DAC Digital to Analog Converter

DDC Display Data Channel

DIA-PoliMi Department of Aerospace Engineering of the Politecnico di Milano DMA Direct Memory Access

DSP Digital-Signal-Processing

EASA European Aviation Safety Agency ECEF Earth-Centered Earth-Fixed EID Extended IDentier

ELT Emergency Locator Transmitter FAR Federal Aviation Regulations FatFs File Allocation Table File System FC Flight Control

(12)

FIR Finite Impulse Response FM Frequency Modulation FPU Floating Point Unit FTE Flight Test Engineer FTI Flight Test Instrumentation FTP Flight Test Pilot

GLONASS GLObalnaya NAvigatsionnaya Sputnikovaya Sistema GPS Global Positioning System

HAL Hardware Abstraction Layer HTTP HyperText Transfer Protocol I2C Inter-Integrated Circuit I2S Integrated Interchip Sound ICU Input Capture Unit

IDE Integrated Development Environment IIR Innite Impulse Response

IMU Inertial Measurement Unit I/O Input / Output

IP Internet Protocol

ISR Interrupt Service Routine

JAR Joint Airworthiness Requirements LED Light Emitting Diode

LFS Large File Support LTI Linear Time-Invariant lwIP light-weight Internet Protocol MAC Media Access Control

MEMS Micro ElectroMechanical System microSD micro Secure Digital

MTOW Maximum Take O Weight

NACA National Advisory Committee for Aeronautics NetBIOS Network Basic Input/Output System

(13)

PAL Ports Abstraction Layer PCM Pulse Code Modulation

PPPoE Point-to-Point Protocol over Ethernet PSRU Propeller Speed Reduction Unit QZSS Quasi-Zenith Satellite System RAM Random Access Memory ROM Read Only Memory RPM Revolutions Per Minute

RTD Resistance Temperature Detectors RTOS Real Time Operating System RTT Round Trip Time

SBAS Satellite Based Augmentation System SDC Secure Digital Card

SDIO Secure Digital Input/Output SPI Serial Peripheral Interface SRAM Static Random Access Memory SSP Synchronous Serial Protocol TCP Transmission Control Protocol TTFF Time-To-First-Fix

UART Universal Asynchronous Receiver/Transmitter UDP User Datagram Protocol

UI User Interface ULM Ultra Light Machines

USART Universal Synchronous/Asynchronous Receiver/Transmitter USB Universal Serial Bus

UTC Coordinated Universal Time VFR Visual Flight Rules

VHF Very High Frequency WWI World War I

WWII World War II

(14)

(15)

Sommario

La presente tesi tratta dello sviluppo un sistema di acquisizione dati per prove di volo, normalmente denito come Flight Test Instrumentation. L'obiettivo di un sistema di strumentazione per prove di volo è quello di acquisire dati ed informazioni del velivolo di prova per poi fornirli al gruppo che si occuperà dell'analisi dei dati. Nel 2005 il POLI-XFlight, un gruppo di ricerca del Dipartimento di Ingegneria Aero-spaziale del Politecnico di Milano, ha iniziato un progetto per un sistema di strumen-tazione per prove di volo chiamato Mnemosine. Il sistema è progettato in particolare per quei velivoli che appartengono alla classe Ultra Light Machines. Dopo qualche anno di sviluppo e prove sul campo, il sistema ha ora raggiunto la quinta generazione chiamata Mnemosine MkV.

Questa nuova generazione si avvantaggia delle soluzioni trovate nei lavori precedenti, in modo speciale dei traguardi raggiunti con Mnemosine MkIV che è stato progettato introducendo una serie di novità rispetto alle versioni precedenti, anche se è stato sviluppato unicamente come prototipo senza mai essere testato.

Mnemosine MkV è un sistema di strumentazione per prove di volo completamente funzionante che ha ereditato le sue caratteristiche principali dalle versioni precedenti ma integrando una serie di nuove funzionalità attraverso le quali è stato fatto un passo importante per la realizzazione di un sistema completo.

Questo documento è il resoconto nale delle attività di progetto e di sviluppo ese-guite. Esso comprende un'introduzione alla storia della strumentazione per prove di volo seguita dalla presentazione dell'architettura hardware e dalla denizione del rmware. Da ultimo verranno presentate le prove di volo eettuate con Mnemosine MkV.

(16)

(17)

Abstract

The present thesis deals with the development of a data acquisition system for ight testing, typically referred as Flight Test Instrumentation. The purpose of a Flight Test Instrumentation system is to acquire data about the operation of the test vehicle and provide them to the data processing group.

In 2005 POLI-XFlight, a research group of the Department of Aerospace Engineering of Politecnico di Milano, started a project for a Flight Test Instrumentation system called Mnemosine. The system is especially designed for a particular class of ying machines: the Ultra Light Machines. After few years of developments and eld tests, the system is now at the fth generation called Mnemosine MkV.

This new generation capitalizes the solutions found during the past works, especially with the accomplishments achieved with Mnemosine MkIV. Indeed it was designed with a high degree of novelty compared to the previous versions even if it was only made as prototype that has never been tested.

Mnemosine MkV is a fully operative Flight Test Instrumentation system which main characteristics derive from older versions but it integrates new features through which an important step is make in the realization of an whole Flight Test Instrumentation system.

This document is the nal report of the design and the development activity per-fomed. It includes an introduction to the Flight Test Instrumentation history followed by the description of the hardware architecture and by the denition of the rmware. In conclusion, it provides a highlight of the ight tests performed with Mnemosine MkV.

(18)

(19)

Compendio

Agli inizi del XX secolo i pionieri dell'aviazione dovevano possedere conoscenze in diversi campi della sica per poter riuscire a sviluppare un nuovo velivolo. A quell'epoca venivano eettuate delle prove simili alle prove di volo ma erano unicamente volte alla verica delle prestazioni, della stabilità e del controllo. Dopo la prima guerra mondiale vi fu una forte spinta per comprendere la teoria del volo ed è forse in questo periodo che nasce la gura dell'ingegnere per le prove di volo. La presenza di questa gura verrà successivamente resa necessaria dall'introduzione di regolamentazioni dell'aviazione.

Dopo la seconda guerra mondiale in supporto all'attività dell'ingegnere per le prove di volo iniziarono ad essere disponibili delle tecniche per registrare i fenomeni sici che avvenivano durante il volo. Nel corso degli anni queste tecniche si sono evolute no ad arrivare ai gior-ni nostri in cui un sistema è in grado di registrare miliogior-ni di parametri simultaneamente. L'insieme di questi strumenti viene chiamato strumentazione per le prove di volo. Nel 2005 il Poli-XFlight, un gruppo di ricercatori del Dipartimento di Ingegneria Aero-nautica del Politecnico di Milano, ha iniziato un progetto per lo sviluppo di un sistema di strumentazione per prove di volo chiamato Mnemosine. Questo sistema doveva essere economico, adabile, essibile, non intrusivo, facile da gestire e da mantenere e doveva assicurare un adeguato potenziale di crescita. Le prime tre versioni del sistema prevede-vano un'architettura federata con nodi diversicati a seconda delle funzioni che doveprevede-vano svolgere.

Nel 2014 è stato portato a termine il progetto per la quarta generazione che è stata radical-mente modicata rispetto alle versioni precedenti. Essa prevedeva un solo modulo centrale a cui si collegavano i diversi sensori. Di questa versione ne è stato sviluppato solamente un prototipo che non è mai stato testato. Il lavoro di questa tesi è partito per la necessità di sviluppare la nuova generazione di strumentazione per prove di volo: Mnemosine MkV.

Architettura hardware

Mnemosine MkV ha ereditato le caratteristiche principali dal suo predecessore, è quindi rimasto un modulo principale a cui vengono connessi tutti i sensori. In questo modulo sono presenti due schede stampate poste una sopra l'altra in modo da avere un ingombro ridotto. Vi è poi un modulo separato, il nodo dati aria. Esso è stato collocato vicino al pitot-boom in modo da garantire una minor distanza tra il sensore e il trasduttore. Il nodo dati aria comunica con la scheda principale tramite il protocollo CAFFE.

Mnemosine MkV è composto da:

• la scheda di sviluppo: una Olimex STM32-E407 che possiede come caratteristiche principali un'unità in virgola mobile, un'ampia memoria su cui scrivere il codice e una serie di interfacce di comunicazione tra cui l'interfaccia SDIO e la CAN;

(20)

• il sistema di alimentazione. Supporta l'alimentazione sia da una batteria esterna che dal circuito di alimentazione del velivolo. Tutti gli strumenti, tra cui anche il nodo dati aria, vengono alimentati direttamente dal modulo principale;

• il modulo di condizionamento dei segnali analogici;

• il nodo dati aria: come già anticipato è l'unico modulo esterno. E' composto da una scheda Olimex STM32-H107, due trasduttori di pressione, un termometro a resistenza, un modulo di condizionamento per segnali analogici e 2 connettori CAFFE;

• uno strumento per misurare gli sforzi di barra; • uno strumento per acquisire le misure inerziali; • un nodo per i dati dell'apparato propulsivo;

• un nodo per i dati ricevuti dal GPS. Il sistema GPS è usato sia come sensore di posizione sia come strumento per la gestione interna del tempo;

• un cosciale.

Realizzazione del rmware

La realizzazione del rmware è stata condizionata dai requisiti imposti al sistema. Esso, infatti, deve essere in grado di acquisire una serie di parametri come la pressione totale e dinamica, la temperatura dell'aria esterna, gli angoli di incidenza e di sbandata, le posizioni e le velocità del velivolo, gli sforzi di barra, la posizione delle superci di controllo e i dati dell'impianto propulsivo. Cionondimeno il sistema deve essere in grado di fornire una base temporale sincrona per tutti i dati, di acquisire e memorizzare in modo corretto i parametri ed evitare in ogni modo la perdita di informazioni. Se possibile, deve poter garantire una connessione stabile con una stazione di terra e con il cosciale presente a bordo.

Per riuscire a soddisfare tutti questi requisiti si è fatto uso di un sistema operativo real-time. Esso è composto da una serie di processi, ciascuno con un compito specico. Ogni processo deve essere in grado di acquisire le misure dai sensori, impacchettarle in un modo specico e inne mandarle al processo della telemetria. Questo processo ha il compito di ricevere tutte le misure, inoltrarle al processo della SD e inne spedirle ala stazione di terra tramite una connessione di tipo UDP. Il processo della SD, oltre a dover garantire la corretta archiviazione dei dati acquisiti, deve gestire anche i processi di avvio e di arresto della registrazione. Per quanto riguarda lo scambio di informazioni con il cosciale, il processo è dierente. Infatti ogni processo può accedere direttamente ad una struttura locale del processo del cosciale e riempirla con le proprie informazioni. Dal cosciale, non tutti i parametri possono essere letti in quanto non vi è la necessità, da parte dell'ingegnere per le prove di volo, di leggere tali valori a bordo senza un'adeguata elaborazione. La caratteristica più importante che un sistema di strumentazione per prove di volo deve avere è sicuramente quella di garantire una base temporale sincrona per tutti i parametri acquisiti. In Mnemosine questo è reso possibile grazie ad una forte integrazione tra il sistema GPS e i cronometri interni della scheda Olimex E407. Ogni secondo infatti vi è un riallineamento tra il cronometro al quarzo della scheda E407 e gli orologi atomici del sistema GPS.

Il lesystem adottato per l'archiviazione dei dati acquisiti è il FatFS. La prima fase del lavoro di tesi ha infatti visto una lunga serie di prove per riuscire a determinare quale

(21)

dovesse essere la scheda microSD da utilizzare e quali fossero i parametri di congurazione del sistema di salvataggio necessari per riuscire a massimizzare la velocità di scrittura. In seguito si è proceduto con la realizzazione di tutti i processi necessari per soddisfare i requisiti del sistema di acquisizione, che sono ivi riportati:

• processo principale • gestore del tempo • processo della telemetria • processo del protocollo ethernet

• processo del convertitore analogico digitale • processo dei dati inerziali

• processo del protocollo CAN

• processo del sistema di navigazione GPS • processo dell'apparato propulsivo • processo degli sforzi di barra • processo del cosciale

• processo dell'interfaccia con l'utente • insieme di processi per il nodo dati aria

Prove sul campo

Una volta realizzato l'intero sistema, sia come progetto hardware che come progetto del rmware, è stato possibile testare le prestazioni e il funzionamento di Mnemosine MkV eettuando prove sul campo. Esse si sono svolte in due giorni asservendo il sistema di strumentazione per prove di volo ai test programmati nel corso di Sperimentazione in Volo del Politecnico di Milano. I test si sono svolti in Mezzana Bigli (PV) presso il campo volo del Club Astra, analizzando le prestazioni del velivolo ultraleggero Folder della società Nando Groppo s.r.l.. Durante questa campagna prove, Mnemosine MkV ha dimostrato di essere un sistema pratico, adabile, con un avanzato sistema di diagnosi soddisfacendo a pieno tutti i requisti richiesti per questo sistema di strumentazione per prove di volo. Mnemosine MkV, rispetto ai suoi predecessori, è stato in grado di mostrare i parametri acquisiti in tempo reale nella stazione di terra grazie alla nuova funzionalità della telemetria.

Pur avendo sviluppato un sistema completo ci sono alcune funzionalità che possono essere aggiunte per migliorare la praticità del sistema e abbassare i costi di produzione. Sono quindi state valutate alcune possibili soluzioni e funzioni che potranno essere integrate nella futura generazione di Mnemosine.

(22)

(23)

Chapter 1

Introduction

December 17, 1903 in North Carolina, Wright brothers ew for 120 ft at about 10 ft from ground and a speed less than 11 km/h on what is nowadays dened as: "...the rst powered, heavier-than-air machine to achieve controlled, sustained ight with a pilot aboard."1_{. After a little more than a century this heavier-than-air machine has undergone}

an astonishing evolution and has become an extreme complex system capable of ying all over the world, at hundreds meters of altitude, and in some case, at supersonic speed in ways that before were unbelievable. The Wright brother ight is dened as the rst ight even if before them other pioneers made similar experiences; this is due to the accurate work of storing data of their work, design choices, ying techniques and detailed time history of every attempt to build a ying machine.

1.1 Flight test engineer history

In the early 20th century, in order to design a new aeroplane, the aviation pioneers needed to manage alone many disciplines such as aerodynamics, material sciences, structural me-chanics, design, propulsion science and so on. In this period, there was something similar to "ight testing" but it was almost entirely aimed at performance, stability and control. Aeronautical development up to World War I (WWI) proceeded initially through the ef-forts of a few individuals. They could identify the deciencies of their aircraft, which they rectied by empirical modication. However, when (comparatively) vast numbers of aircraft were deployed during WWI, own by pilots who had little or no aeronautical training, the deciencies in contemporary designs became embarrassing. As a result, there was considerable pressure to nd solutions [1]. In this scenario, it is hard to tell when the Flight Test Engineer (FTE) function emerged. The driving forces behind the emergence of ight test engineering as a discipline, were probably the development of the theory of ight, particularly that of stability and control, and the development of a scientic/math-ematical basis for predicting the ight behaviour of a given aircraft design. A new breed of engineer - the FTE - arose who understood the theories, and could undertake the nec-essary measurements in ight (aided by primitive "Flight Test Instrumentation (FTI)"). Thus the FTE acted as the interface between theory and practice, working in very close cooperation with the designer(s). He/She took over many of the technical and scientic functions but worked closely with the pilot who was responsible for the actual ying and the ight safety.

(24)

The function of FTE was probably further re-enforced by the introduction of quantitative general requirements in respect of ying qualities, and the introduction of Joint Airwor-thiness Requirements (JAR) and Federal Aviation Regulations (FAR) and the need to demonstrate that they were satised. Moreover, by identifying specic criteria to be met, those requirements must have strongly inuenced the nature of the ight test programs conducted. The many developments in aircraft and aircraft equipment design and the increasing scope and sophistication of predictive techniques modied the scope of ight testing and the role of the FTE. For testing the performance of new subsystems, new methods had to be developed which required close cooperation with the system experts involved. It was the input from these specialists that forced the FTE to develop new ight test methods and techniques. This was the beginning of a period in which the testing of subsystems would gradually start to take a great percentage of the total testing time. In-ight assessment of structural and electronic system performance introduced new disci-plines, and theoretical treatment of the traditional disciplines of stability and control and performance became more and more complicated. As a result, the FTE could no longer remain an expert in all matters being tested and he started to depend on expertise from specialist departments or organizations. The FTE became more of a technical manager of the ight test program with responsibility for detailed specication of test points and analysis/interpretation of the results being disseminated to specialists in each discipline. As new technologies were incorporated, and the technical bases of design became ever more diverse and complicated, the FTE became less of an airborne expert and more of a person responsible for coordinating and managing all the various activities involved so that the objectives of a particular series of ight tests are met.

The FTE, as we know him/her today, deal with ight test engineering which can be sum-marised as the engineering associated with the testing, in ight, of an aircraft or item(s) of aircraft equipment. The aim of testing can be very diverse: they may be to investigate new concepts, to provide empirical data to substantiate design assumptions, or to demonstrate that an aircraft and/or its equipment achieve specied levels of performance, etc. Thus ight testing covers a broad spectrum of topics, the common feature of which is that there is a degree of novelty in the aircraft, its equipment or its intended usage which requires assessment in ight. He has become the central gure in any ight test program and he is responsible for the preparation, coordination, organization, and execution of the program and for reporting the results.

1.2 Flight test instrumentation history

As it was mentioned before the rst FTE was actually the pilot himself that, at the end of ight, reports all information and sensations that he perceived during the ight. National Advisory Committee for Aeronautics (NACA) agency, in 1930, started to use special instruments, as described in [2], to record ight test measurements in order to analyse aircraft ying qualities; at a later stage cameras were used to photograph or lm the pilot's instrument panel or other panels specially installed in the test aircraft for the purpose of the ight test and provided with special instruments and warning or indicator lights. These were the so-called "Automatic Observers" or Photo Panel Recorders [1]. After World War II (WWII) special ight test instruments became available in which a small mirror could be deected under the inuence of an electrical current, an air pressure, an acceleration or another physical phenomenon. By reecting a sharp light beam onto photo-sensitive paper, signals could be recorded. These were the early trace recorders or oscillographs. In this period the development of transducers or sensors began which could

(25)

convert a physical phenomenon into an electrical output. These outputs could be used in conjunction with the early "mirror galvanometers" or with magnetic tape recorders, which made their appearance in ight testing in the fties.

From the early fties, Frequency Modulation (FM) techniques were used for recording these electrical signals on magnetic tape.

Later, in the sixties, Pulse Code Modulation (PCM) became the major recording standard. This digital technique had the advantage of a better accuracy, a bigger dynamic range, and more data could be packed into the same space on the tape. Moreover, it facilitated the direct interfacing with the digital data processing computer. However, FM techniques are still being used at some ight test facilities for high frequency recording. In this period the use of telemetry became more widespread. It had the big advantage of providing real-time results, which could reduce the real-time needed to complete a ight test program. In the sixties the combination of digital techniques and the micro-miniaturization of electronic components triggered the development of high-capacity data acquisition, telemetry and data processing systems. These were necessary as the number of parameters to be recorded and analyzed during ight tests increased sharply from a few tens, just after WWII, to some tens of thousands for the ight testing of present-day aircraft. Not only the total number of parameters increased enormously during this period but also the number of parameters with a high sampling rate for high frequency signals, resulting in enormous gures for the total system sampling rate.

Nowadays, data systems which can cope with several millions of measurement values per second are not uncommon. This increase in capacity of ight test data systems has only been made possible by the great advances in electronic technology during the past few decades.

The continuous development of aeronautics has led to the design of specic Flight Test Instrumentation for dierent purposes. Especially, the topic of this thesis concern the FTI for Ultra Light Machines (ULM) aircraft.

1.3 Ultra Light Machines

There are dierent denitions of ULM all over the world but essentially they are lightweight aircraft with one or two seats that can be split in sub-categories [3], [4]:

• ultralight trike or weight-shift control trike: while the rst generation ultra-lights were also controlled by weight shift, most of the current weight shift ultraultra-lights use a hang glider-style wing, below which is suspended a three-wheeled carriage which carries the engine and aviators. These aircraft are controlled by pushing against a horizontal control bar in roughly the same way as a hang glider pilot ies. Trikes generally have impressive climb rates and are ideal for rough eld operation, but are slower than other types of xed-wing ultralights;

• conventional architecture aircraft: these are the most similar to the conventional civil aircraft. They can be made of metal such as steel or aluminium, wood and canvas or composite material. These aircraft are controlled by a joystick which moves the three control surfaces: ailerons, elevator and rudder so they can be moved around 3 axis: roll, pitch and yaw. They can have very dierent shape, prices and ying qualities.

• autogyro: it is a type of rotorcraft which uses an unpowered rotor in autorotation to develop lift, and an engine-powered propeller, similar to that of a xed-wing aircraft,

(26)

to provide thrust. While similar to a helicopter rotor in appearance, the autogyro's rotor must have air owing through the rotor disc to generate rotation because it is not linked with the engine. They have very high take-o and landing performance but also have high consumption than xed-wing aircraft due to the high power of the engine;

• helicopter: there are a number of single-seat and two-place helicopters which fall under the microlight categories in countries such as New Zealand because of their weight;

• powered parachutes and powered paragliding: these two kind are very similar since they both consist of an engine, a seat and a parachute. The dierence is that one has wheel (powered parachutes) and the other doesn't has wheel so they are foot-launched (powered paragliding);

• hot air balloon: there are numerous ultralight hot air balloons in the US, and several more have been built and own in France and Australia in recent years. Some ultralight hot air balloons are hopper balloons, while others are regular hot air balloons that carry passengers in a basket.

During the late 1970s and early 1980s, mostly stimulated by the hang gliding movement, many people sought aordable powered ight. As a result, many aviation authorities set up denitions of lightweight, slow-ying aeroplanes that could be subject to minimum reg-ulations. Nowadays in Europe there are a lot of local authorities such as "Ente Nazionale per l'Aviazione Civile" in Italy, "Direction Generale de l'Aviation Civile" in France or "Bundesministeriums fur Verkehr, Bau und Stadtentwicklung" in Germany but the major European institute is the European Aviation Safety Agency (EASA).

The tasks of EASA are [5]:

• Make implementing rules in all elds pertinent to the EASA mission;

• Certify and approve products and organisations, in elds where EASA has exclusive competence (e.g. airworthiness);

• Provide oversight and support to Member States in elds where EASA has shared competence (e.g. Air Operations , Air Trac Management);

• Promote the use of European and worldwide standards;

• Cooperate with international actors in order to achieve the highest safety level for EU citizens globally (e.g. EU safety list, Third Country Operators authorisations).

1.3.1 CS-VLA

CS-VLA is an airworthiness code applicable to aeroplanes with a single engine (spark or compression - ignition) having not more than two seats, with a Maximum Certicated Take-o Weight of not more than 750 kg and a stalling speed in the landing conguration of not more than 83 km/h (45 knots)(Calibrated Air Speed (CAS)), to be approved for day-Visual Flight Rules (VFR) only. It applies to aeroplanes intended for non-aerobatic operation only. Non-aerobatic operation includes: any manoeuvre incident to normal ying, stalls (except whip stalls) and lazy eights, chandelles, and steep turns, in which the angle of bank is not more than 60◦_.

(27)

1.3.2 CS-LSA

CS-LSA is a Certication Specication applicable to Light Sport Aeroplanes to be ap-proved for day-VFR only that meet all of the following criteria:

• A Maximum Take-O Mass of not more than 600 kg for aeroplanes not intended to be operated on water or 650 kg for aeroplanes intended to be operated on water; • A maximum stalling speed in the landing conguration (VS0) of not more than 83

km/h (45 knots) CAS at the aircraft's maximum certicated Take-O Mass and most critical centre of gravity;

• A maximum seating capacity of no more than two persons, including the pilot; • A single, non-turbine engine or electric propulsion unit tted with a propeller; • A non-pressurised cabin.

1.4 ULM in Italy

The law, in Italy, recognize 2 dierent kinds of Ultra Light Machines:

• Ultralight or "Ultraleggero" is a totally uncertied aircraft dene as follows [6]: Aircraft with no engine, single seat and empty weight not more than 80 Kg. Aircraft with no engine, two seats and empty weight not more than 100 Kg. Aircraft with engine, single seat, take-o weight not more than 300 Kg that

became 315 Kg if ballistic parachute is installed or 330 Kg for amphibious and stall speed or minimum stationary speed in landing conguration not more than 35 kn CAS for xed wing.

Aircraft with engine, two-seats, take-o weight not more than 450 Kg that became 472.5 Kg if ballistic parachute is installed or 495 Kg for amphibious and stall speed or minimum stationary speed in landing conguration not more than 35 kn CAS for xed wing.

Autogyro having not more than two seats and maximum take-o weight of not more than 560 Kg.

• Advanced Ultralight or "Ultraleggero Avanzato" is an aircraft that must comply with [7], and the main features are listed below:

Maximum take-o weight not more than 600 Kg for land version, 630 Kg for aircraft that can land on snow and 650 Kg for aircraft that can land on water. Stall speed in landing conguration at maximum take-o weight (VS0) of not

more than 65 kn CAS.

Very High Frequency (VHF) radio with A+C, or S or higher mode transponder and automatic Emergency Locator Transmitter (ELT).

This aircraft haven't altitude limits as is for Ultralight and so they can take ad-vantages of all services of aero navigation and with the same modes and duty of the other aircraft, despite they must conduct their ights outside the controlled airspace and air trac zone of airports, at a safe distance from obstacles and a distance not less than 5 km from airports. So an Advanced Ultralight can

(28)

ights in all the airspace of G class with the same rules of the general aviation relative to VFR.

Both of them can be certied under Certication Specications for Very Light Aircraft (CS-VLA) and Certication Specications for Light Sport Aeroplanes (CS-LSA) but in Italy, such as in all other European countries, there is no need to do it.

For this reason, normally no systematic ight test activity is planned by the manufacturing companies as a part of the design, development and production process. Even when it is performed, Flight Test activity is generally carried out adapting to the task some kind of general-purpose, PC based data acquisition system. Such systems tend to be bulky, highly intrusive-especially considering the lack of real estate available in a 450 Kg Maximum Take O Weight (MTOW) aircraft-and very little exible.

Keeping in mind the particular requirements of ULM aircraft, and with the aim to realize a Flying Laboratory capable of fullling the necessities and requirements of both research and didactic activities, the Dipartimento di Ingegneria Aerospaziale of the Politecnico di Milano has launched, in 2007, the Mnemosine project to design, make and exploit a low cost, FTI system [8].

1.5 Flight Test Instrumentation systems

The purpose of a Flight Test Instrumentation system is to acquire data about the operation of the test vehicle and provide the data to the data processing group. In general, a test article will support multiple discipline testing. Many measurands are requested by more than one user and the FTE needs to coordinate with engineers from other disciplines to dene those measurands. Other measurands are exclusively the lead FTE's. All must be dened in detail. A great deal of detailed information is required to prepare and implement an adequate instrumentation specication.

The instrumentation specication describes the measurands that the FTE requires to successfully evaluate and report on the performance or specication compliance of the vehicle and the solution to those requirements as installed in the test vehicle.

Instrumentation Systems can be classied in two areas: airborne and ground [1].

1.5.1 Airborne Systems

The purpose of an airborne instrumentation system is to acquire data about the operation or environment of a test object and store and/or transmit that data for future use. The system can be broken down to six/seven basic components:

Figure 1.1: Airborne systems scheme • A transducer that senses the phenomenon of interest;

(29)

• A signal conditioner that converts the transducer output into a standardized signal, usually electrical (several successive conditioners may be needed);

• A multiplexer to allow multiple signals to share time or space;

• An Analog to Digital Converter (ADC) (in the case of a digital system); • A modulator that converts the standardized signal so that it can be recorded. The

modulators currently in use include Frequency Modulation systems and Pulse Code Modulation Systems;

• A recorder that stores data for future retrieval;

• Telemetry systems are used either in conjunction with airborne recorders to trans-mit portions of the entire data stream to the ground or with only ground recorders when the entire data stream is transmitted such as tests of air-to-air or air-to-ground missiles. Telemetry without on-board recording may also be necessary for cost, safety, or space reasons.

1.5.2 Ground Systems

Ground instrumentation systems in general are used by many separate programs and re-quire relatively large capital investment. These systems include tracking radars, optical tracking systems, electronic warfare threat simulators, ground vibration simulators, ane-choic chambers, weather measuring systems, and data processing.

A special item of ground instrumentation is the telemetry ground station. In this sta-tion the telemetry signal is received and processed to present data to the FTE and other ground-based personnel during ight. This system can be sophisticated, with specialized computers and graphical workstations giving engineering units or can be very simple with strip chart recorders. Magnetic tapes recorded during ight can also be processed by the ground station.

Often a test bench will be used to integrate various airborne system components and pro-vide for ground maintenance by simulating an aircraft installation. Both generic benches and aircraft specic benches are used. Interoperability of components can be observed early in the design and problems can be found and solved well before the actual installa-tion. As software becomes more and more part of the instrumentation system, it too can be checked on the bench and if a recorder or aircraft telemetry transmitter is included, testing of the data processing for the project is possible.

1.6 Mnemosine FTI

The Department of Aerospace Engineering of the Politecnico di Milano (DIA-PoliMi) has often been involved in ight testing, albeit on a limited scale. In 1998, it went as far as buying a high-end ULM (a Tecnam P92 Echo), directly operating it to support ight-related activities. Initially, the airplane was used in ight familiarization experiences for undergraduate students. Gradually, in the subsequent years, it has grown to be a ying laboratory for the study and development of ight instrumentation. A fundamental step toward building up a solid expertise in ight testing has been accomplished with the de-sign, development, and implementation of the FTI system Mnemosine. This started as the core of a Ph.D. project in 2005 and has resulted in a proprietary integrated FTI suite

(30)

tailored on light aircraft, such as ULMs and general aviation xed- and rotary-wing vehi-cles, and it is capable of supporting a wide range of ight-testing activities. The system has reached a considerable degree of maturity, albeit undergoing continuous improvements and expansions, following both technological progress and application needs.

A second important element is the graduate course of Sperimentazione in Volo (ight testing). This course, incepted in 2004, has been regularly held in the second semester of the nal year of the M.S. degree program in aeronautical engineering. Teaching duties have been entrusted to top experts from world-class aeronautical organizations, such as Alenia Aermacchi and AgustaWestland, working in cooperation with DIA-PoliMi perma-nent sta. The program closely adheres to the typical outline of an introductory course oered in a professional ight-testing school. This course is fairly unique, given that it involves a real ight-testing experience on a real airplane, in addition to theory lessons and application laboratory hours. In fact, each attending student is required to plan, individually perform, and report on a ight-test mission, acting as a FTE under all re-spects. A further initiative is the collaboration of DIA-PoliMi with the Club Astra ying school and Ing. Nando Groppo s.r.l., a leading Italian ULM manufacturer. This eort, started in 2008, is directed to support didactic activities, such as the ight missions of the ight-testing course, as well as the manufacturer's ight-testing needs. In particular, Ing. Nando Groppo s.r.l. was seeking support in the process of type certication of its recent Trial model, a new three-axis control ULM, in an eort to expand its market on a European scale.

As anticipated, in order to start o with both didactic and research ight-testing projects on DIA-PoliMi's Tecnam P92 Echo, the aircraft needed to be equipped with an appro-priate FTI system. Given the limitations of a PC-based general-purpose data-acquisition system and willing to acquire and maintain detailed knowledge, eective control, and high exibility of the data-acquisition process, a specic activity aimed to design, develop, and test a ULM-tailored FTI system has been launched as the main topic of a Ph.D. project, eventually yielding the Mnemosine system. [9]

The system requirements are deeply inuenced by the academic nature of the project. Apart the unavoidable low budget constraints, in fact, the highly dynamic nature of the project called for a system capable of being upgraded or maintained in one or more com-ponents without aecting the operational capability of the remaining parts. In addition, it was clear that it was necessary to provide a huge growth potential, because of the pre-dictable expansion of the system as new inputs from the research activities will arise. To summarize, the initial requirements identify the system as [8]:

• Low cost, • Reliable, • Flexible, • Non intrusive,

• Easy to manage and maintain, • Open,

• Assuring a considerable growth potential.

At the beginning it appeared that the most suitable architecture to satisfy the above re-quirements was the federate one, in which the system is divided in a number of autonomous nodes. Every single node can operate independently from the others, and is specialized for

(31)

specic task: it has processing power, memory, power supply and all the signal condition-ing/interface resources required to manage the particular sensor/device it manages. All the data generated by the modules is then shared by means of a common communications line: a digital data bus. Among the advantages of such an architecture, the possibility to distribute the units across the aircraft permits to place every module as close to the sensor it manages as it is possible, avoiding to lay down long, noise sensible analog signal lines, since information is immediately converted to a digital format, processed and transmitted over a robust medium.

1.6.1 Mnemosine Mk I-II-III

So the rst three generation of Mnemosine were realized with the federated system where each node has a common board and a dedicated hardware specically for its purpose.

Figure 1.2: System Block Diagram of Mnemosine MkIII

The block diagram representing the system architecture can be seen in gure 1.2. It con-sists, so far, of six units, named after the Ancient Greek mythology Muses: Terpsicore, Urania, Melete, Polimnia, Eutherpe and Talia. Terpsicore is the Inertial Measurement Unit (IMU) management unit. It controls inertial data acquired by a solid state, Micro ElectroMechanical System (MEMS) based Attitude Heading Reference System (AHRS) unit.

Urania is the Air Data System (ADS) management unit, that interfaces air data sensor to the data bus. Air data is sampled by means of a sensor head, containing all the trans-ducers, installed at the end of a pitot boom.

Power supply and distribution to the various nodes is managed by Melete. At present, in order to avoid messing with the aircraft's electrical system, power for the Mnemosine sys-tem is supplied by a dedicated sealed lead acid 12V 7Ah battery. Melete has the ability to power on and o the entire system, to monitor battery parameters, including voltage and current consumption, and to recharge the battery when connected to a suitable external adapter.

Polimnia is the Global Positioning System (GPS) management node. It includes a Satel-lite Based Augmentation System (SBAS) enabled GPS engine, providing Position, Velocity and Time solution. Signal is received by an antenna installed on the upper surface of the airplane, at the intersection between the fuselage and the wing.

Flight Control (FC) position acquisition is accomplished by Eutherpe. Three linear po-tentiometers are clamped to the kinematic chain that conveys stick and pedal commands to the relevant aerodynamic surfaces. Signal from potentiometers passes through a signal conditioning and anti aliasing ltering block, is sampled, converted and numerically l-tered by Eutherpe before being sent on the data bus.

(32)

Finally, Talia, the engine data module, acquires propeller Revolutions Per Minute (RPM) by means of a hall sensor and a magnet directly mounted the propeller mast. Talia also provides a 2 channel thermocouple signal condition circuitry, so as soon as the thermo-couples will be installed in the engine compartment it will be possible to acquire Cylinder Head Temperature (CHT) and Exhaust Gas Temperature (EGT) values.

1.6.2 Mnemosine Mk IV

The realization of a federate architecture involved some disadvantages with respect to the standard, integrated solutions. First of all it was necessary to dedicate and additional amount of resources during the design and implementation phases, because of the great number of dierent modules. Moreover each single unit replicates in its own structure some common parts, namely the power supply and the data bus interface: this implies a drawback in terms of additional volume and weight of the system. Another deciency of using a federated solution is that data are intrinsically asynchronous and aected by a short random delay.

As outlined in the previous theses regarding the development of new version of Mnemosine MkIII, [10] and [11] it appears the need of a new, deeply changed, conguration with some particular requirements:

• A centralized architecture composed by:

A principal node with a powerful microcontroller unit capable of acquire, collect and store data from all sensors;

An Air Data node with a microcontroller capable of processing data acquired from sensors installed on the Pitot-boom (static and dynamic air pressure, angle of attack, angle of sideslip and temperature) and send them to the main node through a particular communication protocol;

An access point to send data acquire by sensors to a Ground Station; • A GPS receiver installed on-board;

• Three serial channels in order to connect the IMU, the User Interface (UI) and the StickForce;

• Eight analogical input;

• A power selector for switching from battery to aircraft supply and vice-versa; • Possibility of hardware and software upgrade.

As a consequence of the last federated solution (Mnemosine MkIII), it was developed a new version, called Mnemosine MkIV, capable of satisfy all the requirements listed above. What came out is show in gure 1.3.

(33)

Figure 1.3: Mnemosine MkIV

It can be seen that this version is really dierent from the latest one, indeed there are only one main module and one external module (Urania) capable of providing air data. This solution is smaller, lighter, more compact and easy to install.

Mnemosine MkIV is the last FTI system design and developed at Politecnico di Milano. Nevertheless this solution have never ight because of time delay in respect of the Flight testing course of the academic year 2014 and some diculties that have been found during the development.

For this reasons has been decided to develop a new version called Mnemosine MkV with the same requirements of the previous one and the advantage of the awareness got during the development of the last version.

(34)

(35)

Chapter 2

Mnemosine MkV hardware

architecture

In this chapter, the hardware architecture of Mnemosine MkV will be presented. The development initially began capitalizing all the diculties and the solutions found with the work done for the previous versions.

As previously said, Mnemosine MkV has a centralized architecture; nevertheless it was decided to split all the connectors of the main module in two separate boards (the Mas-terboard and the Slaveboard), connected with a 40 pin at cable in order to put them one above the other and to obtain a more compact and easy to install system.

(36)

The ADS is placed near the Pitot-boom and is the only module separated from the main board with which it can communicate through a special version of a Controller Area Network For Flight-test Equipment (CAFFE) protocol. The block diagram of Mnemosine MkV is shown in gure 2.1.

It can be noticed that it is quite similar to the previous version shown in gure 1.3. To summarize, a list of all the components that constitute Mnemosine MkV follows:

• processing board; • power supply unit;

• analog signal conditioning block; • air data system module;

• stick force data block; • inertial data block; • engine data block; • GPS data block; • kneepad data block.

In the following pages each component individually will be analysed .

2.1 Processing board

The processing board is the central core of the whole system. After some researches made in [11], it was chosen an STM32-E407 provided by STMicroelectronics which is a development board featuring a powerful ARM Cortex-M4F microcontroller with the most important peripherals, interfaces and connectors mounted and ready to use.

The Cortex-M4F is equipped with a single precision Floating Point Unit (FPU) which let it work with all types of data. The memory of the microprocessor is composed by up to 1 Mb of ash memory and up to 192+4 Kb of Static Random Access Memory (SRAM) including 64 Kb of Core Coupled Memory (CCM) data Random Access Memory (RAM) which ensure to Mnemosine MkV a suitable memory space for its applications. The timing source is constituted by a factory-trimmed (1% accuracy) 16 MHz crystal oscillator and a 32 kHz oscillator for the real-time clock separately powered, which can rely on 4 Kb of SRAM. The microcontroller should be supplied from 1.8 V to 3.6 V. It is possible to obtain a maximum of three 12 bit, 2.4 MSPS ADC with up to 24 channels and 7.2 MSPS in triple interleaved mode; moreover there are two 12 bit Digital to Analog Converter (DAC), 16-stream Direct Memory Access (DMA), that can be used to direct transfer data from or to memory to minimize the interruptions caused by program-controlled data transfers [12]. It has up to twelve 16 bit and two 32 bit timers up to 168 MHz, each with up to 4 input capture, output compare or Pulse Width Modulation.

In the STM32-E407 are also included up to 15 communication interfaces: • three Inter-Integrated Circuit (I2C) interfaces (SMBus/PMBus);

• four Universal Synchronous/Asynchronous Receiver/Transmitter (USART) and two Universal Asynchronous Receiver/Transmitter (UART) (10.5 Mbit/s, ISO 7816 in-terface;

(37)

• three Serial Peripheral Interface (SPI) (37.5 Mbit/s), 2 with muxed full-duplex In-tegrated Interchip Sound (I2S) to achieve audio class accuracy via internal audio phase-locked loop or external clock;

• Secure Digital Input/Output (SDIO) interface;

• two Controller Area Network (CAN) interfaces (2.0B Active).

The last two communication interfaces are the most useful for Mnemosine MkV since they are used to store data and to communicate with the ADS respectively.

The development board can be seen in gure 2.2.

Figure 2.2: Olimex STM32-E407 development board

2.2 Power supply unit

In gure 2.3, it is shown the Power Supply diagram where it can be noticed that both the aircraft power supply and the external battery can be used at the same time. In gure 3.33, it can be seen how it is possible to switch from one supply to the other. Both the power supply lines are regulated by the power supply unit which ensures a constant voltage of ±12 V. The electrical supply of the sensors is conducted by the main board through some dierent communication protocols. The last thing to be underlined is the access point which can be powered by either the ethernet cable or the aircraft's power supply.

(38)

Figure 2.3: Power supply diagram

2.3 Analog signal conditioning block

In order to acquire the control surfaces position and the propeller pitch, wire potentiome-ters were used. These sensors are easy to integrate and can reach the same performances of a common linear rigid rod potentiometer; at the same time they can ensure a higher degree of safety since they can be broken by the Flight Test Pilot (FTP) if they obstruct the government of the control surfaces.

In order to avoid aliasing these data must be ltered before being sample by the ADC. The adopted lter is a low-pass lter, with a cut-o frequency of 10 Hz.

2.4 Air data system module

The ADS is the only external module of Mnemosine MkV in order to avoid a long linkage pipe between the probe and the transducer. It is composed by an Olimex STM32-H107, two pressure transducer (static and dynamic air pressure), one Resistance Temperature Detectors (RTD), an analog signal conditioning module for wind angles measures and two CAFFE connectors.

(39)

The two pressure transducers are HCLA0050EU [13] and HCA0611ARH8 [14] which fea-tures are displayed in table 2.1:

HCLA0050EU HCA0611ARH8 phenomenon dynamic pressure static pressure

range [hPa] 0 - 50 600 - 1100 max pressure [hPa] 1200 3000 temperature range [◦_C] _{-25 - +80} _{0 - +85}

sensitivity [mV/hPa] 80 8 Table 2.1: Pressure transducers features

The RTD signal for the outside air temperature is sampled through a MAX31865 [15] that is a resistance-to-digital converter.

2.5 Stick force data block

Stick force data are acquired through a small 3D load cell, originally built for automotive application, the Futek MU300 [16]. In order to get out measurable data from the load cell, HX711 load cell amplier was used. The load cell gathers the stick forces in both directions, while the load cell amplier allows complete processing of the signal.

(40)

2.6 Inertial data block

In order to capture the inertial data of the aircraft, Mnemosine MkV capitalizes the Xsens MTi AHRS [17]. The Xsens MTi outputs and technical specications are listed below:

• 3D orientation • 3D rate of turn

• static accuracy (roll/pitch) < 0.5◦

• static accuracy (heading) < 1.0◦

• repeatability 0.2◦

• max update rate 120 Hz

• 3D acceleration • 3D magnetic eld • dynamic accuracy 2◦ _RMS • angular resolution 0.05◦ • operating voltage 4.5 - 30 V • digital interface RS-232, RS-485, RS-422 In table 2.2, the full scale for each sensors is displayed.

rate of turn acceleration magnetic eld temperature [deg/s] [m/s2_] _[mGauss] ◦_C

±300 ±50 ±750 -55...+125 Table 2.2: Xsens MTi calibrated data full scale

2.7 GPS data block

The GPS module is used both as positioning sensor and as time source. This feature will be better explained in section 3.4 but it is already clear its critical task.

In order to meet this requirement the u-blox LEA-6N [18] was chosen for Mnemosine MkV. The LEA-6N is a stand-alone GPS positioning module featuring the high performance u-blox 6 engine. This versatile, standalone receiver combines an extensive array of features with exible connectivity options. LEA-6N modules maintain the industry standard 17.0 x 22.4mm form factor of the LEA-6 and LEA-5 families and have been designed to allow simple migration. The ease of integration results in reduced costs and short time to market for a wide range of automotive, consumer and industrial applications. The LEA-6N adds GLObalnaya NAvigatsionnaya Sputnikovaya Sistema (GLONASS) functionality to high performance u-blox 6 positioning. The Russian GLONASS satellite system is an alternative to the US-based Global Positioning System. LEA-6N also provides u-blox 6 GPS performance with enhanced coverage and performance compared to previous rmware versions by supporting the Japanese Quasi-Zenith Satellite System (QZSS). LEA-6N also supports the GALILEO global navigation satellite system even if the rmware requires an appropriate upgrade. The 50-channel u-blox 6 positioning engine features a Time-To-First-Fix (TTFF) of under 1 second. The dedicated acquisition engine, with over 2 million correlators, is capable of massive parallel time/frequency space searches, enabling it to nd satellites instantly. Innovative design and technology suppresses interference sources and mitigates multipath eects, giving LEA-6N GPS receivers excellent navigation performance even in the most challenging environments. The LEA-6N operating voltage is: 2.7 - 3.6 V. It has several interfaces: UART, Universal Serial Bus (USB) and Display

(41)

Data Channel (DDC) which is compliant with I2C. The LEA-6N main performances are summarized in table 2.3.

parameter specication GPS GLONASS

TTFF1 _{cold start (without aiding)} _{29 s} _{36 s}

warm start (without aiding) 28 s 25 s hot start (without aiding) 1 s 2 s aided starts 1 s n.a. max navigation update rate 2 Hz 1 Hz horizontal position accuracy2 _{2.5 m} _{4 m}

accuracy for timepulse signal3 _RMS _{30 ns} _{50 ns}

99 % <60 ns 100 ns frequency of timepulse signal 0.25 Hz to 1 Hz

velocity accuracy4 _{0.1 m/s}

heading accuracy4 _0.5◦

operational limits dynamics ≤ 4g

altitude5 _{50000 m}

velocity5 _{500 m/s}

Table 2.3: LEA-6N GPS/GLONASS performance

1_{all satellites at -130 dBm}

2_{CEP, 50%, 24 hours static, -130 dBm, SEP: < 3.5 m}

3_{Under good GPS/GLONASS signal conditions}

4_{50% 30 m/s}

(42)

2.8 Hardware overview

In gures 2.5 and 2.6, the renders of the Masterboard and the Slaveboard are shown. These renders were made with the Autodesk Inventor 3D CAD software [19]. The 3D model of Mnemosine MkV was very useful during the design phase, indeed it was used to choose the position that best ts with the requirements of minimal amount of space and of practicality. With the aid of the 3D model, it was also developed the front panel, needed for a safe protection of the Mnemosine MkV components during the ight tests.

Figure 2.5: Mnemosine MkV Masterboard connectors

(43)

Chapter 3

Firmware development

In this section, it will be explained how the rmware was developed. At rst, all the requirements needed by the FTI will be illustrated and then the architecture will be described; the purpose is to clarify all the choices made and to describe in depth the procedure followed to obtain the rmware of Mnemosine MkV.

3.1 Requirements

The main requirements are strongly inuenced by the nature of the project, indeed this system needs to be capable of acquiring all data necessary for ight testing such as:

• air data:

total air pressure; dynamic air pressure; static air pressure; total air temperature; outside air temperature; angle of attack; angle of sideslip; • GPS data: 3D ECEF position; 3D ECEF velocity; UTC time; • stick forces;

• control surface positions: elevator;

aileron; rudder;

(44)

aps; • engine data: engine RPM; propeller RPM; propeller pitch; fuel ow;

The most important feature for an FTI system is that it must provide data in a synchronous way. Furthermore, once data have been sampled, they need to be stored properly and, above all, loss of data must be avoided. For this reason an advanced diagnostic and robust system is mandatory.

The system must be low cost, reliable, non intrusive, easy to manage and maintain and must ensure a considerable growth potential.

Other requirements are those related to the link: a stable wireless link with a ground station is required and also a permanent link with a knee-pad inside the cockpit must be ensured.

3.2 Real Time Operating System

In order to satisfy all the requirements the choice of a adequate Real Time Operating System (RTOS) is necessary. This kind of system are widely used in industrial environ-ment such as: process control, automotive, communication, robots, oce automation or anywhere there is the need of obtain a deterministic time response. Real-time systems are characterized by the severe consequences that result if logical as well as timing correctness properties of the system are not met. Two types of real-time systems exist: soft and hard. In a soft real-time system, tasks are performed by the system as fast as possible, but the tasks don't have to nish by specic times. In hard real-time systems, tasks have to be performed not only correctly but on time. Most real-time systems have a combination of soft and hard requirements like Mnemosine MkV has. Such a combination is also called foreground/background systems or super-loops. An application consists of an innite loop that calls modules (i.e., functions) to perform the desired operations (background). In-terrupt Service Routines (ISRs) handle asynchronous events (foreground). Foreground is also called interrupt level; background is called task level.

A task, also called a thread, is a simple program that thinks it has the Central Processing Unit (CPU) all to itself. The design process for a real-time application involves splitting the work to be done into tasks responsible for a portion of the problem. Each task is assigned a priority, its own set of CPU registers, and its own stack area. Each task typ-ically is an innite loop that can be in any one of ve states: dormant, ready, running, waiting (for an event), or ISR (interrupted). The dormant state corresponds to a task that resides in memory but has not been made available to the multitasking kernel. A task is ready when it can execute but its priority is less than the currently running task. A task is running when it has control of the CPU. A task is waiting when it requires the occurrence of an event (for example, waiting for an Input / Output (I/O) operation to complete, a shared resource to be available, a timing pulse to occur, or time to expire). Finally, a task is in the ISR state when an interrupt has occurred and the CPU is in the process of servicing the interrupt.

(45)

by the ISRs to ensure that they are dealt with in a timely fashion and besides this, the RTOS inside Mnemosine MkV has a specic time-out for each function.

Because of this, ISRs have a tendency to take longer than they should. Also, information for a background module that an ISR makes available is not processed until the back-ground routine gets its turn to execute, which is called the task-level response.

A Shared resources is a resource that can be used by more than one task. Each task should gain exclusive access to the shared resource to prevent data corruption. As you can imagine this an high priority of Mnemosine MkV and the process that manage whit this is called mutual exclusion or mutex.

The multitasking is the process of scheduling and switching the Central Processing Unit between several tasks; a single CPU switches its attention between several sequential tasks. Multitasking is like foreground/background with multiple backgrounds. Multitasking max-imizes the use of the CPU and also provides for modular construction of applications. The kernel is the part of a multitasking system responsible for management of tasks (i.e., for managing the CPU's time) and communication between tasks. The fundamental ser-vice provided by the kernel is context switching. The use of a real-time kernel generally simplies the design of systems by allowing the application to be divided into multiple tasks that the kernel manages. A context switches process occur when a multitasking kernel decides to run a dierent task, it saves the current task's context (CPU registers) in the current task's context storage area - its stack. After this operation is performed, the new task's context is restored from its storage area and then resumes execution of the new task's code.

The last important think to be taken into account is the preemptive kernels which is used when system responsiveness is important. The highest priority task ready to run is always given control of the CPU. When a task makes a higher priority task ready to run, the current task is preempted (suspended), and the higher priority task is immediately given control of the CPU. If an ISR makes a higher priority task ready, when the ISR completes, the interrupted task is suspended, and the new higher priority task is resumed [20]. The last important characteristic that a RTOS has, is the message mailbox which is typ-ically a pointer-size variable. Through a service provided by the kernel, a task or an ISR can deposit a message (the pointer) into this mailbox. Similarly, one or more tasks can receive messages through a service provided by the kernel. Both the sender and receiving task agree on what the pointer is actually pointing to. A waiting list is associated with each mailbox in case more than one task wants to receive messages through the mailbox. A task desiring a message from an empty mailbox is suspended and placed on the wait-ing list until a message is received. Typically, the kernel allows the task waitwait-ing for a message to specify a time-out. If a message is not received before the time-out expires, the requesting task is made ready to run, and an error code (indicating that a time-out has occurred) is returned to it. When a message is deposited into the mailbox, either the highest priority task waiting for the message is given the message (priority-based), or the rst task to request a message is given the message (First-In First-Out or FIFO). Currently there are a lot of RTOS available for every requirement but, avoiding all op-erating system with proprietary license, the one who emerged is ChibiOS/RT [21] which is distributed under GPL3 [22] license so the code can be used also for commercial prod-uct. ChibiOS/RT is designed for deeply embedded real time applications where execution eciency and compact code are important requirements. This RTOS is characterized by its high portability, compact size and, mainly, by its architecture optimized for extremely ecient context switching. The development environment is based upon Eclipse that is an Integrated Development Environment (IDE) for Java, C/C++ and PHP.