1 

 

Autonomous Flight Control and

Data Acquisition System

Lindsey Carboneau

Draft 4

December 10, 2014

CNT 4104 Software Project in Computer Networks

Project Mentor: Dr. Janusz Zalewski

Software Engineering Program

Florida Gulf Coast University

Ft. Myers, FL 33965

2 

 

1. Introduction

Unmanned aviation is a rapidly growing field. Researchers and companies around the

world are continuously finding new practices and applications for remotely piloted and

unmanned systems. Colloquially known as “drones”, these Unmanned Aerial Systems (UAS)

represent an opportunity to expand operations and knowledge in remote, dangerous, protected,

and previously unreachable places. UAS are the ultimate tool for adaptability and versatility –

which is why research and development of new systems is not only suitable for large

organizations, like Lockheed Martin and the Department of Defense, but for students and local

entrepreneurs. Social stigma from their long association with military operations has caused a

delay in developing systems for commercial and civilian use; but more and more often we see

UAS used for everything from law enforcement and firefighting to package delivery and

photojournalism.

 

Figure 1: Parallax ELEV‐8 Y‐6 Multicoptor 

The Parallax ELEV-8 Y-6 (Figure 1) is a multicoptor kit designed for hobby remote

controlled flight and aerial photography [1]. It has six fixed-pitch blades controlled by six

separate motors, each with their own electronic speed controller (ESC). The HoverflyOPEN

3 

 

board (Figure 2) controls the motors by sending Pulse-Width-Modulated (PWM) signals to the

ESCs. The HoverflyOPEN uses a multi-core microcontroller made by Parallax Inc., called a

Propeller, which is capable of quickly processing incoming sensor data to maintain stability [2].

 

Figure 2: HoverflyOPEN Board

It is important to note when using the UAS that the original kit is an RC hobby aircraft,

and when assembled as directed by Parallax, Inc. (Figure 3) “does not constitute the use of an

autonomous UAV [Unmanned Aerial Vehicle] or drone” [2].

 

Figure 3: Parallax ELEV‐8 Y‐6 Standard Build

4 

 

The original construction of the ELEV-8 Y-6 has been slightly modified to meet the

purposes of the project (Figure 4). Notable changes to the recommended construction include

replacing the Red 16 AWG wiring from the brushless motors to the ESCs with 16-3 AWG

insulated cabling, which run externally instead of inside the booms, and replacing the bullet wire

connectors with insulated, crimp-on disconnect pair connectors. These changes significantly

decrease the number of solder points and provide both more secure connections and the ability to

isolate and diagnose any future motor or ESC issues.

 

Figure 4: Parallax ELEV‐8 Y‐6 Modified Build

5 

 

2. Software Requirements Specification

Current trends in aviation and UAS development focus primarily on mechanical flight

systems, and rely on a pilot or operator to control their functions. This UAS, in contrast, is fully

autonomous, capable of performing tasks and monitoring its own status. The objective of this

project is to produce an autonomous flight control and data acquisition system accessed and

utilized via the Internet. Once this is accomplished, development can focus on incorporating

new sensors and improving the efficiency of the flight control software. The specific goal of the

Fall 2014 semester iteration is to establish the web based user interface and to demonstrate

remote utilization of the UAS.

2.1 Physical System

 

Figure 5: Project Physical Diagram 

The diagram in Figure 5 illustrates the physical hardware system for this UAS project.

The current iteration features the BeagleBone Black microcontroller as the primary flight control

and data acquisition hardware. This sends PWM signals to the HoverflyOPEN board, which

includes provided firmware and built in sensors for maintaining stable flight. This directly

6 

 

controls the ESC’s that provide power and appropriate signals for the UAS motors. The sensors

on board the HoverflyOPEN are not accessible from the BeagleBone Black; therefore a separate

set of sensors has to interface directly to the microcontroller board. Finally, the microcontroller

communicates with the server via a wireless Internet connection. Users can then access the

server using a web browser client to view data and make requests.

2.2 Software Context Diagram

 

Figure 6: UAS Context Diagram 

The diagram in Figure 6 illustrates how the UAS Microcontroller software interacts with

the sensors available for data collection and flight control and with external world via the Server.

The objective of the Server software is to fully remove the UAS from direct human interaction.

It will provide extra data processing for human client use and remove human piloting error. The

UAS Microcontroller will autonomously access the Server, obtain tasks assigned by users,

perform those tasks, and report any data back to the Server.

The Client application provides an interface through a webpage that will allow users to

request tasks or data from the UAS Microcontroller, as well as view current tasks and data. The

UAS Microcontroller will have access to a list of requested tasks and data from the server

through its own client application, and will be able to send data and confirmation of received

7 

 

requests and completed tasks. A task is an action to be performed by the UAS which the

Microcontroller can execute using a set of predefined instructions.

2.3 UAS Microcontroller Software Requirements

2.3.1. The Microcontroller shall output PWM signals to the HoverflyOPEN.

2.3.2. The Microcontroller shall be able to respond to input signals from sensors.

2.3.3. The Microcontroller shall connect to the server using a wireless Internet

connection.

2.3.4. The Microcontroller shall request new task data from the server.

2.3.5. The Microcontroller shall record requested data during the execution of a task.

2.3.6. The Microcontroller shall transmit data to the Server Software upon the completion

of a task.

2.3.7. The Microcontroller shall store a local copy of the task data when a wireless

Internet connection to the server cannot be established.

2.3.8. The Microcontroller shall output analog signals to power ON and OFF the

HoverflyOPEN.

2.3.9. The Microcontroller shall transmit UAS status information to the Server at fifteen

minute intervals while a connection with the Server is established.

2.4 Server Software Requirements

2.4.1. The Server shall allow users to submit task requests via a web client.

2.4.2. The Server shall allow users to view the UAS status information via a web client.

2.4.3. The Server shall be able to respond to input data from the connected UAS

Microcontroller.

2.4.4. The Server shall transmit task request data to the connected UAS Microcontroller.

2.4.5. The Server shall allow users to view requested tasks and data via a web client.

8 

 

3. Design Description

3.1 Hardware Considerations

The first phase of the project consisted of the construction and modified build of the

flight platform, as well as the layout of the control structure. Additional elements added to the

platform support the batteries and the control boards (Figure 7). The UAS utilizes multiple

modular levels of control. At the lowest level, the ESCs send signals to the motors, regulating

their speed and monitoring their power output for the flight control board. At the next level, the

HoverflyOPEN regulates the platform’s stability and flight, as well as sends and receives signals

from the ESCs. At the top level, a controller board, such as an Intel Galileo [3], performs data

acquisition, external communications, and navigation (Figure 8).

 

Figure 7: Constructed Flight Platform with HoverflyOPEN

The second phase of the project consisted mainly of learning and modifying the

Propeller’s Spin code, Parallax’s proprietary high-level language [4]. This will lead to

developing unique firmware for the flight control system. The goal of this phase was to ensure

that a microcontroller board would communicate properly with the HoverflyOPEN, allowing it

to navigate and prioritize tasks and objectives while leaving flight and stability to the Propeller

processor (Figure 8). The microcontroller board must be capable of sending a minimum of five

pulse-width-modulated (PWM) signals to the HoverflyOPEN, which emulate the control of a

radio transmitter and receiver. Without all five signals, the HoverflyOPEN will not arm,

9 

 

preventing the system from taking off. The HoverflyOPEN expects a signal frequency of 50Hz,

with a low duty cycle of 5% and a high of 10%. These are essential limits to know when

programming the control board’s PWM signal outputs.

 

Figure 8: Intel Galileo and HoverflyOPEN Connection 

 

The current phase of the project focuses on connecting the microcontroller board to both

the HoverflyOPEN and its own unique website. Users will be able to access flight metrics and

collected data from the UAS on the webpage, as well as request specific tasks and data from the

system. This phase is open-ended, as improvements made to the system will require website

updates to facilitate testing and to ensure optimal control. The current version of the software

and documentation is on the project website [5].

3.2 Microcontroller Selection

During the initial motor and control testing, an Intel Galileo was the microcontroller used

to send signals to the HoverflyOPEN (Figure 8). However, the Galileo board is difficult to work

with both as a Linux system and as an Arduino development board. By default, the sketches are

not persistent, and users must reload their program onto the board each time it is power cycled

off and on again. Due to its strict power requirements, it is also difficult to run off battery power,

which is essential for a flight control board. Running nothing but network communications on

the Galileo consumes about 530mA, and the extended start up procedure requires up to 540mA.

10 

 

Running on a single dedicated battery, this limits flights to less than 30 minutes of operation.

These numbers do not include powering the HoverflyOPEN board, which consumes

approximately 50mA at load.

These results lead to testing additional control boards and their power requirements, as

well as comparing their benchmarking results. The BeagleBone Black (Figure 9) [8] has been

chosen as the microcontroller board based on its benchmark performance, greater power

efficiency (Table 1), and extensive available support.

Table 1: Summary of BeagleBone and Galileo Power Consumption and LINPACK Results [6] 

Device Idle Idle w/ Ethernet Whetstone LINPACK

Intel Galileo 500 mA 530 mA 540 mA 560 mA

BeagleBone Black 160 mA 210 mA 390 mA 390 mA

3.3 Software Design

Following the Context Diagram in Figure 5 and the requirements specification in

previous sections, the software design involves two applications: the Microcontroller application

and the Server application. This section outlines the details of both.

 

Figure 9: Microcontroller and Server Application Architecture

11 

 

The UAS Microcontroller system is built as three components. The first handles

communication with the HoverflyOPEN board by providing the proper signals for the flight

control board. This requires producing PWM signals, as detailed in section 3.1. The second

monitors data coming in from the sensors. The Microcontroller software takes the incoming

sensor data and decides on the signals to be sent to the HoverflyOPEN based on the requested

task received from the Server. The Sensor and HoverflyOPEN components are modular because

they perform the same operations regardless of the task being performed. The Microcontroller

software handles all of the flight control decision making as well as communication with the

Server.

The Server system is built as two components, the Website GUI and the Server software

backend. A mock-up of the website in Figure 10 shows how users will interact with the UAS

system, which is intentionally indirect. The Server software handles the communication with the

Microcontroller software and updates the database.

 

Figure 10: Website GUI Mock‐Up

12 

 

4. Implementation

Initial successful testing done with the Galileo’s Arduino functionality is easy to recreate

with the BeagleBone. The current software development involves writing Python modules in

order to create both the server connection program and the PWM signals required by the

HoverflyOPEN.

Figure 11: BeagleBone Black with AirLink Wi‐Fi Adapter 

The current control board runs a Linux distribution called Debian Wheezy, a small

footprint distribution which is compatible with the BeagleBone Black and other microcontrollers

with ARM processors (Figure 11). A specialized Python package from the Adafruit Learning

System [8] allows the use of pins on the BeagleBone for PWM signals, as well as opening access

to several other analog and digital pins using Python. A control module written in Python

accesses the pins to output the correct signals to the HoverflyOPEN board. The HoverflyOPEN

then sends the proper signals to the ESCs, using its own firmware to take in controller commands

and translate them to stable flight.

13 

 

 

Figure 12: Detailed Design Diagram 

A second module on the control board runs a client program to communicate with the

server. Communication is wireless using an AirLink 101 Wireless N USB adapter [10]. When

accessing the network, the client program on the UAS will request the specific flight tasks the

server has stored. It will then store the information locally and attempt to perform the assigned

tasks. Separate modules monitoring system vitals, sensors, and battery life will alert the system

to problems and initiate safe landing procedures in an emergency.

On the server, a webpage interface will allow users to choose from a list of approved

tasks, as well as specify what data to collect. The server will store these requests in its database

until accessed by the UAS or deleted by an administrator. It is critical that a user is not able to

request any unsafe operation from the system, and that any task can be rejected by an

administrator or the UAS at any time. Figure 12 details the full system design.

In the current implementation of the Control System module, the receiveRequest method

is the primary method. When a request is registered by the webpage, receiveRequest emits a

message back reporting the status of the request as ‘received’. It then calls acceptRequest, which

checks the arming status of the HoverflyOPEN, and then executes the task associated with the

request. The acceptRequest method returns its status to receiveRequest, which then emits that

message to the webpage as ‘complete’ or ‘failed’.

14 

 

5. Testing

During testing it was determined that, while benchmarking performance and power

consumption of the BeagleBone Black are superior to similar boards, this does not mean that the

hardware is fully compatible with this application. The BeagleBone Black features several chips

for dedicated pulse-width modulation for driving motors without using any extra CPU cycles

[11]. There are 8 digital I/O pins which can be configured for PWM, however using these pins is

not supported without the use of an expansion board. As it is a general purpose embedded

system, the board is designed so that any one pin may be configured for a variety of uses. This

means that configuring pins for PWM varies from pin to pin, depending on which other uses that

pin may be capable of. Figure 13 shows the comparison of the various configurations for the

header pins on the BeagleBone Black.

 

Figure 13: BeagleBone Black Pinout Diagrams 

15 

 

The problem with this hardware configuration is that the BeagleBone Black was found to

only be able to reliably produce the proper PWM signals required by the HoverflyOPEN on two

pins, and the flight control board expects input from five separate channels. Without five correct

inputs, it is impossible to arm the system in preparation for flight or testing. The solution for the

fall semester iteration of the project uses an Arduino Uno (Figure 14)[12], which is capable of

producing the proper PWM signals without extra configuration. This is a temporary solution,

and future development of this project must find a way to properly produce the expected signals

with the BeagleBone Black or replace the board with a more appropriate system.

 

Figure 14: Arduino Uno R3, with 6 PWM pins denoted with tilde  

16 

 

6. Conclusion

6.1 Project Summary

Unmanned aerial systems (UAS) represent an opportunity to expand operations and

knowledge in remote, protected, dangerous, and previously unreachable places. This research

focuses on automating the flight control and data acquisition process so that applications of UAS

are more easily implemented by users without specialized training. The primary objective of this

project is to create an autonomous unmanned aerial system for future student projects across

disciplines. This objective relies on the ability to demonstrate remote operation, as well as

autonomous flight control and data acquisition. Students will now have a UAS as a platform to

develop new projects (Figure 15).

 

Figure 15: Final configuration of the UAS  

17 

 

6.2 Considerations

This project has experience several major difficulties during the development and

implementation of the software design. Future teams will need to consider whether the solutions

currently implemented are compatible with new requirements before building on this project.

The first difficulty is in the UAS structure itself. Though improvements have been made

to the wiring and physical build, hardware component failure is always important to consider.

The improvements will make it easier to diagnose faulty ESCs and motors.

Further difficulty came in the selection of microcontroller board for both performance

and power consumption. Original testing with the Intel Galileo led to rejecting it in favor of the

BeagleBone Black, which outclassed the comparable systems available at the time. With this

board, the system is capable of network communication as well as system control with minimal

power draw. It is incapable of reliably sending control signals to the HoverflyOPEN however,

and an additional expansion board or equivalent must be used to correct this. The current

solution makes use of an Arduino Uno, but this is not an ideal or permanent solution.

6.3 Expansion

There are several applications for autonomous UAS in interdisciplinary research. Future

iterations of this project should focus on expanding the functionality of the UAS Microcontroller

system for a specific client to take advantage of these applications. This would help the team

design a control system which focuses on completing a single, well defined task instead of an

overly generalized system.

An important part of extending this project will also be selecting a microcontroller which

can better fill the needs of this application. Suggested upgrades include the Intel Edison, an

embedded Linux board which features a small footprint, an integrated wireless internet adapter

and Bluetooth Low Energy (BTLE) module, 40 general purpose I/O pins, and the dual core Intel

Atom CPU [13]. This board may solve several of the problems encountered with the Intel

Galileo and the BeagleBone Black in a simple and efficient manner.

18 

 

7. References

[1] Parallax, Inc. (2012). ELEV-8 Y-6 Multicopter Kit. URL: http://www.parallax.com/product/80100

[2] Ducharme, A. D. (2012). HoverflyOPEN User's Guide. URL:http://www.parallax.com/sites/default/files/downloads/80000-Hoverfly-OPEN-Users-Guide-v1.0.pdf

[3] Intel. (2013). Intel Galileo Datasheet. URL:https://communities.intel.com/servlet/JiveServlet/previewBody/21835-102-4-25148/Galileo_Datasheet_329681_003.pdf

[4] LaMothe, A. (2006). Game Programming for the Propeller Powered Hydra. Parallax Inc.

[5] Carboneau, L. (2014). Unmanned Aerial Systems at FGCU. URL: arduino.fgcu.edu/UAS

[6] Parallax Semiconductor. (2011, 6 14). Propeller P8X32A Datasheet. URL:http://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf

[7] Hughes, A. (2014). Single and Double Floating Point Performance of Modern Prototyping Platforms. Florida Gulf Coast University Internal Report

[8] BeagleBoard.org Foundation. (2013). Getting Started with the BeagleBone & BeagleBone Black. URL: http://beagleboard.org/Getting%20Started

[9] Adafruit Learning Technologies. (2013). Setting Up IO Python Library on BeagleBone Black. URL: http://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/overview

[10] Airlink 101 Networking Solutions. (2012). AWLL5099 Wireless N 150 Ultra Mini USB Adapter. URL: http://www.airlink101.com/products/awll5099.php

[11] BeagleBoard.org. (2014). Cape Expansion Headers. URL: http://beagleboard.org/Support/bone101

[12] Arduino. (2014). Arduino Uno. URL: http://arduino.cc/en/Main/arduinoBoardUno [13] Intel. (2014). Intel Edison Product Brief. URL: https://communities.intel.com/docs/DOC-23139