sleemanwc_thesis

THE DEVELOPMENT OF A LINUX AND FPGA BASED AUTOPILOT SYSTEM
FOR UNMANNED AERIAL VEHICLES
A thesis submitted in partial fulfillment of the requirements for the degree of Master of
Science at Virginia Commonwealth University.
by
WILLIAM CLIFFORD SLEEMAN IV
Director: Dr. Robert H. Klenke
Associate Professor of Electrical & Computer Engineering
Virginia Commonwealth University
Richmond, Virginia
May 2007

ii
Acknowledgements
I would like to thank Dr. Robert H. Klenke for being my advisor and helping me
through the completion of this research and the writing of this thesis. I would also like to
thank Dr. James E. Ames and Dr. Gregory A. Buck for their time as members of my
thesis committee. I am very appreciative of the funding support given by Dr. Mark A.
Motter of the NASA Langley Research Center. Thanks also go to Jeff McBride, Hoan
Nguyen, and all of the other students of the Digital Systems Prototyping Laboratory for
their help during this project. Finally, I would like to thank my family, especially my wife
Elizabeth, for their support during my time in graduate school.

iii
Table of Contents
Acknowledgements............................................................................................................. ii
Table of Contents...............................................................................................................iii
List of Tables ...................................................................................................................viii
List of Figures.................................................................................................................... ix
Abstract.............................................................................................................................. xi
CHAPTER 1 Introduction .................................................................................................. 1
1.1 Statement of Purpose ................................................................................................ 1
1.2 Problem Definition.................................................................................................... 1
1.3 Overview................................................................................................................... 3
CHAPTER 2 Background................................................................................................... 4
2.1 UAV History............................................................................................................. 4
2.1.1 Early UAVs........................................................................................................ 4
2.1.2 Autopilots........................................................................................................... 5
2.1.3 Current UAV Uses............................................................................................. 6
2.2 Commercial Systems ................................................................................................ 6
2.2.1 Procerus Technologies: Kestrel 2.2 ................................................................... 6
2.2.2 Cloud Cap Technologies: Piccolo II.................................................................. 8
2.2.3 MicroPilot: MP2028g ........................................................................................ 9
2.2.4 Microbotics: Microbot AP............................................................................... 10
2.2.5 Commercial System Comparison .................................................................... 11

iv
2.3 Virginia Commonwealth University’s Previous UAV Research............................ 12
2.3.1 Flight Control System...................................................................................... 12
2.3.2 Ground Control System ................................................................................... 13
2.4 Other University Research...................................................................................... 14
2.4.1 University of Kentucky: BIG BLUE ............................................................... 14
2.4.2 Pennsylvania State University: Quadrotor Device .......................................... 15
2.4.3 Georgia Tech: GTMax..................................................................................... 17
2.4.4 University of Wisconsin – Madison: Aesalon Unmanned Aerial Vehicle ...... 20
2.4.5 Purdue University: Real-Time Java Flight Control System ............................ 21
CHAPTER 3 Hardware Platforms.................................................................................... 23
3.1. Requirements ......................................................................................................... 23
3.2 Investigating Potential Platforms............................................................................ 23
3.2.1 Suzaku-V.......................................................................................................... 24
3.2.2 GumStix Connecx 400 XM ............................................................................. 27
3.3 System Comparisons............................................................................................... 30
3.3.1 Computing Power ............................................................................................ 31
3.3.2 Size and Power Consumption.......................................................................... 33
3.3.3 Ease of Development....................................................................................... 33
3.3.4 FPGA ............................................................................................................... 34
3.3.5 FPGA Interface................................................................................................ 35
3.3.6 Physical Properties........................................................................................... 35
3.4 Suzaku-V Chosen as Final System ......................................................................... 37

v
CHAPTER 4 Flight Control System Architecture............................................................ 38
4.1 Layout of the UAV ................................................................................................. 38
4.1.1 Airframe........................................................................................................... 41
4.1.2 Radio Control Hardware.................................................................................. 42
4.2 Sensors.................................................................................................................... 42
4.2.1 Crossbow IMU................................................................................................. 42
4.2.2 Airspeed and Altitude ...................................................................................... 45
4.2.3 UBlox GPS....................................................................................................... 45
4.3 Intellectual Property Cores ..................................................................................... 45
4.4 Virtex-2 Pro FPGA Architecture ............................................................................ 46
4.5 Pulse Width Modulation Core Design.................................................................... 48
4.5.1 Servo Control................................................................................................... 48
4.5.2 Pulse Width Modulation Core Design ............................................................. 49
4.5.3 Pulse Width Modulation Core Structure.......................................................... 52
4.6 Adding Additional IP Cores.................................................................................... 53
CHAPTER 5 Software Design ......................................................................................... 55
5.1 Linux and General Public License (GNU) Tools ................................................... 54
5.2 Configuring Linux .................................................................................................. 54
5.2.1 Customizing the Kernel ................................................................................... 55
5.2.2 Adding Extra Serial Devices............................................................................ 55
5.2.3 IP Core Settings ............................................................................................... 56
5.3 Using Threads ......................................................................................................... 57

vi
5.4 Flight Control Loop ................................................................................................ 58
5.5 PWM Driver............................................................................................................ 59
5.5.1 Hardware Access ............................................................................................. 60
5.5.2 PWM Driver Design ........................................................................................ 61
5.5.3 Driver Access................................................................................................... 63
5.6 Delay Driver............................................................................................................ 64
5.6.1 Linux Timing ................................................................................................... 64
5.6.2 Delay Driver Design ........................................................................................ 65
5.7 Loading Drivers ...................................................................................................... 66
CHAPTER 6 Future Work................................................................................................ 68
6.1 Real Time OS.......................................................................................................... 67
6.2 Hardware Floating Point Unit................................................................................. 68
6.3 Cloud Cap Technologies: Crista Inertial Measurement Unit.................................. 68
6.4 Other Embedded Platforms..................................................................................... 70
6.4.1 Bluewater System: Snapper............................................................................. 70
6.4.2 Xilinx Virtex-4 based System.......................................................................... 70
6.5 Safety ...................................................................................................................... 71
CHAPTER 7 Summary..................................................................................................... 73
References......................................................................................................................... 74
Appendices........................................................................................................................ 77
A Pulse Width Modulation VHDL Code.............................................................77
B Linux Device Driver Code...............................................................................86

vii
C Flight Control System Code.............................................................................90
D Linux Configuration Files..............................................................................103
E Xilinx Project Files ........................................................................................107

viii
List of Tables
Page
Table 2.1: Comparison of Four Commercial UAV Autopilot Systems.............................11
Table 3.1: Expansion Boards for the Connex System. ......................................................28
Table 3.2: LINPACK Benchmark Results.........................................................................32
Table 3.3: Dhrystone Benchmark Results. ........................................................................32
Table 3.4: Comparison of the Spartan-3 and Virtex-II Pro FPGAs...................................35
Table 3.5: Hardware Comparison of the Connex 400 XM and Suzaku-V Systems..........37
Table 4.1: Format of the Crossbow Data Packets in Angle Mode.....................................44
Table 4.2: FPGA Clock Divider Module Interface............................................................50
Table 4.3: FPGA Read Module Interface. .........................................................................51
Table 4.4: FPGA Write Module Interface. ........................................................................51
Table 6.1: Comparison of the Crossbow and Crista IMUs................................................69

ix
List of Figures
Page
Figure 1.1: The Multi-Segmented Wing of the AN/FQM-117B Aircraft ...........................2
Figure 2.1: Procerus Technologies’s Kestrel 2.2.................................................................8
Figure 2.2: Cloud Cap Technology’s Piccolo II Autopilot System.....................................9
Figure 2.3: MicroPilot MP2028g Autopilot.......................................................................10
Figure 2.4: The Microbotics Microbot AP System............................................................11
Figure 2.5: The BIG BLUE Flight Control System...........................................................15
Figure 2.6: The Quadrotor Aircraft....................................................................................16
Figure 2.7: The PIC Based Flight Control System ............................................................17
Figure 2.8: The GTMax Avionics Rack ............................................................................18
Figure 2.9: The GTSpy Vehicle.........................................................................................19
Figure 2.10: The FCS20 Flight Control System ................................................................20
Figure 2.11: The Aesalon UAV Flight Computer .............................................................21
Figure 3.1: Atmark Techno Suzaku-V System..................................................................24
Figure 3.2: Suzaku-V System Connected to the EX Board...............................................27
Figure 3.3: Gumstix Connex 400 XM Board.....................................................................28
Figure 3.4: Gumstix Connex 400 XM with the Etherstix Expansion Board .....................29
Figure 3.5: Spartan-3 Prototype Board with the Gumstix Connex XM 400 .....................30
Figure 3.6: Connex 400 XM with the Etherstix and Waysmall Expansion Boards ..........36
Figure 4.1: Wiring Diagram of the UAV...........................................................................39
Figure 4.2: Complete Flight Control System in the Aircraft .............................................41
Figure 4.3: The Crossbow IMU.........................................................................................43

x
Figure 4.4: Block Diagram of the Virtex-2 Pro Interconnect ............................................47
Figure 4.5: PWM Core Layout ..........................................................................................52
Figure 5.1: The Flight Control Loop Thread Functionality...............................................59
Figure 6.1: The Crista IMU ...............................................................................................69

Abstract
THE DEVELOPMENT OF A LINUX AND FPGA BASED AUTOPILOT SYSTEM
FOR UNMANNED AERIAL VEHICLES
By William Clifford Sleeman IV
A thesis submitted in partial fulfillment of the requirements for the degree of Master of
Science at Virginia Commonwealth University.
Virginia Commonwealth University, 2007
Major Director: Dr. Robert H. Klenke
Associate Professor of Electrical & Computer Engineering
This project is part of research funded by NASA Langley in field of Unmanned
Aerial Vehicles (UAVs) and is based on past work conducted at Virginia Commonwealth
University. Dr. Mark A. Motter of NASA Langley intends to use the new autopilot
system to test aircraft with many control surfaces. The goal of this project is to port an
existing UAV autopilot system that has more computing power than the previous
generation system to allow for more advanced flight control algorithms.
The steps taken to complete this project include choosing a new hardware
platform, porting C flight control software from a MicroBlaze platform to a PowerPC
platform, and developing FPGA based hardware to interface with external sensors. The
Suzaku-V based system was shown to have much better computing performance than the

previous system, and several successful test flights have proved the viability of the new
autopilot system.

1
CHAPTER 1 Introduction
1.1 Statement of Purpose
The purpose of this Masters project is to develop a new flight control computer
system for NASA Langley’s Flying Controls Testbed (FLiC). The FLiC is a small,
inexpensive Unmanned Aerial Vehicle (UAV) designed for highly experimental flight
control approaches [1].
1.2 Problem Definition
Dr. Mark A. Motter of the NASA Langley Research Center developed the Flying
Controls Testbed to aid in the testing of experimental flight control algorithms. The FLiC
uses a styrofoam core AN/FQM-117B Army target drone as its airframe. The AN/FQM-
117B is approximately a one ninth scale version of a MiG-27 aircraft has a 1.7 meter
wingspan with a 1.87 meter length, and is powered by a 9.83 cc 1.42 kilowatt glow fuel
engine. Glow fuel engines typically burn a mixture of methanol and Castor oil.
Figure 1.1 shows the AN/FQM-117B body with the ailerons broken up into eight
separate sections per side. The independent aileron surfaces were added to gain more
control over the aerodynamics of the plane and to improve fuel efficiency and
maneuverability [1].

2
Figure 1.1 – The Multi-Segmented Wing of the AN/FQM-117B Aircraft [1]
As the number of control surfaces increase above the standard four (aileron,
elevator, throttle, and rudder), it becomes difficult for one pilot to control all of them, let
alone effectively. A flight control computer is needed to fly the plane autonomously or to
give some assistance to the pilot to benefit from the extra control surfaces.
The first flight control system used on the FLiC was the MircoPilot MP2000. The
MP2000 is an autopilot system that provides Global Positioning System (GPS)
navigation, altitude hold, and airspeed hold. Autonomous takeoffs and landings are
possible with an onboard ultrasonic sensor. A future goal of the FLiC project is to add
many more control surfaces to further increase the degrees of freedom of the plane. To
prepare for the additional computational resources required to fly the FLiC with extra
control surfaces, a new flight control computer must be designed. The main requirements

3
for this Masters project include allowing for more control surfaces, executing program
code originating in Matlab, and increasing available computing power to facilitate the use
of more complicated flight control algorithms [1].
1.3 Overview
The remaining chapters of this thesis discuss previous research, the search for a
new hardware platform, and the implementation of the flight control computer system.
Chapter 2 covers the history of UAVs, available commercial autopilot systems, other
university projects, and the research on which this project is based. Chapter 3 describes
the hardware platforms investigated during this project. Chapter 4 contains the hardware
architecture of the flight control system and the custom hardware that was developed.
Chapter 5 describes the software designed and used in this project. Chapter 6 gives an
outline of possible improvements and future research and Chapter 7 gives a summary of
the research conducted during this Masters project.

4
CHAPTER 2 Background
2.1 UAV History
This chapter discusses the history of Unmanned Aerial Vehicles (UAV), currently
available commercial autopilot systems, university research, and UAV research
conducted at Virginia Commonwealth University (VCU).
2.1.1 Early UAVs
A UAV is any aircraft that does not have a human occupant. UAVs have been a
part of commercial and military aviation for as long as powered flight itself and have the
distinct advantage of operating in conditions where it is dangerous, expensive, or
otherwise infeasible to send people. Military applications include reconnaissance, rescue
missions, and attacking enemy targets. UAVs are also used to patrol borders and monitor
crops. NASA Langley is using UAVs to test new flight control theories.
Even before the Wright brothers were able to make their first flight, Samuel P.
Langley flew his unmanned, steam-powered aircraft for over a minute. During World
War I, the Army and Navy each funded projects for unmanned attack vehicles. The Navy
approved $200,000 for Elmer Sperry’s Flying Bomb project. Sperry used a pre-existing
seaplane with a control system based on his work in gyroscopes. The goal of the Flying
Bomb project was to direct a 1,000 pound bomb load over a distance of 75 miles. The

5
Army hired Charles F. Kettering to develop the Kettering Bug. The Bug could carry 180
pounds of explosives for 40 miles. When the plane reached it destination, the wings were
jettisoned and the explosives crashed into its target. Neither project was very successful,
so both were canceled [2].
2.1.2 Autopilots
Autopilot systems are a defining part of UAVs because of the requirement to fly
without human occupant. A UAV can be piloted by a person using radio based control
system, but this method requires line of site or a live video feed. An autopilot system can
give assistance to a pilot or allow a UAV to fly without any human input.
Modern autopilot systems provide two main services: stabilization and heading
correction. Stabilization allows the aircraft to fly with a neutral pitch and roll. This
feature is especially helpful for landings and leveling out the aircraft in the event of
turbulence, crosswinds, or a change in center of gravity. Early autopilot systems did not
have reliable heading control because there was no way of knowing exactly where the
aircraft was in relation to a target location. Accurate heading corrections are now possible
with the advent of Global Positioning Systems (GPS).
The first autopilot system for an aircraft was created in 1914 by Lawrence Sperry,
son of inventor Elmer Sperry. Like current systems, Sperry’s stabilizing autopilot used
gyroscopes to detect changes in pitch and roll. To demonstrate the effectiveness of the
autopilot at an international competition, Sperry and his mechanic both stood on the
wings of the plane during the flight, leaving no one at the controls [3].

6
2.1.3 Current UAV Uses
UAVs have recently played a much bigger part in military operations. The MQ-1
Predator drone plane has been used for several years in reconnaissance missions. The
Predator is 8.22 meters long with a wingspan of 14.8 meters. Powerful cameras allow
targets to be observed while the Predator is at 30,000 feet in altitude. A newer version of
the Predator is equipped with two Hellfire missiles, providing a way to attack enemies as
soon as they are identified. The Predator is controlled by a pilot and two operators who
can be located anywhere in the world, removing the risk to pilots in the event of the
aircraft crashing [4].
2.2 Commercial Systems
There are many commercial autopilot systems available for UAVs. The following
section describes four autopilot system intended for small UAVs.
2.2.1 Procerus Technologies: Kestrel 2.2
The Kestrel 2.2 is a small, low-power UAV autopilot system developed by
Procerus Technologies. The Kestrel, shown in Figure 2.1, measures 50.8 millimeters by
34.8 millimeters, weighs 16.7 grams, and draws only 0.77 Watts of power. The Kestrel’s
Inertial Measurement Unit (IMU) is composed of 3-axis rate gyroscopes, 3-axis
accelerometers, and a 2-axis magnetometer. The accelerometers have an operating limit
of 10 G’s. Although it is unlikely that the aircraft will experience 10 G’s during normal
operation, a higher G-Force limit helps to mitigate some of the aircraft’s vibrations.
Absolute and differential pressure sensors are used to measure barometric pressure and

7
aircraft airspeed. Three temperature sensors are used by a 20-point temperature
compensating algorithm to reduce drift in the sensors. A 29 MHz, 8-bit Rabbit 3000
processor with 512 KB of RAM runs the flight control applications. The Kestrel system
can have up to four serial ports. All of the serial controllers and devices mentioned in this
paper use the RS-232 standard. The base system can control four standard radio control
hobby servos, but more servo controllers can be added with an extender board.
The autopilot can automatically fine tune UAV trim characteristics in the air to
stabilize pitch and roll. Trim is the neutral state of the aircraft’s control surfaces and is
usually set to values that will keep the aircraft flying level and at a constant speed. Flight
control systems use the trim values as the starting point for making pitch, roll, or heading
changes.
The Kestrel provides GPS waypoint navigation and autonomous takeoffs and
landings. Telemetry data can be sent in real time to the Virtual Cockpit ground station
using the Commbox wireless communication device.
The Kestrel system is intended for mini and micro UAVs. Procerus Technologies
sells a UAV test platform aircraft that has a wingspan of 48 inches. Suggested uses for
this system include surveillance and reconnaissance. At the time of this paper, the Kestrel
2.2 system costs $5,000 and the Virtual Cockpit ground station with the Commbox
wireless communications device costs $3,000 [5].

8
Figure 2.1 – Procerus Technologies’s Kestrel 2.2 [5]
2.2.2 Cloud Cap Technologies: Piccolo II
The Piccolo II is an autopilot system capable of flying both rotary and fixed wing
aircraft. It is 121.9 millimeters by 61 millimeters by 38.1 millimeters and weighs 233
grams. The system is based on the 32-bit Motorola MPC555 processor, which is
compatible with the PowerPC architecture. The MPC555 runs at 40 MHz and includes a
hardware floating point unit (FPU) and a 4 Hz GPS. The Piccolo II provides pilot
assistance in manual mode, as well as during autonomous takeoffs and landings. The
Piccolo II system is shown in Figure 2.2.
Cloud Cap Technologies offers a ground station that can control up to ten aircraft
and simulators to test flight control configurations. The Piccolo II system has the ability
to log telemetry data in real-time [6].

9
Figure 2.2 – Cloud Cap Technology’s Piccolo II Autopilot System [6]
2.2.3 MicroPilot: MP2028g
MicroPilot has also developed a small UAV autonomous flight control system.
The MP2028g, shown in Figure 2.3, is only 28 grams and is 100 millimeters by 40
millimeters in size. It uses little power drawing only 0.91 Watts, which includes the GPS
receiver and antenna, gyroscope, and sensors. The on-board GPS has a 1 Hz update rate
and MicroPilot’s IMU has a 3-axis accelerometer and a 3-axis rate gyroscope that have
operating limits of 150 degrees per second and 2 G’s.
The MP2028g can control up to 24 servos or relays and supports manually
directed and autonomous flight modes, as well as an integrated radio control override.
The system also supports autonomous runway takeoff, hand launch, bungee launch, and
catapult launch. The internal control loop runs at 30 Hz and telemetry data is sent to the
HORIZON ground station at 5 Hz. The MicroPilot MP2028g system is priced at $5,500

10
with the HORIZON software and at $5,000 for XTENDER, the software development kit
for the MP2028g [7].
Figure 2.3 – The MicroPilot MP2028g Autopilot [7]
2.2.4 Microbotics: Microbot AP
The Microbot AP system is 66.8 millimeters by 53.3 millimeters and weighs 250
grams. This system is powered by a 32-bit M-Core MMC2114 Reduced Instruction Set
Computer (RISC) processor that runs at 33 MHz. The Microbot AP system, shown in
Figure 2.4, has four serial ports, can control up to 30 servos, and has twelve 12-bit analog
inputs for capturing aircraft data, such as fuel level, battery power, altitude, or airspeed.
The Microbot AP also includes a MIDG II INS/GPS. The MIDG II is an Inertial
Navigation System (INS) with GPS. This product was specifically designed for use with
the Microbot AP but can be used with other flight control systems that need an inertial
navigation solution. The MIDG II includes a 3-axis rate gyroscope, 3-axis accelerometer,
3-axis magnetometer, and a 5 Hz GPS [8].

11
Figure 2.4 – The Microbotics Microbot AP System [8]
2.2.5 Commercial System Comparison
Although these four systems provide similar functionality, they have some
significant differences. The Piccolo II and the Microbot AP use a 32-bit processor,
whereas the Kestrel only uses an 8-bit processor. The Kestrel and MP2028g autopilot
systems weigh much less than the Piccolo II and Microbot AP autopilot systems. Not all
of the system information listed below was provided by the manufacturer. Table 2.1
shows a comparison of the four systems.
Table 2.1 – Comparison of Four Commercial UAV Autopilot Systems
Name Piccolo II Kestrel 2.2 MP2028g Microbot AP
Size 121.9 mm x
61 mm
50.8 mm x
34.8 mm
100 mm x
40 mm
66.8 mm x 53.3 mm
Weight 233 g 16.7 g 28 g 250 g
Power
Consumption
N/A 0.77 W 0.91 W 3.3 W
Processor 32-bit
MPC555
With FPU
8-bit Rabbit
3000
N/A 32-bit RISC M-Core
MMC2114
Cost N/A $8,000 $10,500 N/A

12
2.3 Virginia Commonwealth University’s Previous UAV Research
For several years, the Computer Engineering department at Virginia
Commonwealth University has been conducting graduate and undergraduate research in
the field of autonomous vehicle control systems. Present work includes autonomous
ground vehicles, fixed wing aircraft, and rotary wing aircraft. Past and present students
have developed the existing flight control software which is the foundation of this
project. Students have also designed a ground control system that receives real-time
telemetry information from the aircraft, adjusts trim values, and designates GPS based
flight paths while the UAV is in flight.
2.3.1 Flight Control System
The preexisting flight control system, developed by VCU students, was written in
C and originally ran on an Atmel FPSLIC (Field Programmable System Level Integrated
Circuit) device. The FPSLIC includes an AT40K Field Programmable Gate Array
(FPGA) with up to 40,000 gates, 36 KB of SRAM, and an 8-bit AVR RISC
microcontroller core. The AVR processor can calculate 30 Million Instructions Per
Second (MIPS). Atmel provides an integrated software/hardware co-design environment
for system design. Co-verification tools are also included to allow concurrent software
and hardware debugging [9].
The flight control software uses a PID (Proportional-Integral-Derivative) inner
loop at a rate of 20 Hz to continuously reposition the aircraft’s control surfaces. PID is a
controls methodology that uses a feedback loop to correct for deviations from the desired

13
system value. The flight control software sets a target altitude, heading, pitch, and roll
based on the current flight path. The PID loop corrects for differences in the aircraft’s
actual and desired orientation.
The Suzaku-S system was the next hardware platform of the VCU team’s flight
control computer. The Suzaku-S is based on the Spartan-3 FPGA and uses the
MicroBlaze soft-core processor. MicroBlaze is a 32-bit processor that can run an
embedded version of Linux. The flight control software for the Suzaku-S was ported by
the author to the Connex and Suzaku-V platforms.
2.3.2 Ground Control System
The Ground Control System (GCS) was developed by VCU students and provides
a way for a human user to monitor and adjust the aircraft while in flight. The aircraft and
the GCS both have a radio modem that allows data to be transmitted over a distance of
several hundred meters. The GCS software displays telemetry data that is sent from the
aircraft at 4 Hz. This data includes information such as pitch, roll, airspeed, altitude,
control surface positions, and GPS location.
A symbol for the aircraft is superimposed on a satellite image of the current
airfield. GPS waypoints can be added to the satellite image, forming a flight path. Having
the aircraft and waypoints superimposed on the satellite image make it easy to tell if the
aircraft is going in the correct direction and to determine where the aircraft is in relation
to known ground structures.

14
The GCS also gives a way for the user to change the trim values and PID settings
while the aircraft is in flight. The numerical trim values and PID parameters can be
manually changed through the GCS [10].
2.4 Other University Research
In addition to VCU, many other universities have been conducing research related
to UAVs. This section discusses some of these other university based projects.
2.4.1 University of Kentucky: BIG BLUE
The BIG BLUE (Baseline Inflatable-wing Glider, Balloon-Launched Unmanned
Experiment) project at the University of Kentucky is a test bed for UAV systems
intended for Mars missions. This project focuses on a low cost system that can operate at
high altitudes and have long range communication capabilities. To provide a smaller
package for transport to Mars, the BIG BLUE system uses wings that can be inflated and
made rigid at altitude.
The BIG BLUE system is tested by being taken to approximately 100,000 feet in
altitude while attached to a balloon. When the system reaches the desired altitude, the
wings are inflated. The wings are coated with a UV-curable resin that hardens when
exposed to the Sun’s rays. The aircraft is then released from the balloon, navigates back
to the launch location, and lands with the assistance of a parachute.
The flight hardware is broken up into a mission controller, a flight controller, and
a parachute controller. The controllers are connected together using a single I2
C bus and
have access to global data stored in non-volatile Electronically Erasable Programmable

15
Read-Only Memory (EEPROM). Each controller, developed by Silicon Laboratories, has
its own processor that is based on the 8051 architecture. The mission control unit handles
all of the communication with the ground station, collects scientific data from sensors,
and sends instructions to the other two controllers. The flight control unit receives
heading and flight mode changes from the mission controller. Data from the airspeed
sensor, gyroscope, and accelerometer feed into the flight controller’s PID software loop
to keep the aircraft level. The parachute controller unit is responsible for inflating the
aircraft’s wing, operating the on-board cameras, and cutting the parachute cord [11].
Figure 2.5 shows the control system hardware used in the BIG BLUE project.
Figure 2.5 – The BIG BLUE Flight Control System [11]
2.4.2 Pennsylvania State University: Quadrotor Device
Pennsylvania State University created a small rotary wing UAV using a quadrotor
design. The quadrotor, shown in Figure 2.6, has four motors at the ends of a cross frame
extending to the front, rear, left, and right of the vehicle. The left and right motors rotate
clockwise, whereas the front and rear motors rotate counterclockwise. The quadrotor is

16
controlled by changing the speeds of the four motors. Roll is determined by the relative
speed of the left and right motors and pitch is determined by the relative speed of the
front and rear motors. Yaw is determined by the relative speed of the left and right
motors versus the speed of the front and rear motors. The tail rotor of a traditional
helicopter is only used for yaw control and does not provide any lift unlike the quadrotor
design that gets lift from every rotor.
Figure 2.6 – The Quadrotor Aircraft [12]
The quadrotor uses a custom made PIC 18F8720 controller board. The PIC
18F8720, developed by Microchip Technologies, Inc., is an 8-bit microcontroller that has
68 input/output (I/O) pins, 128 KB Flash program memory, 4KB RAM, and has a clock
speed of 25 MHz. The custom controller board has Analog Digital Converters (ADC),
can read radio controller input, and generates Pulse Width Modulation (PWM) signals to
control the rotors. The PIC 18F8720 does not have an operating system but instead runs

17
Embedded C program code directly from memory. The controller board shown in Figure
2.7 is 6.4 centimeters by 10.2 centimeters and weighs 45.4 ounces.
Two Microelectromechanical Systems (MEMS) sensors, a gyroscope, and an
accelerometer are connected to the PIC system. The gyroscope can detect angular
velocities up to 150 degrees per second and updates at 40 Hz. The accelerometer senses
accelerations up to 10 G’s in the perpendicular axes. A small data recorder from Eagle
Tree Systems was added to the quadrotor system to store the pilot input, altitude,
airspeed, and battery life data. Figure 2.7 shows the PIC based controller board [12].
Figure 2.7 – The PIC Based Flight Control System [12]
2.4.3 Georgia Tech: GTMax
Georgia Tech is developing a three vehicle autonomous reconnaissance system
that uses a GTMax helicopter, a GTRover ground vehicle, and a GTSpy ducted fan
aircraft. The three vehicles use a wireless link to communicate with each other while
exploring an unknown territory. One of Georgia Tech’s future goals is to have the
GTMax system control the GTRover and GTSpy vehicles to autonomously explore large

18
areas of uncharted land. The GTMax helicopter will carry the GTRover and GTSpy
vehicle to locations of interest.
The GTMax is built on the Yamaha R-Max helicopter airframe that has a 10.2
foot rotor, a 205 pound maximum gross weight, and a flight endurance of one hour. The
aircraft’s electronic systems are broken into the following exchangeable modules: flight
computer, mission computer, GPS, data link, and IMU. The hardware modules are placed
in a vibration isolated avionics rack located below the aircraft. Figure 2.8 shows the
GTMax avionics rack.
Figure 2.8 – The GTMax Avionics Rack [13]
The primary flight computer has a PC-104 233 MHz processor, 8 serial ports, and
Ethernet. The secondary flight computer uses a PC-104 833 MHz Pentium 4 processor
and a video capture system. Sensors used by the GTMax system include an IMU, a
differential GPS, a magnetometer, and a sonar altimeter. The primary flight computer
runs the guidance, navigation, and control algorithms needed to fly the aircraft. The

19
secondary flight computer is used for experimental flight control algorithms and image
processing software that will identify items of interest autonomously.
The GTSpy is a ducted-fan vehicle that weighs five pounds and only has a flight
time of ten minutes. Because little payload is available on the GTSpy, the FCS20 flight
control system was created. The FCS20 uses a Texas Instruments C6713 FPGA/Digital
Signal Processor (DSP) chip. The FPGA portion of the C6713 handles the I/O operations
and external communications whereas the DSP chip is used for data processing. Figure
2.9 shows the GTSpy vehicle, and Figure 2.10 shows the FCS20 flight control system
[13].
Figure 2.9 – The GTSpy Vehicle [13]

20
Figure 2.10 – The FCS20 Flight Control System [13]
2.4.4 University of Wisconsin – Madison: Aesalon Unmanned Aerial Vehicle
The Aesalon UAV was developed by the University of Wisconsin – Madison to
provide a low-cost system that can accomplish both high and low speed flight during the
same mission. Many surveillance tasks require the monitoring aircraft to reach the area of
interest quickly, but then fly slowly enough to see what is happening on the ground.
The Aesalon UAV, shown in Figure 2.11, is three meters long and has an empty
weight of 70 pounds. The aircraft has a three meter wingspan with the wings fully
extended and wingspan of 2.4 meters when the wings are swept back. A swept wing
design is used to facilitate the change in flight modes. The Aesalon is powered by the 36
pound-foot turbine jet engine. A thrust vectoring system is attached to the engine to
increase control of the vehicle’s pitch.
The flight computer for the Aesalon is a PC-104 system that uses a 400 MHz
processor and 128 MB of RAM. Data is stored on a 1 GB Compact Flash card. In
addition to the processor board, the flight computer stack also has a digital I/O board, a

21
PWM board for controlling the servos, and a GPS board. Sensors detecting pitch, roll,
yaw, airspeed, and altitude are used to support autonomous flight if the connection with
the ground station pilot is lost [14].
Figure 2.11 – The Aesalon UAV Flight Computer [14]
2.4.5 Purdue University: Real-Time Java Flight Control System
Purdue University and Boeing Company partnered to develop a real-time Java
virtual machine called the Ovm. This virtual machine is an application programming
interface based on the Real-Time Specification for Java (RTSJ). The Ovm virtual
machine provides real-time thread and scheduler support, timers, asynchronous event
handler support, memory management, and ahead of time compiling.
All of the threads running in the Ovm share the same process on the underlying
operating system allowing the Ovm to control all of the scheduling of the real-time Linux
software. The entire Ovm virtual machine can still stall because of blocking calls in
external processes. The Ovm I/O subsystem overcomes this problem by restricting the
operating system to the non-blocking and asynchronous system calls. The Ovm allows

22
hard-time, soft-time, and non-real time code to interoperate in the same computing
environment. Engineers can use standard Java components to get the benefit of
programming in a type-safe language.
All of the flight tests with RTSJ based system used the ScanEagle UAV. The
ScanEagle UAV is a low-cost, long-endurance aircraft developed by Boeing and the
Insitu Group. The ScanEagle UAV’s flight control system has a PowerPC 8260 processor
with a clock speed of 300MHz, 256 MB of SDRAM, 32 MB of Flash, and uses the
Embedded Linux operating system [15].

23
CHAPTER 3 Hardware Platforms
3.1. Requirements
The main goal of this Masters project is to develop a new embedded flight control
system that has more computing power than the existing system. The flight control
computer will use the Linux operating system to aid in software development and
debugging, and the flight control software will be written in the C programming
language.
3.2 Investigating Potential Platforms
Before the flight control system could be implemented, a hardware platform
needed to be selected. Two proposed systems were the Atmark Techno Suzaku-V and the
Gumstix Connex 400 XM. Atmark Techno and Gumstix are companies that develop
embedded computer systems. The flight control computer was implemented using both
systems because it was not clear which would be a better hardware platform for the FLiC.
This chapter describes the Atmark Techno Suzaku-V and Gumstix Connex 400 XM
platforms in detail.

24
3.2.1 Suzaku-V
The Suzaku-V is an embedded Linux device that uses Xilinx’s Virtex-2 Pro
FPGA. Xilinx is a company that designs FPGAs such as the Spartan-3, Virtex-2 Pro, and
Virtex-4 chips mentioned in this paper. In addition to having programmable logic, the
Virtex-2 Pro also has an IBM PowerPC 405 processor. This processor has 32 MB of
DRAM, 8 MB of Flash memory, 10/100 Mbit Ethernet, and runs at 270 MHz. The
Suzaku-V system is shown in Figure 3.1.
Figure 3.1 – Atmark Techno Suzaku-V System [16]
Atmark Techno provides a custom version of the 2.4 Linux kernel with separate
build trees for the MicroBlaze and PowerPC architectures. Linux for the Suzaku-V, and

25
the applications that run on it, are built with the powerpc-linux-gcc (GCC) 3.3.5 (Debian
1:3.3.5-13) C compiler. The Linux operating system and user applications are stored in
real-only persistent Flash memory. A temporary directory is mapped to RAM so data can
be saved, but this data will be erased when the Suzaku-V system is turned off. New files
and applications that should persist between reboots must be built into the Linux image
that lives in the Flash memory. A special boot mode allows the Linux image to be loaded
on the Suzaku-V using a serial interface [16].
At the beginning of this project, VCU was using the Atmark Techno Suzaku-S
system for a flight control computer. The Suzaku-S has the same form factor as the
Suzaku-V but uses an older Spartan-3 FPGA. The Suzaku-S uses the MicroBlaze soft-
core processor instead of the PowerPC 405 hard-core processor. A soft-core processor is
a programmable processor that is loaded onto an FPGA and can be re-routed to best fit
the FPGA’s current hardware configuration. A hard-core processor is permanently wired
and cannot be changed after being manufactured. Soft-core processors have the
advantage of being more flexible than hard-core processors but tend to use up more space
and run slower. The Suzaku-S uses a MicroBlaze soft-core processor, which runs at 50
MHz.
The Suzaku-V system was investigated as a new flight computer hardware
platform because it has the same form factor as the Suzaku-S but uses a much faster
processor. To make it easier to connect a Suzaku board to external devices, the EX
expansion board was created.

26
EX Expansion Board
The EX expansion board, shown in Figure 3.2, was created by VCU students to
add needed functionality to a Suzaku system. The following devices are present on the
EX expansion board:
• Power regulator to drop the 12V flight battery voltage to the 3.3V used by
the Suzaku board
• Barometer sensor for altitude
• Air speed sensor
• Two serial (RS-232) level shifters
• Serial Peripheral Interface (SPI)
Keeping all of these devices on the same board makes the system more compact
and reduces the amount of external wiring. Because the Suzaku-S and Suzaku-V have the
same pin configuration, they both can be used with the EX expansion board. The Suzaku
systems plug directly into the EX board using header pins.

27
Figure 3.2 – Suzaku-V System Connected to the EX Board
3.2.2 GumStix Connecx 400 XM
The Connex 400 XM, developed by Gumstix Incorporated, is an embedded Linux
device that features Intel’s XScale PXA255 400 MHz processor. The XScale chips are
based on the ARM RISC architecture. The Connex system has 64 MB of SDRAM, 16
MB of Flash memory, a 90-pin Hirose connector, and a 62-pin Hirose connector.
Gumstix makes many expansion boards that can be attached to the Connex board
for added functionality. Table 3.1 shows some of the expansion boards that can be used
with the Connex system.

28
Table 3.1 – Expansion Boards for the Connex System
Device Function Connector Type
Cfstix Provides access the Compact Flash memory 92-pin Hirose
GPSstix GPS receiver 60-pin Hirose
Wifistix 802.11b/g wireless 92-pin Hirose
Robostix Up to 6 PWM output channels at 5 Volts 60-pin Hirose
Waysmall Two serial ports and USB client 60-pin Hirose
Etherstix 10/100 Mb Ethernet 92-pin Hirose
Because the flight control system needs serial devices and Ethernet, the Waysmall
and Etherstix expansion boards were chosen. The Connex board, shown in Figure 3.3,
does not have a normal power input and relies on the power input present on one of the
expansion boards. Future references to Connex will refer to the Connex XM 400 board
with the Etherstix and Waysmall expansion boards attached. The Connex XM 400 board
with the Etherstix expansion board is shown in Figure 3.4.
Figure 3.3 – Gumstix Connex 400 XM Board [17]

29
Figure 3.4 – Gumstix Connex 400 XM with the Etherstix Expansion Board [17]
Gumstix ships its systems with a customized version of the 2.6 Linux kernel. The
arm-linux-gcc (GCC) 3.4.5 C compiler is used to build the Linux image and the flight
control application. The Linux file system and user applications are stored in read-write
persistent Flash memory so changes to files remain even after the Connex is turned off
[17].
Connex with the Spartan-3 FPGA
The Connex does not have an onboard FPGA and must be connected to an external one.
A Spartan-3 FPGA prototype board made by Digilent was connected to the Connex board
using a ribbon cable. Because only fifteen general purpose I/O pins were made available
through the Waysmall board, a simple bus protocol was developed to share data between
the Gumstix and the Spartan-3 FPGA. Figure 3.5 shows the Spartan-3 prototype board
with the Gumstix boards.

30
Figure 3.5 – Spartan-3 Prototype Board with the Gumstix Connex XM 400
3.3 System Comparisons
The Connex 400 XM and Suzaku-V systems were compared to determine which best
fit the requirements of the FLiC project. The following features were used to compare the
two systems:
• Computing power
• Size and power consumption
• Ease of development
• FPGA
• FPGA interface
• Physical properties

31
3.3.1 Computing Power
A major motivation for not using the more familiar Suzaku-S system was the need
for additional computing power. The MicroBlaze core that runs on the Suzaku-S has a
maximum clock speed of 50 MHz, whereas the Connex 400 XM and Suzaku-V have core
clock speeds of 400 MHz and 270 MHz, respectively. The LINPACK and Dhrystone
benchmarks were used to compare computing power between these systems.
LINPACK
The LINPACK benchmark solves a large system of linear equations using
floating point numbers. Results from the benchmark are in millions of floating point
operations per second (MFLOPS). The benchmark was run with single and double
precision floating point numbers. Single floating point numbers are 32-bit and are
accurate to about 6 decimal digits, and double floating point numbers are 64-bit and are
accurate to about 15 decimal digits. Double floating point variables can also hold
numbers with much larger absolute values than single floating point variables. Floating
point numbers are used in mathematical calculations where fractional values are required.
Calculations done on floating point numbers take significantly longer than the same
calculations done on integer numbers. Table 3.2 contains the results of the LINPACK
benchmark [18].

32
Table 3.2 – LINPACK Benchmark Results
LINPACK Performance Single Precision
Suzaku-V Suzaku-S Connex
MFLOPS 1.038 0.0848 4.061
LINPACK Performance Double Precision
Suzaku-V Suzaku-S Connex
MFLOPS 0.635 0.0418 2.065
Dhrystone 2.1
The Dhrystone benchmark was developed by Reinhold P. Weicker to compare the
effectiveness of different hardware/compiler combinations for system programming
applications. Unlike the LINPACK benchmark, Dhrystone does not use any floating
point math. The Linux operating system does not use any floating point numbers, so the
Dhrystone results can be used to compare how fast Linux will run on different computer
systems. The original benchmark was written in the Ada programming language but was
later ported to C.
Dhrystones per second can be converted to MIPS by dividing by 1,757. The VAX
11/780 computer is a 1 MIPS machine and can run the benchmark at 1,757 Dhrystones
per second. Table 3.3 shows the results of the Dhrystone benchmark [19].
Table 3.3 – Dhrystone Benchmark Results
Suzaku-V Connex
Dhrystones/sec 270270.3 495049.5
Dhrystones MIPS 153.82 281.76

33
Benchmark Comparison
Based on the comparison of both the LINPACK and Dhrystone benchmarks for
each system, the Connex system performed much better than either Suzaku system. This
superiority is most likely attributed to the higher CPU clock rate. The performance
difference may also be affected by architectural differences, memory latency, differences
between kernel versions, and the compiler.
3.3.2 Size and Power Consumption
The Connex and Suzaku-V are both small at 80 millimeters by 20 millimeters and
72 millimeters by 47 millimeters, respectively. As the name suggests, Gumstix’s Connex
is approximately the size of a stick of gum, and the Suzaku-V is a little bit smaller than a
credit card. Although the Connex is very small, it is used with the external Spartan-3
board, which is 145 millimeters by 102 millimeters. The Connex and Spartan-3 boards
will fit in the plane but take up much more space than the Suzaku-V with an EX board.
Both systems use about 1.5 Watts of power, well within the constraints of the project.
3.3.3 Ease of Development
Another major criterion in the selection of an operating system for the flight
control system is the ease of software development. Linux provides drivers, error logs, a
file system, and standard C compilers. Many embedded systems use some Linux variant
as an operating system, and the presence of Linux makes it easier to port applications to
new platforms. The Suzaku-V and Connex systems both include all of the necessary

34
software tools, and a software engineer experienced in Linux easily can develop
applications for these two systems.
The Connex system does have a clear advantage when it comes to documentation
and support. Gumstix has a very active email mailing list that proved to be a good way to
obtain information about the various Gumstix systems and to get assistance with
development problems. The Gumstix website (http://gumstix.com) is frequently updated
with tutorials and device information.
Atmark Techno is a Japanese company and most of its users are not English
speakers. The English e-mail mailing list for the Suzaku-V system is not very active, and
there is much less online documentation. The relative lack of support makes the learning
curve for the Suzaku-V much steeper than for the Connex.
3.3.4 FPGA
The biggest difference between these two systems is their FPGAs. The Suzaku-V
has a built in Virtex-2 Pro FPGA, and the Connex uses an off-board Spatan-3 FPGA
connected via ribbon cable. The advantage of having an external FPGA is that different
ones can be switched in as the requirements of the project change. Unfortunately, an
external FPGA also needs extra space and introduces more electrical connections that can
be jostled loose. In the case of the Connex and Spartan-3, only fifteen bits of data lines
can be connected between the processor and FPGA. Because the Suzaku-V directly maps
memory to the FPGA on the same chip, potentially hundreds of bits of data lines could be
created. Table 3.4 gives a comparison between the Spartan-3 and Virtex-II Pro systems.

35
Table 3.4 – Comparison of the Spartan-3 and Virtex-II Pro FPGAs
Virtex-II Pro Spartan-3
FPGA Version XC2VP4-FG256 XC3S200
Logic Cells 6,768 4,320
Power Consumption 1.5W (FPGA and CPU) > 1W
3.3.5 FPGA Interface
The Linux kernel that was provided by the Gumstix system allows memory
locations to be accessed directory using pointers in the C language flight control
software. This method of access is convenient because it makes reading or writing to
hardware no more complicated than reading or writing to a local variable. One drawback
of using this method is that there is no way to check to see if the requested memory
location is valid. Accessing an invalid memory location may result in the flight control
software crashing.
Unlike the Connex system, the Suzaku-V system does not allow for direct
memory referencing and therefore requires kernel device drivers. Device drivers are the
pieces of code that bridge the gap between user software and the computer’s hardware.
Drivers can be used to control hardware devices like hard drives, printers, or keyboards.
3.3.6 Physical Properties
The Suzaku-V system is much more physically stable than the Connex. The
Suzaku-V attaches securely to the EX board and is at no risk of detaching under normal
flight conditions. The Connex based flight control system is at a much higher risk of
physical separation because it is composed of three circuit boards and an external FPGA.

36
The Connex is connected to the Etherstix and Waysmall boards by the 60-pin and 92-pin
Hirose connectors. It takes very little force to disconnect the Hirose connectors and
without extra stability, separation during flight is a likely scenario. Gumstix has added
several mounting holes on each Connex board to allow screws to stabilize the boards. At
the start of the project, no such screws could be purchased from Gumstix, so third party
parts had to be used. Although the correct size screws could be found, they were not a
perfect fit for the board. Not all of the holes lined up through all of the boards, thus only
two screws could be used. Non-conductive nuts had to be placed between the boards to
keep the middle board from shifting. Because of the location and size of the mounting
holes, it was impractical to mount the Gumstix boards directly to the aircraft, making it
even harder to stabilize the flight control system. After the Connex board was tested,
Gumstix began selling mounting hardware which may be more effective than what was
used for this project. Figure 3.6 shows the Connex XM system with the Etherstix and
Waysmall expansion boards.
Figure 3.6 – Connex 400 XM with the Etherstix and Waysmall Expansion
Boards

37
3.4 Suzaku-V Chosen as Final System
After investigating both systems, the Suzaku-V system was chosen as the
hardware platform for this project. The deciding factor in choosing a system was physical
stability. Although the Connex was easier to program, had better manufacturer support,
and had more computing the power, it was not stable enough to be a reliable flight
control computer. The Connex board could be easily separated and creates a great risk of
the flight control system malfunctioning during flight. The lack of an integrated FPGA
also made the Connex a less desirable hardware platform.
The Suzaku-V system was a good hardware platform for the FLiC not only
because of good physical stability but also because of features of the FPGA. The Virtex-2
Pro has more available programmable logic than the Spartan-3. This extra logic allows
for more custom hardware in the future and more serial controllers for more sensors.
Extra I/O pins make the Suzaku-V more scalable than the Connex. Table 3.5 shows a
hardware comparison of the Connex 400 XM and Suzaku-V systems.
Table 3.5 – Hardware Comparison of the Connex 400 XM and Suzaku-V Systems
Connex 400 XM Suzaku-V
CPU Type Intel PXA255 IBM PPC405
CPU Speed 400 MHz 270 MHz
I/O Pins 15 70
DRAM 64 MB 32 MB
Flash 16 MB 8 MB
Power Consumption 1.25 W 1.5 W
Ethernet 10/100 Mb 10/100 Mb
Linux Version 2.6 2.4

38
CHAPTER 4 Flight Control System Architecture
This chapter describes the layout of the UAV, the sensors used to fly the aircraft,
and the hardware designed for this project.
4.1 Layout of the UAV
The UAV electronics include the Suzaku-V and EX boards, sensors, radio control
receivers, an optical isolator, a safety switch, and servos. Figure 4.1 is the wiring diagram
of the UAV.

39
Figure 4.1 – Wiring Diagram of the UAV
As Figure 4.1 shows, the servos are controlled by the output of the safety switch.
The safety switch is used to allow a human pilot to switch between manual and
autonomous flight while the aircraft is in the air. The aircraft can take off or land
manually and still conduct autonomous tasks during the same flight. A human pilot can
also take over the plane in case there is a problem with the autonomous flight control
system. The radio controller receiver reads five channels, one for the each control surface
and one to determine whether the manual or autonomous signals are to be outputted from
the safety switch.
While the flight control system was being tested, it was discovered that if the
FPGA connected to the safety switch was not powered, the signal coming from the radio

40
controller to the safety switch could be corrupted. The corrupted signal could cause a
dangerous situation because if that FPGA lost power, the ground pilot would be unable to
take control of the aircraft. An optical isolator was added between the radio control
receiver and the safety switch to mitigate this problem. Figure 4.2 shows the flight
control system electronics used in the aircraft.

41
Figure 4.2 – Complete Flight Control System in the Aircraft
4.1.1 Airframe
Like the airframe used by NASA’s FLiC, VCU’s aircraft uses a surplus FQM-
117B MIG-27 Army target drone. The FQM-117B has a wingspan of 1.68 meters and is
made of foam core. Futaba hobby servos were added the aircraft to move the four control
surfaces: aileron, elevator, throttle, and rudder.

42
4.1.2 Radio Control Hardware
A Futaba hobby radio receiver was placed in the aircraft to allow a person on the
ground to pilot the vehicle using a corresponding controller.
4.2 Sensors
The flight control system relies on several sensors to determine the current
location of the plane, air speed, altitude and pitch, roll, and yaw angles.
4.2.1 Crossbow IMU
The original VCU flight control system used the Co-Pilot sensor from FMA
Direct to determine pitch and roll. The Co-Pilot works by comparing the infrared
signature between the Earth and the carbon dioxide in the atmosphere to calculate the
aircraft’s pitch and roll in respect to the ground [19]. The Co-Pilot unit was replaced with
the Crossbow AHRS400-200 to get more accurate angle sensing with less dependency on
weather conditions.
The Crossbow uses MEMS accelerometers to calculate pitch, roll, and yaw at
rates up to plus or minus 200 degrees per second and accelerations up to 4 G’s. A serial
interface is used to connect the Crossbow to the EX board. The Crossbow unit uses less
than 3 Watts of power at 12 Volts, weighs 640 grams, and is 76.2 millimeters by 95.3
millimeters by 81.3 millimeters in size [20]. Figure 4.3 shows the Crossbow IMU.

43
Figure 4.3 – The Crossbow IMU [20]
The Crossbow will stop outputting angle data for several seconds if the unit
rotates faster than 200 degrees per second. This constraint makes minimizing engine
vibration very important. The Crossbow was padded with foam to isolate engine
vibration before the unit was bolted to the plane. Normal operation of the aircraft has not
exceeded the 200 degrees per second limit.
The Crossbow IMU is accessed by the flight control software using one of the
serial ports on the Suzaku-V system. The Crossbow unit must be configured before the
flight control software can read its data. First an ‘R’ ASCII character is sent to the
Crossbow to verify the serial connection. If the connection is present, an ‘H’ character is
returned. The Crossbow can send data in angle, scaled, or voltage modes but the flight
control software only uses angle mode data. The flight control system sends an ‘a’
character to the Crossbow to set the angle mode. The Crossbow returns an ‘A’ character
to the flight control system if the angle mode was successfully set. Sending a ‘G’
character to the Crossbow will cause the Crossbow to return a data packet that contains

44
the angle information of the aircraft. A thread in the flight control software sends the ‘G’
character every 50 milliseconds. Table 4.1 shows the data packet format used by the
Crossbow.
Table 4.1 – Format of the Crossbow Data Packets in Angle Mode [20]
Byte Data Element Description
0 Header (255)
1 Roll Angle (MSB)
2 Roll Angle (LSB)
3 Pitch Angle (MSB)
4 Pitch Angle (LSB)
5 Heading Angle (MSB)
6 Heading Angle (LSB)
7 Roll Angular Rate (MSB)
8 Roll Angular Rate (LSB)
9 Pitch Angular Rate (MSB)
10 Pitch Angular Rate (LSB)
11 Yaw Angular Rate (MSB)
12 Yaw Angular Rate (LSB)
13 X-Axis Acceleration (MSB)
14 X-Axis Acceleration (LSB)
15 Y-Axis Acceleration (MSB)
16 Y-Axis Acceleration (LSB)
17 Z-Axis Acceleration (MSB)
18 Z-Axis Acceleration (LSB)
19 X-Axis Magnetic Field (MSB)
20 X-Axis Magnetic Field (LSB)
21 Y-Axis Magnetic Field (MSB)
22 Y-Axis Magnetic Field (LSB)
23 Z-Axis Magnetic Field (MSB)
24 Z-Axis Magnetic Field (LSB)
25 Temp Sensor Voltage (MSB)
26 Temp Sensor Voltage (LSB)
27 Time (MSB)
28 Time (LSB)
29 Checksum

45
4.2.2 Airspeed and Altitude
The aircraft’s altitude is calculated using data from Freescale Semiconductor’s
MPX5100AP pressure sensor. Airspeed is determined by the MPX5010DP differential
pressure sensor. Both sensors have analog outputs that are connected to the ADC chip on
the EX board using an SPI bus. The SPI bus allows for multiple channels of ADC data to
be transmitted to the Suzaku-V board using the same wires, saving space on the EX
board.
The SPI chip can connect to up to eight ADC devices. This project only uses two
ADC devices, so only the first two channels are sampled. The first channel is connected
to the altitude sensor, and the second channel is connected to the airspeed sensor.
The code in the Adc_driver.c file, found in Appendix A, shows how the SPI driver is
accessed from the flight control software.
4.2.3 UBlox GPS
The flight control system uses an UBlox GPS to determine the location of the
aircraft, allowing the aircraft to use GPS-based waypoints for flying missions. The GPS
location is read by the flight control software four times a second. The gps_comm.c file,
found in Appendix A, contains the code used to communicate with the GPS.
4.3 Intellectual Property Cores
Xilinx, developer of the Virtex-2 Pro and Spartan-3 FPGAs, has produced two
software applications that were used in developing hardware for this project: Integrated

46
Software Environment (ISE) and Embedded Development Kit (EDK). The ISE was used
for general FPGA design. It specifies which internal signals correspond to which external
I/O pins and creates the data file used to program the FPGA. It also can interface with
third-party simulation software for hardware verification and debugging. The EDK
program was used to load Intellectual Property (IP) cores, the system interfacing code,
and custom logic that were loaded on the Suzaku-V system. ISE and EDK project files
are included with the Suzaku-V system.
An IP core is a logic design that implements some reusable functionality.
Examples of IP cores include a serial controller, an Ethernet controller, DSP designs, and
math co-processors. The EDK provides many IP cores that can be added to a Suzaku-V
system. Some of the included IP cores used in this project include Ethernet, a serial
controller, and a memory controller.
4.4 Virtex-2 Pro FPGA Architecture
The Virtex-2 Pro chip on the Suzaku-V system is broken up into two main
sections: the FPGA and the PowerPC processor. These two parts and any additional IP
cores used in the system are connected with the CoreConnect architecture.
CoreConnect was developed by IBM and is an on-chip bus-communications link
that enables chip cores from multiple sources to be interconnected. The Processor Local
Bus (PLB) and On-chip Peripheral Bus (OPB), part of the CoreConnect system, connect
components in the Virtex-2 Pro chip. The PowerPC core uses the OPB bus to access low

47
speed and low performance system resources, whereas the PLB bus accesses high speed
and high performance system resources [21].
Figure 4.4 – Block Diagram of the Virtex-2 Pro Interconnect [22]
As shown in Figure 4.4, the Virtex-2 Pro components are connected using the
PLB and OPB busses. Slow resources such as Ethernet and serial controllers are
connected to the OPB bus, whereas fast memory resources are connected to the PLB bus.
Unlike the PLB bus, the OPB bus is not directly connected to the PowerPC core. OPB
devices must be bridged to the PLB bus to have access to the PowerPC core. The
PLB2OPB_BRIDGE allows data to be sent from the PLB bus to the OPB bus and the
OPB2PLB_BRIDGE allows data to be sent from the OPB bus to the PLB bus [22].

48
4.5 Pulse Width Modulation Core Design
An IP core was created to contain all of the logic required to read Pulse Width
Modulation (PWM) signals from the radio control receiver and to send PWM signals to
the aircraft’s servos. The following section describes the design of the PWM IP core.
4.5.1 Servo Control
The servos used for this project are controlled using Pulse Width Modulation
(PWM). Pulse Width Modulation encodes data into a series of electronic pulses. Each
pulse is a continuous logic high value between 1 millisecond to 2 milliseconds in length.
The pulse width is directly proportional to the position of the corresponding control
surface. For example, a 2 millisecond pulse on the throttle channel would fully open the
choke, a 1.5 millisecond pulse would result in the choke being half open, and a 1
millisecond pulse would close the choke. A new pulse is started every 20 milliseconds.
Reading a PWM signal is done by reversing the generation process. A counter is
set to zero and is incremented once for every 10 microseconds that the pulse is high. A
new number is read every 20 milliseconds as a new pulse arrives. The numerical
representation of the PWM signals coming from the radio control receiver are forwarded
to the ground station through the flight control computer.
The flight control software uses an 8-bit integer value to represent the position of
a servo where a value of 100 corresponds to a 1 millisecond pulse and a value of 200
corresponds to a 2 millisecond pulse. Because each integer increment translates to a 10
microsecond increase in the pulse width, the PWM signal generation must be accurate to

49
at least 10 microseconds not to lose accuracy. It is difficult to get this level of timing
accuracy with software running on an operating system, so dedicated hardware was
created in the FPGA to handle to reading and generation of PWM signals.
The PWM IP core is used to read the incoming radio control positions and to
generate PWM signals that will drive the servo motors. Incoming PWM pulses are
converted to integer values that correspond to the duration of the high portion of the
pulse. Each integer value is stored in a register that is part of the PWM core logic. These
registers are byte addressable by the Linux flight control software.
To generate PWM signals that will drive servos, the Linux flight control software
stores integer values in registers in the PWM core. These registers are also memory
mapped and their values correspond to the duration of the high portion of a PWM signal.
Each incoming or outgoing PWM signal line has its own dedicated register space.
4.5.2 Pulse Width Modulation Core Design
The PWM IP core was written in VHDL (Very-high-speed integrated circuit
Hardware Description Language). The core is broken into four parts:
• Clock Divider
• Read PWM
• Write PWM
• User Logic
Clock Divider
The PWM core uses a clock signal with a cycle length of 10 microseconds to
count the width of the incoming PWM signal and to calculate the width of the PWM
signal that will be sent to the servos. The available system clock, named Bus2IP_Clk,

50
runs at 65.3552 MHz. The clock divide circuitry was designed to convert the Bus2IP_Clk
signal to a signal with a cycle length of approximately 10 microseconds. This new clock
signal drives a counter used by the read and write portions of the PWM core. Table 4.2
shows the Clock Divider module interface.
Table 4.2 – FPGA Clock Divider Module Interface
Port Name Direction Type Function
Oldclk In Std_logic Incoming system clock
Newclk Out Std_logic Outgoing divided clock
Read PWM
The Read PWM module reads an incoming PWM signal from the radio controller
and represents the signal high portion as a 12-bit number. The flight control software
currently only uses 8-bits to represent the high portion of the PWM signal, but 12-bits
were used for the PWM core to allow for higher resolution in the future. When the input
makes a low to high transition, a counter starts incrementing once per falling clock edge.
The input clock for this module is the divided clock output from the clock divider. A high
portion of the PWM cycle of 1.5 milliseconds corresponds to 2400 clock ticks. The
counter gets reset to zero on a falling edge of the input PWM signal and starts counting
again on the next PWM rising edge. Table 4.3 shows the core interface of the Read
module.

51
Table 4.3 – FPGA Read Module Interface
Clk In std_logic Clock
Pwm In std_logic Incoming PWM signal to read
Reset In std_logic Active high reset
Value Out std_logic_vector[11:0] 12-bit representation of the PWM
signal
Write PWM
The Write PWM module takes a 12-bit input number and generates a PWM
output signal. The outgoing PWM signal is scaled so that a value of 2400 corresponds to
a high portion of 1.5 milliseconds. The input clock for this module is the divided clock
output from the clock divider. Table 4.4 shows the interface of the Write module.
Table 4.4 – FPGA Write Module Interface
Data In std_logic_vector[11:0] 12-bit value to be converted to
an out going PWM signal
Reset In std_logic Active high reset
uClk In std_logic Divided clock input
Clk In std_logic System clock input
writeEn In std_logic Sets whether the Write module
output should be enabled
Pulse Out std_logic Generated PWM signal
User Logic
The UserLogic.vhd file is provided by the EDK software to interface with the
FPGA code required to use the PowerPC processor with custom IP cores. Five Read
PWM modules and four Write PWM modules are instantiated in the UserLogic.vhd file
to give the PWM functionality to the FPGA. A Clock Divider is also instantiated, and its

52
resulting clock signal is used by all Read PWM and Write PWM modules. Selected code
from the UserLogic.vhd file is found in Appendix B.
4.5.3 Pulse Width Modulation Core Structure
Selected code used in the Virtex-2 Pro FPGA can be found in Appendix C. Figure
4.5 shows the PWM core layout of the flight control system.
Figure 4.5 – PWM Core Layout
The diagram above shows that the PWM core is connected to the SDRAM
through the PLB bus. The PWM core is used to write Radio Control Receiver data to the
SDRAM and to write data from the SDRAM to the servos.

53
4.6 Adding Additional IP Cores
By default, only one serial IP core is part of the stock EDK project, but the flight
control system needs three. To solve this problem, additional serial IP cores were added.
The appropriate signals were mapped to I/O pins on the Suzaku-V board using the top.ucf
configuration file. The top.ucf file, part of the ISE project, is found in Appendix B.
The airspeed and altitude sensors use an SPI chip on the EX expansion board. An
SPI controller IP core must be added to the EDK project for the PowerPC processor to
have access to data from these sensors. The SPI and PWM IP cores were added to the
EDK project in the same way as the serial cores.

54
CHAPTER 5 Software Design
This chapter describes the tools used in this project, how the Linux operating
system was configured, steps taken to port the flight control software to the Suzaku-V
system, and driver design.
5.1 Linux and General Public License (GNU) Tools
Linux is an enticing operating system to use for this project because it is open
source. In order to qualify as an open source application, all source code for the
application or project must be made available. Having access to the source code allows
embedded systems software developers to customize the operating system to better fit the
requirements of their project.
The GNU Project was started to provide a free, open source, Unix-like system.
The GCC program, part of the GNU Project, was used to compile and link the Linux
operating system, device drivers, and flight control code.
5.2 Configuring Linux
Before the Linux shipped with the Suzaku-V system will work with the flight
control software, some kernel options must be changed, access to extra serial devices
must be added, and support for an SPI device must also be enabled.

55
5.2.1 Customizing the Kernel
Like the flight control software, the Linux operating system is compiled with the
GCC compiler. This program uses a file called “Makefile” that specified what files and
settings are needed to create an application. The “make menuconfig” command provides
a graphical interface to change the options listed in the “Makefile” used to compile the
Linux operating system.
To use the PWM device driver, the “Enable loadable module support” and
“Kernel module loader” options must be set and the “Set version information on all
module symbols” must be disabled. These options are found in the “Loadable module
support” menu item. SPI support is added by enabling the “Xilinx SPI” option under
“Character devices”.
5.2.2 Adding Extra Serial Devices
The Linux operating system that comes with the Suzaku-V board is set up to use
one serial device. The flight control system needs three serial devices, so support for two
more devices is required. Serial devices are specified in the xuartlite_g.c file found in the
linux-2.4.x/drivers/char/xilinx_uartlite directory of the Linux build tree. The uartlite_g.c
file is listed in Appendix D of this paper.
The XUartLite_ConfigTable array holds information about the serial devices used
by Linux. To add more serial devices, the element count specified in the braces must be
changed to reflect the new total number of serial devices. For each serial device added to

56
Linux, a new entry must also be added to the XUartLite_ConfigTable array. Each serial
device entry has the following structure, where [NUMBER] is the number of the device:
XPAR_OPB_UARTLITE_[NUMBER]_DEVICE_ID,
XPAR_OPB_UARTLITE_[NUMBER]_BASEADDR,
XPAR_OPB_UARTLITE_[NUMBER]_BAUDRATE,
XPAR_OPB_UARTLITE_[NUMBER]_USE_PARITY,
XPAR_OPB_UARTLITE_[NUMBER]_ODD_PARITY,
XPAR_OPB_UARTLITE_[NUMBER]_DATA_BITS
The xuli_irq array, shown below, is used to map Interrupt Requests, also known
as IRQs, to serial devices used in Linux. Linux uses IRQs to tell which device is raising
an interrupt. The xuli_irq array assigns IRQs numbers to serial devices starting at value
of 31. A unique vector ID is used to give each serial device a different IRQ number. The
vector ID numbers are assigned in the xparameters_suzaku-v.h file found in Appendix D.
The xuli_irq array is found in /linux-2.4.x/drivers/char/xilinx_uartlite/xuartlite_serial.c
file.
static const int xuli_irq[XPAR_XUARTLITE_NUM_INSTANCES] = {
31 - XPAR_INTC_0_UARTLITE_0_VEC_ID,
#ifdef XPAR_OPB_UARTLITE_1_BASEADDR
5.2.3 IP Core Settings
One of the important Linux operating system files that must be changed is
xparameters_suzaku-v.h. This file tells Linux which memory addresses and setting were

57
used with each IP core in the FPGA project. The xparameters_suzaku-v.h file is found in
the linux-2.4.x/arch/ppc/platforms/xilinx_ocp folder in the Linux build tree.
5.3 Using Threads
The original C code that ran on the FPSLIC used interrupt handlers to access the
serial controllers. Interrupt handlers allows the C software to get notifications when
events happen like incoming data or the completion of a system call.
When the flight control system was ported from the FPSLIC to the Suzaku-S and
Suzaku-V systems, the interrupt handling was replaced with blocking I/O and threads.
Threads can only be used on machines that have an operation system that has thread
support, which the FPSLIC does not.
A thread, or a thread of execution, allows a program to be split into multiple parts
that are intended to run pseudo-simultaneously. The operating system allocates an
amount of time that each thread can be run on the CPU. If the time runs out, the thread is
suspended so that the next thread can run. If a thread needs to wait on incoming data, the
thread can suspend itself until the required data arrives, allowing another thread to run
while the suspended thread is waiting. The C language includes code libraries that
provide the thread functionality to programmers.
I/O operations like file reads or writes can be either blocking or non-blocking.
Blocking I/O causes a thread to suspend when there is a pending I/O request. Suspending
one thread lets other threads or processes run while the blocked thread is waiting for an

58
event. Non-blocking I/O causes the thread to not give up the CPU while waiting for an
I/O operation to finish.
Threads are available in the Linux versions employed by the embedded systems
used in this project. Thread libraries included in Linux make threads easier to use than
interrupt handlers. For this reason, threads were used with the Suzaku-V and Connex
systems in this project.
5.4 Flight Control Loop
The flight control software uses a main thread, serial thread, telemetry thread, and
a control loop thread. The main thread runs the function that executes when the flight
control software starts. The main thread spawns the other threads and queries the
Crossbow unit for new angle data. The serial thread reads data from the three serial
devices. The telemetry thread sends new telemetry packets two times a second, and the
control loop thread does the calculations that are used to direct the aircraft.
The flight control loop thread, shown in Figure 5.1, is forced by a timer to run
once every 50 milliseconds. The system time is recorded at the beginning and the end of
the loop to calculate the time it took for the loop to complete. The resulting time is
subtracted from the 50 milliseconds allotted to an iteration of the loop giving the
remaining time. The flight control loop thread is suspended for the duration of the
remaining time. When the leftover time has passed, the flight control loop is restarted.
The diagram below shows the steps taken in the flight control loop.

59
Figure 5.1 – The Flight Control Loop Thread Functionality
5.5 PWM Driver
To fully utilize the resources available on the Suzaku-V and Connex systems, the
flight control application running on Linux must be able to talk to the FPGA hardware.
For the Suzaku-V system, a Linux device driver was written to give the flight control
software the ability to access the PWM IP core in the FPGA.

60
5.5.1 Hardware Access
The Linux kernel that was provided with the Connex system allows memory
locations to be accessed directly using pointers in the flight control software. This method
of access is convenient because it makes reading or writing to the PWM device no more
complicated than reading or writing to a local variable. One drawback of using this
method is that there is no way to check to see if the requested memory location is valid.
Accessing an invalid memory location may result in the flight control software crashing.
Unlike the Connex system, the Suzaku-V system does not allow for direct
memory de-referencing and requires kernel device drivers. Device drivers are the pieces
of code that bridge the gap between user software and the computer’s hardware. Drivers
can be used to control devices like printers, keyboards, or sound cards.
Code running on a Linux machine can be either in kernel space or user space.
Kernel space consists of the operating system and drivers that need low level access to
the computer’s hardware. User space is intended for applications with which an end user
will directly interact, such as a text editor or a web browser. Linux abstracts its inner
workings and underlying hardware from users to protect the system from potentially
dangerous code. Keeping user programs from accessing memory directly greatly
decreases the chance of an application bug or malicious code crashing the machine,
overwriting protected files, or damaging hardware.
Linux device drivers live in kernel space and therefore have special privileges that
normal user space software does not. These privileges include wider memory access,

61
access to kernel data, and access to hardware devices. Kernel drivers were used in this
project to access the memory mapped IP core that contained the PWM logic.
Like most UNIX based operating systems, Linux treats almost all objects and
devices as files. Drivers are no different and can be accessed by the same system calls
that are used on files. Device drivers let a developer write the code that the system calls
will execute when accessing the driver. This feature allows every driver to have the same
interface to user software and still control pieces of hardware as different as a mouse and
a printer.
5.5.2 PWM Driver Design
The purpose of the PWM driver is to share data between the PWM IP core on the
FPGA and the flight control software running on Linux operating system. Linux drivers,
including this PWM driver, have standard structures. This section describes the design of
the PWM driver. Driver code used in this project was based on examples in book Linux
Device Drivers [23].
Module Variables
Some global variables and defines needed to be accessed by multiple functions in
the FPGA driver. The FPGA_BASE define holds the base memory address of the PWM
IP core that this driver will be controlling. The FPGA_MAX define contains the highest
memory address accessible by the PWM core. The FPGA_DRIVER define specifies the
major number to be used by the driver. Linux uses major numbers to specify which driver
is being used to control a device. The io_base variable is used to point to the memory
addresses used by the PWM core. The MODULE_LICENSE macro is used to specify

62
which license the module falls under. Using a license that is not compatible with the
General Public License (GPL) will result in Linux giving a kernel error message stating
that the kernel is tainted.
file_operations
Each Linux driver has a set of standard functions. The file_operations struct maps
local functions to their generic system call names, giving every driver the same interface
to external code. The only two system calls that can be called on the FPGA driver are the
read and write functions.
fpga_init
All Linux drivers need an init function to get registered with the operating system
and allocate memory. The fpga_init function is called when the driver is loaded and uses
the ioremap function to allocate memory in the range [FPGA_BASE, FPGA_MAX –
FPGA_BASE] to the FPGA driver.
fpga_exit
The fpga_exit function is called when the driver is unloaded. The iounmap
function is used to release the memory allocated to the driver in the fpga_init function.
fpga_read
The flight control software uses the fpga_read function to get the PWM value that
was read from the manual controller. The driver reads this value from the memory
mapped register of the PWM IP core and returns that value to the flight control software.
The fpga_read function has four parameters: struct file *filp, char *buf, size_t count,
loff_t *f_pos. The fpga_read function reads count bytes of data from the PWM core

63
starting at the f_pos position, and the returned data is then stored in the buf array. The filp
parameter is the file pointer used to locate the driver.
fpga_write
The Write function sends a 12-bit value from the flight control software to the
PWM IP core to set the position of a servo. The value from the flight control software is
written to a memory mapped register of the PWM IP core and that value is used to set the
servo position. The fpga_write function takes four parameters: struct file *filp, char *buf,
size_t count, loff_t *f_pos. The fpga_write function writes count bytes of data from the
buf parameter to the PWM core starting at the f_pos position. The filp parameter is the
file pointer used to locate the driver.
5.5.3 Driver Access
Accessing a driver in Linux is very similar to accessing a file. The first step is to
create a file handler by using the Linux system call the open function as shown below.
int fp = open(FPGADEVICE, O_RDWR);
The fp variable is the file pointer to the driver. FPGADEVICE is defined as “/dev/fpga”,
which is the location of the driver in the Linux file system. The O_RDWR flag specifies
that the driver should be opened for reading and writing.
The next step is to read or write a PWM value to the driver. Reading and writing
to the driver is done using the read and write system calls that are part of the Linux
operating system and that are mapped to specific code in the PWM driver. The code used
in this project to read and write the PWM core registers is in adc_driver.c file found in
Appendix A. The PWM driver file is located in Appendix E.

64
5.6 Delay Driver
In addition to the FPGA driver, a Delay driver was also created. The Delay driver
is used to regulate the speed at which the main control loop executes.
5.6.1 Linux Timing
A potential problem with using an operating system to manage the flight control
software is the lack of accurate timing. Linux, like most other operating systems, uses
interrupts to process requests from devices. When events occur in the computer, an
interrupt signal is raised and added to a queue in the operating system. At regular
intervals, Linux checks to see if there is an interrupt in the queue. If an interrupt is
present, Linux takes the necessary steps to process the request or keeps going if there is
no interrupt present.
The system’s timing hardware processes interrupts at a programmed interval. This
interval is hard-coded in the Linux operation system in the linux/param.h file as the HZ
variable. By default, the HZ value is 100 for 2.4 version Linux kernels and 1000 for 2.6
version Linux kernels. The HZ value denotes how many times per second the operating
system will pause to process interrupts. A HZ value of 100 will cause interrupts to be
processed every 10 milliseconds, and an HZ value of 1000 will cause interrupts to be
processed every 1 millisecond.
The Suzaku-V system uses a 2.4 kernel and so the HZ value was 100. To improve
interrupt responsiveness, the HZ value was increased to 1000 for the Suzaku-V system in
the linux/param.h file. Even interrupt latency on the order of 1 millisecond is far higher

65
than the 10 microsecond resolution of the PWM signals used to control the servos,
supporting the case for using FPGAs for PWM access.
Although PWM signals were not directly accessed through Linux based software,
it was important that the servos were updated at a constant rate of 20 Hz. The main flight
control loop is paused for the portion of the allocated 50 milliseconds that is not needed
for calculations. The simplest way to pause the loop is to use the C sleep() function. This
function is bound by the interrupt rate of Linux, now 1000 Hz, so its accuracy is on the
order of 1 millisecond. To improve the loop’s timing accuracy, a new device driver was
created. The new delay driver uses a sleep function that has better accuracy than the
standard sleep function used by C code.
5.6.2 Delay Driver Design
The Delay driver has a similar structure to the PWM driver. In addition to the init,
exit, read, and write functions, the Delay driver uses the ioctl function. The ioctl function
is used to change driver settings.
The Delay driver’s ioctl function has the following parameters: struct inode
*inode, struct file *filp, unsigned long arg, and unsigned int cmd. The flip parameter is a
file pointer that points to the Delay driver in Linux. The arg parameter specifies how
many microseconds the Delay driver should sleep. If the cmd parameter is zero, the
number of clock ticks to sleep is rounded down, otherwise the number of clock ticks to
sleep is rounded up. The inode parameter is not currently used. The Delay driver code,
found in the delay_driver.c file, is listed in Appendix E.

66
5.7 Loading Drivers
The PWM and Delay drivers must be loaded in the Linux operating system before
they can be used. The Linux command insmod is used to load drivers as shown below.
insmod /lib/modules/2.4.27-uc0-suzaku0/kernel/drivers/char/driver.o
insmod /lib/modules/2.4.27-uc0-suzaku0/kernel/drivers/char/delay_driver.o
To ensure that the drivers will be ready to use at all times, the insmod commands shown
above must be run when Linux starts. The file /vendors/AtmarkTechno/SUZAKU-
V/etc/rcdhcpcd-new is run when the system is booted so the insmod commands were
added to this file.

67
CHAPTER 6 Future Work
The following section discusses several areas of this project that can be improved
with future work.
6.1 Real Time OS
Linux provides a well known, easy to use interface for the flight control
application. Preexisting drivers for Ethernet, serial controllers, and SPI greatly decreases
development time and because many embedded systems use some Linux variant it also
makes the flight control software more portable. The major downside of using Linux as
the operating system is that there are no timing guarantees. Linux was designed as a time-
sharing operating system that allows for multiple users to be accessing the machine at the
same time. A real time operating system is tailored to applications that need guaranteed
timing. The standard Linux kernel caps the interrupt rate at around 1500 Hz which limits
the speed that events can be processed. Real time Linux operating systems are designed
to minimize event processing delays or at least provide a known worst case instead of
maximizing throughput. Three available real time Linux operating systems are QNX,
RTLinux, and RTAI [24].

68
6.2 Hardware Floating Point Unit
Floating point performance of the embedded systems used in this project is hurt
by not having an onboard Floating Point Unit (FPU). The FPU uses specialized hardware
to carry out mathematical operations on floating point numbers. Floating point math
requires much more complicated hardware than integer math. Because of the limited
resources of many embedded systems the FPU is often left out. Although the Linux
operating system does not use any floating point instructions, the flight control software
does. When an FPU is not present, floating point operations are emulated with integer
instructions.
One way to add an FPU is to use an IP core. Jidan Al-Eryani has developed a 32-
bit FPU using VHDL that supports add, subtract, multiply, divide, and square root
operations. This core was successfully loaded and tested on the Suzaku-V system.
Unfortunately, the Suzaku-V’s FPGA is not large enough to hold the FPU core and all of
the other required logic for the flight control system. Using an embedded system that has
a larger FPGA such as a Virtex-4 would allow the FPU core to be used. It is possible that
between the execution time in the FPGA and the overhead of going through a Linux
driver the FPU core might be slower than using the software emulation [25].
6.3 Cloud Cap Technologies: Crista Inertial Measurement Unit
The Crista Inertial Measurement Unit is a small three axis inertial sensor that
provides high resolution digital rate and acceleration data through a serial interface. The
Crista unit, shown in Figure 6.1, is only 50.8 millimeters by 38.1 millimeters by 25.4

69
millimeters in size, and weighs 37 grams. The maximum power consumption is 0.715
Watts (0.143 Amps at 5 Volts). The 3-axis gyroscopic rate sensors and accelerometers
have operating limits of 300 degrees per second and 10 G’s respectively. The IMU’s
internal ADC sampling rate is over 1 KHz, and the external serial data rate is over 200
Hz.
Figure 6.1 – The Crista IMU [26]
As Table 6.1 shows, the Crista is much smaller than the Crossbow and also uses
about five percent of the power. In addition to better physical properties, the Crista can
handle a higher angler velocity and G forces [26].
Table 6.1 – Comparison of the Crossbow and Crista IMUs
Weight Power Degrees/second Maximum G Force
Crossbow 640 g 3 W 200 4 G’s
Crista 37 g 0.715 W 300 10 G’s

70
6.4 Other Embedded Platforms
There are many other embedded systems available that were not tested in this
project. Two others systems that may meet the requirements of the FLiC project are
Bluewater System’s Snapper and Xilinx’s Virtex-4 family FPGA devices.
6.4.1 Bluewater System: Snapper
Bluewater Systems has developed an embedded system called Snapper that uses
Intel’s 400 MHz XScale processor with an Altera FPGA on the same board. The Snapper
includes a 4-channel ADC input, 10/100 Mbit Ethernet, SPI, 64 MB of SDRAM, two
serial controllers, and over 123 FPGA I/O pins. The Snapper has dimension of 70
millimeters by 40 millimeters, making it lightly smaller than the Suzaku-V.
The Snapper system incorporates many functions of VCU’s EX expansion board.
Removing the EX board would reduce the complexity of the flight control system and
save space. If the Altera FPGA is large enough for the logic required for this project, the
Snapper system may also be a viable platform for NASA’s flight control applications
[27].
6.4.2 Xilinx Virtex-4 based System
As of May 2006, there is a new version of MicroBlaze that can run on a Virtex-4
FPGA. Xilinx’s Virtex-4 can run the MicroBlaze soft processor at speeds up to 200 MHz
compared to 50 MHz on a Spartan-3 FPGA. With an available hardware FPU, the new
MicroBlaze system may outperform the hard core PowerPC of the Virtex-2 Pro FPGA.

71
Embedded systems using the new Virtex-4 FPGA may be good candidates for next
generation flight control platform.
6.5 Safety
One important aspect of a flight control that was not fully addressed in the project
is safety. Whether or not this flight control system is on a manned aircraft, it is critical
that the vehicle does not crash. A crash may endanger people on the ground and risks
damage to the aircraft itself.
One way to improve the safety of the flight control system is to add redundancy.
A triple modular redundancy (TMR) system could be used to help keep the aircraft
working correctly in case of a hardware or software failure. A TMR system uses three
copies of the original hardware modules and a new voter module. Each original hardware
module, in this case the flight control hardware, generates PWM output to drive the servo
motors. The new voter module takes the three PWM outputs and using majority voting,
chooses the correct output. The winning output is then forwarded to the servo motors.
TMR systems allow for one of the three systems not to work because the two correct
outputs will win the vote. If more than two modules are not working, the voted output
will not be correct. The TMR system assumes that the voter module is perfect because it
is very simple compared to the three modules on which outputs are being voted.
Another way to increase redundancy is to add a single backup flight control
system module with a watchdog. The backup system can be activated when the watchdog
detects that the main system is no longer working. Instead of using a backup system that

72
is the same as the primary system, a simpler backup system could be used that only puts
the aircraft in a safe flight mode. A safe flight mode could be the aircraft flying at a safe
altitude in a large circle giving a ground operator a chance to take control of the aircraft.
The primary flight control system could also be backed up by a commercial flight control
system.
During this project it was discovered that if the flight control system’s FPGA
loses power, the electrical properties of the output pins are unknown. These PWM output
pins and the radio control input are both connected to the safety switch. Because the
safety switch was not buffered, the unpowered FPGA pins can affect the radio control
input values and effectively prevent manual control of the aircraft. Using buffers or
optical isolators on the PWM outputs would prevent the radio control input values from
being corrupted.

sleemanwc_thesis

Recommended

Recommended

More Related Content

Similar to sleemanwc_thesis

Similar to sleemanwc_thesis (20)

sleemanwc_thesis