Flight Data Acquisition Platform Development, Integration, and Operation On Small-To Medium-Sized Unmanned Aircraft

AIAA SciTech Forum 10.2514/6.
2019-1262
7-11 January 2019, San Diego, California
AIAA Scitech 2019 Forum
Flight Data Acquisition Platform Development, Integration, and

Operation on Small- to Medium-Sized Unmanned Aircraft
Or D. Dantsker ∗ Renato Mancuso†

Al Volo LLC, Urbana, IL 61801 Boston University, Boston, MA 02215
Unmanned aerial vehicles (UAVs) are rapidly increasing in popularity for civilian, military, and research
Downloaded by IOWA STATE UNIVERSITY on February 6, 2019 | http://arc.aiaa.org | DOI: 10.2514/6.2019-1262
applications, and as part of this uptrend, significant effort has been undertaken to integrate an increasing
amount of sensing into these vehicles. This sensing, or in other words, acquisition of sensor data, is part of
the core functionality of UAVs — without the ability to sense, an unmanned aircraft is unable to function. By
intelligently integrating sensors into a vehicle and properly interfacing with them, one is able to derive streams
of data from these sensors, which allow the aircraft to fly and the desired mission to occur. In just the past
several years, along with the uptrend in UAV use, there has been an increase in the research to evaluate and
improve aircraft performance and flight characteristics. All of these efforts depend on the ability to acquire
and utilize high fidelity data from a large range of sensors and devices. This paper will first provide an overview
for the development of a data acquisition system. It will then focus on the design aspects involved including
system architecture, sensing interfaces, common sensors, and user interface. Next, the paper will present
a study of data acquisition systems and flight control systems that have been used in UAV research, with
their specifications. Finally, avionics integration examples will be provided to demonstrate application in an
unmanned aircraft.
Nomenclature
ADC = analog-to-digital converters

AHRS = attitude and heading reference system
CPU = central processing unit
DOF = degree of freedom
ECU = engine control unit
ESC = electronic speed controller
GPS = global positioning system
GNSS = global navigation satellite system
IC = integrated circuit
IMU = inertial measurement unit
INS = inertial navigation system
I/O = input output
PCB = printed circuit board
PW M = pulse width modulation
PPM = pulse position modulation
RC = radio control
UAV = unmanned aerial vehicle
∗ Aero-Mechanical Engineer. [email protected]

† Assistant Professor, Department of Computer Science. [email protected]
1 of 31
Copyright © 2019 by Or D. Dantsker and Renato Mancuso. Published by theAmerican Instituteofof

American Institute Aeronautics
Aeronautics and Astronautics
and Astronautics, Inc., with permission.
I. Introduction
Unmanned aerial vehicles (UAVs) are rapidly increasing in popularity for civilian, military, and research applications.
As part of this uptrend, significant effort has been undertaken to integrate an increasing amount of sensing into these
vehicles. This sensing, or in other words, acquisition of sensor data, is part of the core functionality of UAVs — without
the ability to sense, an unmanned aircraft is unable function. By intelligently integrating sensors into a vehicle and
properly interfacing with them, one is able to derive streams of data from these sensors, which allow the aircraft to fly
and complete the desired mission.
In just the past several years, along with the uptrend in UAV use, there has been an increase in the research to
evaluate and improve aircraft performance and flight characteristics. For example, significant effort has been put into
studying their aerodynamic qualities,1, 2 especially in high angle-of- attack conditions,3–5 as well as the development of
new control algorithms.6–11 In addition, unmanned aircraft are often used as low-cost stand-ins for experiments that are
too risky or costly to perform on their full scale counterparts.12–14 They are often also used to explore new aircraft
configurations15–18 or flight hardware.19–21 All of these efforts depend on the ability to acquire and utilize high fidelity
data from a large range of sensors and devices.

This paper will first provide an overview for the development of a data acquisition system. It will then focus on
the design aspects involved including system architecture, sensing interfaces, common sensors, and user interface.
Next, the paper will present a study of data acquisition systems and flight control systems that have been used in UAV
research, with their specifications. Finally, avionics integration examples will be provided to demonstrate application in
an unmanned aircraft. The paper will conclude with a summary.
II. Development Overview
Capturing data is a fundamental component of con-

ducting flight research with unmanned aircraft and doing
so requires the acquisition of high fidelity flight data from
a large range of sensors and devices. This naturally leads
one to either attain and utilize an existing data acquisition
platform or to develop their own if they are unable to find
a system that can satisfy their needs. This process, as do
many others, generally follows the engineering design
process, shown in Fig. 1. At the start, one has to under-
stand the underlying problem: what type of data needs
to be collected; this will depend on the intended research
that will be conducted. This often involves performing
an extensive study of platforms currently available as
well as those that have been developed at universities and
research agencies, as will be presented in the following
section. This research then leads to an extensive list of de-
sired and/or required specifications, most often based on
what is state of the art. The first and likely most critical
consideration that must be taken into account is that of
the intended uses of a platform and the sensors required.
Essentially, what data must be captured and why? From
this point forth, it will be assumed that the interested party Figure 1. The engineering design process.
was unable to find an existing system that satisfies their
requirements and has decided to develop their own.
2 of 31
American Institute of Aeronautics and Astronautics

The next consideration is that of platform integration, i.e., how will it be integrated into the aircraft and whether there
are size, weight, access constraints. This is especially important on small unmanned aircraft, which leads to the notion
that a platform must likely be highly integrated; however, at the same time, such tight integration can be restrictive,
especially if modifications must be made. Should the platform designer, for example, split the data acquisition between
multiple logical devices, sending all of the measurements back into a central device? This could be advantageous in
distributing the work, especially if some logical devices can be given the task of handling high-level tasks while others
handle low-level tasks. Yet implementing such a platform design may lead to sensory streams having undesirable
temporal properties, which in turns affects the quality of produced data. Alternately, the platform may be made up of a
single logical device prudently managing all of the sensors and measurement devices. Generally, performing benchmark
testing of a platform will help determine which approach should be used.
In order to reach design maturity, testing is key. Initial development is often performed by piecing together and
interconnecting a set of mostly independent, integrated circuit (IC) components, each on their own printed circuit
board (PCB). The strict segregation of components is initially used to test each and every subsystem individually,
while designing the software/hardware infrastructure with the integration goal in mind. The divide et impera approach
has shown to produce highly reliable sensor-processor communication. Then, as the system is miniaturized, these
components moved into close proximity with each other. Apart from the obvious hardware integration, subtle signal
interplay and similar issues arising from circuit-level integration must be extensively investigated and addressed.
Many issues are largely software dependent, as timing properties of software-hardware interaction routines need to be
re-calibrated once all the subsystems are contemporarily active. For other issues, new revision of the hardware layout
are often required and yield the most reliable solution in terms of reliability and robustness. Flight testing, throughout
the whole miniaturization process, also reveals several other challenges that cannot be discovered on the ground.
Minimizing the time required to develop and integrate a platform into an aircraft is also very important and thus a
crucial design driver that must be taken into account. Effectively, there is little point to perform system development if
the end results will either be too late to meet a project timeline or be impossible to integrate. Therefore, significant effort
should be put into developing a self-contained system that could be assembled, installed, and controlled. Regarding
control, the end use researcher must be able to interface with the platform in order to communicate required commands.
This can mean a wired or wireless connection; however, extra care should be taken with the later for some applications,
especially those with possible RF interference or other limitations. Thus, the goal of this particular design effort is to
ensure that in a complex environment, as most aircraft testing setups are, the platform can be self-contained, not cause
interference, and finally be controllable. Effectively, this describes the deployability of the platform solution, which is
especially difficult on small electric unmanned aircraft.
3 of 31

III. Design Aspects
The design of a data acquisition system requires careful consideration and forethought. In this section we discuss a
variety of design aspects, which should be considered during the development process.
A. Architecture
A data acquisition system designed to operate on board in a UAV is required to define two main sub-systems. The first
essential sub-system is comprised of a set of sensor-side I/O interfaces that goes under the name of low-level sensor
interface. The second fundamental building block is the data aggregation and storage unit, which, as the name suggests,
aggregates what is collected via the low-level interface into a single data stream. It then performs a minimum set of
format conversion operations, on each sample of the data stream, intended to optimize the aggregated data for long-term
storage.
While the subsystems described above represent the bare minimum for a data acquisition system, a number of
additional modules can be added to increase functionality, in-the-field deployability, and composability with the rest
of the onboard avionics. An important module that is usually implemented is a command & control unit to direct
acquisition and logging operations. Apart from local storage of the acquired data, the system may also provide a set of
live feed data streaming communication units. Communication interfaces can be used to provide a sensor feed to other
on-board sub-systems (e.g. an autopilot), to establish a telemetry channel with a ground station, and to allow in-flight
access to the command control interface. Finally, a data acquisition system may offer a graphical user interface that
internally leverages the communication and the command control interface. The goal of the graphical interface is to
simplify in-the-field configuration and operation.
Given the required and optional modules described above, the mapping of these modules onto computation units
dictates a number of important properties of the final acquisition system, such as: (1) maximum acquisition rate; (2)
degree of user-level interactivity; (3) degree of integration with other on-board avionics; (4) degree of inter-operability
with different UAVs. We now delve into typical design trade-offs between system complexity and the four properties
mentioned above.
1. Processing Domains
In this work, we refer to a processing domain as a self-contained processing system. This includes one or more
processors (CPUs), memory resources and communication interfaces. A processing domain also defines a power and
clock domain. It follows that different processing domains are also tolerant with respect to power and/or clock loss that
occurs in a different processing domain.
The multiple components of a data acquisition system mentioned above operate at very different time scales. On
the one side of the spectrum, the low-level sensor interface needs to be precise at a micro-second scale. On the other
hand, the communication with the user can be carried out few times every second. Components like data aggregation
unit, command control, and communication have their own timescale. In principle it is possible to consolidate all
these components onto the same general-purpose processing domain. In practice, however, this choice leads to unstable
performance and sub-optimal maintainability.
A system design where both necessary and optional units are implemented onto the same processing domain will
be sub-optimal for two main reasons. First, low-level communication with sensors often involve handling a large
number of short-lived I/O events to/from the sensor pool. While each event generally requires few processor cycles, a
context-switch from other processing flows (e.g. user interface handling) is required. Unfortunately, in a general-purpose
processing system, context-switches are not only costly, but introduce significant latency. As such, it would be necessary
to deploy a high-performance CPU to achieve sampling rates in the order of 50-100Hz. High-performance CPUs,
however, are not power-efficient and may require active cooling, which directly impacts the minimum power and
weight that can be achieved with such an approach. In order to lower the power and weight requirements, an embedded
CPU can be used. The lower operating frequency of traditional embedded CPUs, however, imposes a hard cap on the
4 of 31

achievable sampling rate. It can be noted in the previous sections that solutions that are compact in weight and power
are characterized by sampling rates in the 20-50Hz range. Achieving higher rates is possible only by playing careful
workload optimization.
The route of performing ad-hoc optimization to reconcile the activity of system components with different character-
izing time-scales, however, highlights the second main weakness of the single processing domain approach. A system
implemented following this approach is hard to maintain and expand. This is because while certain system components
are almost immutable (e.g. the low-level sensors interface), others undergo continuous refinements and expansions (e.g.
a graphical user interface). Often, a revision/expansion of a high-level component can break an ad-hoc optimization that
is crucial for temporal sampling stability. As such, a costly re-consolidation of all the system components is required.
Following an approach that is the opposite of what described above (consolidation of all the system units onto the
same processing domain), one can first assign each system unit onto its own processing domain. Then, the multiple
domains can be integrated with the specification of appropriate inter-domain communication channels. We refer to this
as the composite approach. The main advantage of the composite approach is that hardware resources can be ideally
tailored to match the computation needs required by each and every sub-system.
Unfortunately however, the additional burden introduced by synchronization and the increased overall system
complexity make the composite approach not necessarily cost-efficient. This is particularly true for high-end units that
implement all the auxiliary sub-systems descried above.
A hybrid approach, known as the dual-domain design, appears to strike the best compromise. In the dual-domain
design, two processing domains are used. A first time-sensitive domain handles all the low-latency communication with
the sensor pool which occurs at the nanosecond/microsecond time-scale. A second compute-heavy processing domain
handles all the data processing, storage and external communication workload at the millisecond/second time-scale.
2. Communication Interfaces
In a minimal setup, a data acquisition system only performs local storage of acquired flight data for offline analysis. It
is not uncommon, however, for modern data acquisition systems to also output a live feed of sensor data during flight.
Two main communication interfaces are usually provided. The first is directed towards a ground station and uses either
a high-power point-to-point radio link, or a wireless network infrastructure (e.g. 4G). A second is usually provided for
other onboard avionics that are co-located on the same aircraft. A typical example is an autopilot.
When data is relayed using a wireless channel to a ground station, the data bottleneck is typically represented by
the channel itself. Commercial point-to-point radios with a transmission range of few miles have a typical bandwidth
that does not exceed a few hundreds of Kbps. As such, heavy data compression is required. Moreover, the refresh
rate for streamed data needs to be in the few tens of Hz. Leveraging a network infrastructure can provide significantly
higher transmission rates. For instance, by exploiting 4G networking it is possible to transmit up to 50 Mbps under
ideal conditions. The downside of this approach is that contact with the ground can be lost if the aircraft temporarily
enters an area with poor network coverage. Additionally, since the available bandwidth is strictly dependent on the
congestion level of the network, sudden sags in available bandwidth can cripple ground-to-aircraft communication.
A data acquisition unit has a global view of all the sensor streams in the aircraft. As such, it is convenient to
implement an autopilot since the acquired data feed can be used to compute aircraft attitude and actuation decisions.
Based on this observation, a number of different designs have been provided, surveyed in the next section. For systems
that do implement an autopilot system, there exist two main design choices.
A first option consists in implementing the autopilot on the same processing system as the data acquisition. In this
case, we refer to a unified implementation, where the autopilot and data acquisition sub-systems use internal resources
and interfaces to communicate. These can be a shared memory channel, or a message-passing interface, such as a
socket network interface. A shared memory channel offers benefits in terms of performance — the two sub-systems
generally pay little overhead to synchronize over the shared sensor data pool. Nonetheless, message-passing interfaces
provide benefits in terms of robustness, because they decouple the behavior (and misbehavior) of the two sub-systems.
5 of 31

A second common approach is to implement the autopilot on an entirely separated processing domain. As such, we
say that such designs implement a split paradigm. In this way, both the autopilot and data acquisition systems have their
own processing and memory resources, and exclusive interfaces to actuators and sensors. This approach guarantees
maximum isolation between the two sub-systems, but it comes at the expense of additional complexity, weight, and
power consumption. In systems that are designed according to the split paradigm, a dedicated, physical interface is used
to provide sensing data from the data acquisition side to the autopilot side of the system. Typical interfaces include serial
connections (e.g. UART, RS-232, RS-485), or wired network interfaces (e.g. Ethernet). While serial connections can be
supported easily in data acquisition systems implemented on simpler processors, these interfaces provide relatively low
bandwidth, topping at few Mbps. Conversely, significantly higher bandwidth (few hundreds of Mbps) can be achieved
using network interfaces, but their support is limited to platforms that feature a full networking stack.
B. Sensing Interfaces
A data acquisition system needs to aggregate sensor data produced by a number of different sensors. Depending on the
type of sensor and on the rate at which sensor data is available, a number of interfaces are used for raw data acquisition.
We hereby provide a short summary of the most common interfaces, along with their main strenghts and shortcomings.
1. Synchronous and Asynchronous Serial
Serial communication with sensing devices is commonplace in many data acquisition systems. The RS-232 standard
is widely used to implement inter-device serial communication. The standard defines a variety of communication
bandwidths and can be used for both asynchronous and synchronous communication. In spite of its versatility, the
RS-232 interface requires 5 wires (a ground line, 2 data lines, 2 flow control lines) to be fully supported. For this
reason, many embedded systems implement only a subset of the full RS-232 features, namely a UART interface. UART
communication is always asynchronous and only requires 3 lines for full-duplex communication (1 ground line, 2 data
lines).
Communication using traditional serial interfaces can sustain a maximum bandwidth in the order of few hundreds of
Kbps. In fact, the most commonly supported maximum bit-rate is 115.2 Kbps. Newer controllers and devices support
rates up to 921.6 Kbps. Newer revisions of the RS-232, such as the RS-485 standard, introduce support for higher
bandwidth, up to 10 Mbps. Nonetheless, their support in embedded devices and sensors is limited.
Using serial interfaces to communicate with external sensors requires little-to-none OS-level support. As such,
serial communication represents a low-overhead, reliable channel for low/mid-bandwidth sensors. The main limitation
of this interface is that a dedicated controller is required for each individual device that needs to be interfaced. The
hard cap on how many devices can be attached to a data acquisition system using serial interfacing is imposed by the
number of UART/RS-232 controllers available in modern embedded platforms. Our survey highlighted that this number
is typically between 2 and 4.
2. SPI
A popular interface for communication with off-chip sensors is the Serial Peripheral Interface (SPI). SPI consists in a
master-slave interface where the master is in charge of selecting which slave is the receiver of the communication, and
the clock frequency for sending/receiving data. The typical SPI interface requires 5 wires (1 ground line, 2 data lines, 1
clock line, 1 slave select line). The data rate that can be achieved via SPI strictly depends on the clock frequency that
can be generated by the master controller. Nonetheless, our survey indicates that typical embedded controllers support
up to few Mbps of data throughput.
The structure of a SPI-based bus follows a centralized structure. Multiple slaves/devices can be connected at the
same time to the same master, as long as a dedicated slave-select line is available per each device in the master. If we
indicate with N the number of SPI controller in an typical embedded platforms and with S the number of slave-select
lines per controller, it follows that the number of devices that can be interfaced via SPI is N × S. Our survey indicates
that the typical values of N and S are 2-4 and 1-2, respectively.
6 of 31

Implementing support for an SPI interface is straightforward. It follows that, despite the inherent limitation in the
number of devices that can be supported, SPI represents a good trade-off between achievable data throughput and ease
of implementation.
3. I2 C
The Inter-Integrated Circuit (I2 C) communication interface is comparable in adoption with respect to SPI. The great
advantage of I2 C over SPI is in the number of wires required to establish communication, and in its capability to support
a large number of devices. Only 3 lines are required to establish communication between a master and a slave device (1
ground line, 1 data line, 1 clock line). Moreover, multiple devices can share the same three line.
Similarly to SPI, I2 C follows a master-slave approach for communication. But unlike SPI, a slave on the I2 C bus is
assigned a unique address. Any given slave can transmit data only after a read or write request with a matching address
has been generated by the master. Data from/to the slaves is transported over the same single data line, which needs to
be properly arbitrated for successful communication.
I2 C slaves have 7-bit addresses, meaning that, theoretically, up to 128 devices could be attached to the same I2 C bus.
In practice however this number is much smaller because it is common for I2 C devices from the same vendor to have
overlapping addresses, with only 1 or 2 configurable address bits. Additionally, it is often the case for I2 C buses having
more than 16 attached devices to exhibit electrical instability, making the data exchange error-prone.
Three main standards are followed by manufacturers in their I2 C interfaces. These are commonly referred to as
Standard-, Fast-, and High-speed I2 C. Standard-speed mode supports 100 Kbps, but it is largely considered obsolete.
Fast-speed mode is typically implemented in the vast majority of modern sensors and embedded controllers, providing
data rates up to 400 Kbps. Devices that can operate in High-speed mode can reach data rates of 1 Mbps.
Implementing support for I2 C communication is more difficult compared to SPI and UART, because bus arbitration
requires more complex logic.
4. USB
The Universal Serial Bus (USB) interface is the most widespread in general-purpose computing system for I/O and
device interfacing. Nonetheless, its adoption in data acquisition systems is limited. Interfacing a device via USB allows
reaching data rates up to 480 Mbps. Support for USB devices typically requires a full-fledged OS, as small footprint
embedded solutions often do not implement the complex set of drivers required to support the USB interface stack.
Additionally, few sensor devices provide USB as a native I/O interface. Those devices that do include USB interfacing
are generally high-bandwidth devices that would be unusable otherwise. Some examples are RGBD cameras and 3D
LIDARs.
While comparatively less commonplace to interface a data acquisition system with individual sensors, USB
represents a valid option for high-speed communication between multiple processing domains. For instance, in data
acquisition systems that follow split approach, USB represents a viable option for reliable synchronization and data
aggregation between the fast- and slow-timescale processing domains. In this case, the complexity of implementing a
full USB stack is largely hidden because a traditional OS (e.g. Linux) can be deployed on the slow-timescale side of the
system; while the fast-timescale side of the system only needs to implement a partial device-side USB stack.
5. Ethernet
An even smaller number of sensing devices provides a full-fledged network interface like Ethernet. Like USB, it
is possible to achieve large data transfer bandwidths if Ethernet interfacing is available and supported. The typical
bandwidth ranges between 100 Mbps and 1 Gbps (gigabit Ethernet). Technically only one device can be connected
to a given Ethernet port, but by adding switching elements it is possible to extend the number of devices that can be
simultaneously connected.
7 of 31

Due to its similarity with USB, few sensors are usually interfaced via Ethernet. It is also not common for Ethernet
to be used for communication across multiple processing domains of the same system. Nonetheless, Ethernet is largely
adopted to interface data acquisition systems with third-party autopilot systems.
C. Common Sensors
It is crucial to select the appropriate sensors needed for each application. Generally, most vehicular applications
will require some type of motion logging, involving an inertial and/or global positioning system. It is also important
to monitor the vehicle’s propulsion and energy generating or storage devices as well as other components. Often
component states are measured using sensors that provide a voltage output proportional to their state. On aircraft, air
data, including air density, velocity, and direction is rather important.
1. Inertial
Inertial sensors allow for motion of a vehicle to be measured. Inertial sensors arrive in the form of accelerometers
and gyroscopes: accelerometers are used to determine acceleration and gyroscopes are used to determine rotation rate.
These sensors are often combined together in all 3 axes, and in combination with a 3-axis magnetometer, to form
an inertial measurement unit (IMU). An IMU is the basis of an inertial navigation system (INS), which utilizes raw
measurements from the IMU sensors to calculate linear and angular position and velocity with respect to a global
reference frame. The raw data produced by the accelerometer and gyroscope is combined using filtering with attitude
reference data from the magnetometer and position reference data from the global positioning system (addressed in the
next section), to generate motion state solutions. There is extensive literature regarding how to best fuse inertial data to
provide the best solution for a given environment.
Inertial sensors can be integrated into a data acquisition system in several ways. First, the sensors can be directly
incorporated into the design - this can be very developmentally expensive as proper support for the sensor is needed,
including power and/or signal regulation and shielding. The next option is to integrate a ready-to-use development
(”dev”) board, which already includes all the sensor specific support, onto the data acquisition system; such development
board integrations are common in custom research systems, where size and weight constraints are relatively loose.
Finally, the last option is to place the sensor off of the data acquisition board and connect it. This option comes with
inherent advantages, where the sensors can be placed in an optimal spot, away from interference and error sources;
however, this can introduces communication challenges - connecting the sensor and the main system board. Some of
the systems presented in Section IV feature multiple IMUs, on- and off-board to get the best of both options.
2. Global Position
Global positioning is an integral part of modern inertial navigation systems and provide the basis for determining
aircraft position, in conjuction with inertial sensors. Global positioning systems (GPS) or global navigation satellite
system (GNSS) provide geolocation and time information by trilaterating location in 3-dimensions. Basic positioning
requires a minimum of 3 satellites while the addition of time, through receiver clock time offset calculations, requires a
minimum of 4 satellites; additional satellites can increase precision of a positioning system. It should be noted that
base systems are only passive receiving units. However, GPS and GNSS systems can be enhanced, for added precision,
using augmentation including the popular Wide Area Augmentation System (WAAS) or other differential GPS (DGPS).
Position systems can also be enhanced using other methods such as carrier phase tracking and real-time kinematic
(RTK) positioning.
3. Air Data
Air data sensors are crucial in aircraft research and flight control. These will include barometric pressure sensors,
temperature sensors, humidity sensors, and differential pressure sensors as well as wind vanes. The output from these
8 of 31

sensors highly vary from simple analog voltages to complex digital signals; sensors interfaces are described above in
Section III.B and analog-input sensors are discussed below in Section III.C.5.
Barometric pressure sensors can help augment the altitude estimation of an inertial navigation systems. Barometric
pressure sensors can also be used to determine the air density in conjunction with temperature sensor; humidity sensors
may also be added for better air density determination if operating in high humidity environments.
Differential pressure sensors are used to determine airspeed using pitot probes. These probes come in a variety
of flavors ranging from simple pitot tubes, static tubes, or pitot-static tubes, with different geometries, and number of
holes, commonly: 1, 5, or 7. 5 or 7 hole probes also provide the angle-of-attack and side-slip angle of the the probe.
Calibration is needed for pitot probes in order to accuracy and their data output is often integrated in to the inertial
navigation system filter in order to account for pressure altitude, climb rate, and Mach effects as well as tubing distance
lag. It is very important to great care of pitot probes as malfunctioned probes have shown to cause devastating results if
integrated with a flight control system.
Wind vanes are another option for measuring angle-of-attack and side-slip angle rather than using multi-hole probes.
The vanes can be mounted stand alone, however, are often integrated into an air data boom, with a pitot probe on the tip
and two vanes on the mast. Wind vanes can vary in construction and are most often mounted on ball bearing, with the
angle measured by a ’friction-less’ encoder or hall effect sensors.
4. Propulsion
Integrating a data acquisition system with the propulsion system of an aircraft can be challenging, however, can provide
a great deal of information. For example, in order to compute the aerodynamic forces and moments at play, one needs
to subtract the force and moment created by the thrust force(s) (as well as the gravitational force) from the total force
and moment measured by the inertial navigation system. This often requires knowing the rotation rate of the propulsion
unit(s), whether it be an internal combustion engine, electric motor, or turbine. The rotation rate of these propulsion
systems can be measured using optical, magnetic, or electrical sensors. In the case of an electric motor, the electronic
speed controller (ESC) can be interfaced in order to extract this rotation rate information, along with other parameters
such as voltage, current, and throttle percentage; these later parameters are vital for calculating motor electrical to
mechanical conversion efficiency or for monitoring the voltage of the energy source (battery, solar panel, etc.). For
a turbine, an interface can be developed that communicates with the engine control unit (ECU), also called the ’full
authority digital engine control’ (FADEC).
5. Analog or Digital
A great number of sensors and devices output a simple analog or digital signal that are designed for easy acquisition.
Analog measurement is performed using the analog-to-digital (ADC) converters, which will then interface with the
data acquisition system. Potentiometers as well as other types of linear or angular position sensors output a voltage
or current that is proportional to their measure inputs; these sensors will allow for aircraft component positions to be
measured such as control surface deflections. As discussed earlier, air data sensors will often output data using an
analog signal. Analog measurement is also important for determining aircraft system voltages or currents, which may
require amplification or indirect methods of measurement (e.g. a hall effect based current transducer sensor to measure
current rather than direct measurement). An additional example is a load or torque cell, which require analog amplified
measurement.The rate at which analog signals need to be acquired will highly depend on the specifications of the device
as well as the expected noise - sampling at a higher rate can allow for time averaging.
On the other hand, these sensors may also output simple digital signals such as a pulse-width modulation (PWM) or
pulse-position modulation (PPM) signal. Servo actuators, which are often used on UAVs to drive the control surfaces or
other mechanisms, use PWM signals as input; these signals directly correlate to an intended value, however, in some
cases, the amplitude of the spacing of the signal may be reversed. PWM signals are also integral parts of brushless
(stepper) motor and their measurement can therefore allow the system to determine position or rotation rate. Similarly,
optical or magnetic rotation rate sensors can output an amplified or non-amplified PWM signal, which would need to be
9 of 31

measured. Analog and digital signals measurement can occur within the main unit of the data acquisition system or
can be done so externally. Moving the signal acquisition off-board is often beneficial because losses may otherwise
occur during transmission, especially though long signal wires or within wires that pass in close proximity to wires with
high and/or alternating current. However, depending on the complexity of the integration and the types and number
of interfaces available on the data acquisition system main unit, moving signal acquisition off-board may be overly
difficult and/or time or cost prohibitive, and therefore impractical.
D. User Interface
As mentioned earlier, data acquisition systems often provide a command & control interface. The minimal set of
commands provided by this interface include: start/stop of logging and data forwarding on the various communication
interfaces; a set of commands to assess the sanity of the current hardware configuration; and a way to inspect and
download the stored flight logs.
The command & control user interface is typically bound to one of the external communication interfaces, such as
UART and Ethernet. In order to make interfacing more convenient, graphical user interfaces that internally use the
command-based interface are often provided for easier in-the-field operation. The drawback of this approach is that
only a few devices can be used for interfacing with a data acquisition system in the field. This is because defining the
same graphical interface while supporting multiple systems represents an extra development burden. A recent trend
is in the definition of graphical user interfaces that are web-based. In this case, the interface is provided by the data
acquisition system itself via a network interface (wired or wireless). But the burden of rendering the actual interface
is put on the client, which is typically a general purpose desktop/laptop machine. The additional advantage of this
approach is that little development effort is required to support mobile devices (e.g. smartphones and tablets).
For instance, Figure 2(a) depicts the dashboard of the command & control graphical user interface available on the
Al Volo FDAQ. The interface is entirely web-based and dynamically refreshed. When a mobile client is detected, the
same information is displayed in a mobile-frienly layout, as depicted in Figure 2(b).
(a) (b)
Figure 2. The Al Volo FDAQ data acquisition system user interface dashbaord on (a) PC and (b) iPhone.
10 of 31

IV. Existing Systems
Researchers have performed flight data acquisition on unmanned aircraft using a variety of data acquisition systems
and flight control systems. In order to choose or develop a data acquisition platform, it is important to survey existing
systems. Here we evaluate existing systems, which are differentiated into several overlapping categories: commercial
products, custom-solutions, flight control systems, and data acquisition systems. The writing and tables below provide
information on these system along with references to use cases by researchers. This is not a comprehensive study of
autopilots or data acquisition systems, however, it is done so to provide a general survey of what is available. It should
be noted that the information presented in the tables was extracted completely from the sources cited.
There are two types of commercially produced autopilot solutions available: closed-sources and open-source. Closed-
source commercial autopilots presented include the Collins Aerospace Cloud Cap Piccolo II,22 MicroPilot MP2128g,23
Lockheed Martin Kestrel Flight Systems Autopilot v2.4,24 Embention Veronte,25 and the Al Volo FC+DAQ.? The
specifications for these systems are given in Table 1.
Open-source commercially-produced autopilots examined include the Emlid NAVIO2/RPi3,26 Intel Aero Compute
Board,27 Paparazzi Lisa/M,28 3D Robotics APM 2.6,29 and Pixhawk Autopilot.30 All of these autopilots use the
open-source Ardupilot.29 The specifications for these systems are given in Table 2. It should be noted that open-source
commercially-produced autopilots presented mostly use the ArduPilo UAV Autopilot Software Suite29 as that has been
how the open-source environment has evolved to. There is extensive documentation, which has allowed researchers to
often adapted the software or completely change some or all of the software.
Next are the commercial data acquisition systems, which include the RCAT Systems Industrial UAV datalogger,31
Eagle Tree Systems Flight Data Recorder Pro,32 National Instruments CompactRIO,33 and Al Volo FDAQ.34 The Eagle
Tree Systems Flight Data Recorder Pro is a high-end hobby / prosumer data acquisition system while the RCAT Systems
Industrial UAV datalogger, NI CompactRIO, and the Al Volo FDAQ are industrial- / research-grade data acquisition
systems. It should be noted that there are not many commercial data acquisition systems available that are intended to
or could be used on small- to mid-sized unmanned aerial vehicles; as an example of this, due the NI CompactRIO’s size
and mass, it is not suitable for smaller aircraft. The specifications for these systems are given in Table 3.
Finally, a variety of custom-solution avionics systems are examined and organized by year developed. Tn 2006
Christophersen et al. at Georgia Institute of Technology developed the FCS-20 flight control system8, 35 in order to
serve as the backbone for their control development flight campaigns. NASA’s EAV36, 37 and AirSTAR12 programs
produced testbed platforms that included avionics systems which are able to perform data collection and control. Next
in 2011, Brusov et al. developed the PRP-J5 flight data acquisition system for small UAVs.38 Then in 2013, the Flight
Control Systems Laboratory at West Virginia University developed a Gen-V avionics system in order to support their
Phastball research into simplifying and reducing the cost of flight testing.39–41 Afterwards in 2013, researchers at the
University of Illinois developed the SDAC data acquisition for subscale aerodynamics flight testing;5, 42–44 this system
was the basis for development of the Al Volo FDAQ and FC+DAQ.34 Then in 2014, Stockton and Vuppala at Oklahoma
State University developed a flight control system and hardware in the loop testing environment to demonstrate new
control strategies.45–47 In 2017, Bingler and Mohseni at the University of Floriday a minature dual-radio autopilot
system for swarm research, based on their previous design at the University of Colorado - Boulder.48 Also in 2017,
researchers at the University of Minnesota developed their third generation flight control system to study body freedom
flutter and flutter suppression strategies;18, 49 this system was commercialized by Bolder Flight Systems.50 Finally
in 2018, McCrink and Gregory at the Ohio State University developed a custom inertial navigation system to enable
record setting beyond visual line-of-sight operations, as well as allow high-frequency logging of flight and RF system
data and demonstrate real-time adaptive control techniques.51 The specifications for these units are given in Table 4.
11 of 31

Table 1. Closed-source commercially-produced autopilot comparison
System: Cloud Cap Piccolo II22 MicroPilot MP2128g23 Kestrel Autopilot v2.424 Embention Veronte25 Al Volo FC+DAQ34
Internal Sensing
Inertial Proprietary Proprietary Proprietary Proprietary Proprietary
Accelerometer 10 g 5g 10 g 16 g 16 g
Gyroscope 300 deg/s Yes 300 deg/s 300 deg/s 2000 deg/s
Magnetometers Add-on Add-on Yes 6G 6G
Global positioning u-blox GPS u-blox GPS Proprietary GPS Proprietary GNSS u-blox GNSS
Rate 4 Hz 4 Hz 4 Hz 4 Hz 10-18 Hz
Differential Available Available - Available Available
Altimeter (barometric) 1 ft resolution 1 ft resolution 0.8 ft resolution 0.3 ft resolution
Analog voltage 4x 10 bit 32x 24 bit at 5 Hz 3x 12 bit 5 32x 12 bit
Servo position (PWM) 8-13 - 4-8 up to 16 up to 22
External Sensing
Ext. IMU/INS/AHRS - - - - XSens , MicroStrain 3DM, or
VectorNav
Airspeed up to 180 mph up to 300 mph up to 130 mph up to 240 mph up to 130 mph
Propulsion optical or magnetic RPM and - RPM and fuel flow Castle ESC (voltage, current,
12 of 31
fuel flow RPM, %) and optical RPM
Interfacing
Digital I/O 16 8 12 up to 16 up to 22
Peripheral interfaces CANbus - 4 Ports: UART, SPI, and/or CANbus, RS232, RS485 UART, I2C, and USB
I2C UART, I2C, and USB
Data Handling

Processing MPC555 40 MHz Embedded unknown 29 MHz CPU w/ 512K RAM unknown 2 or 4 core, 500 MHz to
Power PC w /26K RAM 1 GHz CPU w/1-4GB RAM
Sampling rate 20 Hz 5–30 Hz 100 Hz 200 Hz 100-400 Hz
Storage 448 KB 1.5 MB 512 KB unknown 8 GB+
RF link 25 mi 3 mi 15 mi 20-75 mi 30 mi
Physical
Size 142.0 x 46.0 x 62.6 mm 100.0 x 40.0 x 15 mm 57.7 x 35.6 x 12.7 mm 63 x 39.6 x 67.9 mm 110.0 x 58.0 x 25.4 mm
Weight 220 gr 24 gr 21 gr 190 gr 100 gr
Power 4W 1.3 W 5W 1W
Estimated cost $15,000+ $6,000+ $2,500+ $6,000+ $9,500+
Use cases UIUC,52 NPS/UCSC,53 U. NASA,57 MITRE Corp58 U. Toronto59 UIUC60–62
KS,19, 54 U. ND55 NASA56
Table 2. Open-source commercially-produced autopilot comparison
System: Emlid NAVIO2/RPi326 Intel Aero Compute27 Paparazzi Lisa/M28 3D Robotics APM29 Pixhawk Autopilot30
Internal Sensing
Inertial MPU9250 and LSM9DS1 BMI160 and BMI150 MPU-6000 and HMC5883 MPU-6000 MPU 6000, L3GD20, and
LSM303D
Accelerometer 2-16 g 2-16 g 2-16 g 2-16 g 2-16 g
Gyroscope 250-2000 deg/s 125-2000 deg/s 250-2000 deg/s 250-2000 deg/s 250-2000 deg/s
Magnetometers 4-48 G 13/25 G 8G 8G 2-12 G
Global positioning u-blox M8N GNSS - - uBlox LEA-6 u-blox GPS
Rate 5 Hz (GPS) or 10 Hz (GNSS) - 5 Hz 5 Hz
Differential - - - - -
Altimeter (barometric) 0.3 ft resolution - 0.8 ft resolution 1.0 ft resolution 0.3 ft resolution
Analog voltage 4 5x 12 bit 7 up to 12 2
Servo position (PWM) 8 12 - 8 0
External Sensing
Ext. IMU/INS/AHRS - - - - -
Airspeed - - - - -
Propulsion - - - - -
13 of 31
Interfacing
Digital I/O 2 25 3 up to 12 -
Peripheral interfaces UART, I2C, USB, and Ether- UART, I2C, SPI, and USB CANbus, UART, I2C, SPI, I2C and UART CANbus, UART, I2C, SPI,
net and USB and USB
Data Handling

Processing 4-core 1.2 GHz Broadcom 4-core 2.55 GHz Intel Atom STM32F105RCT6 (Cortex 16 MHz Atmega2560 and 168 MHz Cortex M4 w/256K
BCM2837 x7-Z8750 M3) 72 Mhz w/ 64K RAM 16 MHz Atmega32U-2 RAM
Sampling rate 100 Hz 200 Hz 50 Hz 50 Hz 200 Hz
Storage 4-32 GB microSD 32 GB + microSD 512 KB 16 MB 2 MB + 8 GB microSD
RF link - - - - -
Physical
Size 96.0 x 70.0 x 25.0 mm 88mm x 63mm x 20mm 60.0 x 33.7 x 10.0 mm 70.5 x 45 x 13.5mm 81.5 x 50.0 x 15.5 mm
Weight 76 gr 60 gr 10 gr 31 gr 38 gr
Power 4W 1.3 W 1 W (est.) 0.5 W 1.1 W
Estimated cost $200+ $399 $199 $160-340 $199
Use cases NCSU,63 U. MO-KC/NPS,64 Stanford,66 U. KS,67 Delft,68 Techn. Univ. Sofia,70 Cal OSU,73 Embry-Riddle,74 U.
UIUC65 U. Toulouse69 Poly,71 OKSU72 TX-Arl,75 Linkoping76, 77
Table 3. Closed-source commercially-produced data acquisition systems comparison
System: RCAT Systems Industrial Eagle Tree Systems Flight National Instruments Com- Al Volo FDAQ34
UAV31 Data Recorder Pro32 pactRIO33
Internal Sensing
Inertial Proprietary Proprietary - Proprietary
Accelerometer 1-axis 16 g - - 16 g
Gyroscope - - - 2000 deg/s
Magnetometers - - - 6G
Global positioning Proprietary Proprietary Add-on u-blox GNSS
Rate 1 Hz 10 Hz - 10-18 Hz
Differential - - - Available
Altimeter (barometric) 8 ft resolution 1 ft resolution Add-on 0.3 ft resolution
Analog voltage 2 2 4, 8, 16, or 32 32x 12 bit
Servo position (PWM) 4 - up to 22
External Sensing
Ext. IMU/INS/AHRS - 2-axis 38 g Add-on XSens, MicroStrain, or Vec-
torNav
Airspeed up to 290 mph up to 350 mph - up to 130 mph
Propulsion RPM, voltage, current, and RPM (optical, magnetic, or Add-on Castle ESC (voltage, current,
14 of 31
thermocouple ESC), voltage, current, ther- RPM, %) and optical RPM
mocouple, and EGT
Interfacing
Digital I/O - - 4, 8, or 32 up to 22
Peripheral interfaces - - RS232, Ethernet, and USB UART, I2C, USB, and Ether-
net

Data Handling
Processing 20 MHz microcontroller unknown Intel or ARM 400 MHz to 2 core, 500 MHz CPU
1.33 GHz
Sampling rate 20 Hz 40 Hz 100-400 kHz 100-400 Hz
Storage 512 MB SD 10 KB on-board 2x 4 GB SD 8 GB+
RF link 10 mi+ 14 mi Add-on 30 mi
Physical
Size 101.6 x 95.3 x 44.5 mm 50.0 x 35.0 x 17.0 mm 179.6 x 88.1 x 88.1 mm+ 110.0 x 58.0 x 25.4 mm
Weight unknown 28 gr 1580g 100 gr
Power 4W 1W 6-25 W+ 1W
Estimated cost $2,495 $299-1,500 $2,000-8,000 base plus sensor $4,950+
modules
Use cases U. FL78 NASA79, 80 U. FL2, 81 UIUC13, 82 NRL83 UIUC84, 85
Table 4. Custom avionics system solution comparison
System: Georgia Tech FCS208, 35 NASA EAV-2/336, 37 NASA AirSTAR12 Brusov et al. PRP-J538 WVU RED ”Phastball”
Data Logger39–41
Year Developed 2006 2007 2008 2011 2013
Internal Sensing
Inertial Analog Devices ADXL210E Rockwell Collins Athena Microbotics MIDGII and ST LIS344ALH and (3) ADIS16405 and (1)
and ADXR300 GS111m INS/GPS Unit Memsense MAG LPY530AL ADIS16355
Accelerometer 10 g 8g 10 g 2-6 g 10 g
Gyroscope 300 deg/s 200 deg/s 600 deg/s 300 deg/s 150 deg/s
Magnetometers - yes yes - 2.5 G
Global positioning ublox TIM-LF GPS RC Athena GS111m Microbotics MIDGII - Novatel OEM-V1 GPS
Rate 4 Hz yes 5 Hz - 20 Hz
Differential - (ready) - - -
Altimeter (barometric) yes yes yes yes yes
Analog voltage 10x 16 bit 16x 12 bit 48x 16 bit 24x 12 bit 8
Servo position (PWM) - 10 - 3 4
External Sensing
Ext. IMU/INS/AHRS - - - - -
15 of 31
Airspeed yes yes, 5-hole yes, alpha-beta yes yes
Propulsion - - Turbine throttle and RPM, - -
fuel flow
Interfacing
Digital I/O 12 - 2 - -

Peripheral interfaces 4x RS232 2x CAN, 8x RS232 3x Serial UART and SPI -
Data Handling
Processing TI TMS320C6713 DPS and Diamond Athena 660MHz PC104 Silicon Labs C8051F206 (2) Netburner MOD5213
Altera EP1S40 Stratix FPGA with 128MB RAM and Mo-
torola DSP56807
Sampling rate 100 Hz 100 Hz 200 Hz (50 Hz IMU), 100 Hz 50 Hz
Storage 64 MB on-board 2x 8 GB CF 512 KB on-board 512 MB SD microSD
RF link - yes yes - yes
Physical
Size 85.0 x 55.0 x 20.0 mm 239.8 x 160.0 x 121.4 mm unknown 57.0 x 37.0 x 9.0 mm 71.1 x 45.7 x 25.4 mm
Weight 40 gr 2551 gr unknown 17 gr 226 gr
Power 1-3 W 26 W unknown 0.25 W unknown
Table 4 (continued). Custom avionics system solution comparison
System: UIUC SDAC5, 42–44 OK State Stabilis45–47 UFL AMP48 UMN Goldy III18, 49 / OSU Avanti INS/FMC51
Bolder Flight Systems50
Year Developed 2013 2014 2017 2017 2018
Internal Sensing
Inertial XSens MTi-G VectorNav VN-200 GPS/INS MPU-9250 MPU-9250 (3) IMUs
Accelerometer 18 g 16 g 2-16 g 2-16 g unknown
Gyroscope 300 deg/s 2000 deg/s 250-2000 deg/s 250-2000 deg/s unknown
Magnetometers 750 mG 2.5 G 4-48 G 4-48 G unknown
Global positioning XSens MTi-G VectorNav VN-200 GPS/INS Linx TM GNSS - ublox RTK GPS
Rate 4 Hz 5 Hz 10 Hz - 4 Hz
Differential - - - - Yes
Altimeter (barometric) 1.0 ft resolution 1.0 ft resolution 0.5 ft resolution yes unknown
Analog voltage ”7x 10 bit, 16x 12 bit, 1x 6x 10 bit yes, unknown 2x 10 bit 8-24x 13 bit unknown
14 bit”
Servo position (PWM) 8 8 - 16 via SBUS (not PWM) 8 (est.)
External Sensing
Ext. IMU/INS/AHRS - - - VectorNav VN-200 GPS/INS -
Airspeed external external - yes yes, 5-hole probe
16 of 31
Propulsion RPM, Voltage, Current - - - ECU
Interfacing
Digital I/O up to 20 unknown yes, unknown 2-14 unknown
Peripheral interfaces CAN, UART, I2C, SPI, USB, CAN, RS232, RS248, UART, I2C and SPI CAN, RS232, RS248, UART, unknown
and Ethernet I2C, SPI, USB, and Ethernet I2C, SPI, USB, and Ethern

Data Handling
Processing BeagleBone TI AM3358 BeagleBoneBlack 140 MHz dsPIC33EP BeagleBoneBlack Parallax Propeller and ARM
720 MHz Cortex-A8 TI AM3359 1 GHz Cortex-A8 TI AM3359 1 GHz Cortex- CPU
A8 and (1-3) Teensy 3.6
Cortex M4
Sampling rate 100 Hz 10 Hz 100 Hz 50 Hz 256 Hz
Storage 8 GB+ microSD 2 GB on-board + microSD 512 MB on-board 2 GB on-board unknown
RF link 25 mi external 300 ft and 1 mi yes yes, 25 mi+ (900MHz) and
SATCOM
Physical
Size 90.5 x 54.3 x 26.8 mm 124.0 x 76.2 x 45.0 mm 32.5 x 30.0 mm (main board) 96.0 x 70.0 x 25.0 mm unknown
14 x 11 mm (sensor board)
Weight 80 gr 80 gr 6.25 gr 76 gr unknown
Power 0.45 W 2.0 W unknown 4W unknown
V. Integration Cases
In order to better illustrate the development, integration, and operation of a data acquisition system in an unmanned
aerial vehicle, we look at several integration cases that the authors performed in previous works. Two data acquisition
systems, the UIUC SDAQ42, 43 and Al Volo FDAQ,34 and one flight control and data acquisition system, the Al Volo
FC+DAQ,34 which can be seen below in Fig. 3, will be used as example. The aircraft used for demonstration will
include the UIUC Subscale Sukhoi ,5 the UIUC GA-USTAR ,85 and the UIUC Solar Flyer ,60, 86 all of which are
distinctly different types of aircraft and have different types of integration and operation challenges. Photos of the
aircraft are shown below.
(a) (b)
Figure 3. Data acquisition and flight control systems used as examples: (a) UIUC SDAC and (b) Al Volo FDAQ and FC+DAQ (photo taken
from Al Volo34 ).
(a) (b)
(c)
Figure 4. Aircraft used as examples: (a) UIUC Subscale Sukhoi, (b) UIUC GA-USTAR, and (c) UIUC Solar Flyer (baseline aircraft shown
without solar panels).
17 of 31

A. UIUC Subscale Sukhoi
The UIUC Subscale Sukhoi was developed to perform aerodynamics research in the full-envelope flight regime,
specifically to capture unsteady aerodynamic effects exhibited during high angle-of-attack flight. The unmanned aircraft
was built from a 35% scale, 2.6 m (102 in) wingspan Sebart Sukhoi 29S electric radio control (RC) model, which
provided a light yet robust structure that along with large control surfaces, that allowed the aircraft to perform aggressive
aerobatic maneuvers. The aircraft used an electric propulsion system in place of an internal combustion gasoline engine
to provide near constant performance, increased reliability, and low vibrations; a diagram of the propulsion system
is given in Fig. 5. The completed flight-ready aircraft physical specifications are given in Table 5, and its airframe
component specifications are given in Table 12.
Parallel to 14S 10Ah

Series to 14S 5Ah Series to 14S 5Ah

7S 5Ah LiPo Battery
7S 5Ah LiPo Battery
7S 5Ah LiPo Battery
7S 5Ah LiPo Battery
REMOVE BEFORE FLIGHT
Emcotec
Safety Power Switch Hacker
A150-8 Motor
Hacker
MasterSPIN 220 ESC
MasterSPIN 220
EMCOTEC
SPS
Hacker
To ELECT Port To PDU To RPM Port
Figure 5. A propulsion system diagram for the UIUC Subscale Sukhoi unmanned aircraft
Table 5. UIUC Subscale Sukhoi unmanned aircraft physical specifications
Geometric Properties
Overall Length 100.0 in (2540 mm)
Wingspan 102.4 in (2600 mm)
Wing Area 2015 in2 (130.0 dm2 )
Wing Aspect Ratio 5.20
Inertial Properties
Weight
Empty (w/o Batteries) 27.16 lb (12.33 kg)
14S 2P 10Ahr LiPo Main Battery 8.13 lb (3.69 kg)
RC and Avionics Batteries 0.77 lb (0.35 kg)
Gross Weight 36.00 lb (16.37 kg)
Wing Loading 41.2 oz/ft2 (126 gr/dm2 )
18 of 31

Table 6. UIUC Subscale Sukhoi unmanned aircraft airframe component specifications
Construction Built-up balsa and plywood structure, foam turtle decks, carbon fiber wing and stab tube,
aluminum landing gear, fiberglass cowl, fiberglass wheel pants, and styrene and fiberglass
canopy.
Flight Controls
Control Surfaces Ailerons (2), elevator (2), rudder, and throttle
Transmitter Futaba T14MZ
Receiver Futaba R6014HS
Servos (8) Futaba BLS152
Power Distribution SmartFly PowerSystem Competition 12 Turbo
Receiver Battery Thunder ProLite RX 25c 2S 7.4V 2700 mAh
Propulsion
Motor Hacker A150-8 Outrunner
ESC Hacker MasterSPIN 220

Propeller Mejzlik 27x12TH
Motor Flight Pack (4) Thunder Power ProPerformance 45c 7S 5000 mAh in 2S2P config.
Motor Power Switch Emcotec SPS 120/240
Based on previous experience gained in developing and operating the UIUC AeroTestbed, which was used for spin
and upset testing,13, 82 the data acquisition system for the UIUC Subscale Sukhoi had to be able to simultaneously log:
accelerations, velocities, position, angular rotation, Euler angles, pitot probe airspeed, propulsion system parameters,
and control surface deflections. The new data acquisition system also had to be able to do so at 100 Hz as the system
used on the UIUC AeroTestbed, which operated at 25 Hz, did not provide a sufficient acquisition rate to measure
the effects of high control surface deflection maneuvers, especially during dynamic changes such as initial upset and
non-constant spinning behavior. An additional requirement was that the IMU used on the UIUC Subscale Sukhoi be
isolated in some way from the propulsion system as the magnetic field created by the UIUC AeroTestbed’s propulsion
system overwhelmed its IMUs magnetomer, and therefore severely interfered with its estimation of attitude.
The aircraft was instrumented with an updated version of the custom-made UIUC Sensor Data Acquisition System
(SDAC),42, 43, 87 which had recently been developed and made use of only commercial-off-the-shelf (COTS) components.
Two photo of the installation can be seen in Figs. 6 and 7; note that the IMU is separated from the battery area by a
thin steel plate to decrease the effects of propulsion system generated magnetic fields. A system diagram depicting the
specific configuration of the instrumentation, along with the flight control and propulsion systems, is shown in Fig. 8.
The specifications of the components used in the updated, tested sensor data acquisition system are given in Table 7. A
description of the software architecture used in the implementation is given in Mancuso et al.42
19 of 31

Figure 6. A photo of the fuselage of the UIUC Subscale Sukhoi showing (from front to back): the motor and controller, battery compart-
ment, the avionics (XSens MTi-G IMU center and UIUC SDAC on the right), the flight control system (power distribution unit, RC receiver,
and rudder pull-pull servo tray and servos), and GPS antenna.
20 of 31

Figure 7. The center of the fuselage of the UIUC Subscale Sukhoi with the UIUC SDAC (top right) and XSens MTi-G IMU (center) visible;
note the thin steel plate separating the IMU from the battery compartment in front.
Table 7. Updated UIUC SDAC system component specifications
Processing unit BeagleBone running 32-bit Ubuntu Linux

Sensors
IMU XSens Mti-g 6-DOF IMU with Wi-Sys WS3910 GPS Antenna
Airspeed probe EagleTree Systems pitot-static probe
Airspeed sensor All Sensors 20cmH2O-D1-4V-MINI differential pressure sensor
Analog-to-digital converters 4x Gravitech 12 bit - 8 Channel ADC
Potentiometers BI Technologies 6127
Tachometer Sparkfun ProMicro
Magnetometer PNI Corp MicroMag3
Power
Regulators Castle Creations CCBEC
Batteries 30cmThunder Power ProLite 3S 1350 mAh (avionics, telemetry and/or video)
Telemetry transceiver Digi 9X Tend 900-MHz card
Data Storage 8GB microSD card
21 of 31

GPS Pots
Pitot IMU
2.4 GHz RX 3D-Mag 3x ADC
Regulator
R/C Receiver LiPo
AVI
Regulator
LiPo
SDAC
Motor
LiPo Pulse
Tachometer
900 MHz
microSD Telemetry Radio
ESC
Regulator
22 of 31
Servos Motor
Radio
ADC
LiPo

Key
Signal (line color): Power (shading color):
█ Flight controls █ Flight controls
Video
LiPo █ Sensor data █ Motor
Camera █ State data █ Avionics
█ Transmission █ Telemetry
5.8 GHz █ Power █ Video
Regulator
Video TX
Wiring (line type) :
— Signal and power
---- Signal only …... Power only
Figure 8. A block diagram of the UIUC SDAC as installed in the UIUC Subscale Sukhoi
B. UIUC GA-USTAR
The UIUC General Aviation Upset and Stall Testing Aircraft Research (GA-USTAR) project aims to ultimately reduce
the number of general aviation (GA) incidents resulting from stall and upset by creating higher fidelity modelling tools
to improve simulators and pilot training.84, 85 The GA-USTAR project therefore focuses on the development and flight
testing of a sub-scale GA aircraft for stall/upset aerodynamic modeling. To design and build a correct model, research
was conducted to determine the requirements, including dynamically scaling the aircraft, not only in terms of mass but
also in terms of moments of inertia, Additional effort was put into researching a methodology to modify the aircraft
flight surfaces to properly take into account Reynolds number effects.88
The aircraft developed to date was the first baseline aircraft, in series of three aircraft phases, which will ultimately
take into account dynamic scaling and then Reynolds number corrections. The Phase 1 GA-USTAR aircraft was built,
with the help of a team of undergraduate students, from a Top Flite 1/5-scale Cessna 182 RC model airplane, which had
been slightly modified to increase aircraft safety, reliability, and ease of flight testing.89 The completed flight-ready
aircraft physical specifications are given in Table 8, and its airframe component specifications are given in Table 9.
Part of the design methodology employed in the aircraft development required the latest state-of-the-art sensors to
be incorporated into the aircraft, which increased the integration challenge. Primarily, this included using a current-
generation 400 Hz INS as well as interfacing with the ESC such that high-fidelity motor parameters could be acquired.
The UIUC SDAC, which although provided excellent data for the high angle-of-attack flight testing research using
the UIUC Subscale Sukhoi, was unable to meet these requirements. A full list of data acquisition requirements can be
found in Ananda, et al.84 An Al Volo FDAQ was used in the GA-USTAR project as it met the requirements. Component
details of the aircraft can be seen in Fig. 10. The component specifications of the GA-USTAR aircraft instrumentation
are given in Table 10.
Table 8. Baseline GA-USTAR unmanned aircraft physical specifications.
Overall Length 64.0 in (1630 mm)
Wingspan 81.0 in (2060 mm)
Wing Area 898 in2 (57.9 dm2 )
Wing Aspect Ratio 7.47
Inertial Properties
Weight
Empty (w/o Batteries) 12.08 lb (5.48 kg)
8S 6.6 Ahr LiPo Main Battery 2.74 lb (1.25 kg)
RC and Avionics Batteries 0.49 lb (0.22 kg)
Gross Weight 15.31 lb (6.94 kg)
Wing Loading 39.3 oz/ft2 (120 gr/dm2 )
23 of 31

Table 9. Baseline GA-USTAR unmanned aircraft airframe component specifications.
Airframe
Model Top Flite 1/5-scale Cessna 182
Construction Built-up balsa and plywood structure, aluminum landing gear, fiberglass cowl, fiberglass wheel
pants, and styrene canopy.
Flight Controls
Control Surfaces (2) Ailerons, (2) elevator, rudder, (2) flap, and throttle
Receiver Futaba R6008HS

Servos (7) Futaba S3010
Power Distribution SmartFly PowerSystem Sport Plus
Receiver Battery (2) Thunder Power ProLite RX 25c 2S 7.4V 1350 mAh
Propulsion
Motor Hacker A50-14L Outrunner
ESC Castle Creations
Propeller APC Thin Electric 16x8
Motor Flight Pack (4) Thunder Power ProLite 25c 8S 6600 mAh
Motor Power Switch Emcotec SPS 60/120
Table 10. Component specifications of the GA-USTAR aircraft instrumentation.
Data acquisition system Al Volo FDAQ 400 Hz system

Sensors
Inertial measurement unit XSens MTi-G-700 AHRS with GPS
Airspeed sensor Al Volo pitot-static airspeed sensor
Motor Sensors Al Volo Castle ESC sensor
Power
Regulator Built into FDAQ
Battery Thunder Power ProLite 3S 1350 mAh
24 of 31

(a)
(b) (c)
Figure 9. Construction details in baseline GA-USTAR aircraft: (a) custom front tray holding the two elevator servos, rudder servo, Smart-
Fly power distribution system, and the receiver, (b) nose with the motor, ESC, and safety power switch visible, and (c) Al Volo FDAQ flight
data acquisition system and the XSens MTi-G-700 IMU mounted in the aircraft rear.
25 of 31

C. UIUC Solar Flyer
The UIUC Solar Flyer60, 86 is currently in development with the ultimate aim of sustaining continuous flight for extended
periods of time while performing on-board, real-time computation and to shift the paradigm of solar powered flight.
The traditional approach for small size UAVs, is to capture data on the aircraft, stream it to the ground through a high
power data-link, process it remotely (potentially off-line), perform analysis, and then relay commands back to the
aircraft as needed. However, given the finite energy resources found onboard an aircraft (e.g. batteries and solar arrays),
the traditional design greatly limits aircraft endurance, since significant power is consumed for transmission of visual
data instead of being allocated to keeping the aircraft flying. The UIUC Solar Flyer is being developed to carry a high
performance embedded computer system to minimize the need for data transmission. The process of reducing aircraft
power consumption allows for decreasing aircraft size, prolonging flight time, and ultimately minimizing cost, therefore
supporting the widespread adoption of UAVs for various types of missions.
The UIUC Solar Flyer was designed using a mixture of trade studies and power simulations in order to enable
a variety of missions to be performed while minimizing aircraft size. The aircraft is being built from a majority of
commercial-off-the-shelf components in order to minimize both development time and cost. The completed 4.0 m
(157 in) wingspan UIUC Solar Flyer aircraft is based on the F5 Models Pulsar 4.0 Pro, and once completed, should
weight approximately 2.5 kg (88 oz). The aircraft will be powered by a 65 W gallium arsenide (GaAs) solar array
from Alta Devices.90 The aircraft configuration, sizing, and propulsion system were all chosen based on analysis of
estimated solar power production and aircraft, instrumentation, and avionics power consumption, and therefore, efficient
integration of avionics is critical. Flight testing is currently being done to increase aircraft efficiency, which requires
high-fidelity data acquisition. The physical specifications for the instrumented, non-solar aircraft are given in Table 11.
The specifications of the components used in the construction of the airframe is provided in Table 12.
Table 11. Instrumented (non-solar) UIUC Solar Flyer aircraft physical specifications.
Overall Length 1815 mm (71.5 in)
Wing Span 4000 mm (157.5 in)
Wing Area 85 dm2 (1318 in2 )
Aspect Ratio 18.8
Inertial Properties
Gross Weight 1.966 kg (4.33 lb)
Empty Weight 1.739 kg (3.83 lb)
Wing Loading 23.1 gr/dm2 (7.57 oz/ft2 )
Table 12. Instrumented (non-solar) UIUC Solar Flyer aircraft airframe component specifications.
Airframe
Model F5 Models Pulsar 4.0E
Construction Fully-composite kevlar and carbon fiber fuselange and built-up
balsa wood with carbon fiber and a kevlar-carbon fiber laminate
reinforced flight surfaces.
Flight Controls
Control Surfaces (2) Ailerons, (2) elevator, rudder, (2) flap, and throttle
Receiver Futaba R6208SB
Servos (6) S3173SVi
Power Castle ESC - BEC
Propulsion
Motor Model Motors AXi Cyclone 46/760
ESC Castle Creations Phoenix Edge Lite 50
Propeller Aeronaut CAM Folding 13x6.5
Motor Flight Pack Thunder Power ProLiteX 3S 2800 mAh
26 of 31

A custom version of the Al Volo FC+DAQ flight control and data acquisition system was fabricated to meet the
needs of the UIUC Solar Flyer. Part of the integration challenge is fitting the system within the aircraft geometry, which
given the streamlined and narrow design, was very difficult. The components of the FC+DAQ have been stripped of
their protective enclosures to save weight and are being split between location in the fuselage and the wings. Figs. 10(a)
and 10(b) show the locations of the various control system elements. A top-view photo of the fuselage pod is shown in
Fig. 11 and a photo of the entire center wing panel showing instrumentation components and servo actuators can be
found in Fig. 12. The specifications of the instrumentation on the UIUC Solar Flyer are given in Table 13.
(a)
(b)
Figure 10. Current layout of the Al Volo FC+DAQ within the UIUC Solar Flyer: (a) fuselage and (b) wing.
Table 13. Instrumentation specifications.

Autopilot-DAQ system Al Volo FC+DAQ 100 Hz flight control and data acquisition system
RF Module Digi International 900 MHz XBee Pro S3B Module
Multiplexer 8-channel custom PWM multiplexer with redundant input
Sensors
Inertial 100 Hz AHRS integrated into FC+DAQ
Positioning 10 Hz GNSS integrated into FC+DAQ
Airspeed sensor Al Volo Pitot Static Airspeed Sensor
Motor sensor Al Volo Castle ESC Interface
Power
Regulator Built into FC+DAQ
Battery Thunder Power ProLiteX 2S 500 mAh
27 of 31

Figure 11. A photo of the top of the UIUC Solar Flyer fuselage pod showing propulsion system elements in the front of the pod and the
instrumentation in the rear of the pod; note that the wires connect to the sensors and flight control actuation system located in the wing.
Figure 12. The center wing panel of the instrumented UIUC Solar Flyer airframe showing the instrumentation components and servo
actuators.
VI. Summary
This paper focused on the development, integration, and operation of avionics platforms used to perform in-flight
measurements, with specific emphasis for use on small- to medium-sized unmanned aircraft. First, the paper provided
an overview of the development process followed by a discussion of design aspects involved in the process. Then, the
paper presented a study of data acquisition and flight control systems that have been used in UAV research. Finally,three
avionics integration examples were given that demonstrated application in an unmanned aircraft.
28 of 31

References
1 Lykins, R. and Keshmiri, S., “Modal Analysis of 1/3-Scale Yak-54 Aircraft Through Simulation and Flight Testing,” AIAA Paper 2011-6443,
AIAA Atmospheric Flight Mechanics Conference, Portland, Oregon, Aug. 2011.

2 Johnson, B. and Lind, R., “Characterizing Wing Rock with Variations in Size and Configuration of Vertical Tail,” Journal of Aircraft, Vol. 47,
No. 2, 2010, pp. 567–576.

3 Perry, J., Mohamed, A., Johnson, B., and Lind, R., “Estimating Angle of Attack and Sideslip Under High Dynamics on Small UAVs,”
Proceedings of the ION-GNSS Conference, Savannah, Georgia, 2008.

4 Uhlig, D., Sareen, A., Sukumar, P., Rao, A. H., and Selig, M. S., “Determining Aerodynamic Characteristics of a Micro Air Vehicle Using
Motion Tracking,” AIAA Paper 2010-8416, AIAA Guidance, Navigation, and Control Conference, Toronto, Ontario, Canada, Aug. 2010.
5 Dantsker, O. D. and Selig, M. S., “High Angle of Attack Flight of a Subscale Aerobatic Aircraft,” AIAA Paper 2015-2568, AIAA Applied
Aerodynamics Conference, Dallas, Texas, Jun. 2015.

6 Mockli, M., Guidance and Control for Aerobatic Maneuvers of an Unmanned Airplane, Ph.D. thesis, ETH Zurich, Department of Mechanical
and Process Engineering, 2006.

7 Frank, A., McGrewy, J. S., Valentiz, M., Levinex, D., and How, J. P., “Hover, Transition, and Level Flight Control Design for a Single-Propeller
Indoor Airplane,” AIAA Paper 2007-6318, AIAA Guidance, Navigation, and Control Conference, Hilton Head, South Carolina, Aug. 2007.
8 Johnson, E. N., Wu, A. D., Neidhoefer, J. C., Kannan, S. K., and Turbe, M. A., “Test Results of Autonomous Airplane Transitions Between
Steady-Level and Hovering Flight,” Journal of Guidance, Control, and Dynamics, Vol. 31, No. 2, 2008, pp. 358–370.
9 Gaum, D. R., Aggressive Flight Control Techniques for a Fixed-Wing Unmanned Aerial Vehicle, Master’s thesis, Stellenbosch University,
Department of Electrical and Electronic Engineering, 2009.

10 Bilodeau, P. R., Poulin, E., Gagnon, E., Wong, F., and Desbiens, A., “Control of a Hovering Mini Fixed Wing Aerial Vehicle,” AIAA Paper
2009-5794, AIAA Guidance, Navigation and Control Conference, Chicago, Illinois, Aug. 2009.
11 Johnson, B. and Lind, R., “Trajectory Planning for Sensing Effectiveness with High Angle-of-Attack Flight Capability,” AIAA Paper
2012-0276, AIAA Aerospace Sciences Meeting, Nashville, Tennessee, Jan. 2012.

12 Jordan, T. L. and Bailey, R. M., “NASA Langley’s AirSTAR Testbed: A Subscale Flight Test Capability for Flight Dynamics and Control
System Experiments,” AIAA Paper 2008-6660, AIAA Atmospheric Flight Mechanics Conference, Honolulu, HI, Aug. 2008.
13 Ragheb, A. M., Dantsker, O. D., and Selig, M. S., “Stall/Spin Flight Testing with a Subscale Aerobatic Aircraft,” AIAA Paper 2013-2806,
AIAA Applied Aerodynamics Conference, San Diego, CA, June 2013.

14 Bunge, R. A., Savino, F. M., and Kroo, I. M., “Approaches to Automatic Stall/Spin Detection Based on Small-Scale UAV Flight Testing,”
AIAA Paper 2015-2235, AIAA Atmospheric Flight Mechanics Conference, Dallas, Texas, Jun. 2015.
15 Risch, T., Cosentino, G., Regan, C., Kisska, M., and Princen, N., “X-48B Flight-Test Progress Overview,” AIAA Paper 2009-934, AIAA
Aerospace Sciences Meeting, Orlando, FL, Jan. 2009.

16 Lundstrom, D. and Amadori, K., “Raven: A Subscale Radio Controlled Business Jet Demonstrator,” International Congress on the Aeronautical
Sciences Systems (ICUAS), Anchorage, Alaska, Sep. 2008.

17 Regan, C. D. and Taylor, B. R., “mAEWing1: Design, Build, Test - Invited,” AIAA Paper 2016-1747, AIAA Atmospheric Flight Mechanics
Conference, San Diego, California, Jun. 2016.

18 Regan, C. D., “mAEWing2: Conceptual Design and System Test,” AIAA Paper 2017-1391, AIAA Atmospheric Flight Mechanics Conference,
Grapevine, Texas, Jun. 2017.

19 Leong, H. I., Keshmiri, S., and Jager, R., “Evaluation of a COTS Autopilot and Avionics System for UAVs,” AIAA Paper 2009-1963, AIAA
Infotech@Aerospace, Seattle, Washington, April. 2009.

20 Esposito, J. F. and Keshmiri, S., “Rapid Hardware Interfacing and Software Development for Embedded Devices Using Simulink,” AIAA
Paper 2010-3415, AIAA Infotech@Aerospace, Atlanta, Georgia, June 2010.

21 Garcia, G. and Keshmiri, S., “Integrated Kalman Filter for a Flight Control System with Redundant Measurements,” AIAA Paper 2012-2499,
AIAA Infotech@Aerospace, Garden Grove, California, June 2012.

22 Cloud Cap Technology, “Cloud Cap Technology – Piccolo II highly integrated UAS Autopilot,” https://www.cloudcaptech.com/piccolo II.shtm.
23 MicroPilot, “MicroPilot - Products - MP2128g,” http://www.micropilot.com/products-mp2128g.htm.
24 Lockheed Martin, “Kestrel Flight Systems,” http://www.lockheedmartin.com/us/products/procerus/kestrel.html.
25 Embention Sistemas Inteligentes SL, “Veronte Autopilot for UAV, UAS & drones - Embention Products,”
https://products.embention.com/veronte/uav-autopilot.
26 Emlid Ltd, “Emlid Navio2 Raspberry Pi autopilot HAT powered by ArduPilot & ROS,” https://emlid.com/navio/.
27 Intel Corporation, title = Intel Aero Compute Board, h. . h. o. . O. t. . .
28 The Paparazzi Project, LLC, “Paparazzi,” http://paparazzi.enac.fr/.
29 “ArduPilot Open Source Autopilot,” http://ardupilot.com/.
30 PX4, “PX4 Autopilot Platform,” https://pixhawk.ethz.ch/.
31 RCAT Systems, “RCAT Systems - UAV & Unmanned Vehicle Products, UAV Telemetry System, UAV Electronics, Pitot Probes, Alpha Beta
Probes,” http://rcatsystems.com/.
32 Eagle Tree Systems, LLC, “Eagle Tree R/C Telemetry,” http://www.eagletreesystems.com/.
33 National Instruments, title = CompactRIO Systems - National Instruments, h. . h.
34 Al Volo LLC, “Al Volo: Flight Data Acquisition Systems,” http://www.alvolo.us.
35 Christophersen, H. B., Pickell, R. W., Neidhoefer, J. C., Koller, A. A., Kannan, S. K., and Johnson, E. N., “A Compact Guidance, Navigation,
and Control System for Unmanned Aerial Vehicles,” Journal of Aerospace Computing, Information, and Communication, Vol. 3, No. 2, 2006,
pp. 187–213.
36 Ippolito, C., Yeh, Y. H., and Kaneshige, J., “Neural Adaptive Flight Control Testing on an Unmanned Experimental Aerial Vehicle,” AIAA
Paper 2007-2827, AIAA Infotech@Aerospace, Rohnert Park, CA, May 2007.

37 Yeh, Y.-H., Kumar, P., Ishihara, A., and Ippolito, C., “Hardware Implementation of COTS Avionics System on Unmanned Aerial Vehicle
Platforms,” AIAA Paper 2010-3508, AIAA Infotech@Aerospace Conference, Atlanta, Georgia, Apr. 2010..
29 of 31

38 Brusov, V., Grzybowski, J., and Petruchik, V., “Flight Data Acquisition System for Small Unmanned Aerial Vehicle,” Proceedings of the
International Micro Air Vehicles, ’t Harde, The Netherlands, Sept. 2011.

39 Rhudy, M., Larrabee, T., Chao, H., Gu, Y., and Napolitano, M. R., “UAV Attitude, Heading, and Wind Estimation Using GPS/INS and an Air
Data System,” AIAA Paper 2013-5201, AIAA Guidance, Navigation, and Control Conference, Boston, MA, Aug. 2013.
40 Rhudy, M., Gu, Y., and Napolitano, M. R., “Low-Cost Loosely-Coupled Dual GPS/INS for Attitude Estimation with Application to a Small
UAV,” AIAA Paper 2013-4957, AIAA Guidance, Navigation, and Control Conference, Boston, MA, Aug. 2013.
41 Napolitano, M. R., “Development, Instrumentation, and Flight Testing of UAVs as Research Platforms for Flight Control Systems Research,”
http://www.dsea.unipi.it/Members/polliniw/sgn/semn apolitano1, May2013.

42 Mancuso, R., Dantsker, O. D., Caccamo, M., and Selig, M. S., “A Low-Power Architecture for High Frequency Sensor Acquisition in
Many-DOF UAVs,” International Conference on Cyber-Physical Systems, Berlin, Germany, Apr. 2014.
43 Dantsker, O. D., Mancuso, R., Selig, M. S., and Caccamo, M., “High-Frequency Sensor Data Acquisition System (SDAC) for Flight Control
and Aerodynamic Data Collection Research on Small to Mid-Sized UAVs,” AIAA Paper 2014-2565, AIAA Applied Aerodynamics Conference,
Atlanta, Georgia, June 2014.
44 Dantsker, O. D., Measurement of Unsteady Aerodynamic Characteristics of a Subscale Aerobatic Aircraft in High Angle-of-Attack Maneuvers,
Master’s thesis, University of Illinois at Urbana-Champaign, Department of Aerospace Engineering, Urbana, IL, 2015.
45 Stockton, J., Modular Autopilot Design and Development Featuring Bayesian Non-Parametric Adaptive Control, Master’s thesis, Oklahoma
State University, Department of Mechanical & Aerospace Engineering Engineering, Stillwater, OK, 2014.
46 Vuppala, S. T., Implementation and Validation of Gaussian Process Model Reference Adaptive Control for Fixed Wing Unmanned Aerial
Systems, Master’s thesis, Oklahoma State University, Department of Mechanical & Aerospace Engineering Engineering, Stillwater, OK, 2016.
47 Barbeau, Z. P., Fehrenbach, S. D., Andalibi, M., Chowdhary, G., and Jacob, J. D., “System Development for the NASA UAS Airspace
Operations Challenge,” AIAA Paper 2015-3328, AIAA Aviation Technology, Integration, and Operations Conference, Dallas, Texas, Jun. 2015.
48 Bingler, A. and Mohseni, K., “Dual Radio Autopilot System for Lightweight, Swarming Micro/Miniature Aerial Vehicles,” Journal of
Aerospace Information Systems, Vol. 14, No. 5, 2017, pp. 293–305.

49 University of Minnesota, “UAV Lab - Goldy III,” https://www.uav.aem.umn.edu/resources/goldy-iii.
50 “Bolder Flight Systems,” https://bolderflight.com.
51 McCrink, M. H. and Gregory, J. W., “Design and Development of a High-Speed UAS for Beyond Visual Line-of-Sight Operations,” AIAA
Paper 2018-0750, AIAA Infotech@Aerospace Conference, Kissimee, Florida, Jan 2018.

52 Uhlig, D., Bhamidipati, K. K., and Neogi, N., “Safety and Reliability Within UAV Construction,” Proceedings of the IEEE Digital Avionics
System Conference, Portland, OR, 2006.

53 Dobrokhodov, V. N., Yakimenko, O. A., Jones, K. D., Kaminer, I. I., Bourakov, E., Kitsios, I., and Lizarraga, M., “New Generation of
Rapid Flight Test Prototyping System for small Unmanned Air Vehicles,” AIAA Paper 2007-6567, AIAA Modeling and Simulation Technologies
Conference and Exhibit, Hilton Head, SC, Aug. 2007.
54 Jager, R., Test and Evaluation of the Piccolo II Autopilot System on a One-Third Scale Yak-54, Master’s thesis, University of Kansas,
Department of Aerospace Engineering, Lawrence, KS, 2009.

55 Czarnomski, M., Spitsberg, R., Dvorak, D., Schultz, R. R., and Semke, W. H., “Benefits of Autopilot Integration for Enhanced UAS
Operations,” AIAA Paper 2009-1995, AIAA Infotech@Aerospace, Seattle, WA, Apr. 2009.
56 Ortiz, P. and Nicholas, A., “Spanwise Adaptive Wing - PTERA Flight Test,” Tech. Rep. AFRC-E-DAA-TN57887, National Aeronautics and
Space Administration, 2018.

57 Motter, M. A., Logan, M. J., French, M. L., and Guerreiro, N. M., “Benefits of Autopilot Integration for Enhanced UAS Operations,” AIAA
Paper 2006-3305, Aerodynamic Measurement Technology and Ground Testing Conference, San Francisco, CA, June 2006.
58 Maroney, D. R., Bolling, R. H., and R. Athale, A. D. C., “Experimentally Scoping the Range of UAS Sense and Avoid Capability,” AIAA
Paper 2007-2850, AIAA Infotech@Aerospace, Rohnert Park, CA, May 2007.

59 Li, N. H. M., Liu, H. H. T., Earon, E. J. P., Fulford, C. D., Huq, R., and Rabbath, C. A., “Multiple UAVs Autonomous Mission Implementation
on COTS Autopilots and Experimental Results,” AIAA Paper 2009-5775, AIAA Guidance, Navigation and Control Conference, Chicago, IL, Aug.
2009.
60 Dantsker, O. D., Theile, M., Caccamo, M., and Mancuso, R., “Design Development and Initial Testing of a Computationally-Intensive
Long-Endurance Solar-Powered Unmanned Aircraft,” AIAA Paper 2018-4217, AIAA Applied Aerodynamics Conference, Atlanta, Georgia, June
2018.
61 Dantsker, O. D., Theile, M., and Caccamo, M., “A High-Fidelity, Low-Order Propulsion Power Model for Fixed-Wing Electric Unmanned
Aircraft,” AIAA/IEEE Electric Aircraft Technologies Symposium, Jul. 2018.

62 Theile, M., Dantsker, O. D., Nai, R., and Caccamo, M., “uavEE: A Modular, Power-Aware Emulation Environment for Rapid Prototyping and
Testing of UAVs,” Accepted to IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, Hakodate, Japan,
Aug. 2018.
63 Soltmann, L. M. and Hall, C. E. J., “Determination of Power Required through Accelerated Flight with Application to Unmanned Vehicles,”
AIAA Paper 2016-0042, AIAA Aerospace Sciences Meeting , San Diego, California, Jan. 2016.
64 Kraft, T. E., Fields, T. D., and Yakimenko, O. A., “Feasibility of Flying-Wing-based Aerial Delivery,” AIAA Paper 2017-3885, AIAA
Aerodynamic Decelerator Systems Technology Conference, Denver, Colorado, June 2017.

65 Vahora, M., Development of UAV Flight Test Demonstrator for Cyclotronic Arc-Plasma Actuators, Master’s thesis, University of Illinois at
Urbana-Champaign, Department of Aerospace Engineering, Urbana, IL, 2018.

66 Mahboubi, Z., Kolter, Z., Wang, T., and Bower, G., “Camera Based Localization for Autonomous UAV Formation Flight,” AIAA Paper
2011-1658, AIAA Infotech@Aerospace, St. Louis, MO, Mar. 2011.

67 Chao, H., Flanagan, H. P., Tian, P., and Hagerott, S. G., “Flight Test Investigation of Stall/Spin Detection Techniques for a Flying Wing UAS,”
AIAA Paper 2017-1631, AIAA Atmospheric Flight Mechanics Conference, Grapevine, Texas, Jun. 2017.
68 Sun, S., Schilder, R. J., and de Visser, C., “Identification of Quadrotor Aerodynamic Model from High Speed Flight Data,” AIAA Paper
2018-0523, AIAA Aerospace Sciences Meeting, Kissimmee, Florida, Jan. 2018.

69 Hattenberger, G., Bronz, M., and Gorraz, M., “Using the Paparazzi UAV System for Scientific Research,” IMAV 2014, International Micro Air
Vehicle Conference and Competition 2014.
30 of 31

70 Zafirov, D., “Autonomous VTOL Joined Wing UAV,” AIAA Paper 2013-5087, AIAA Atmospheric Flight Mechanics Conference, Boston,
MA, Aug. 2013.

71 Srinivasan, T. and Bhandari, S., “Path-Planning around Obstacles for a Quadrotor UAV Using the RRT Algorithm for Indoor Environments,”
AIAA Paper 2016-2196, AIAA Infotech@Aerospace Conference, San Diego, California, Jan. 2016.
72 Mitchell, T. A., Brown, C. T., and Jacob, J. D., “System Development for CO2 Plume Detection Using UAS,” AIAA Paper 2015-1459, AIAA
Infotech@Aerospace Conference, Kissimee, Florida, Jan 2015..

73 Thorpe, R. L., McCrink, M. H., and Gregory, J. W., “Measurement of Unsteady Gusts in an Urban Wind Field using a UAV-based Anemometer,”
AIAA Paper 2018-4218, AIAA Applied Aerodynamics Conference, Atlanta, Georgia, June 2018.
74 Hamada, S. and Moreno, C. P., “Development of an Unmanned Aerial Vehicle (UAV) Research Platform for Flutter Analysis,” AIAA Paper
2018-0021, AIAA Atmospheric Flight Mechanics Conference, Kissimmee, Florida, Jan. 2018.
75 Erturk, S. R. V. S. A. and Dogan, A., “Development and Flight Test of Moving-mass Actuated Unmanned Aerial Vehicle,” AIAA Paper
2016-3713, AIAA Atmospheric Flight Mechanics Conference, Washington, D.C., Jan. 2016.
76 .Sobron, A., Lundstrom, D., Staack, I., and Krus, P., “Design and Testing of a Low-Cost Flight Control and Data Acquisition System for
Unstable Subscale Aircraft,” International Congress on the Aeronautical Sciences Systems (ICUAS), Daejeon, Korea, Sep. 2016.
77 Sobron, A., On Subscale Flight Testing: Applications in Aircraft Conceptual Design, Ph.D. thesis, Linkoping University, Department of
Management and Engineering, Linkoping, Sweden, 2018.

78 Lee, K., Development of Unmanned Aerial Vehicle (UAV) for Wildlife Surveillance, Master’s thesis, University of Florida, Department of
Mechanical and Aerospace Engineering, Gainesville, FL, 2004.

79 Antol, J., Chattin, R. L., Copeland, B. M., and Krizan, S. A., “The NASA Langley Mars Tumbleweed Rover Prototype,” AIAA Paper 2006-64,
AIAA Aerospace Sciences Meeting, Reno, NV, Jan. 2006.

80 Hogge, E. F., Quach, C. C., Vazquez, S. L., and Hill, B. L., “A Data System for a Rapid Evaluation Class of Subscale Aerial Vehicle,” Tech.
Rep. TM-2011-217145, National Aeronautics and Space Administration, 2011.

81 Johnson, B. and Lind, R., “High Angle-of-Attack Flight Dynamics of Small UAVs,” AIAA Paper 2009-61, AIAA Aerospace Sciences
Meeting, Orlando, FL, Jan. 2009.

82 Dantsker, O. D., Johnson, M. J., Selig, M. S., and Bretl, T. W., “Development of the UIUC Aero Testbed: A Large-Scale Unmanned Electric
Aerobatic Aircraft for Aerodynamics Research,” AIAA Paper 2013-2807, AIAA Applied Aerodynamics Conference, San Diego, CA, Jun. 2013.
83 Heinzen, S., “Flight Testing of the Free-to-Pitch Variable Pitch Propeller,” AIAA Paper 2018-0762, AIAA Aerospace Sciences Meeting,
Kissimmee, Florida, Jan. 2018.

84 Ananda, G. K., Vahora, M., Dantsker, O. D., and Selig, M. S., “Design Methodology and Flight-Testing Protocols for a Dynamically-Scaled
General Aviation Aircraft,” AIAA Paper 2017-4077, AIAA Applied Aerodynamics Conference, Denver, Colorado, Jun 2017.
85 Dantsker, O. D., Ananda, G. K., and Selig, M. S., “GA-USTAR Phase 1: Development and Flight Testing of the Baseline Upset and Stall
Research Aircraft,” AIAA Paper 2017-4078, AIAA Applied Aerodynamics Conference, Denver, Colorado, June 2017.
86 Real Time and Embedded System Laboratory, University of Illinois at Urbana-Champaign, “Solar-Powered Long-Endurance UAV for
Real-Time Onboard Data Processing,” http://rtsl-edge.cs.illinois.edu/UAV/.

87 Dantsker, O. D., Loius, A. V., Mancuso, R., Caccamo, M., and Selig, M. S., “SDAC-UAS: A Sensor Data Acquisition Unmanned Aerial
System for Flight Control and Aerodynamic Data Collection,” AIAA Paper 2015-0987, AIAA Infotech@Aerospace Conference, Kissimee, Florida,
Jan 2015..
88 Vahora, M., Ananda, G. K., and Selig, M. S., “Design Methodology for Aerodynamically Scaling of a General Aviation Aircraft Airfoil,”
AIAA Paper 2018-1277, AIAA Aerospace Sciences Meeting, Kissimmee, Florida, Jan. 2018.
89 Qadri, M., Vahora, M., Hascaryo, R., Finlon, S., Dantsker, O. D., Ananda, G. K., and Selig, M. S., “Undergraduate Contribution to Dynamically
Scaled General Aviation Research at the University of Illinois at Urbana-Champaign,” AIAA Paper 2018-1069, AIAA Aerospace Sciences Meeting,
Kissimmee, Florida, Jan. 2018.
90 Alta Devices, “Technology Brief - Single Junction,” https://www.altadevices.com/wp-content/uploads/2018/01/tb-single-junction-1712-
001.pdf, Accessed Apr. 2018.
31 of 31

Flight Data Acquisition Platform Development, Integration, and Operation On Small-To Medium-Sized Unmanned Aircraft

Uploaded by

Copyright:

Available Formats

Flight Data Acquisition Platform Development, Integration, and Operation On Small-To Medium-Sized Unmanned Aircraft

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flight Data Acquisition Platform Development, Integration, and Operation On Small-To Medium-Sized Unmanned Aircraft

Uploaded by

Copyright:

Available Formats

AIAA SciTech Forum 10.2514/6.

Flight Data Acquisition Platform Development, Integration, and

Or D. Dantsker ∗ Renato Mancuso†

ADC = analog-to-digital converters

∗ Aero-Mechanical Engineer. [email protected]

Copyright © 2019 by Or D. Dantsker and Renato Mancuso. Published by theAmerican Instituteofof

data from a large range of sensors and devices.

II. Development Overview

Capturing data is a fundamental component of con-

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

1. Synchronous and Asynchronous Serial

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

Table 1. Closed-source commercially-produced autopilot comparison

American Institute of Aeronautics and Astronautics

Table 2. Open-source commercially-produced autopilot comparison

American Institute of Aeronautics and Astronautics

Table 3. Closed-source commercially-produced data acquisition systems comparison

American Institute of Aeronautics and Astronautics

Table 4. Custom avionics system solution comparison

American Institute of Aeronautics and Astronautics

Table 4 (continued). Custom avionics system solution comparison

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

Parallel to 14S 10Ah

Series to 14S 5Ah Series to 14S 5Ah

7S 5Ah LiPo Battery

7S 5Ah LiPo Battery

7S 5Ah LiPo Battery

REMOVE BEFORE FLIGHT

To ELECT Port To PDU To RPM Port

Table 5. UIUC Subscale Sukhoi unmanned aircraft physical speciﬁcations

American Institute of Aeronautics and Astronautics

ESC Hacker MasterSPIN 220

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

Table 7. Updated UIUC SDAC system component speciﬁcations

Processing unit BeagleBone running 32-bit Ubuntu Linux

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

Table 8. Baseline GA-USTAR unmanned aircraft physical speciﬁcations.

American Institute of Aeronautics and Astronautics

Receiver Futaba R6008HS

Table 10. Component speciﬁcations of the GA-USTAR aircraft instrumentation.

Data acquisition system Al Volo FDAQ 400 Hz system

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

Table 13. Instrumentation speciﬁcations.

American Institute of Aeronautics and Astronautics

American Institute of Aeronautics and Astronautics

AIAA Atmospheric Flight Mechanics Conference, Portland, Oregon, Aug. 2011.