Architecture Inertial Navigation and Payload Designs For Low-Cost Remote Sensing

Utah State University
DigitalCommons@USU
All Graduate Theses and Dissertations Graduate Studies
5-2010
Architecture, Inertial Navigation, and Payload Designs for Low-

Cost Unmanned Aerial Vehicle-Based Personal Remote Sensing
Calvin Coopmans
Utah State University
Follow this and additional works at: https://digitalcommons.usu.edu/etd
Part of the Electrical and Electronics Commons
Recommended Citation
Coopmans, Calvin, "Architecture, Inertial Navigation, and Payload Designs for Low-Cost Unmanned Aerial
Vehicle-Based Personal Remote Sensing" (2010). All Graduate Theses and Dissertations. 692.
https://digitalcommons.usu.edu/etd/692
This Thesis is brought to you for free and open access by

the Graduate Studies at DigitalCommons@USU. It has
been accepted for inclusion in All Graduate Theses and
Dissertations by an authorized administrator of
DigitalCommons@USU. For more information, please
contact digitalcommons@usu.edu.
ARCHITECTURE, INERTIAL NAVIGATION, AND PAYLOAD DESIGNS FOR
LOW-COST UNMANNED AERIAL VEHICLE-BASED PERSONAL REMOTE
SENSING
by
Calvin Coopmans
A thesis submitted in partial fulfillment

of the requirements for the degree
of
MASTER OF SCIENCE
in
Electrical Engineering
Approved:
Dr. YangQuan Chen Dr. Christopher Winstead

Major Professor Committee Member
Dr. Reyhan Baktur Dr. Byron R. Burnham

Committee Member Dean of Graduate Studies
UTAH STATE UNIVERSITY

Logan, Utah
2010
ii
Copyright © Calvin Coopmans 2010
All Rights Reserved

iii
Abstract
Architecture, Inertial Navigation, and Payload Designs for Low-Cost Unmanned Aerial
Vehicle-Based Personal Remote Sensing
by
Calvin Coopmans, Master of Science
Utah State University, 2010
Major Professor: Dr. YangQuan Chen

Department: Electrical and Computer Engineering
This thesis presents work done towards a Personal Remote Sensing (PRS) system:
small Unmanned Aerial Vehicles (UAVs) with electronic, control, and sensing subsystems.
Based on papers presented to conferences (AutoTestCon2008 and MESA2009), as well as
other work on PRS, multiple levels of engineering are detailed: complex multi-UAV data
flow; attitude estimation filters; real-time microprocessor functionality; and small, mobile
power systems. Wherever possible, Open-Source tools and designs have been used, mod-
ified, or studied, providing excellent cost to performance ratios in most cases. First, the
overall PRS UAV architecture, AggieAir, is presented with a motivating examples (Ghost-
Eye and EagleEye camera payloads). Then, AggieNav, an inertial navigation system for
small UAVs, is detailed, along with information about a Kalman filter for estimation of UAV
navigation, position, and attitude. Finally the Spatial Environment Autonomous Logger
(SEAL), a general-purpose wireless datalogger for small UAV applications, is presented,
with application examples with and without small UAVs. This work represents designs
based on two years of organic small UAV system growth, and provides integrated solutions
to many problems of small UAV communication, sensing, and control.
(118 pages)
iv
To my family; to my friends; and mostly, to my enemies (if any).

v
Acknowledgments
I would like to sincerely thank my advisor, Dr. YangQuan Chen, for his endless sup-
port, ideas, perspectives, and artful encouragement during the last two and a half years.
Thanks to Dr. Chen, I have had—and continue to have—a unique, challenging, and ever-
rewarding career as a graduate student. In the service of my laboratory, the Center for
Self-Organizing and Intelligent Systems (CSOIS), I have been to Las Vegas, NV, for my
first ASME (IDETC08) conference; Salt Lake City, UT, to present my first conference
paper (AutoTestCon08); Boston, MA, for the 2009 Microsoft Imagine Cup competition;
Uganda, Africa, for humanitarian work; San Diego, CA, for my 2nd ASME conference
(where I presented five papers); and Golden, CO, for a nice conference on networked robotics
(NetRob09). Dr. Chen, thank you for turning my master’s degree program into a grand
adventure.
I owe an incalculable debt of gratitude to Dr. Gary Bohannan, who showed me—and
continues to show me—crucial mentorship and guidance. Thank you, Gary.
Dr. Mac McKee, director of the Utah Water Research Laboratory (UWRL), funded
the research in this thesis, and continues to support CSOIS UAVs and my endeavors. Thank
you, Mac.
In the summer of 2009 I spent a month in Uganda helping orphans and having the
biggest adventure (thus far) of my life with Dr. Roger Hansen of the Utah Bureau of
Reclamation. This trip irrevocably and wonderfully changed my life for the better. Thank
you, Roger.
I would also like to thank the Utah State University Electrical and Computer Engi-
neering Department, as well as Utah State University itself, for the utmost commitment to
the students even in these desperate economic times.
Many people at USU have brought joy and education to me. Among them, I would like
to thank my committee members, Drs. Winstead and Baktur, for not only agreeing to be
part of my thesis committee, but also for following through. I would like to thank Yiding
vi
Han for his dependability in intellectual partnership, Daniel Stuart for his dependability
in general, Christophe Tricaud for being a constant source of cheer and sarcasm, Shayok
Mukhopadhyay for his wonderfully unique style (and for teaching me to eat Indian food
properly), and all the members of CSOIS for being excellent scholars and generally buena
gente.
Several people who helped me arrive deserve thanking: Thanks to Dr. David Klumpar
of the Montana State University Space Science and Engineering Lab (SSEL) for providing
me with the tools, environment, and employment to learn real engineering skills. Thanks
to Dr. Joe Shaw and Dr. Bob Gunderson (formally of CSOIS) from the MSU Electrical
and Computer Engineering Department for their support by way of writing me letters of
recommendation and for their assistance and guidance in applying to the graduate program.
Lastly, Dr. Todd Moon of the USU ECE Department was kind enough to believe in
me, and for his crucial support of my acceptance into the graduate program I am most
grateful. Thank you, Mary Lee Anderson, ECE graduate advisor and department secretary
extraordinaire, for always keeping me on track, from drowning in a sea of paperwork, and
for your attention to the text and formatting during the editing of this thesis.
Calvin Coopmans
vii
Contents
Page
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Personal Remote Sensing . . . . . . ..... .... .... . .... .... .... . .... .. 3
2.1 Sensing at a Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Personal Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 PRS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Thesis Contributions to PRS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 AggieAir: An Integrated and Effective Small Multi-UAV Command, Con-
trol, and Data Collection Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 2.4GHz Wi-Fi Communication Link . . . . . . . . . . . . . . . . . . . . . . 12
3.4 JAUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Coven-Ready Multi-UAV Capabilities . . . . . . . . . . . . . . . . . . . . . 15
3.6 rsync for Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 AggiePilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8 Gumstix Embedded Computer System . . . . . . . . . . . . . . . . . . . . . 19
3.9 AggieNav Navigation Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.10 Example Payload 1: GhostFoto . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.11 Example Payload 2: EagleEye . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.12 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 AggieNav: AggieAir Inertial Measurement and Navigation Design . ... 26
4.1 UAV Flight Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Low-Cost UAV Navigation Solutions and AggieNav Comparison . . . . . . 28
4.3 Enter AggieNav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 AggieNav Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
viii
4.4.1 Inertial Measurement Unit . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.2 Magnetic Compass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.3 GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.4 Pressure Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 Power System and Temperature . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 Microprocessor and Embedded Software . . . . . . . . . . . . . . . . . . . . 36
4.7 The Gumstix Processor and AggieNav Extended Kalman Filter . . . . . . . 39
4.8 Software Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5 Design and Implementation of Sensing and Estimation Software in Ag-
gieNav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1 UAV Attitude Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Attitude Representation . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.2 Implementation of an Extended Kalman Filter (EKF) . . . . . . . . 44
5.1.3 Attitude Estimation using EKF . . . . . . . . . . . . . . . . . . . . . 45
5.2 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Raw Sensor Data Comparison . . . . . . . . . . . . . . . . . . . . . . 47
5.2.2 Preliminary Results for Attitude Estimation using Kalman Filter . . 50
5.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 A Generic UAV Payload: Modular Design . . . .... . .... .... ..... ... 52
6.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 SEAL Design Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.1 Power System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.2 SEAL Sensor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.3 GPS Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.4 Data Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.5 USB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.6 Optional Wi-Fi Interface . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.7 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.4 Sensor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.6 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6.1 UAVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6.2 Fleet Vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ix
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix A Lessons Learned During Design and Implementation of AggieNav
and SEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.1 System-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.2 Embedded Hardware Development . . . . . . . . . . . . . . . . . . . . . . . 76
A.3 Embedded Software Development . . . . . . . . . . . . . . . . . . . . . . . . 77
A.4 SEAL Development Narrative . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.5 AggieNav Development Narrative . . . . . . . . . . . . . . . . . . . . . . . . 79
A.6 Lessons Learned Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Appendix B AggieNav V1.2 Electronic Schematics . . . . . . . . . . . . . . . . 82
Appendix C AggieNav V1.2 Printed Circuit Board Layout . . . . . . . . . . . 87
Appendix D SEAL V.2 Electronic Schematics . . . . . . . . . . . . . . . . . . 93
Appendix E SEAL V.2 Printed Circuit Board Layout . . . . . . . . . . . . . . 98
x
List of Tables
Table Page
4.1 AggieNav versus other small INS solutions. . . . . . . . . . . . . . . . . . . 29
4.2 AggieNav power, mass, and cost budget. . . . . . . . . . . . . . . . . . . . . 38
6.1 SEAL R2 power and mass budget. . . . . . . . . . . . . . . . . . . . . . . . 55

xi
List of Figures
Figure Page
2.1 Passive remote sensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Active remote sensing requires some kind of stimulation to reveal the desired
data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Complete Google search results for “personal remote sensing” (April 5th, 2010). 6
2.4 The Estes Eagleye remote control toy. Image copyright Amazon.com. . . . . 7
2.5 The Spygear ATV-360. Image copyright Toy Store Inc. . . . . . . . . . . . . 7
2.6 The WowWee Rovio telepresence robot. Image copyright Thinkgeek Inc. . . 8
3.1 AggieAir Aero-team block diagram. . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 AggieAir detailed system architecture. . . . . . . . . . . . . . . . . . . . . . 12
3.3 AggieAir system complexity changes depending on mission requirements. . 13
3.4 Ubiquity Bullet2-HP modified for small UAV flight with 5.5dBi antenna. . . 14
3.5 Wi-Fi groundstation: 14dBi, 160◦ horizontal sectorial antenna with Bullet2-HP. 15
3.6 Gain pattern of sectorial antenna. . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 rsync data collection script flowchart. . . . . . . . . . . . . . . . . . . . . . 18
3.8 Paparazzi TWOG board: a fully autonomous autopilot system. . . . . . . . 18
3.9 Gumstix Overo computer-on-module, between a US Quarter coin, an actual

stick of chewing gum, and the Gumstix Tobi board. . . . . . . . . . . . . . 20
3.10 Ghostfoto CCD camera: modified Canon Powershot SX100-IS. . . . . . . . 22
3.11 AggieAir GhostFoto data flow. . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.12 Aerial image and orthorectified image. . . . . . . . . . . . . . . . . . . . . . 24
3.13 Logitech, Inc. Quickcam Orbit autofocus pan-tilt camera. . . . . . . . . . . 25
4.1 AggieNav hardware block diagram. . . . . . . . . . . . . . . . . . . . . . . . 30

xii
4.2 AggieNav internal data connection diagram. . . . . . . . . . . . . . . . . . . 31
4.3 6-DoF IMU: Analog Devices ADIS16354. . . . . . . . . . . . . . . . . . . . 32
4.4 ADIS1635X block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 IMU data before and during takeoff from 111609 flight. . . . . . . . . . . . 33
4.6 Honeywell HMC6343 magnetic compass with tilt-compensation. . . . . . . . 34
4.7 Sample of magnetic compass data from 111609 flight. . . . . . . . . . . . . 34
4.8 AggieNav prototype with Gumstix and GPS unit. Mass as pictured: 70g. . 35
4.9 GPS flight log from 111609, plotted in Google Earth. . . . . . . . . . . . . . 36
4.10 VTi SCP-1000 pressure sensors. . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.11 Selected pressure data from the 111609 flight. . . . . . . . . . . . . . . . . . 37
4.12 AVR32 processor core diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.13 AggieNav main data collection flowchart. . . . . . . . . . . . . . . . . . . . 42
4.14 AggieNav EKF failover diagram. . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 Gyro sensor comparison: p. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Gyro sensor comparison: q. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 Gyro sensor comparison: r. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Acceleration sensor comparison: x. . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 Acceleration sensor comparison: y. . . . . . . . . . . . . . . . . . . . . . . . 49
5.6 Acceleration sensor comparison: z. . . . . . . . . . . . . . . . . . . . . . . . 49
5.7 Roll angle estimation comparison using the AggieNav EKF. . . . . . . . . . 50
5.8 Pitch angle estimation comparison using the AggieNav EKF. . . . . . . . . 51
6.1 SEAL Revision 0 prototype hardware. Includes several sensors, a Secure

Digital memory card slot, and a GPS unit. . . . . . . . . . . . . . . . . . . 53
6.2 SEAL Revision 1 hardware with sensors and Wi-Fi. This package weighs
114g (light enough for a small aircraft payload) and has 8+ hours of run time. 54
6.3 SEAL system diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xiii
6.4 SEAL power diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5 SEAL power distribution diagram. . . . . . . . . . . . . . . . . . . . . . . . 57
6.6 SEAL sample GPX log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.7 Plot of uncalibrated CO2 vs. location via GPSVisualizer. . . . . . . . . . . 61
6.8 Plot of uncalibrated NH3 vs. location via GPSVisualizer. . . . . . . . . . . 62
6.9 Location data from fig. 6.7 and 6.8 plotted in Google Earth. . . . . . . . . . 63
6.10 UAV monitoring cattle in a remote location. . . . . . . . . . . . . . . . . . . 64
6.11 UAV returning to Wi-Fi base station for high-speed data downlink. . . . . . 64
A.1 SEAL Revision 2 hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

xiv
Acronyms
ASIC Application-Specific Integrated Circuit
AUVSI Association for Unmanned Vehicle Systems International
CCD Charge-Coupled Device
CO2 Carbon Dioxide
CPU Central Processing Unit
CSOIS Center for Self-Organizing and Intelligent Systems
DCM Direction Cosine Matrix
DDR Double Data Rate
DFU Device Firmware Upgrade
DoF Degrees of Freedom
EEPROM Electrically Erasable Programmable Read-Only Memory
GPIO General Purpose Input/Output
GPS Global Positioning System
GPX GPS EXchange format
ICE In Circuit Debugging
IIC, I2C Inter-Integrated Circuit Standard
IMU Inertial Measurement Unit
INS Inertial Navigation System
JAUS Joint Architecture for Unmanned Systems
JTAG Joint Test Action Group (IEEE 1149.1 Standard Test Access Port and
Boundary-Scan Architecture)
LED Light Emitting Diode
Li-Poly Lithium-Ion Polymer
LIDAR LIght Detection And Ranging

xv
LNA Low Noise Amplifier
MEMS MicroElectroMechanical Systems
MIPS Millions of Instructions Per Second
MSD Mass Storage Device
NDVI Normalized Difference Vegetation Index
NH3 Ammonia
OBS Ocean Bottom Seismometers
OSS Open Source Source Software
OTG On The Go
PCB Printed Circuit Board
PRS Personal Remote Sensing
PWM Pulse Width Modulation
RADAR RAdio Detection And Ranging
RAM Random Access Memory
SEAL Spatial Environmental Autonomous Logger
SPI Serial Peripheral Interface
SSH Secure SHell
TCP/IP Transfer Control Protocol over Internet Protocol
TWOG Tiny Without GPS
UAV Unmanned Aerial Vehicle
USB Universal Serial Serial Bus
VIP Very Important Person
Wi-Fi Wireless Fidelity, IEEE 802.11b/g/n standard

1
Chapter 1
Introduction
1.1 Motivation
Imagine a near-future farmer, looking at a map of her fields on a tablet computer from
the deck of her house. This map includes detailed pictures of the current state of her crops
(in this case an accurate representation of the current water content of her fields), as well as
the history of the water usage of every part of her farm. Using this data, she assigns paths
and plans the movements of her robotic water sprinkler system, allowing her to save money
against high water rates, as well as conserve resources for other water users downstream
from her. A scenario like this can be made possible by Personal Remote Sensing (PRS), via
small Unmanned Aerial Vehicles (UAVs).
Remote sensing via small UAVs is fertile ground for research. Civilian applications
for such systems are just starting to be realized, and new opportunities for research are
appearing rapidly. A small UAV system, extensible for new payloads and applications, can
fulfill many of the needs of this new field of remote sensing, and provide further insight and
data in many fields of active research. Others would benefit, for example, such as highway
passengers, if UAV remote sensing systems were deployed for inspection of roadways to
increase hazard safety. A detailed introduction and review of existing literature can be
found in Chapter 2.
This thesis presents efforts to move toward the promise of Personal Remote Sensing
with Unmanned Aerial Vehicles. Since the main driver of such “personal” systems is price,
the system design efforts have been centered around providing the most functionality and
scientific effectiveness for the lowest price. Of course, a quest for low price and features
in any electronic field is unending; therefore the work contained in this thesis is simply a
snapshot of the AggieAir system available as of this writing.

2
1.2 Thesis Organization
• Chapter 2 gives an overview and background of and motivation for Personal Remote
Sensing.
• Chapter 3 introduces the AggieAir architecture, and shows how it is used for small
UAV-based Personal Remote Sensing.
• Chapter 4 contains information about AggieNav navigation system hardware and low-
level programming and software design.
• Chapter 5 is about the progress made on AggieNav state-based Kalman filter estima-
tion software.
• Chapter 6 covers SEAL, a general geo-spatial UAV payload datalogger, and applica-
tions.
• Chapter 7, the conclusion of this work, summarizes the results obtained and presents
a spectrum of possibilities for future work.
The appendices contain the files and lessons resulting from the hardware design and
production of various AggieAir components.
• Appendix A holds a small report on the lessons learned and practical insights into the
joy and pain of hardware development from AggieNav and SEAL.
• Appendix B contains schematic information for the AggieNav navigation unit hard-
ware.
• Appendix C has the board artwork for the completed printed AggieNav circuit board
(PCB).
• Appendix D has schematic diagrams for the SEAL datalogger.
• Appendix E has the respective board layout artwork for the latest version of the SEAL
PCB.
3
Chapter 2
Personal Remote Sensing
Sensing, or the use of sensors, is a basic function of life. Active entities, such as living or-
ganisms from mammals to mosses and non-living things from robots to traffic lights, change
themselves or react to their environments depending on their specific goals or behaviors.
Every entity which has the ability to make choices or react must do so on the basis of feed-
back; information that is percipient to the situation, and gathered through some accessible
and usually repeatable means. The gathering of useful information—reliable information—
is the act of detection, that is, purposeful “fishing” information most important to the task
at hand. For this feedback information to be useful, of course, it must be timely enough to
use effectively. Therefore, the act of sensing for feedback must be in at least half the same
time-scale as (at the Nyquist rate of) the process of change.
2.1 Sensing at a Distance
While information can come from many sources, the best way to collect specific infor-
mation is by the use of a sensor. Multiple sensors work in concert providing many sources
of good information at once; depending on the information demanded these sensors could
be actuated (alone, or with other entities via communication) to gather better data as time
passes and requirements or environments change. As humans, we have a given set of per-
ceptions granted by our suite of sensors (eyes, ears, nerves, etc.), but with science, through
engineering, we are able to extend this perception set further. Remote sensing allows us to
gather data at a physical distance, data for which there is either no other way or no safe
way to collect in person. Remote sensing, then, is simply detection at a distance.
There are two methods of remote sensing: passive (fig. 2.1) and active (fig. 2.2). Pas-
sive remote sensing is as described above: “waiting” for data where it is expected to be
4
found. Active sensing involves stimulation of the sensed environment to excite or otherwise
illuminate the situation in question, not unlike using a flashlight to inspect a noise in the
dark. Many examples of active remote sensing can be found today: RADAR systems [1], the
use of lasers for detection of aerosols in the atmosphere [2], detection of evasive species [3],
or detection of land mines via honeybees [4].
2.2 Personal Sensing
Remote sensing usually connotes large-scale instruments requiring large-scale support
operations (such as the Hubble telescope), and budgets far beyond even the most serious
everyday user’s budget. However, as humans, we have been attempting to extend our
senses for as long as we have used tools. Devices such as the looking glass allow our eyes to
see further, and the “tin ear” extends the range of an ear. These are examples of personal
remote sensing: the detection of data useful to a small number of people on short time-scales
and within small budgets.
Although the term is not commonly used currently (fig. 2.3), much like the beginning
of the Personal Computer (PC) age, examples of Personal Remote Sensing (PRS) systems
are beginning to emerge. Some can be found in consumer-level hardware and toys such
as the Estes Eagleye [5], a radio-controlled airplane with an integrated digital still camera
and memory (fig. 2.4), and the Spygear ATV-360 [6] (fig. 2.5) which includes a head-
mounted, greyscale, live video feed from a camera on the vehicle, in addition to a sound
feed from a microphone. Under the moniker “telepresence,” the WowWee Rovio [7] seen in
fig. 2.6 [8] provides many of the same features as the ATV-360 with a more robust vehicle
Sensor
Process of
interest
Fig. 2.1: Passive remote sensing.

5
Sensor
Process of
interest
Active
stimulation
Fig. 2.2: Active remote sensing requires some kind of stimulation to reveal the desired data.
chassis, better camera system, Wi-Fi for high-bandwidth data transfer, and a speaker for
bi-directional user interaction.
Like the PC, PRS systems have much more potential than simple playthings, or inci-
dental computer peripherals. Aerial photography is one application of PRS that has been
named by Shimada et al. [9] (fig. 2.3). Shimada makes use of a radio-controlled helicopter
with an NDVI (Normalized Difference Vegetation Index) [10] detection system gathering
4-band (near-infrared, red, green, blue) data about grazing land. Systems such as these can
provide vital data for individual farmers, with costs orders of magnitude lower and with
data of much higher density than alternatives such as flying full-size aircraft over the fields
or making use of satellite NDVI data.
However, all of the aforementioned systems are lacking aspects of autonomy: these
systems require a large amount of user interaction for useful function. Flying, driving, or
otherwise controlling a remote sensing system can be time consuming and in some cases
demands high levels of skill or training for consistent quality data. An autonomous system
such as an Unmanned Aerial Vehicle (UAV) can be preprogrammed to patrol for changes in
a scene or “follow” a data trail such as an airborne pollutant to collect data automatically.
In the case of NDVI, a farmer (as in above) could use a UAV for remotely sensing the water
content in her fields, seeing where the water is needed most. Such a PRS will not only save
water for others downstream, but will also save the farmer time and energy otherwise spent
overwatering.
6
Fig. 2.3: Complete Google search results for personal remote sensing (April 5th, 2010).
2.3 PRS Outlook
The key driver for success with PRS systems is price. Personal remote sensing can only
be personal if individuals and small groups can a ord to own and operate systems capable of
delivering the data they need. Progression of technology (Microelectromechanical or MEMS
devices, embedded processing power, battery power density, etc.) coupled with acceptance
of PRS systems by industry and legislators, will allow PRS to become commonplace.
7
Fig. 2.4: The Estes Eagleye remote control toy. Image copyright Amazon.com.
Fig. 2.5: The Spygear ATV-360. Image copyright Toy Store Inc.
8
PRS systems are poised to provide the next generation of useful data about our world.
While large-scale remote sensing (like large-scale computing) will always have applications
such as weather prediction, PRS allows individuals or small groups to collect valuable data
about situations or processes that concern them specifically. Personal remote sensing is
an upcoming technology, and will show effectiveness when combined with UAVs and other
autonomous systems. With PRS, new ways of interaction and feedback can be used—with
scientific accuracy—to make better, more efficient decisions about what concerns us most.
2.4 Thesis Contributions to PRS
For PRS systems to be affordable and still provide scientifically accurate data, the elec-
tronic sensing and control architectures must be miniaturized and integrated in thoughtful
ways, while leveraging existing technology whenever possible. This thesis presents advances
in small UAV PRS systems, specifically toward UAV use for civilian use such as farming
and agriculture. Extendible system approaches, such as the work in Chapter 3, allow for
systems to scale and grow with new sensing solutions and technologies, while integrated
designs as in Chapter 4 and Chapter 6 give systems low cost and mass-producibility.
Fig. 2.6: The WowWee Rovio telepresence robot. Image copyright Thinkgeek Inc.
9
2.5 Chapter Summary
This chapter provides a low-level motivation for and definition of personal remote
sensing. A description of remote sensing is presented, then extended into more personal
examples, where current consumer personal remote sensing systems are presented. An
outlook shows the prospects for PRS in the near future, and the need for PRS systems,
which will drive development and legal support for PRS in the future.
10
Chapter 3
AggieAir: An Integrated and Effective Small Multi-UAV
Command, Control, and Data Collection Architecture
An Unmanned Aerial Vehicle (UAV) is a complex aircraft system that is able to nav-
igate without the manual control of a human pilot. The inception of UAVs traces back to
World War I, and they have been used primarily for military applications. However, entry
of UAVs into the civil/commercial market is as recent as the last few decades. There is
an increasing interest in developing UAV systems for a variety of civil applications such as
traffic control, border patrol, fire-fighting management [11], agriculture monitoring [12], etc.
UAVs of different sizes, types, and configurations are developed for specific applications.
Generally speaking, an autonomous UAV system consists of automatic pilot (autopi-
lot) system, navigation system that includes a variety of sensors, on-board microcomputer
system for coordination, and a ground control station that monitors and changes flight
missions in real-time.
At the Center of Self-Organizing and Intelligent System (CSOIS) at Utah State Uni-
versity, miniature fixed-wing autonomous UAVs are developed for civil applications, such as
water management, irrigation control, highway mapping, etc. The UAVs we developed are
equipped with light-weight multispectral high-resolution optical imagers for aerial images
within reconfigurable bands [13].
This chapter presents AggieAir, a novel hardware and software architecture. AggieAir
is fundamentally based on a proven system architecture: that of a real aircraft. Figure 3.1
shows a simplified version of this hierarchy, allowing specific mission tasks and goals. On
the ground, the Flight Commander (a human or humans, in the AggieAir system), oversees
the whole mission as it progresses. The Science Team is also on the ground, monitoring
data and controlling experiments on the plane in real-time.

11
3.1 Functionality
Overall, the AggieAir Aero-team paradigm is illustrated in fig. 3.1. Each part of the
system has its respective role, even the humans on the ground. A much more detailed
system block diagram is fig. 3.2, which shows some of the nuances of the AggieAir system.
3.2 Data Flow
Figure 3.3 shows the AggieAir data flow hierarchy versus system complexity. This
allows for many system configurations depending on the demands of the mission at hand.
A demand analysis is carried out for each mission, and given the mission parameters (an
update frequency required by the ground operators, for instance) and payload demands
(on-board processing, communication to other UAVs in flight), the various parts of the
AggieAir system can be included or excluded as needed.
For example, a particular mission could demand only AggiePilot and AggieNav for basic
navigation and flight path following. AggieCap and the other parts of the system are not
required and could therefore be left out of the system. Given a more complex mission, one
more level could be added: AggieCap’s payload management could be demanded without
the need for the Wi-Fi data link and this could easily be left out of the mission. The
full system (AggieNav, AggieCap, and Wi-Fi with multiple ground stations) could be also
implemented easily if required for a complex mission with multiple UAVs.
Airborne
AggieCap
(Captian)
Payload{1, 2, ...}
AggieNav Papazazzi (Pilot)

(Navigator)
Command + Telemetry Link Payload Data Link
Flight Payload Team(s)

Commander
Ground
Fig. 3.1: AggieAir Aero-team block diagram.

12
Airframe
AggieNav Gumstix Flight Software (Separate Processes)
IMU, Compass, GPS,
Pressure, Temperature AggieCap Payload #1
{Fractional, Extended}
SPI Kalman Filter
GPos+LPos Data Server GhostFoto
UART
GCS + Payload Message
AggiePilot (PPRZ) Bus
UART
Autopilot Payload #2
Ethernet + Local BlackBox Flight
JAUS
GPos+LPos+Payload
Recorder/
GCS C+C
Message Socket Interface Thermal Camera/
UART Other Payload
Downlink Radio
PPRZ C+C Link High-Bandwidth WiFi Datalink
GCS C+C Uplink

Ground Control Station
Radio
GCS Computer #1 GCS Computer #2
PPRZ GCS + • GhostEye Interface
UART
JAUS
• gRAID Interface
GCS + Payload Message
Bus
GCS Computer #3
Ethernet + Local
• Thernal Camera
JAUS
GPos+LPos+Payload
Interface
Message Socket Interface • Etc.
Fig. 3.2: AggieAir detailed system architecture.
3.3 2.4GHz Wi-Fi Communication Link
CSOIS has developed a high-bandwidth 2.4GHz Wi-Fi (IEEE 802.11g) communication
link for use with single or multiple UAVs and ground stations. Designed to be inexpensive
and easily set up in the field, this link is based on lightweight (80g including antenna and
cable), high-power (800mW), inexpensive ($70), “carrier-class” Wi-Fi units manufactured
by Ubiquiti Wireless [14], known as the Bullet2-HP. These units are employed on both ends
of the data link, and have been tested at more than one mile range to provide greater than
400KB/second and up to 1.6MB/second transfer speeds depending on antenna orientation.

13
Increasing System
Complexity
Offboard
Payload Payload Payload(s) via
#1 #2 Mesh Network
AggieCap
AggieNav
AggiePilot
AggieAir Payload
Groundstation Groundstation
Fig. 3.3: AggieAir system complexity changes depending on mission requirements.
The Bullets have been modified for flight by the removal of the outer plastic case, and
the replacement of the heavy integrated N-male RF connector with a hard-soldered, short
LMR-400 co-axial pigtail and a standard 5.5dBi monopole Wi-Fi antenna (fig. 3.4). A
power-over-Ethernet (POE) splice cable allows the airborne Bullet unit to integrate with
the onboard UAV li-ion battery supply as well as the Gumstix flight computer via Ethernet.
The ground station network is connected to the Wi-Fi network via a 14dBi sector
antenna (pictured in fig. 3.5), giving the Wi-Fi link a wide horizontal angle (fig. 3.6, from
the HG2414SP-120 Datasheet [15]), tested to function well at ±80 degrees from center. A
vertical gain pattern of 20 degrees allows complete coverage of a long-range UAV flight area.
The alternative Wi-Fi operating system DD-WRT [16] supports Bullet2-HP units. DD-
WRT is a Linux-based operating system with many capabilities, not the least of which is
support for OLSR, the Open-Source Link State Routing protocol [17]. OLSR creates an
Ad-hoc mode Wi-Fi mesh network by manipulating the Linux kernel routing table based
on the status of the wireless network topology, allowing for a flexible UAV flying mesh such
as the one implemented by Tisdale et al. [18].
3.4 JAUS
JAUS, the Joint Architecture for Unmanned Systems, is a comprehensive, cross-platform

14
Fig. 3.4: Ubiquity Bullet2-HP modified for small UAV flight with 5.5dBi antenna.
command and control architecture designed for interoperability by the US Department of
Defense, and is a standard for US military unmanned systems. It is ideal for architec-
tures and systems such as AggieAir, and allows for well-tested packet-based transmission
of critical data such as airframe pose or payload status. Implementations of JAUS vary
in price and licensing; the AggieAir system uses OpenJAUS [19], a free and open-source
implementation of the JAUS system.
JAUS is packet-level, and is defined for TCP, UDP, and serial links. Since JAUS needs
a transport protocol to be effective, AggieAir uses TCP/IP for reliable communication.
While JAUS is ideal for command and control applications, due to the limited data-
transfer types, it is not a particularly good choice for transmission of data from sensors or
other payloads, and AggieAir therefore uses other protocols (such as rsync [20], see sec. 3.6)
for data such as aerial images.

15
Fig. 3.5: Wi-Fi groundstation: 14dBi, 160◦ horizontal sectorial antenna with Bullet2-HP.
3.5 Coven-Ready Multi-UAV Capabilities
AggieAir allows for command and control of one or more UAVs. In the case of multiple
(a “coven” of) UAVs, for example in distributed wind measurement, the UAVs communicate
with each other and maintain a formation for collection of unique data available no other
way.
For multi-UAV communication, the Wi-Fi network is used with a mesh-networking
protocol (such as the above-mentioned OLSR), which maintains the best network topology
over time, terrain, and other factors. This allows the UAVs to keep in contact. Once
connected, the UAVs exchange position and other vital data though their JAUS subsystems,
16
Fig. 3.6: Gain pattern of sectorial antenna.
allowing each UAV to request as much or as little data as needed for a particular task.
With a technology like JAUS, the UAVs using AggieAir can enjoy enhanced robustness.
If, in a flying coven, UAV “A” suffers a hardware failure (the loss of the data-radio modem,
for instance), UAVs “B,” “C,” and “D” can relay their data to the degraded UAV via the
Wi-Fi network, and the coven can still perform the required mission.
In another scenario, a single “VIP” UAV could have a very expensive device, such as a
high-quality IMU, while the other UAVs have more rudimentary navigation hardware, such
as thermopiles and local-infrared sensors for targeting the VIP UAV. The whole coven could
then navigate with the accuracy of the VIP UAV, by communicating while flying. With
such a configuration, it is them possible to outfit the other UAVs with heavier or high-
value payloads such as thermal cameras, while reducing overall cost without sacrificing
performance.
3.6 rsync for Data Transfer
Currently, the best method for transferring arbitrarily large data sets over unstable
links such as the Wi-Fi link in AggieAir is the rsync protocol [20]. rsync is an open-
source cross-platform software utility that implements the rsync protocol, and provides
fast incremental file transfer, allowing data transfers to be interrupted by variable-quality

17
communication links and resumed later when the link has been restored. A simple Bash
“wrapper” script allows the Payload Ground Station to asynchronously request the data
files from the airborne processor and save them on the groundstation for further processing
or analysis. In this way, the ground network can re-target or change a UAV’s behavior
based on any combination of human or machine decisions.
rsync is currently implemented in AggieAir on the Windows XP operating system via
Cygwin [21], but a small section of compatibility code changes the ping syntax and allows
the same script to operate on multiple Unix variants as well as Windows. Currently, the
behavior of the airborne image payload is of a steady, continuous production of separate
data files (discrete images, in the case of GhostFoto, see sec. 3.10). This technique will
also perform nicely with growing-length (appended-mode) data files with different rsync
options. Although rsync can be used in conjunction with other protocols such as SSH [22],
to conserve airborne CPU load and bandwidth, the data is sent in an unencrypted stream
via the standard rsync protocol.
Figure 3.7 shows the logic flowchart for collection of data via rsync. Note that in this
case, rsync has been configured to remove the remote data after downlink to the ground,
since each iteration will take progressively more time to index the source data files if they
are not cleaned each loop iteration. Additionally, rsync is used in Backup mode so it will
not overwrite files that have identical names in case a naming collision occurs (caused by
a reset of the flight computer or the crashing of a payload, for instance). In this way, a
reliable, cross-platform data collection system has been made using established, well-tested
software.
3.7 AggiePilot
The AggieAir module responsible for both low-level flight control (airframe attitude
control) and high-level execution of flight plans is adapted from a pre-existing project,
Paparazzi. Paparazzi is an open-source, fully-autonomous autopilot developed by aerospace
students at ENAC University in France, and CSOIS has been using Paparazzi since 2007
[23], to much success. Figure 3.8 shows the Tiny Without GPS (TWOG) Paparazzi autopilot
18
START
Ping Airframe
No Yes
2 ICMP Start rsync
Sleep 5 Seconds
Responses? Command
Download Data
(delete source)
Sleep 3 Seconds
Fig. 3.7: rsync data collection script flowchart.
system board from the Paparazzi Wiki [24].
In the AggieAir architecture, the Paparazzi system has been augmented with a JAUS
data channel to become AggiePilot, allowing JAUS packets to be transmitted to and from
the UAV(s) while in flight. This allows for a useful amount of JAUS command and control
data to be sent over the UAV’s normal control link, up to 10 miles away, depending on
antenna and radio factors.
Paparazzi is an ideal platform on which to base a system like AggieAir. More system-
level details as well as information about the CSOIS implementation and use of Paparazzi
Fig. 3.8: Paparazzi TWOG board: a fully autonomous autopilot system.

19
can be found in A. Jensen’s thesis [25].
3.8 Gumstix Embedded Computer System
AggieAir relies on the Gumstix computer modules for general mission operation, pro-
cessing, as well as payload control. The Gumstix product line are so-named due to their
form-factor’s similarity to sticks of chewing gum (fig. 3.9 from Wikipedia [26]), and for
their relative low-cost. The current model of Gumstix used by the AggieAir system is the
Gumstix Overo Earth. The Gumstix Overo computers have the following features [27].
• Price: $149.00 USD as of this writing
• Up to 1200 Dhrystone Millions of Instructions Per Second (MIPS)
• Based on the Texas Instruments OMAP3503 or OMAP3530 Processors
• 256MB Flash memory
• 256MB Double Data Rate (DDR) Random Access Memory (RAM)
• On-board MicroSD slot for expansion memory
• Universal Serial Bus (USB) powered host port
• USB On The Go (OTG) port
• Analog-to-digital converter, Pulse Width Modulation unit, etc.
• Ethernet via USB, or via Tobi (and other) expansion boards
• Bluetooth (Overo Air and Fire only)
• Wi-Fi (Overo Air and Fire only)
The majority of the software needed to operate the Overo computer is provided in the
Ångström Linux distribution [28]. At least one other similar product to the Overo exists,
the BeagleBoard [29] also uses the OMAP3530 processor, and natively runs the Linux
20
Fig. 3.9: Gumstix Overo computer-on-module, between a US Quarter coin, an actual stick
of chewing gum, and the Gumstix Tobi board.
operating system, also shipping with the Ångström distribution. This is an advantage—the
heterogeneity of distribution compilation targets will help guarantee continued community
software support for the Overo computers, and allow systems using them to continue to
persist before obsolescence for a longer period of time.
The OpenJAUS node manager is also running on the Gumstix, allowing the command
and control of the software payloads relevant to the mission at hand. The Gumstix interfaces
(USB, Ethernet, etc.) allow access to the other parts of the AggieAir system. AggieAir
Payload software is written for the Linux system environment, and by use of standard
libraries, can exploit the Open Source nature of the underlying software, allowing for low-
cost upkeep and community support via the normal Open Source software channels (Internet
blogs, email lists, forums, etc.).
3.9 AggieNav Navigation Sensor
Presented in much more detail later (Chapter 4), AggieNav is a small, accurate, low-
cost, tightly-integrated UAV navigation sensor INS suite [30]. Figure 4.1 shows a system
21
block diagram. AggieNav serves as the Navigator in the aerial team paradigm, and provides
the Captain and with real-time global pose (attitude and location) data from a 6-DoF IMU,
GPS and compass module, as well as dual pressure sensors for estimation of altitude and
airspeed via Pitot tube [31]. AggieNav also serves as a relay for filtered data between
AggieCap and AggiePilot, with a safety fallback. As seen in fig. 4.8, AggieNav also holds
and powers the Gumstix computer.
AggieNav uses some of the Gumstix CPU time for an Extended Kalman Filter (EKF),
allowing for more accurate navigation. AggieNav then passes the filtered data along to
AggiePilot, allowing the system to function with the best navigation performance. How-
ever AggieNav has enough processing power (70 MIPS) to allow a fallback/failsafe mode
(fig. 4.14) if the Gumstix computer should fail or not be required for a given mission. If,
after 1 second (100 packets), AggieNav does not receive data from its companion software
process on the Gumstix, AggieNav will step in and provide its own data. In this case,
the AggieNav processor does some basic filtering work on the sensor data and passes this
data to AggiePilot in the same format as the normal system operation, allowing a seamless
failover, or minimum flight gear configuration if flying without the Gumstix processor.
3.10 Example Payload 1: GhostFoto
GhostFoto (GFoto) is a light-weight, cost efficient, multi-spectral imager which oper-
ates in both visible and near infrared (NIR) light wavelengths. The hardware of this payload
consists of RGB and/or NIR CCD cameras, shown in fig. 3.10, and Gumstix microprocessor
with software component, GhostEye, running to both configure and control the imagers.
GhostEye also provides an interface between the imager payload and UAV system, estab-
lishing a JAUS message and command channel, through which users are able to monitor
and operate the payload during flight. Figure 3.11 shows this flowchart.
Another key functionality of GhostEye is geo-referencing of the airborne imagery. The
orthorectification of the aerial images is indispensable for end users that demand accurate
geographic information. For instance, in applications such as target recognition and ground
mapping, the geographic coordinates of any pixel on the aerial image should be retrievable.
22
Fig. 3.10: Ghostfoto CCD camera: modi ed Canon Powershot SX100-IS.
Fig. 3.11: AggieAir GhostFoto data ow.

23
By querying sensor data via JAUS, such as the UAV geographic coordinates, and pitch,
yaw, and roll angles of the plane, GhostEye logs the geo-referencing information for each
image so that they can be accurately orthorectified [13], either post-mission, or in real-time
during flight.
This access is enabled in the AggieAir architecture through AggieCap, which dispatches
the EKF filtered flight data to JAUS, from which the payload (or any JAUS node) can
query for geo-referencing information. The message and control channel of GhostEye is also
managed by AggieCap, and is sent through AggieNav to AggiePilot, which communicates
with ground station, where the status of GFoto is monitored.
Airborne imagery can be saved on the memory card in the cameras, or downloaded
from the imager onto the SD card on the Gusmtix processor, and hence sent to the Ground
Control Station via rsync through the high-bandwidth Wi-Fi Datalink. This process allows
the ground station to process the acquired imagery in real-time, allowing feature-based
navigation can be implemented in AggieAir architecture.
As an example, fig. 3.12 shows an aerial image (top) taken over Little Bear River near
the Utah State University (USU) owned research farm (GPS: 41.8155945, -111.9816552).
The image is orthorectified with the provided geo-referencing data (rotated and projected
onto globe coordinate with its upper side pointing North), and seen in the bottom picture
of the figure.
3.11 Example Payload 2: EagleEye
A second example payload is the EagleEye system, designed to allow a UAV pilot a real-
time look at the horizon, as if they were actually piloting the aircraft. Because other wireless
camera systems use the 2.4GHz band occupied by the AggieAir Wi-Fi link, the best solution
is to use the existing datalink to transfer the video data. This is made possible by the Apache
HTTP server running on the Gumstix computer, with the webcam server module. This
allows a pilot or other observer to connect to the airframe from a groundstation, and stream
video from the forward-looking camera at a highly compressed rate to a second monitor or
other display device via a standard web browser. When properly compressed, this video
24
Fig. 3.12: Aerial image and orthorectified image.

25
stream can be usable for a pilot, and consume as little as 20-50kb/second of communication
bandwidth.
The camera in fig. 3.13 (from the Logitech, Incorporated website [32]) is a full pan/tilt
solution designed for consumer-level videoconferencing. This camera is ideal for several
reasons; the foremost of which is Linux driver support by the manufacturer, Logitech. This
driver allows access to the video streams as well as the pan, tilt, and focus settings. This
camera is of adequate quality, and at $100 per camera, the system is functional and low-
cost. Other Logitech camera solutions exist if the pan/tilt functionality is not needed, and
can easily be integrated with minimal change in the underlying design and software.
The EagleEye camera system is commanded by JAUS from the groundstation, or other
elements in the AggieAir system as demanded by mission requirements. The USB connec-
tion technique allows the video stream to be processed by the host Gumstix computer for
use in target recognition or other flight-intelligence algorithms.
3.12 Chapter Summary
AggieAir is an effective, low-cost system design for unmanned aerial personal remote
sensing systems. This chapter contains high-level design descriptions for AggieAir, with
block diagrams and details of implementation to illustrate the system. Example payloads
are included, with integration details showing how the AggieAir system is extensible and
useful many types of UAV applications and missions.
Fig. 3.13: Logitech, Inc. Quickcam Orbit autofocus pan-tilt camera.

26
Chapter 4
AggieNav: AggieAir Inertial Measurement and Navigation
Design
To accomplish mission goals or to fly passengers to their destinations, all aircraft rely
on sensors as the core of their navigational systems. For small UAVs, the sensor suite
determines much about the usefulness and capabilities of such a system, and is mostly
limited by the relatively high cost of high-quality navigational sensors and equipment.
The options for low-cost miniature attitude navigation sensing are few; most inexpen-
sive, small fixed-wing UAVs use infrared thermopiles which sense the relative heat differ-
ential from the black body radiation of the Earth’s surface and the open sky. While this
technique does work, it is not accurate enough for most remote measurement tasks and
has problems when flying near large land features such as mountains, through valleys, or
near oceans. When attitude sensors are combined with a modern civilian GPS receiver,
autonomous navigation is possible. However, payloads such as cameras demand better atti-
tude estimation performance to enable accurate orthorectification (see sec. 3.10), so better
sensors and filtering schemes must be employed.
Inertial measurement units with roll-rate gyros and accelerometers are the standard
sensors for attitude determination in flight. Several solutions exist for navigation in small
UAVs, such as the Microstrain GX2 [33], CrossBow MNAV [34], and Procerus Kestral [35],
all of which use Kalman or other state-estimation filter of some kind to provide a high-
accuracy estimation of the current position and attitude of the system at a given instant.
While these systems work well for their intended applications, even the academic prices are
prohibitive for integration into single or multiple inexpensive UAVs. Additionally, the source
code is not made available, and users of the systems are forced to accept the filter/algorithm
performance of the systems as they are given.

27
Recently, due to the high-availability of low-cost inertial sensing chips, many consumer-
level devices such as the Apple iPhone, Nintendo Wii, and Sony PlayStation 3 [36] have
integrated accelerometers into their hardware for more immersive user-experiences. Sev-
eral chip manufactures are producing 3-axis accelerometers, however, the availability of
integrated 3-axis roll-rate gyro chips is not as broad. Analog Devices Incorporated is, at
the time of this writing, the only company producing fully-integrated 6-degree-of-freedom
sensor units [37]. Other academic efforts such as Hirokawa, Kajiwara, and Ohata [38] and
Affonseca [39] have been put forth, but the Analog Devices part is the most flight-ready
and integrated design currently available for purchase outside of the US military.
AggieNav is a unique design of advanced sensing, power and processing hardware,
paired with sophisticated data filtering algorithms, giving it a decisive lead in front of other
similar systems.
AggieNav has a unique combination of features.
• Full high-accuracy 6-Degree-of-Freedom IMU
• Full 3-axis tilt-compensated compass
• Standard interface with any low-voltage GPS unit via a serial port
• Dual pressure sensors for static and dynamic air pressures
• 72 MIPS onboard processing power
• Onboard hardware mounts for a 600MHz Gumstix Linux computer, and Paparazzi [24]
based autopilot system (“AggiePilot”) for a full UAV system
• Lowest total price for any such system
• Open software architecture allows AggieNav to be customized or augmented easily
• Weight: 70g, power: 1.0W total with Gumstix and GPS

28
4.1 UAV Flight Testing
AggieNav has been tested on UAV flights as a payload in data-logging mode. In the
following sections, plots of data recorded during a flight on November 16th, 2009, (hereafter
written as “111609”) are included in the sections relevant to the various sensors included
with AggieNav (figs. 4.5, 4.7, 4.9, 4.11).
4.2 Low-Cost UAV Navigation Solutions and AggieNav Comparison
Three different kinds of navigation solutions are common for small UAVs.
1. No IMU (typically IR sensor-based) with GPS
• Least expensive option for navigation. Many drawbacks (inaccurate and difficult
to tune, etc.), but functional.
2. Loosely integrated INS: IMU (such as the Microstrain 3DM-GX2) with uncoupled
GPS
• Estimations are workable, and better than IR-based navigation, but are not ideal.
3. Tightly integrated INS: IMU + GPS + Compass + Pressure etc. w/Kalman or other
combining filter. These are the best current solutions for small (and large) UAV
flight. Several companies are making solutions target UAV flight, but most are very
expensive.
• Micropilot (full autopilot solution) ($8,000)
• XSens MTi-G ($7000)
• Crossbow Micronav + Stargate Processor (discontinued, $1,900)
• Procerus Kestral ($5,000)
• AggieNav ($1,200)
More specific information on the closest competitors to AggieNav can be found in
Table 4.1.
Table 4.1: AggieNav versus other small INS solutions.
INS Unit AggieNav Stock Microstrain 3DM GX2 Crossbow MNAV Procerus Kestrel
Max Gyro Bandwidth 700Hz (unfiltered) 250Hz 25Hz 9Hz
Max Gyro Dynamic Range ±300deg/sec ±300deg/sec standard ±150deg/sec ±300deg/sec
Accelerometer Dynamic Range ±10g ±5g ±2g ±10g
Accelerometer Resolution 14bit 16bit NA 14bit
Accelerometer Bandwidth 700Hz (unfiltered) 250Hz 25Hz 9Hz
Magnetics Rate 5Hz heading solution 250Hz 1-100Hz NA
Magnetics Accuracy ±3deg 0.001Gauss NA NA
GPS Rate 4Hz No GPS 4Hz NA
Max GPS Accuracy 2.5m No GPS 3m 5m
Pressure Rate 1.8Hz No Pressure NA NA
Pressure Accuracy (Abs) 1.5Pa No Pressure NA 2.44Pa
Power Draw 600mW 470mW (minimum) 400mW 700mW
29
30
4.3 Enter AggieNav
AggieNav has been developed as a “best of” between low-accuracy thermopile sensors
and high-cost, closed source navigation systems. By leveraging new digital MEMS sensors,
such as Analog Devices ADIS1635x IMU parts, a new level of performance vs. cost can be
achieved. Figure 4.1 provides a block diagram of AggieNav’s sensors and system design.
Since many of our UAV missions at Utah State University (and indeed, the general de-
velopment of filtering for AggieNav’s sensor data) require the use of a Gumstix Linux com-
puter, a mounting footprint and connector has been included, as well as a 5V-powered USB-
host port. This allows the high-level flight software to be aware of the current flight/mission
state via JAUS, creating many possibilities such as location-based science and swarm/mesh
(coven) networked behavior. Figure 4.2 shows how AggieNav integrates with the AggieAir
hardware system defined in Chapter 3.
4.4 AggieNav Subsystems
AggieNav has a unique combination of sensors to support high quality flight navigation.
Gumstix 5.0V; 3.3V uBlox

Verdex Linux Switching LEA-5H
System Regulators GPS Receiver
External Papazazzi-
User Atmel
Data based
Interface AVR32A256B
Interfaces Autopilot
(LEDs, Micro-
(TTL-Serial; Board
Buttons) controller
SPI Slave) (AggiePilot)
Honywell VTI
Analog
HMC6343 SCP-1000
Devices
3-axis Pressure
ADIS1654
Magnetic Sensors (x2)
6-DoF IMU
Compass
Fig. 4.1: AggieNav hardware block diagram.

31
Gumstix Linux
Computer
TTL
Serial
IMU
SPI Data
Compass AggieNav Bus
GPS, Etc.
SPI Bus
Master
AggiePilot
Autopilot
Fig. 4.2: AggieNav internal data connection diagram.
All devices on AggieNav are factory calibrated and have digital interfaces to shift the load
of testing and verification from the system assembly stage and allow for the fastest possible,
lowest cost assembly time.
4.4.1 Inertial Measurement Unit
The primary sensor for AggieNav is an Analog Devices ADIS1635x Inertial Measure-
ment Unit (fig. 4.3 and fig. 4.4 from the ADIS16354 Datasheet [37]), with six full axis of
roll-rate and accelerometer data. Analog Devices manufactures several different models in
the same IMU family which vary in sensing ranges and included sensors. The ADIS1635x
sensors are factory calibrated and require little integration during manufacturing of an Ag-
gieNav unit. The ADIS1635x sensors have comparable performance to (and in many cases,
better performance than) competing small UAV INS solutions.
IMU data from the 111609 test flight is seen in fig. 4.5. We can observe clearly a
constant 1g acceleration force before takeoff (via a “bungie” [25]), and forces seen after the
takeoff event represent the measurements effected by the flight dynamics. Note that the
data becomes more noisy after the electric propellor motor is engaged, as is to be expected.
32
Fig. 4.3: 6-DoF IMU: Analog Devices ADIS16354.
Fig. 4.4: ADIS1635X block diagram.

33
IMU Acceleration Data from 11/16/2009 Flight
Motor testing
1000 (ground)
Takeoff event!
Motor off
500
Acceleration (mg)
−500
−1000
−1500
200 220 240 260 280 300 320

Time (sec)
Fig. 4.5: IMU data before and during takeoff from 111609 flight.
4.4.2 Magnetic Compass
A Honeywell HMC6343 tilt-compensated magnetic compass (shown in fig. 4.6 from its
datasheet [40]) provides slower (2Hz), more accurate absolute heading data. The HMC6343
compass includes an MSP430 ASIC as well as internal accelerometers to provide a tilt-
compensated heading independent of orientation. The internal filtering algorithms have
been enabled and set to their most low low-pass settings to better eliminate mechanical
resonances generated by the flight dynamics. Flight data from this sensor can be seen in
fig. 4.7; note that the heading reference is indeed constant for parts of the flight, and the
noise is low.
4.4.3 GPS Receiver
A high-rate civilian GPS receiver, a 4Hz u-Blox LEA-5H unit, provides data about
the UAV’s global position. This GPS receiver is pictured alongside AggieNav in fig. 4.8
34
Fig. 4.6: Honeywell HMC6343 magnetic compass with tilt-compensation.
Magnetic Heading Data from 11/16/2009 Flight
350
300
250
Heading (deg)
200
150
100
50
0
600 620 640 660 680 700 720 740 760 780 800
Time (sec)
Fig. 4.7: Sample of magnetic compass data from 111609 flight.

35
Fig. 4.8: AggieNav prototype with Gumstix and GPS unit. Mass as pictured: 70g.
and includes an LNA (low-noise amplifier) helical antenna from Sarantel [41]. Although
requiring 100mW of extra power beyond alternates with passive antennas, this GPS solution
gives AggieNav and the host UAV the best possible signal gain towards the sky and the
best 3D GPS lock accuracy.
AggieNav’s GPS receiver is designed to be replaceable/upgradable as newer and better
GPS units appear on the market, and for this reason the GPS receiver is separated by a
length of wire and an interface connector. This technique also allows the GPS system to be
relocated anywhere on the UAV for the best possible RF interference avoidance. In fig. 4.9,
a 3D plot of the full flight location and elevation log from the u-Blox receiver during the
111609 flight is visualized in Google Earth.
4.4.4 Pressure Sensors
Two small yet accurate pressure sensors (fig. 4.10, from VTi [42]) give accurate (1.5Pa)
pressure, allowing for the calculation of both absolute elevation (with launch time cali-
36
Fig. 4.9: GPS flight log from 111609, plotted in Google Earth.
bration) and wind speed (differential via Pitot tube [31]). Raw data recorded from these
sensors is seen in fig. 4.11.
4.5 Power System and Temperature
The AggieNav switching power system is designed for the full voltage range of the
batteries in the CSOIS UAVs [23] (5.1-17.0V), and provides additional power to the Gum-
stix computer and the onboard host-mode mini-USB port. Two power rails, 5.0 and 3.3V,
are implemented with Texas Instruments TPS62110-series step-down switching power con-
verters as in the datasheet [43]. This power system has been tested in flight conditions
and efficiently provides clean power to the AggieNav system and hosted Gumstix board.
A full power and mass budget is presented in Table 4.2. All parts used in AggieNav are
temperature tolerant from at least -20◦ to 80◦ C.
4.6 Microprocessor and Embedded Software
AggieNav is based on the 32-bit AVR32UC3B0256 microprocessor from Atmel Corpo-
ration [44]. This processor (fig. 4.12, from the datasheet [44]) gives 72 MIPS at 60 MHz with
37
Fig. 4.10: VTi SCP-1000 pressure sensors.
4 Raw Pressure Data from 11/16/2009 Flight

x 10
8.85 Pressure 1 (Pitot)

Pressure 2 (Static)
8.8
Pressure (Pa)
8.75
8.7
8.65
0 200 400 600 800 1000 1200

Time (sec)
Fig. 4.11: Selected pressure data from the 111609 flight.

Table 4.2: AggieNav power, mass, and cost budget.
AggieNav Budget Voltage (V) Current (mA) Power (mW) Mass (g) Cost (USD) Source
AT32UC3B0256 CPU 3.3 23 75.9 0.2 $12.00 Sample from Atmel
ADIS16355 IMU 5 57 285 16 $357.00 Analog Devices
HMC6343 Digital Compass 3.3 13 42.9 0.32 $175.00 Digikey
u-Blox LEA-5H GPS 3.3 60 198 2.1 $100.00 u-Blox America
GPS Antenna 3.3 110 363 10 $10.00 Digikey
SCP1000-D11 Pressure Sensor 3.3 0.03 0.08 0.2 $20.00 VTI.no
SCP1000-D11 Pressure Sensor 3.3 0.03 0.08 0.2 $20.00 VTI.no
Misc Electronics Hardware 3.3 20 66 15 $25.00 Estimate
PCB @ 30cm2 0 0 0 20 $20.00 Estimate
Totals 1030.97 64.02 $739.00

38
39
one of the lowest modern watt-per-MIP ratings in its class. AggieNav is fully programmable
from both the Linux and Windows operating systems via an Atmel JTAG-ICE Mk-II pro-
gramming unit. All system software is written in the C language and compiled with the
GNU C toolset, also provided by Atmel with their Java-based AVR32Studio product. This
combination has proved to be a workable and inexpensive solution to a high-performance
development problem.
The AggieNav software architecture is almost entirely interrupt-based for hard real-
time performance. Figure 4.13 provides a flowchart of the main data collection loop, which
occurs at 100Hz. Other interrupts process the GPS data (binary-mode single-character
processing), as well as sending data to the autopilot for filtered attitude and position data.
The main loop for the software is not idle, however, and is tasked with a secondary
Kalman filter for the data as seen below.
4.7 The Gumstix Processor and AggieNav Extended Kalman Filter
An extended Kalman state filter is employed for processing the large amount of sensor
data generated by AggieNav. This filter runs on the mounted Gumstix board as a co-
process, and is being developed on the Gumstix for ease of testing and verification. The
filter is under development; it is not yet optimized and as such can require a great deal of
processing power. Additionally, many UAV missions demand control over payloads or other
high-level computing, and therefore the flexibility of a full traditional operating system
is required for many missions. Therefore, a Gumstix Linux computer is mounted to and
powered by AggieNav, allowing the sensor data to be processed and filtered, then returned
to AggieNav for reporting to the attached Paparazzi autopilot.
4.8 Software Failover
This system design allows AggieNav to fail over to an internal Kalman filter should the
Gumstix experience a software crash or become otherwise disabled, as depicted in fig. 4.14.
AggieNav waits a sufficient period (in this case, 50 missed packets, or 0.5 seconds), and
40
starts sending the Autopilot AggieNav’s internal data. This decision is made at every
sensor data collection loop, and could be adapted to other fault/failover scenarios.
AggieNav is designed to integrate tightly into the CSOIS AggieAir system design,
as well as function well on its own in any application that requires a well coupled INS
solution. The main AggieNav communication channel is a TTL-level serial port, over which
AggieNav transmits 100 packets/second of sensor data. The guest Gumstix computer is
used as a co-processor, filtering the location and sensor data, and transmitting it back to
AggieNav, which then relays the filtered data to the autopilot (AggiePilot) at the regular
rate of 100Hz.
4.9 Chapter Summary
For many UAV applications, inertial measurements are a requirement for accurate flight
performance. This Chapter presents AggieNav, an integrated inertial measurement system
for small UAV applications. System-level design details are given, and physical specifications
such as power and mass are shown. Implementation specifics are given (sensors, processors,
etc.), and data collected during test flights is shown.

41
Fig. 4.12: AVR32 processor core diagram.

42
Begin Main
Interrupt @
100Hz
Collect IMU
Data (6-DOF)
Every 10 Ints Query Compass

Data
Every 25 Ints Query Pressure

Data
Retreve GPS
Data from Buffer
TX Raw Data
Packet Over
Serial
No Yes
Failover
Mode?
Yes Gumstix No No Data from Yes
Timeout? Gumstix?
Enter Failover Enter Normal

Mode Mode
End
Fig. 4.13: AggieNav main data collection flowchart.
Fault Line
AggieNav Gumstix EKF
Process
AggiePilot
Fig. 4.14: AggieNav EKF failover diagram.

43
Chapter 5
Design and Implementation of Sensing and Estimation
Software in AggieNav
As in Chapter 4, attitude estimation is performed in UAVs small and large by various
means. This attitude estimation problem is best solved using inertial navigation, a tech-
nique which requires a combining filter such as a Kalman state-based estimation filter. For
the purposes of autonomous sensing, high-accuracy flight data is required, and therefore
AggieNav requires a software Kalman filter for navigation estimation.
5.1 UAV Attitude Estimation
AggieNav provides three axis gyro, accelerometer, magnetic and heading sensors, and
GPS data channels. AggieNav targets unmanned vehicles and robotics navigation, which
require estimation of vehicle orientation with respect to the inertial frame [45]. The accurate
estimation of unmanned vehicle orientation has a large impact on later image referencing
and registration [13]. Therefore, an attitude estimation algorithm is also being developed
for AggieNav. Many researchers have done similar work [46–49]. However, to achieve a
low-cost solution the most must be made of the sensor data collected, and for this reason a
Kalman filter is implemented in AggieNav for accurate state estimation.
To test the filter, we are using MATLAB to process actual flight data collected in
tandem with the commercial Microstrain 3DM-GX2 IMU (a unit which includes a magnetic
compass). This allows us to test the results of our filter against a known good solution on
the same data.
5.1.1 Attitude Representation
There are several methods to represent the orientation of a 3D rigid body in the inertial
44
frame including Euler angles, directional cosine matrix (DCM), and unit quaternions. The
most commonly used system are the traditional Euler angles (roll, φ, pitch, θ, and yaw, ψ).
The trajectory control of an unmanned aerial vehicle can be converted to cascaded control
of roll, pitch, and yaw. However, the use of Euler angles have some singularity points. Unit
quaternion provides another representation without introducing a gimbal lock problem [50].
The unit quaternion is defined as follows:
 
q
 0 
 
 q1 
q= , where q02 + q12 + q22 + q32 = 1. (5.1)
 
 q2 
 
 
q3
The conversion back from unit quaternion to Euler angles can be written as:
2(q2 q3 + q0 q1 )
φ = arctan( ), (5.2)
q02 − q12 − q22 + q32
θ = arcsin(−2(q1 q3 − q0 q2 )), (5.3)
2(q1 q2 + q3 q0 )
ψ = arctan( ). (5.4)
q02 + q12 − q22 − q32
5.1.2 Implementation of an Extended Kalman Filter (EKF)
Given a nonlinear system, an extended Kalman filter as in Welch and Bishop [51] can
be designed as follows. Assume the simplified nonlinear model is:
xk = f (xk−1 , uk ) + wk , (5.5)
yk = g(xk ) + vk , (5.6)
where xk is the system state vector, uk is the system input vector, yk is the system mea-
surement vector, wk is the process white noise with the distribution wk ∼ N (0, Q), vk is
the observation white noise with the distribution vk ∼ N (0, R) (i.e., both wk and vk are
0-mean, Gaussian noise processes with variance Q and R, respectively).
The key idea of Kalman filter is to fuse the estimates of system states from both the
45
system equation and the system measurement equation. The recursive structure of the
Kalman filter also makes it more robust to system changes and unmodeled dynamics. To
start the Kalman filter estimation, the initial values need to set including Q, R, and P0|0 .
The Kalman filter predicts and updates as below:
x̂k|k−1 = f (xk−1|k−1
ˆ , uk ),
Pk|k−1 = Fk Pk−1|k−1 FkT + Qk ,
yˆk = yk − g(xk|k−1
ˆ ),
Kk = Pk|k−1 GTk (Gk Pk|k−1 GTk + Rk )−1 ,
x̂k|k = xk|k−1
ˆ + Kk yˆk ,
Pk|k = (I − Kk Gk )Pk|k−1 ,
(5.7)
where
∂f ∂g
Fk = |x̂ ,u , Gk = |x̂ . (5.8)
∂x k−1|k−1 k ∂x k|k−1
5.1.3 Attitude Estimation using EKF
Assume the system state is a vector q, representing the unit quaternion and the gyro
bias, and the system output is a vector ŷ, representing the acceleration data [49]:
 
q0
 
 

 q1 

   

 q2 
  ax 
   
q= q3 ,  ay  .
y= (5.9)
  
   
 

 bp 
 az
 
bq
 
 
 
br
Assuming that p is the gyro measurement from the roll axis, q is the gyro measurement
46
from the pitch axis, and r is the gyro measurement from the yaw axis (with bp , bq , and
br representing the gyro biases for each axis) the nonlinear system can be modeled as in
Jung [49]. It must be pointed out that eq. (5.11) is an approximation close to the static
case since only the effects of gravity are considered for accelerometer measurements. It is
true when the UAV is only experiencing small accelerations.
 
0 −p̂ −q̂ −r̂ 0 0 0
 
 

 p̂ 0 r̂ −q̂ 0 0 0 

 

 q̂ −r̂ 0 p̂ 0 0 0 

1 
q̇ = r̂ q̂ −p̂ 0 0 0 0  q + wk , wk ∼ N (0, Q), (5.10)
 
2


 

 0 0 0 0 0 0 0 

 
0 0 0 0 0 0 0
 
 
 
0 0 0 0 0 0 0
 
 2g(q1 q3 − q0 q2 ) 
 
ŷ = 
 2g(q2 q3 + q0 q1 )  + vk ,
 vk ∼ N (0, R), (5.11)
 
g(q02 − q12 − q22 + q32 )
where      
p̂
   p   bp 
     
 q̂  =  q  −  b . (5.12)
     q 
     
r̂ r br
A more general dynamic case from Beard [46] can be represented as follows:
 
qVa sin θ
 g + sin θ 
 
ŷ =  rVa cos θ−pVa sin θ
 g  + vk ,
− cos θ sin φ  vk ∼ N (0, R), (5.13)
 
−qVa cos θ
g − cos θ cos φ
where Va is the 3D speed as measured by the GPS unit. Currently, however, eq. (5.11) is
used for experiments. The attitude state estimation can then be calculated using the steps
described in sec. 5.1.2.

47
5.2 Experimental Results
5.2.1 Raw Sensor Data Comparison
The raw sensor data from AggieNav is compared with the sensor data from the Mi-
crostrain GX2 IMU in figs. 5.1, 5.2, 5.3, 5.4, 5.5, 5.6. The AggieNav data is scaled to the
same units as GX2 IMU; the gyro data is shown degree/s and the acceleration data is in
m/s2 .
200
aggienav
gx2
150
100
50
p (deg/s)
−50
−100
−150
−200
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.1: Gyro sensor comparison: p.
250
aggienav
200 gx2
150
100
50
q (deg/s)
−50
−100
−150
−200
−250
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.2: Gyro sensor comparison: q.

48
200
aggienav
gx2
150
100
50
r (deg/s)
0
−50
−100
−150
−200
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.3: Gyro sensor comparison: r.
10
aggienav
8 gx2
2
ax (m/s2)
−2
−4
−6
−8
−10
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.4: Acceleration sensor comparison: x.

49
10
aggienav
8 gx2
2
ay (m/s2)
−2
−4
−6
−8
−10
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.5: Acceleration sensor comparison: y.
0
aggienav
−2 gx2
−4
−6
−8
az (m/s2)
−10
−12
−14
−16
−18
−20
80 90 100 110 120 130 140 150 160
time (s)
Fig. 5.6: Acceleration sensor comparison: z.

50
5.2.2 Preliminary Results for Attitude Estimation using Kalman Filter
These preliminary EKF results are based on the descriptions above with no heading
corrections due to some magnetic sensor interpretation problems. The EKF is set to run at
100Hz.
From figs. 5.7 and 5.8, we can see that the roll and pitch angles can be estimated with
the current EKF although there is some obvious high frequency noise. Remaining work
includes some kind of prefilter for the raw sensor data, possible inclusion of the model in
eq. (5.13), and Kalman filter covariance matrix estimation.
5.3 Chapter Summary
Inertial navigation is a complex problem that requires digital signal processing for useful
results. In this chapter, a preliminary Extended Kalman Filter (EKF) is presented for small
unmanned aerial vehicle navigation. Mathematic equations for attitude representation and
estimation are presented, and preliminary experimental Kalman filter results are included.
50
40
30
20
10
phi (deg.)
−10
−20
−30 gx2
kalman
−40
−50
5 10 15 20 25 30 35 40
Fig. 5.7: Roll angle estimation comparison using the AggieNav EKF.
51
20
15
10
5
the (deg.)
−5
−10
−15 gx2
kalman
−20
5 10 15 20 25 30 35 40
Fig. 5.8: Pitch angle estimation comparison using the AggieNav EKF.
52
Chapter 6
A Generic UAV Payload: Modular Design
The need for a small, ubiquitous sensing continues to grow all around us. Applications
such as tracking climate change, air pollution, or other environmental data are drawing
increasing attention from both academia and industry. Although, frequently, this attention
is about how such data changes over time, rarely is the change over both space and time
studied. The addition of this fourth dimension to scientific data while costs low, and
providing large datasets, is the goal of the Spatial Environmental Autonomous Logger, or
SEAL platform.
A confluence of development has set the stage for concepts like SEAL: cellular telephone
development has driven mobile electronics to be smaller, lighter, more power efficient, and
less expensive. Power densities for batteries such as Lithium-ion polymer (Li-Poly) have
been increasing. GPS receivers have been dropping in price, size, and weight, and increasing
in sensitivity. Finally, flash memory has made steady progress as an inexpensive and reliable
source of large, long-term storage.
Typically, the types of tasks SEAL is suited for are accomplished with handheld Win-
dows Mobile devices (such as in CarWeb [52]), but these units are neither inexpensive, nor
power efficient, nor truly light-weight. Much like these devices, SEAL includes Wi-Fi and
logs its data onto a flash memory card with a Microsoft FAT16 file system.
Development work on SEAL is being done in stages. The first hand-built prototype
(based on Atmel, Incorporated’s AT90USBKey [53]) for the datalogger is shown in fig. 6.1,
and did not include the power system, final GPS unit, or the eventual Wi-Fi interface.
Figure 6.2 includes all of these parts, as detailed in sec. 6.2 below.
The main contribution of this chapter is to showcase and document the design of a
new generation of general-purpose datalogging equipment enabled by the latest technology

53
advancements, including power and space usage.
6.1 Related Work
Inexpensive, tiny dataloggers such as in Dedrick et al. [54] have been the norm for the
last decade. However, such systems are smaller in both data memory and scope than SEAL.
Other flash-memory based projects such as Ocean Bottom Seismometers [55] (OBSs), and
multi-year environmental logging projects like the solar-powered autonomous underwater
vehicle [56] developed by the Autonomous Undersea Systems Institute (AUSI) have similar
structures to SEAL, but their design paradigms remain specific to their particular projects.
A more similar project is Cartel by MIT’s Computer Science and Artificial Intelligence
Laboratory [57]. As GPS becomes more integrated with everyday life, organizations such
as Microsoft Research Asia [58] have made great progress in visualization and storage of
GPS logs and movement history. Other projects such as CarWeb [52] are taking place to
analyze traffic systems.
6.2 SEAL Design Details
SEAL is composed of relatively low-cost components, and is based on an Atmel AT90USB1287
8-bit RISC microprocessor [59]. A system-level block diagram is found in fig. 6.3, and a full
power, mass, and cost breakdown is found in Table 6.1.
Fig. 6.1: SEAL Revision 0 prototype hardware. Includes several sensors, a Secure Digital
memory card slot, and a GPS unit.
54
Fig. 6.2: SEAL Revision 1 hardware with sensors and Wi-Fi. This package weighs 114g
(light enough for a small aircraft payload) and has 8+ hours of run time.
USB SEAL LiPoly

Venus634FLPx
Interface Power
GPS Receiver
System
Analog Sensors
User Atmel Analog • EasySen
Interface AT90USB1287 Devices SBT80
(LEDs, Micro- ADS8344 • N H3
Buttons) controller A/D • CO2
Converter • Etc.
Optional MicroSD Digital Data

Wi-Fi 2GB Flash and Event
Interface Memory Sources
Storage
Fig. 6.3: SEAL system diagram.

Table 6.1: SEAL R2 power and mass budget.
Part Current @ 3.3v (mA) Power Draw (mW) Mass (g) Est. Cost (USD) Source
Atmel CPU 20 66 3 $5.00 Digikey
ETEK GPS 50 165 25 $60.00 Sparkfun
ETEK GPS Cable Assy 0 0 10 $0.00 Sparkfun
LiPoly Cell 0 0 22 $10.00 Sparkfun
MicroSD Card 20 66 1.5 $12.00
MicroSD Card Holder 0 0 3 $3.00 Sparkfun
Mini-USB Plug 0 0 5 $1.00 Digikey
PCB @ 30cm2 0 0 20 $40.00
LEDs 5 16.5 1 $2.00 Digikey
Misc. Electronics 10 33 10 $15.00
EasySen SBT80 8 26.4 15 $190.00 EasySen LLC
Total 113 372.9 115.5 $338.00
55
56
6.2.1 Power System
SEAL’s power system (fig. 6.4) is based on a high-performance Lithium-ion-polymer
(Li-Poly) 1200mAh single battery cell. A Texas Instruments TPS63001 80-90% efficient
single-inductor Buck-Boost converter [60] provides system power. Safe battery charging is
handled by a National Semiconductor LM3658 USB-compatible Li-Poly charging chip [61]
which also allows for higher-current charging from an alternative source, such as an AC
adapter. A Linear Technologies LTC1998 low battery detect chip [62] rounds out the power
system design, with a hardware interrupt to give the CPU warning of an impending system
power loss. Actual non-sleep run times have been in line with the anticipated eight hours
at 80% efficiency (1200mAh×0.80/115mA= 8.3h).
SEAL’s power system also includes a Texas Instruments TPS2097 High-Side MOSFET
Switch [63], allowing the main elements of the system to be shut down to allow various low
power modes (see fig. 6.5) for instance, to shut the Wi-Fi interface down when not in GPS
range of an acceptable known access point. With the TPS2097’s over-current protection,
this power distribution scheme also gives power separation to the various subsystems; if one
part fails and shorts its power rail, the other systems and CPU will not be affected and
SEAL can carry on in a degraded mode.
6.2.2 SEAL Sensor Interfaces
SEAL is foremost a sensor platform, and as such has interfaces for both analog and
digital sensors. SEAL’s sensor interface includes:
USB Power 3.3V

Wall Power LM3658 LTC1998 TPS63001
LiPoly + Low-Batt Buck-Boost
EN
Charger Detect Converter
Power Shutdown Interrupt
Fig. 6.4: SEAL power diagram.

57
uBlox
SEAL LiPoly LEA-5H
Power GPS Receiver
System Power
Atmel TI TPS2097 WiFi

AT90USB1287 MOSFET Interface
Micro- Power Switch Power
controller
Sensor Power
System
Fig. 6.5: SEAL power distribution diagram.
• A Texas Instruments ADS8433 analog-to-digital converter [64] (bearing the Burr-
Brown brand) allows for eight analog input channels with 16-bit resolution;
• Eight individual general-purpose digital I/O (GPIO) lines (alternatively exposing the
CPU’s 2-Wire serial interface for IIC communications);
• A dedicated external hardware interrupt CPU line;
• 3x pulse-width-modulation (PWM) outputs (alternately three more GPIO lines);
• Switched analog and digital 3.3V sensor power.
6.2.3 GPS Integration
SEAL’s GPS unit is the LEA-5H from u-Blox AG [65], and is one of the most advanced
consumer GPS modules available. In its 22.4x17.0mm, 2.1g package, it has a 50-channel
satellite tracking engine, -160dBm maximum sensitivity, and includes flash memory to retain
GPS almanac and configuration data. In addition to the reception of standard American
GPS signals, the LEA-5H can also receive European GALILEO positioning signals. A
passive ceramic patch antenna on a ground plane is included with SEAL, but may be
upgraded to a helical model in the future for better coverage in various orientations.
58
6.2.4 Data Memory
While traditional dataloggers—even in the last 10 years—use EEPROM or other small
and generally expensive memory [54], SEAL uses cheap, large, consumer Flash Memory in
the form of MicroSD cards. Using Microsoft’s FAT16 file format (via code from Roland
Riegel [66]) makes SEAL’s data logs easily accessible from any modern operating system.
Many laptop manufactures include MMC/SecureDigital card readers standard with their
PC hardware, which natively read MicroSD memory cards. MicroSD cards are very small
(15mm × 11mm × 0.7mm) and very light (0.40g), and their capacities are expected to
continue increasing. SEAL has been tested with cards ranging from 512MB to 2GB (the
maximum physical limit for the FAT16 filesystem), although at the time of this writing, the
largest MicroSD card is 8GB.
6.2.5 USB Interface
A USB interface is included in SEAL to give it maximal usability for many appli-
cations. At a base level, the USB connection charges the Li-Poly battery. Atmel, Inc.’s
Flexible In-system Programmer Software, or “FLIP,” in-system programming tool allows
for AT90USBXX firmware upgrades over the USB, so users can flash custom or updated
firmwares in-field by starting SEAL in Device Firmware Upgrade (DFU) mode. Using stan-
dard USB device profiles such as the generic Mass Storage Device (MSD) device class, future
software upgrades will allow users to retrieve data stored on the MicroSD flash card over
the USB interface, or change logging parameters such as data channels, frequencies, Wi-Fi
settings, etc.
6.2.6 Optional Wi-Fi Interface
Wi-Fi is a ubiquitous wireless data-link layer networking standard and adds many
possibilities to SEAL. Although Wi-Fi has large power requirements (up to 750mA burst
and around 400mA steady-state), a Wi-Fi + TCP/IP enabled SEAL unit reports all or
some of its data to any server on the Internet, or periodically upload collected data to some
central data server. It is also possible to communicate with other SEAL units in range,
59
effectively converting the SEALs into a sensor mesh network.
A Lantronix Matchport b/g unit [67] has been tested with SEAL as seen in fig. 6.2.
6.2.7 User Interface
A minimal, yet functional user interface is included with SEAL. Three LEDs indicate:
• First, charging status of the Li-Poly battery;
• Second, the GPS 3D lock status;
• Thirdly, System heartbeat/logging indicator.
Three push buttons are also part of SEAL:
• The first activates Atmel’s USB DFU during start up (also available as a soft button
during normal operation);
• The second is a dedicated soft button for stopping and starting the datalogging pre-
cess;
• The third button is attached to an external hardware CPU interrupt allowing an
operator to press the button and create an “on demand” data point.
6.3 Data Storage
SEAL logs its data on a MicroSD flash card, in a Microsoft FAT16 filesystem. The
formatting chosen for the data log files is GPX: the GPS eXchange Format [68]. This is
an XML schema describing GPS (and other) data such as Routes, Tracks, and Waypoints.
SEAL’s data is logged as successive Track points (<trkpt></trkpt>) in a single Track
(<trk></trk>). An example data point is in fig. 6.6.
The GPX format allows for full interoperability in all modern operating systems as
well as full extensibility for any possible sensor or data requirements. GPS also allows use
of modern programming development and analysis tools (Perl, C#, MATLAB, etc.) for
working on SEAL data. Additionally, using standard libraries and a minimal amount of
60
<?xml version=” 1 . 0 ” e n c o d i n g=” u t f −8” standalone=no ?>

<gpx c r e a t o r=”CSOIS SEAL D a t a l o g g e r ” version=” 1 . 1 ”>
<t r k>
<t r k p t l a t=” 4 1 . 7 4 3 1 8 7 0 0 ” l o n=” −111.80720000 ”>
<g p s l o c k>1</ g p s l o c k>
<time>2008−02−04 T 0 3 : 2 2 : 5 6 . 1 6 4 Z</ time>
<e l e>1 3 6 1 . 7 9 8</ e l e>
<s p e e d>0 . 0 0 1</ s p e e d>
<co2>132</ co2>
<a c c e l y>2</ a c c e l y>
<t e m p e r a t u r e>11</ t e m p e r a t u r e>
<nh3>502</nh3>
</ t r k p t>
<t r k p t>
....
</ t r k p t>
</ t r k>
</ gpx>
Fig. 6.6: SEAL sample GPX log.
interpretation code, it is possible to transfer data logs from any number of SEAL units into
a relational or object database such as MySQL [69] or GOODS [70].
The GPX format produced by SEAL also loads directly into Google Earth [71] and
NASA WorldWind [72], allowing instantaneous 3D plotting of a data log. Using mapping
tools such as GPSVisualizer [73], it is possible to produce plot outputs with colors that vary
according to sensor readings. For instance, plotting CO2 on the map gives a colored visual
representation of the spatial concentration of the gas.
SEAL’s hardware includes a warning external hardware interrupt signal that allows the
CPU to close the GPX file and end the logging session when the battery is depleted (see
fig. 6.4) to avoid corruption of data.
6.4 Sensor Options
SEAL’s first conception included an interface to the EasySen Technologies SBT80 sen-
sor board [74], giving the system the following default sensors:
• Visual light,
• Infrared light,
61
• Acoustic sound pressure,
• Temperature,
• Dual-axis magnetometer,
• Dual-axis accelerometer.
The SBT80 is commercially available and fits the SEAL paradigm of small, light, low-power
sensing hardware.
SEAL has also been equipped with powered CO2 (model MG811 [75]) and NH3 (model
SP-53 [76]) gas sensors, from Hanwei Electronics Co., and FIS, Inc., respectively. These
sensors are small and light, but require approximately 1.2W each to power their heating
elements.
Other possibilities include pollutant, air pressure, and humidity sensors.
6.5 Results
Figures 6.7 and 6.8 show plots of uncalibrated data taken during a car trip. A SEAL
module was attached to the hood of a car via a magnetic mount and the sensors were
Fig. 6.7: Plot of uncalibrated CO2 vs. location via GPSVisualizer.

62
Fig. 6.8: Plot of uncalibrated NH3 vs. location via GPSVisualizer.
first allowed to warm up to operating temperature. During the drive, various vehicles were
followed and changed the relative amounts of CO2 and NH3 in the data log. The overall
location dataset is seen in 3D in fig. 6.9.
6.6 Applications
While SEAL’s small form factor and low cost are advantages, the integrated GPS
receiver allows not only for spatially-related data sets but for logging scenarios that are
unique to SEAL.
6.6.1 UAVs
Small Unmanned Aerial Vehicles (UAVs) are growing in popularity for various mon-
itoring purposes, both military and non-military. Typically, UAVs send their telemetry
back to their ground station in real-time, using various kinds of medium to high-speed data
links. However, for scenarios that do not demand hard real-time data such as long-term
environmental monitoring (fig. 6.10) or very high resolution experimental data which pro-
duces large data sets, it is possible to use the GPS receiver to enable the Wi-Fi interface
63
Fig. 6.9: Location data from gs. 6.7 and 6.8 plotted in Google Earth.
only when the UAV ies nearby the co-ordinates of a known access point ( g. 6.11), and
put the UAV into a holding pattern until the downlink is nished.
Use of Wi-Fi in this manner allows for maximum data transfer and maximum run-
1
time, given that the transmit power required decreases as a function of r2
(where r is the
transmission distance).
Additionally, given SEAL s ability to track multiple sensors and data sources, a UAV
(or UAVs) tted with meteorological sensors for barometric pressure, temperature, and
relative humidity can estimate wind speed in- ight and serve as a mobile meteorological
station.
64
UAV:
Lat:2 Lon:3
SE
A
L
Wi-Fi Base:
Lat:1 Lon:1
Fig. 6.10: UAV monitoring cattle in a remote location.
UAV:
Lat:1 Lon:2
L
A
SE
Wi-Fi Base:
Lat:1 Lon:1
Fig. 6.11: UAV returning to Wi-Fi base station for high-speed data downlink.
65
6.6.2 Fleet Vehicles
SEAL can be used on a single vehicle or a fleet of vehicles such as mail trucks, garbage
trucks, or public transportation systems such as city buses. Such an arrangement would
give many different sets of data from the same or similar routes over time, and could help
model changes in environmental status such as pollutant levels over different times of the
day, week, or year.
With SEAL’s external hardware interrupt connected to a device that “counts” pas-
sengers on a public bus, passenger trends such as crowd tendencies over times and routes
can be established, and the bus system can be adjusted to re-establish routes, and more
optimally accommodate more popular stops. This will increase the efficiency of the overall
public transportation system.
6.7 Chapter Summary
Personal remote sensing requires sensors to operate. A small, light, battery-powered
GPS datalogger is presented in this chapter, along with technical implementation details
such as embedded processor and power system. Some applications for small, mobile, in-
expensive sensing packages such as SEAL are presented (such as use in fleet vehicles), but
many more exist, and only limited by a designer’s imagination.

66
Chapter 7
Conclusion
Personal Remote Sensing is an emerging technology, and will change the way data is
collected and consumed by individuals and small groups. Creation of scientifically accu-
rate data while preserving safety and mission security requires innovation and advanced
electronic design. Toward this end, the AggieAir system has been developed.
The current state of the small UAV AggieAir system development is presented in this
thesis. System level plans for multi-UAV and multi-payload scenarios have been docu-
mented, inertial navigation hardware and estimation software has been shown, and example
payloads have been detailed.
7.1 Summary
This thesis presents work done towards a Personal Remote Sensing (PRS) system:
small Unmanned Aerial Vehicles (UAVs) with electronic, control, and sensing subsystems.
Based on papers presented to conferences (MESA2009, partially included in Chapter 3, 4,
and 5 [30, 77, 78], and AutoTestCon2008 partially included in Chapter 6 [79]), as well as
other work on PRS, multiple levels of engineering are detailed: complex multi-UAV data
flow, attitude estimation filters real-time microprocessor functionality, and small, mobile
power systems. Wherever possible, Open-Source tools and designs have been used, mod-
ified, or studied, providing excellent cost to performance ratios in most cases. First, the
overall PRS UAV architecture, AggieAir, is presented with a motivating examples (Ghost-
Eye and EagleEye camera payloads). Then, AggieNav, an inertial navigation system for
small UAVs is detailed, along with information about a Kalman filter for estimation of UAV
navigation, position and attitude. Finally, the Spatial Environment Autonomous Logger
(SEAL), a general-purpose wireless datalogger for small UAV applications is presented, with
67
application examples with and without small UAVs. This work represents designs based on
two years of organic small UAV system growth, and provides integrated solutions to many
problems of small UAV communication, sensing, and control.
7.2 Future Work
As civilian PRS applications and inexpensive enabling technology for small UAVs de-
velop, future work towards Multiple UAV (MUAV) formation sensing, mixed fixed-wing,
rotorcraft, ground-based or even underground scenarios can progress. Remote sensing has
many aspects; some are represented well by current small UAV capabilities, while some
are too heavy or costly to fly with the increased risk of a small UAV airframe. Devel-
opment toward higher UAV system affordability, reliability as well as miniaturization and
development of payloads will spur capabilities of small UAV systems.
Specific future work on the AggieAir system should be as follows:
• Full implementation and testing of the JAUS capabilities for the CSOIS UAVs;
• AggieNav must be updated to connect with the Gumstix Overo line of computer-on-
modules;
• Further evaluation must be done on the AggieNav Kalman filter, and other filters
such as Direction Cosine Matrix (DCM) filters must be done;
• Implementation and flight testing of Multi-UAV capabilities using JAUS must be
performed;
• More PRS mission profiles can be defined, and more payloads developed and inte-
grated.
General future directions for the AggieAir platform:
• Cognitive behaviors for the UAVs can be defined for swarming covens;
• Resilience should be integrated into the AggieAir platform;

68
• Scenarios for loss of a UAV or compensation for a degraded UAV can be defined;
• Internal scanning of the flying Wi-Fi mesh can performed to assure there are no
intruders on the network.

69
References
[1] J. Ward, “Space-time adaptive processing for airborne RADAR,” Lincoln Laboratory
Technical Report ESC-TR-94-109, 1995.
[2] R. A. Ferrare, C. A. Hostetler, J. W. Hair, A. Cook, D. Harper, S. P. Burton, M. D.

Obland, R. Rogers, A. J. Swanson, A. D. Clarke, C. S. McNaughton, Y. Shinozuka,
J. Redemann, J. M. Livingston, P. B. Russell, C. A. Brock, D. A. Lack, K. D. Froyd,
J. A. Ogren, B. Andrews, A. Laskin, R. Moffet, M. K. Gilles, A. Nenes, T. L. Lathem,
and P. Liu, “Airborne high spectral resolution lidar aerosol measurements during ARC-
TAS,” American Geophysical Union Fall Meeting Abstracts, p. A164, 2009.
[3] J. A. Shaw, J. A. Churnside, J. J. Wilson, N. E. Lerner, , R. R. Tiensvold, P. E. Bigelow,

and T. M. Koel, “Airborne lidar mapping of invasive lake trout in Yellowstone Lake,”
Proceedings of the 24th International Laser Radar Conference, 2008.
[4] J. A. Shaw, N. L. Seldomridge, D. L. Dunkle, P. W. Nugent, L. H. Spangler, J. J.

Bromenshenk, C. B. Henderson, J. H. Churnside, and J. J. Wilson, “Polarization lidar
measurements of honey bees in flight for locating land mines,” Optics Express, vol. 13,
no. 15, pp. 5853–5863, 2005.
[5] Productwiki.com, [http://www.productwiki.com/].
[6] The Toy Store, Inc., [http://www.toystoreinc.com/].
[7] WowWee Group, [http://www.wowwee.com/].
[8] ThinkGeek, Inc., [http://thinkgeek.com/].
[9] H. Shimada, E. Shima, K. Tanaka, and T. Nagayoshi, “Use of personal remote sensing
system in grazing land,” in Proceedings of the American Society of Agricultural and
Biological Engineers Annual International Meeting, 2008.
[10] J. A. Gamon, C. B. Field, M. L. Goulden, K. L. Griffin, A. E. Hartley, G. Joel,

J. Penuelas, and R. Valentini, “Relationships between NDVI, canopy structure, and
photosynthesis in three Californian vegetation types,” Ecological Applications, vol. 5,
no. 1, pp. 28–41, 1995.
[11] D. W. Casbeer, Sai-Ming Li, R. W. Beard, T. W. McLain, and R. K. Mehra, “For-

est fire monitoring with multiple small UAVs,” Proceedings of the American Control
Conference, vol. 5, pp. 3530–3535, June 2005.
[12] L. F. Johnson, S. R. Herwitz, S. E. Dunagan, B. M. Lobitz, D. V. Sullivan, and R. E.

Slye, “Collection of ultra high spatial and spectral resolution image data over California
vineyards with a small UAV,” Proceedings of the 30th International Symposium on
Remote Sensing of Environment, vol. 20, no. 845-849, 2003.
70
[13] H. Chao, M. Baumann, A. Jensen, Y. Q. Chen, Y. Cao, W. Ren, and M. McKee,

“Band-reconfigurable multi-uav-based cooperative remote sensing for real-time water
management and distributed irrigation control,” Proceedings of the 2008 International
Federation of Automatic Control World Congress, vol. 17, pp. 11 744–11 749, July 2008.
[14] Ubiquiti Networks, “Bullet2-HP datasheet,” [http://www.ubnt.com/].
[15] L-Com, Inc., “Wireless 2.4 GHz 14 dBi 120 degree vertical polarized sector panel
wireless LAN antenna,” [http://www.l-com.com/].
[16] DD-WRT, [http://www.dd-wrt.com/].
[17] OLSRd, [http://www.olsr.org/].
[18] J. Tisdale, A. Ryan, Z. Kim, D. Tornqvist, and J. K. Hedrick, “A multiple UAV

system for vision-based search and localization,” Proceedings of the 2008 American
Control Conference, pp. 1985–1990, June 2008.
[19] OpenJAUS JAUS architecture, [http://openjaus.com/].
[20] rsync, [http://rsync.samba.org/].
[21] Cygwin, [http://www.cygwin.com/].
[22] OpenSSH, [http://www.openssh.com/].
[23] CSOIS Open Source Autonomous Multiple-UAV project, [http://www.engr.usu.

edu/wiki/index.php/OSAM].
[24] Paparazzi UAV Project, [http://www.recherche.enac.fr/paparazzi/].
[25] A. M. Jensen, “gRAID: A geospatial real-time aerial image display for a low-cost
autonomous multispectral remote sensing,” Master’s thesis, Department of Electrical
and Computer Engineering, Utah State University, Logan, UT, 2009.
[26] The Wikipedia Foundation, [http://en.wikipedia.org/wiki/File:Gumstix_

oconnor.JPG].
[27] Gumstix, Inc., [http://www.gumstix.com/].
[28] Angstrom Software Distribution, [http://www.angstrom-distribution.org/].
[29] BeagleBoard.org, [http://beagleboard.org/].
[30] C. Coopmans, “AggieNav: A small, well integrated navigation sensor system for small
unmanned aerial vehicles,” in Proceedings of the ASME International Design Engineer-
ing Technical Conferences & Computers and Information in Engineering Conference
IDETC/CIE, 2009.
[31] R. Klopfenstein Jr., “Air velocity and flow measurement using a Pitot tube,” Proceed-
ings of The International Society of Automation Transactions, vol. 37, pp. 257–263,
1998.
71
[32] Logitech Inc., [http://www.logitech.com/].
[33] Microstrain, Inc., [http://www.microstrain.com/].
[34] Crossbow, Inc., [http://www.xbow.com/].
[35] Procerus Technologies, [http://www.procerusuav.com/].
[36] Chipworks, Inc., “Sony Playstation 3 game console basic product teardown,”
Online Technical Report, [http://www.chipworks.com/uploadedFiles/Technical_
Competitive_Analysis/Capabilities/Sony_Playstation_report%20(2).pdf].
[37] Analog Devices, Inc., “High precision tri-axis inertial sensor datasheet,” [http:
//www.analog.com/].
[38] R. Hirokawa, N. Kajiwara, and R. Ohata, “Low-cost miniature GPS/INS

for small UAVs with reduced order Kalman filter,” Oral Report, Nov. 2008,
[http://www.gnss-pnt.org/symposium2008/abstract/poster/P-1/7-421-a.pdf].
[39] A. F. V. de Affonseca, “Estimation of angular positions of a UAV from inertial mea-

surements,” Master’s thesis, Czech Technical University in Prague, 2008.
[40] Honeywell International, Inc., “3-axis compass with algorithms,” [http://www.

magneticsensors.com/].
[41] Sarantel Group, [http://www.sarantel.com/].
[42] VTi Technologies International, [http://vti.fi/].
[43] Texas Instruments, Inc., “TPS6211x series datasheet,” [http://www.ti.com/].
[44] Atmel Corporation, “AVR32 32-bit microcontroller datasheet,” [http://www.atmel.

com/].
[45] H. Chao, Y. Cao, and Y. Q. Chen, “Autopilots for small fixed wing unmanned air
vehicles: a survey,” Proceedings of IEEE International Conference on Mechatronics
and Automation, Aug. 2007.
[46] R. W. Beard, State Estimation for Micro Air Vehicles, Studies in Computational In-
telligence, vol. 70, pp. 173–199. Springer Berlin / Heidelberg, 2007.
[47] A. M. Eldredge, “Improved State Estimation for Miniature Air Vehicles,” Master’s
thesis, Brigham Young University, Provo, UT, Dec. 2006.
[48] R. S. Christiansen, “Design of an Autopilot for Small Unmanned Aerial Vehicles,”

Master’s thesis, Brigham Young University, Dec. 2004.
[49] J. S. Jang and D. Liccardo, “Automation of small UAVs using a low cost MEMS sensor
and embedded computing platform,” Proceedings of the 25th Digital Avionics Systems
Conference, 2006 IEEE/AIAA, pp. 1–9, Oct. 2006.
[50] E. M. Jones and P. Fjeld, “Gimbal angles, gimbal lock, and a fourth gimbal for
Christmas,” [http://www.hq.nasa.gov/office/pao/History/alsj/gimbals.html].
72
[51] G. Welch and G. Bishop, “An introduction to the Kalman filter,” Technical Report,
[http://www.cs.unc.edu/~welch/kalman/kalmanIntro.html].
[52] C. H. Lo, W. C. Peng, C. W. Chen, T. Y. Lin, and C. S. Lin, “CarWeb: A traffic data
collection platform,” Proceedings of the Ninth International Conference on Mobile Data
Management, 2008.
[53] Atmel Corporation, “AT90USBKey hardware user guide,” [http://www.atmel.com/].
[54] R. R. Dedrick, J. D. Halfman, and D. B. McKinney, “An inexpensive, microprocessor-

based, data logging system,” Technical Report, 1999.
[55] S. S. Panahi, S. Ventosa, J. Cadena, A. L. Manuel, A. Bermudez, V. Sallares, J. Piera,

and J. D. Rio, “A low power datalogger based on Compactflash memory for ocean
bottom seismometers (OBS),” Proceedings of Instrumentation and Measurement Tech-
nology Conference, pp. 1278–1281, 17 May 2005.
[56] J. Jalbert, J. Baker, J. Duchesney, P. Pietryka, W. Dalton, D. R. Bildburg, S. Chappel,

R. Nitzel, and K. Holappa, “Solar-powered autonomous underwater vehicle develop-
ment,” Autonomous Undersea Systems Institute, Technical Report, 2003.
[57] V. B. B. Hull, Y. Zhang, K. Chen, M. Goraczko, A. Miu, E. Shih, H. Balakrishnan, and

S. Madden, “Cartel: a distributed mobile sensor computing system,” Proceedings of
the 4th international conference on Embedded networked sensor systems, pp. 125–138,
2006.
[58] Y. Zheng, L. Wang, R. Zhang, X. Xie, and W. Y. Ma, “GeoLife: Managing and under-
standing your past life over maps,” Proceedings of the Ninth International Conference
on Mobile Data Management, 2008.
[59] Atmel, Inc., “8-bit AVR microcontroller with 64/128K bytes of ISP flash and USB
controller datasheet,” [http://www.atmel.com/].
[60] Texas Instruments, Inc., “TPS63001 - 96% buck-boost converter with 1.7A current
switches, 3.3V fixed output voltage datasheet,” 2008, [http://www.ti.com/].
[61] National Semiconductor Corporation, “LM3658 - Dual source USB/AC Li chemistry

charger IC for portable applications datasheet,” [http://www.national.com/].
[62] Linear Technology, “LTC1998 - 2.5uA, 1% accurate SOT-23 comparator and voltage
reference for battery monitoring datasheet,” [http://www.linear.com/].
[63] Texas Instruments, Inc., “TPS209x-series power-distribution switch datasheet,”

[http://www.ti.com/].
[64] Texas Instruments, Inc., “16-bit, 8-channel serial output sampling analog-to-digital
converter datasheet,” [http://www.ti.com/].
[65] u-blox AG, “LEA-5 u-blox 5 modules for GPS and GALILEO datasheet,”
[http://www.u-blox.com/].
73
[66] R. Riegel, “MMC/SD/SDHC card library,” [http://www.roland-riegel.de/

sd-reader/index.html].
[67] Lantronix, Inc., “MatchPort b/g wireless device server,” [http://www.lantronix.
com/].
[68] TopoGrafix, “GPX: the GPS exchange format,” [http://www.topografix.com/gpx.
asp].
[69] MySQL AB, “MySQL 3.23, 4.0, 4.1 Reference Manual,” [http://dev.mysql.com/
doc/refman/4.1/en/index.html].
[70] K. Knizhnik, “Generic Object Oriented Database System documentation,”
[http://www.garret.ru/knizhnik/goods.html].
[71] Google Earth, [http://earth.google.com/].
[72] N. WorldWind, [http://worldwindcentral.com/].
[73] A. Schneider, “GPS Visualizer,” [http://www.gpsvisualizer.com/].
[74] EasySen, LLC., “Multi-modality sensor board for telosb wireless motes,”
[http://www.easysen.com/].
[75] Hanwei Electronics Co., LTD, “MG811 CO2 sensor datasheet.”
[76] FIS, Inc., “FIS gas sensor SP-53A for ammonia detection,” 3-36-3 Kitazono, 664-0891,
Japan.
[77] C. Coopmans and Y. Han, “AggieAir: An integrated and effective small multi-UAV
command, control and data collection architecture,” in Proceedings of the ASME In-
ternational Design Engineering Technical Conferences & Computers and Information
in Engineering Conference IDETC/CIE, 2009.
[78] C. Coopmans, H. Chao, and Y. Chen, “Design and implementation of sensing and
estimation software in aggienav, a small uav navigation platform,” in Proceedings of
the ASME International Design Engineering Technical Conferences & Computers and
Information in Engineering Conference IDETC/CIE, 2009.
[79] C. Coopmans and Y. Chen, “A general-purpose low-cost compact spatial-temporal
data logger and its applications,” in Proceedings of IEEE AutoTestCon, 2008.
[80] CadSoft Computer GmbH, [http://www.cadsoft.de/].
[81] PCBExpress, [http://www.pcbexpress.com/].
[82] Digi-Key Corporation, [http://www.digikey.com/].
[83] The Ganssle Group, [http://www.ganssle.com/].
[84] J. Ganssle, “The firmware handbook.” Butterworth-Heinemann, 2004.
[85] KDevelop project, [http://www.kdevelop.org/].
74
Appendices
75
Appendix A
Lessons Learned During Design and Implementation of
AggieNav and SEAL
The challenges of development of a modern embedded system are demanding, and the
skills required to produce quality products can only partly be learned in school. Classroom
time will give knowledge, but despite lab-based classes, true skill with embedded systems
and other hardware comes not only from knowledge but from priceless experience; from
time spent designing, debugging, and iteration of designs. During their development, Ag-
gieNav and SEAL required much of both of these two crucial qualities. The purpose of
this Appendix is to document some of the lessons learned when implementing the hardware
contained in this thesis.
A.1 System-Level Design
Embedded systems are always a product of trade studies; generally performed by a
system designer with goals beyond simple embedded development. Development requires
embedded work, however, and the embedded scope of a system will have impacts on the
overall system-level development time. Once the impacts of the embedded development
portion of a project have been acknowledged, there are a few points that will help system
designers chose proper hardware for a project.
The central microprocessor is (or processors are) of primary concern for most embedded
projects, and choosing a processor with a highly functional development board is extremely
important to lower development time as well as lowering stress on the developers. The
development board should allow for all of the functionality of the project at hand, as well
as some overhead for additional functionality or helpful debugging practices later in the
project.
76
All embedded projects will require software code to run properly. This code will be de-
signed and iterated upon during the project, but from the of myriad of embedded processing
choices, options with a solid code library (bootstrapping examples, drivers for peripherals,
etc.) will most speed the development process. In addition, in-circuit debugging is a ne-
cessity for many coding tasks; when talking to peripherals such as GPS receivers and other
processors, single-stepping through “live” protocols can be very effective, and the effects
cannot be recreated any other way.
A.2 Embedded Hardware Development
Hardware development is difficult and time consuming because of the manifold set of
errors that can plague the development process. After hours spent developing AggieNav,
SEAL, and other projects, the following is a list of time management considerations.
• Purchase as many development kits from the respective manufacturers as possible for
prototyping.
• Connect (solder) parts with 32-gauge wire wrap wire, and secure the wire with tape.
This will allow the use of an oscilloscope and will greatly ease the debugging process.
• Learn how to solder parts or hire the services of someone capable of doing quality work.
There is no reason to waste valuable development time on poor quality hardware.
• Work toward a hardware PCB as early as possible once the first prototypes are func-
tional. These prototypes tend to be less durable and breakage will cause more lost
time.
Once the time has come for PCB development, Eagle PCB by CadSoft [80] is recom-
mended for small to medium scale jobs (barring preferred options). CadSoft allows the free
version to Eagle to create medium-size, 2-layer PCBs for non-commercial use: all of the
SEAL and AggieNav prototypes shown in this thesis were created with the free version of
Eagle.
77
A quickturn PCB boardhouse is vital for prototyping. SEAL and AggieNav prototype
boards were made by PCBExpress [81], a trustworthy company at the time of this writing.
It should be noted that the boardhouse’s specifications for trace spacing and hole sizing
should be adhered to strictly to avoid unexpected board features.
Once the PCBs have been sent to the boardhouse, the time will have come to order
the parts for the prototypes. Eagle has a function (found in the “User Scripts”) to track
parts used in a project in a simple text-based database. It is possible to keep part numbers
for several vendors in this database, but it is most simple, if at all possible, to restrict the
parts for a given project to a single reliable vendor such as Digi-Key [82].
A.3 Embedded Software Development
Embedded software development is more challenging than hardware development, sim-
ply because the task appears less difficult than it actually is. A good author for further
reading on this subject is Jack Ganssle [83], in particular his “Firmware Handbook” [84].
Because the hardware is the underlying fabric upon which the software is arraigned, simple
unexpected “glitches” in the hardware can leave the software dealing with any number of
problems, both manageable and unmanageable.
The effort in embedded software is put toward management of events and errors (and
bugs), so the overall system works like any other electronic part; one that does not need
intervention for proper operation, or put more simply, something reliable. Once the hard-
ware is chosen for a project, the software can begin to materialize. More or less strenuous
testing will occur during development depending on the importance of the project and time
allotted. Because embedded systems rarely have memory protection units, in addition to
good code hygiene, planned unit testing of some kind is recommended as this will force
software authors to thoroughly plan the functionality of their code.
The debugging of protocols, such as I2C or serial, can be a demanding task. Debugging
with an ICE is usually a pleasant experience, but effectively eliminating elusive bugs in real-
time systems is sometimes impossible with ICE devices alone. Functions like data transfer
over protocols need to be fast and concurrent, and the state machines associated must be
78
robust. Specific to protocol debugging (and the debugging of incoming data from devices
from various vendors with differing packet specifications), the following techniques have
proven themselves for debugging and are worth learning.
• Software-to-software: Capture the embedded code (in the case of I2C or another
protocol with specialized hardware), and move the code into a local C-compiler en-
vironment with a quality PC debugger such as KDevelop [85], and write wrapper
functions to handle the I/O. This will allow the developer to control many factors and
test complex receiver state machines easily.
• Software-to-hardware: If the device in question uses a serial port, attach the device
hardware (such as a GPS unit) in question to the PC, and allow the software under
test to run on the PC, and receive data in real-time from the device. With the help
of the PC debugger, this process can be accelerated greatly.
• Hardware-to-hardware (captive): After recording a dataset onto the PC, attach the
embedded system with the code under test to the PC in lieu of the device. This will
allow the transmission of serial data from the local PC to the embedded target in a
controlled manner, and allow data dumps of arbitrary completeness and error-levels
for better testing of robustness of the target system.
• Hardware-to-hardware (actual): Testing of the embedded system and the sender de-
vice in their final configuration. If the above debugging steps have been taken, the
errors experienced in this testing configuration will be solely due to the other parts of
the existing embedded system and the interface code to the code under test.
A.4 SEAL Development Narrative
For SEAL, a low-power chip with built-in USB functionality was chosen to lower the
part count, and the AT90USB-series is packaged with many USB software implementa-
tion examples. This chip proved to be a good choice because the development hardware
(AT90USBKey) was in a very small form-factor and allowed the first SEAL prototype to be
79
constructed directly by building around the inexpensive development board. In addition,
the Atmel STK5000 development kit was useful for SEAL development, as well as several
other projects since completed by other members of CSOIS.
Development of SEAL has so far involved three prototypes: a hand-made prototype
seen in fig. 6.1, a prototype created in relative haste (fig. 6.2), and a third prototype
(produced in slightly less haste) seen in fig. A.1.
The first prototype was simple, and its creation was a mainly matter of soldering and
tape (this is evident in the figure). The second prototype was made under extreme time
pressures (the entirety of the design, build, and test process was done in under two weeks),
and was, in the interest of production time, produced using soldermask-free, raw copper
PCBs. The decision to use PCBs without soldermask was a poor choice, and the resulting
stray copper slivers plagued the design for many unproductive hours. Although most of the
functionality of the SEAL board, such as battery charging and discharging, worked well,
these parts were quite difficult to mount on the PCBs, and time was lost to the mounting
and testing of very small, leadless chip packages. Official manufacturer development kits
would have saved considerable time in this phase of the development.
Due to hardware limitations, the AT90USB chip chosen for SEAL has only a single serial
port peripheral. The Wi-Fi interface and GPS both use low-voltage serial communication,
and in SEAL revision 1, it was decided to use a SPI-to-serial convertor chip to interface the
Wi-Fi module, and attach the GPS to the serial port. This ended poorly, as the converter
chip refused to oscillate, despite being attached to crystal oscillator hardware as described in
its datasheet. The third iteration, SEAL revision 2, was constructed by using the hardware
serial interface for the Wi-Fi, and a special software UART was written based on a hardware
interrupt pin and the AT90 timer hardware. This interrupt-based approach worked much
better than the previous attempt, and avoided the use of several parts on the PCB.
A.5 AggieNav Development Narrative
The SEAL software development had left an Atmel USB JTAG-ICE tool, which allowed
development and debugging of the AVR32 series of application processors in Linux as well
80
Fig. A.1: SEAL Revision 2 hardware.
as Windows. Since a goal of the AggieNav project included a Linux computer which needed
software development, the AVR32A256B processor was chosen for AggieNav, in addition to
its purportedly large library of example software.
AggieNav was built entirely without development board kits, partially because the
specific clock/crystal configuration chosen was not realizable on the Atmel boards, and
partly because it was thought that avoiding purchasing of development kits would save
time and money. Although the first round of AggieNav PCBs were made with relatively
few errors, time was still taken interfacing with the Analog Devices IMU part, as well as
the Honeywell compass part, due to the process of mounting and providing power. Hours
of development time would have been saved if development kits for the IMU and compass
parts had been purchased before starting the prototype process.
The VTi SCP-series pressure sensors used in AggieNav were difficult to mount, due to
their packaging. The plastic casings were made from a relatively low temperature plastic,
and the electrical contacts, while metal, were apt to melt off if a soldering iron was brought
close to them. While a heat gun was used for mounting the pressure sensors, the pads
created on the AggieNav PCBs were of the size recommended by the manufacturer, and
were not large enough to provide any tolerance in mounting and would cause the parts
to appear mounted when they were not. This problem was overcome by “tapping” the
81
PCB with a tool such as a tweezers while the board was under a heat gun and locally at
temperature, helping the chips to settle over their pads, and connect with the molten solder
under the chips.
The AggieNav software development process was not ideal, due to unexpected factors
in the Atmel software development libraries. Because nearly every I/O pin on the AggieNav
chip was taken by some function, to provide all the functionality needed by AggieNav, the
main crystal was moved to the secondary oscillator on the chip. This was not demonstrated
by Atmel in the development tools, and the Atmel development board did not support this
configuration. Therefore, the software libraries given with the AVR32 toolkit were ignored,
and CSOIS-internal code was written to allow the chip to start up. The AVR32 software
toolset was lacking in other functionality, but has since been updated, and now is more
complete than the first days of AggieNav development.
The power system for AggieNav works well, and should be reused in other CSOIS UAV
hardware projects, since it can be connected directly to the battery-based power system on
the UAVs. In many hours of testing, the power system has yet to cause any upsets or show
any faults.
Lastly, the IMU—while indeed a fine sensor—was new when the AggieNav development
began, and was lacking good documentation references for reading the actual data (a less-
than-clear datasheet). A support request possibly would have expedited this process. Once
the data was being read from the sensor, the rest of the project was straightforward.
A.6 Lessons Learned Conclusion
Embedded development is a difficult task, but manageable when approached correctly.
Although knowledge is important, experience is priceless. The lessons learned from SEAL
and AggieNav are all part of this development process, and the use of proper system design,
implementation techniques (such as the use of vendor development kits, when necessary)
will save hours of time.

82
Appendix B
AggieNav V1.2 Electronic Schematics

Pas 1
Pas 1
Pas 1
+3V3
Sup 0
C8 C9 C10
Sup 0
47nF 100nF 33nF
DGND AVR32UCB
Pas 1 Pas 1
Pas 1 Pas 1
Pas 1 Pas 1
+3V3
Sup 0
C11 C12 C13 AVR32B_TQFP64
U3
47nF 100nF 33nF AVR32 USB
I/O 0 21 Compass Set/Reset Control
21-VDDIN 53047-04
Pas 1
Pas 1 Sup 0
Pas 1
0
52 I/OVBUS_AVR32 Pas 0
52-VBUS R14 AVR_USB-1
Pas 1
Pas 1
DGND 51 I/O 0 Pas 1 Pas 0 Pas 1
51-DM R15 AVR_USB-2
C16 C17 I/O 0 32 0 1
50 I/OPas Pas 1 Pas 0
+5V
32-VDDIO 50-DP 22 AVR_USB-3 R16
Sup 0
Sup 0
Pas 0
Sup 0
I/O 0 48 Pas 0 Pas 1 Pas 1 Pas 1 Pas 1
48-VDDIO 22 AVR_USB-4
Sup 0
2.2uF 470pF I/O 0 64 T1B
64-VDDIO 220
9 I/O 0 ADC_00
1uF
Pas 1
Pas 1
Pas 1
Pas 1
Pas 1
Pas 0
C18
9-PA03 DGND DGND
I/O 0 20 10 I/O 0 ADC_01 Pas 0
DGND C19 C20 C21 20-VDDOUT 10-PA04
11 I/O 0 MAG_X_SR Pas 1 Pas 1
11-PA05
I/O 0 8 12 I/O 0 MAG_Y_SR
Sup 0
2.2uF 100nF 33nF 8-VDDCORE 12-PA06
I/O 0 22 13 I/O 0 MAG_Z_SR
C22
22-VDDCORE 13-PA07
Pas 0 Pas 0
Pas 1
Pas 1
Pas 1
I/O 0 56 14 I/O 0 GS_DETECT Pas 1 Pas 1 3D Magnetic Compass
56-VDDCORE 14-PA08
Pas 1
Pas 1
Pas 1
DGND 28 I/O 0 MAG_I2C_SCL T1A U4
28-PA09 HMC6343
I/O 0 I/O 0
+3V3
C24 C25 C26 53 29 MAG_I2C_SDA

Sup 0
C23
53-VDDPLL 29-PA10
30 I/O 0 Pas 0 3 Pwr 0
0.1uF 0.1uF
RESET 30-PA11 3-VDD1
Sup 0
JTAG I/O 0 In 0 Pwr 0
+3V3
+3V3
2.2uF 100nF 33nF 31 IMU_RST* 24 21
Sup 0
Sup 0
31-PA12 24-XOFF+ 21-VDD2
Sup 0
Pas 1
Pas 1 10 9 Pas 1 I/O 0 63

RESET 33 I/O 0 DFU_BUTTON In 0 20 11 Pwr 0
Pas 1
Pas 1
Pas 1
Pas 0 Sup 0 Pas 0
63-RESET_N 33-PA13 20-YOFF+ 11-VDD3
Pas 1
Pas 1 8 7 Pas 1 34 I/O 0 SENSOR_MOSI In 0 16 C28
DGND 34-PA14 DGND 16ZOFF+
.1uF Pas 1 6 5 Pas 1 I/O 0 3 35 I/O 0 SENSOR_SCK 2 NC 0
3-TDI 35-PA15 DGND 2
Pas 1 Pas 1 I/O 0 I/O 0 In 0 NC 0
+5V
4 3 4 36 SENSOR_IMU_CS R17 23 4 1uF
Sup 0
Pas 0
Sup 0
4-TDO 36-PA16 Pas 1 Pas 1 Pas 1 Pas 1 23-XOFF- 4
Sup 0
C30 Pas 1 2 1 Pas 1 I/O 0 5 37 I/O 0 SENSOR_P1_CS In 0 19 5 NC 0
Pas 1 Sup 0
5-TMS 37-PA17 T2B 19-YOFF- 5

I/O 0 2 39 I/O 0 UART0_RXD_GPS 220 In 0 15 6 NC 0
Pas 1
2-TCK 39-PA18 15-ZOFF- 6 DGND
1uF
Pas 0
C31
40 I/O 0 UART0_TXD_GPS DGND 7 NC 0
DGND 40-PA19 Pas 0 7
44 I/O 0 EX_SPI_CLK 8 NC 0
44-PA20 Pas 1 Pas 1 8
I/O 0 19 45 I/O 0 9 NC 0
+3V3
19-VDDANA 45-PA21 9
Pas 1
Pas 1
Sup 0
I/O 0 18 46 I/O 0 In 0 32
MAG_I2C_SCL 10 NC 0
18-ADVREF 46-PA22 32-SCL 10
C33
C35 C36 47 I/O 0 EX_SPI_MOSI In 0 36
MAG_I2C_SDA 12 NC 0
Pas 0 Pas 0
47-PA23 Pas 1 Pas 1 36-SDA 12
59 I/O 0 EX_SPI_MISO 13 NC 0
59-PA24 T2A 13
0 1
100nF I/O33nF 60 I/O 0 SENSOR_MISO Out 0 33 14 NC 0
1-GND1 60-PA25 33-TX 14
C37
I/O 0 17 61 I/O 0 EX_UART2_TXD In 0 1 17 NC 0
Sup 0
Pas 1
Pas 1
17-GND2 61-PA26 Pas 0 1-RX 17
0.1uF 0.1uF
I/O 0 23 62 I/O 0 EX_UART2_RXD 18 NC 0

23-GND3 62-PA27 18
I/O 0 49 15 I/O 0 26 NC 0
49-GND4 15-PA30 26
Pas 0 Sup 0 Pas 0
DGND 16 I/O 0 Out 0 34 27 NC 0

16-PA31 34-SDO 27
6 I/O 0 DGND 28 NC 0
6-PB00 28
7 I/O 0 30 NC 0
+5V
7-PB01 R18 30
Sup 0
Pas 0
Sup 0
24 I/O 0 LOBATT_5.55V Pas 1 Pas 1 Pas 1 Pas 1 I/O 0 22 31 NC 0

24-PB02 22-CS 31
25 I/O 0 LOBATT_5.96V T3B In 0 35
25-PB03 220 35-CS_CTRL
26 I/O 0 EX_SPI_SS 29 Pwr 0
1uF
Pas 0
C39
26-PB04 DGND 29-GND1

27 I/O 0 SENSOR_P2_CS Pas 0 25 Pwr 0
27-PB05 25-GND2
38 I/O 0 Pas 1 Pas 1
38-PB06
Sup 0
43 I/O 0
43-PB07
54 I/O 0
C41
54-PB08
Pas 0 Pas 0
55 I/O 0 Pas 1 Pas 1

55-PB09 DGND
57 I/O 0 LED1_EN T3A
57-PB10
I/O 0
41-PA28
42-PA29
58 LED2_EN
C43
58-PB11
Pas 0
0.1uF 0.1uF
41
42
Pas 0 Sup 0 Pas 0
I/O 0
I/O 0
DGND
Pas 1
Pas 1
Pas 1
Q1
Pas 1
1 2
13pF 13pF
Sup 0
C44 C45
Pas 1
Pas 1
DGND
11/2/09 10:31 PM f=0.85 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.sch (Sheet: 1/1)

83
Pas 1
Pas 1
+3V3
Pas 1
Pas 1
Sup 0
+3V3
Sup 0
1K
1K
R10
R11
R12
47K
R13
47K
RESET DFU_BUTTON
Pas 1 Pas 0
Pas 1 Pas 0
1
1
Pas 1 I/O 0
Pas 1 I/O 0
LED1
LED2
LED1_EN LED2_EN
Pas 1
Pas 1
1
1
Pas 0
Pas 0
220nF 220nF
2
2
C14 C15
Pas 1
Pas 1
SWB SWA
2
2
Sup 0
I/O 0
I/O 0
DGND
netic Compass
U4
HMC6343
+3V3
Sup 0
3 Pwr 0
3-VDD1
21 Pwr 0
21-VDD2
Pas 1
11 Pwr 0
11-VDD3
C28
2 NC 0
6DoF IMU
2
4 NC 0 1uF IMU1
4
NC 0
+5V
5 ADIS1635X
Pas 1 Sup 0
Sup 0
5 Pressure Sensor 1
6 NC 0
Sup 0
Pas 1
Sup 0
6 DGND
Pas 1
7 NC 0 Pwr 0
P$10
7 10-VCC1 P1 C27
8 NC 0 C29 Pwr 0
P$11 In 0
P$21
8 11-VCC2 21-AUX_ADC I/O 0 I/O 0
9 NC 0 Pwr 0
P$12 Out 0
P$20 DGND ATST AVSS DGND
9 12-VCC3 20-AUX_DAC I/O 0 I/O 0 0.1uF
10 NC 0 1uF P$9I/O 0 TRIG AVDD
10 9-DIO2 P_DRDY1 I/O 0 I/O 0 SENSOR_P1_CS
Pas 1
12 NC 0 0
SENSOR_IMU_CS In P$6 P$7I/O 0 DRDY CSB
Pas 1 Sup 0
12 6-CS* 7-DIO1 I/O 0 I/O 0 SENSOR_MISO
13 NC 0 0 CLK MISO
Pas 1
13 DGND SENSOR_MOSI In P$5 5-DIN I/O 0 I/O 0 SENSOR_MOSI
NC 0 0
+3V3
14 SENSOR_MISO Out P$4 DVDD MOSI
Sup 0
14 4-DOUT C32 I/O 0 I/O 0 SENSOR_SCK
17 NC 0 SENSOR_SCK 0
In P$3 DVSS SCK
Sup 0
17 3-SCLK I/O 0 I/O 0

18 NC 0 DVDDS PD
18 0.47uF
26 NC 0 IMU_RST* In 0 P$8
26 8-RST* C34
Pas 1 Pas 1
27 NC 0 DGND
27
28 NC 0
28 0.1uF
30 NC 0 Pwr 0
P$13
30 13-GND1
Pas 1
31 NC 0 Pwr 0
P$14 Pressure Sensor 2
Sup 0
Pas 1
Sup 0
31 14-GND2
Pwr 0
P$15
L 15-GND3 P2 C38
29 Pwr 0
29-GND1 I/O 0 I/O 0
Sup 0
25 Pwr 0 DGND ATST AVSS DGND
25-GND2 I/O 0 I/O 0 0.1uF
TRIG AVDD
P_DRDY2 I/O 0 I/O 0 SENSOR_P2_CS
Sup 0
Pas 1
DRDY CSB
DGND I/O 0 I/O 0 SENSOR_MISO
CLK MISO
Pas 1
I/O 0 I/O 0 SENSOR_MOSI

+3V3
DVDD MOSI
Sup 0
DGND C40 I/O 0 I/O 0 SENSOR_SCK

DVSS SCK
Sup 0
I/O 0 I/O 0
DVDDS PD
0.47uF
C42
Pas 1 Pas 1
DGND
0.1uF
Pas 1
84
U1 3.3V Power Rail
TPS62111
6.8mH
+VBATT
Sup 0
Pwr 0 Pas 1
+3V3
2 14PasOut1 0
Sup 0
VIN1 SW1
Pwr 0 3 15 Out 0
VIN2 SW2 L1
3.3V_POWER_EN In 0 4
EN
Pas 1
Pwr 0 8
Pas 1
VINA
C1
13 Out 0
PG
Pas 1
1uF 10 In 0
FB
Pwr 0 0
R2
750K 1%
9 6 OutLOBATT_5.55V C2
Pas 1
Pas 1
AGND LBO
Pas 0
In 0
D1
MMBD1501-TP
7 1 Pwr 0
C3 LBI PGND1
Pas 1
In 0 5 16 Pwr 0 22uF 1210 X5R
SYNC PGND2
Pas 1
22uF 1210 X5R
Pas 1
Pas 0
Pas 1
PPAD
GND1
GND2
R4
220K 1%
Sup 0
17
11
12
Pwr 0
Pwr 0
Pwr 0
Pas 1
DGND
G
U2 5.0V Power Rail
TPS62112
6.8mH
Pas 1
Pwr 0 Pas 1
+5V
2 14PasOut1 0
Sup 0
VIN1 SW1
Pwr 0 3 15 Out 0
VIN2 SW2 L2
R7
1M
In 0 4
+VBATT
EN
Pas 1
Sup 0
Sup 0
Pwr 0 8
Pas 1
VINA
DB2 C5
PPRZ_TWOG 13 Out 0
3.3V_POWER_EN
Pas 1
PG DGND
Pas 1
1uF 10 In 0
FB
Pas 1
Pwr 0 0
R8
768K 1%
9 6 OutLOBATT_5.96V C6 U
Pas 1
I/O 0
SPI_GND I/O 0
PWR_VBATT AGND LBO
1-SPI_GND PWR_VBATT C7 In 0 7 1 Pwr 0 E
Sup 0
TWOG_3.3 I/O 0
SPI_3.3V LBI PGND1
Pas 1
2-TWOG_3.3V In 0 5 16 Pwr 0 22uF 1210 X5R
EX_SPI_CLK I/O 0
SPI_SCK SYNC PGND2
3-SPI_CLK 22uF 1210 X5R
Pas 1
I/O 0
SPI_MISO
Pas 1
DGND EX_SPI_MISO 4-SPI_MISO
Pas 1
EX_SPI_MOSI I/O 0
SPI_MOSI
5-SPI_MOSI
PPAD
GND1
GND2
EX_SPI_SS I/O 0
SPI_SSEL
6-SPI_SS
EX_SPI_DRDY I/O 0
SPI_DRDY
7-SPI_DRDY I/O 0
PWR_GND
R9
205K 1%
PWR_GND
Sup 0
17
11
12
GNDVIA1
GNDVIA2
GNDVIA3
GNDVIA4
GNDVIA5
GNDVIA6
GNDVIA7
GNDVIA8
S
S
Pwr 0
Pwr 0
Pwr 0
Pas 1
Sup 0
DGND E
I/O 0
I/O 0
I/O 0
I/O 0
I/O 0
I/O 0
I/O 0
I/O 0
E
Sup 0
DGND
U
GNDVIA1
GNDVIA2
GNDVIA3
GNDVIA4
GNDVIA5
GNDVIA6
GNDVIA7
GNDVIA8
DGND F
+3V3
+3V3
Sup 0
Sup 0
Pas 0 Pas 0
DATA_OUT-1 GPS_UART-1
EX_UART2_TXD Pas 0 UART0_TXD_GPSPas 0
+5V
Sup 0
EX_UART2_RXD Pas 0 UART0_RXD_GPSPas 0

Sup 0
Sup 0
Pas 0 Pas 0
DGND DGND
85
Pas 1
Pas 1
Pas 1
+3V3
Sup 0
C8 C9 C10
Sup 0
47nF 100nF 33nF
DGND AVR32UCB
Pas 1 Pas 1
Pas 1 Pas 1
Pas 1 Pas 1
+3V3
Sup 0
C11 C12 C13 AVR32B_TQFP64
U3
47nF 100nF 33nF AVR32 USB
I/O 0 21 Compass Set/Reset Control
Pas 1
21-VDDIN 53047-04
Pas 1 Sup 0
Pas 1
0
52 I/OVBUS_AVR32 Pas 0
52-VBUS R14 AVR_USB-1
Pas 1
Pas 1
DGND 51 I/O 0 Pas 1 Pas 0 Pas 1

+3V3
Sup 0
C2
22uF 1210 X5R
+3V3
Gumstix Verdex Interface
Sup 0 Pas 1
R1
1M
DB1
Sup 0
GS_DETECT Pwr 0 Pwr 0
GND GND
Sup 0
I/O 0
I/O 0 I/O 0 USB_DM
Pas 1
GPIO67_L_DD09 USBH_N1
Pas 0
Pas 0
Pas 0
Pas 0
I/O 0
I/O 0 I/O 0
1
GPIO77_L_BIAS GPIO28_BITCLK DGND
I/O 0 I/O 0
+5V
1
Sup 0
GPIO61_L_DD03 GPIO76_L_PCLK DGND
I/O 0 I/O 0
12
GPIO30_SDATA_OUT GPIO73_L_DD15 USB_DP
I/O 0 I/O 0 Pas 0
12
GPIO66_L_DD08 GPIO72_L_DD14 5
Sup 0
Pwr 0 I/O 0 FF_RXD Pas 0 USB_OTG_ID
2
GND GPIO34_FF_RXD 4 R3
I/O 0 I/O 0 Pas 0 Pas 1 Pas 1 USB_DM
2
GPIO71_L_DD13 GPIO65_L_DD07 3 R5
I/O 0 I/O 0 Pas 0 Pas 1 Pas 1
I/O 0
DGND GPIO70_L_DD12 GPIO63_L_DD05 2 22

Sup 0
I/O 0 I/O 0 Pas 0

I/O 0
GPIO69_L_DD11 GPIO68_L_DD10 1 22
C6 USB_DP I/O 0 I/O 0
USBH_P1 GPIO59_L_DD01
I/O 0 I/O 0
+5V
EX_UART2_TXD
Sup 0
GPIO46_IR_RXD GPIO113_NACRESET DGND ZLLS500TA R6

Pas 1
22uF 1210 X5R I/O 0 I/O 0 EX_UART2_RXD VBUS_GUMSTIX Pas 0 Pas 1 Pas 0 Pas 1
GPIO60_L_DD02 GPIO47_IR_TXD
I/O 0 I/O 0 10uF
GPIO100_FF_CTS GPIO62_L_DD04 D2 600
I/O 0 I/O 0
GPIO9_CLK_32 GPIO31_SYNC
I/O 0 I/O 0 EX_SPI_MOSI C4
GPIO75_L_LCLK GPIO11_SSPRXD2
I/O 0 I/O 0 EX_SPI_SS
Pas 1 Sup 0
GPIO17_PWM1 GPIO14_SSPSFRM2
I/O 0 I/O 0
GPIO58_L_DD00 GPIO29_SDATA_IN0 DGND
Sup 0
SDA I/O 0 Pwr 0
GPIO118_SDA GND
SCL I/O 0 I/O 0
GPIO117_SCL GPIO74_L_FCLK
EX_SPI_CLK I/O 0 I/O 0
GPIO19_SSPSCLK2 GPIO64_L_DD06 DGND
I/O 0 I/O 0
GPIO87_L_DD17 GPIO27_FF_RTS
EX_SPI_MISO I/O 0 I/O 0
GPIO13_SSPTXD2 GPIO101
USB_OTG_ID I/O 0 I/O 0 FF_UART Breakout BT_UART Breakout
N_MANUAL_RESET
GPIO41_SSPRXD3_OTG_ID
I/O 0 I/O 0
GPIO2_SYS_EN GPIO16_PWM0
FF_TXD I/O 0 I/O 0 BT_TXD
GPIO39_FF_TXD GPIO43_BT_TXD Pas 0 Pas 0
I/O 0 I/O 0
+3V3
+3V3
FF_UART-1 BT_UART-1
Sup 0
Sup 0
GPIO86_L_DD16 GPIO45_BT_RTS FF_TXD Pas 0 BT_TXD Pas 0

Pwr 0 I/O 0 BT_RXD FF_UART-2 BT_UART-2
V_BATT GPIO42_BT_RXD FF_RXD Pas 0 BT_RXD Pas 0
Pwr 0 I/O 0 FF_UART-3 BT_UART-3
Sup 0
Pas 0 Pas 0
+5V
V_BATT GPIO44_BT_CTS
Sup 0
Sup 0
Sup 0
Pwr 0 Pwr 0 FF_UART-4 BT_UART-4
V_BATT GND
VERDEX60H4 DGND
DGND DGND
86
Pas 1
Pas 1
+3V3
Pas 1
Pas 1
Sup 0
+3V3
Sup 0
1K
1K
R10
R11
R12
47K
R13
47K
RESET DFU_BUTTON
Pas 1 Pas 0
Pas 1 Pas 0
1
1
Pas 1 I/O 0
Pas 1 I/O 0
LED1
LED2
LED1_EN LED2_EN
Pas 1
Pas 1
1
1
Pas 0
Pas 0
220nF 220nF
87
Appendix C
AggieNav V1.2 Printed Circuit Board Layout

AggieNav top copper layer
11/2/09 6:52 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd
88
AggieNav bottom copper layer
89
AggieNav top silkscreen layer
90
AggieNav bottom copper layer
91
AggieNav drill layer
92
93
Appendix D
SEAL V.2 Electronic Schematics

U8 U6
VCC_27
+5V
Sup 0
Sup 0
I/O 0 1 I/O 0
5 VCC_SD_SBT80 I/O 0 1 I/O 0
5 VCC_SENSOR_5V
1-VIN 5-VOUT 1-VIN 5-VOUT
Pas 1
Pas 1
EN_SD_SBT80_PWR I/O 0 3 4 I/O 0 EN_SENSOR_5V_PWR I/O 0 3 4 I/O 0
3-ON 4-ISET 3-ON 4-ISET
2K
I/O 0 2 I/O 0 2
R16
R15
3.3K
2-GND 2-GND
Sup 0
Sup 0
FPF2125 FPF2125
Pas 1 Sup 0
Pas 1 Sup 0
DGND
DGND
DGND DGND
U10
+5V
U9
Sup 0
I/O 0 I/O 0
VCC_27
1 5 VCC_WIFI
1-VIN 5-VOUT
Sup 0
I/O 0 1 I/O 0
5 VCC_GPS
Pas 1
EN_WIFI_PWR I/O 0 3 4 I/O 0 1-VIN 5-VOUT
3-ON 4-ISET
Pas 1
EN_GPS_PWR I/O 0 3 4 I/O 0
I/O 0 2 3-ON 4-ISET
374
R19
2-GND
Sup 0
I/O 0 2 R17
3.3K
FPF2125 2-GND
Sup 0
Pas 1 Sup 0
DGND FPF2125
DGND
Pas 1 Sup 0
DGND
DGND
VCC_WIFI
I/O 0
1 64 I/O 0 VCC_WIFI
1 64
Sup 0
I/O 0
2 63 I/O 0
2 63GND 80
I/O 0
3 62 I/O 0 Pas 0 Pas 1 Pas 0 Pas 1
3 62
I/O 0
4 61 I/O 0 DGND
4 61VCC LED6 R26
I/O 0 5 60 I/O 0 ANT
5 60 VCC_WIFI
I/O 0 6 59 I/O 0
6 59
I/O 0
P$1
7 58 I/O 0
7 58-LEDLINK 80
I/O 0 8 57 I/O 0 Pas 0 Pas 1 Pas 0 Pas 1
8 57-LEDACT
I/O 0 9 56 I/O 0 GPS
9 56 LED7 R29 VCC_GPS
Pas 1
I/O 0 10 55 I/O 0
P$1
10 55
I/O 0 11 54 I/O 0
I/O 0
11 54 U13
I/O 0 12 53 I/O 0 I/O 0 32 2 I/O 0
12 53 RFIN VCC
I/O 0 13 52 I/O 0 I/O 0 38 36 I/O 0
VCC_27
R30
33K
13 52 MOSI REGEN
I/O 0 14 51 I/O 0 I/O 0 39 1 I/O 0
14 51 MISO RSTN
Sup 0 Pas 1
I/O 0 15 50 I/O 0 I/O 0 43 9 I/O 0 1uF
15 50 CSN BTSEL
I/O 0 I/O 0
VCC_27
I/O 0 16 49 I/O 0 41 18
Pas 1
16 49 CLK VBAT
R31 I/O 0 I/O 0
10K
I/O 0 17 48 I/O 0 40 17 C31
Sup 0Pas 1
17 48 PPS RTC
I/O 0 18 47 I/O 0 I/O 0 42 6 I/O 0
Pas 1 Sup 0 Pas 1 Pas 1
VCC_27
18 47 RX GPIO1
Pas 1
I/O 0 19 46 I/O 0 GPS_SWUART_RX I/O 0 44 5 I/O 0

19 46 R34 LED8 TX GPIO2 DGND
Sup 0
Pas 1 Pas 0 Pas 1 Pas 0 I/O 0 I/O 0
R32
10K
R33
10K
I/O 0 20 45 I/O 0 7 14
20 45 LED GPIO20
I/O 0 21 44 I/O 0 I/O 0 10 8 I/O 0
21 44 80 GND GPIO24 PSE_SEL = Low power mode
Pas 1
Pas 1 Sup 0
I/O 0 22 43 I/O 0 I/O 0 11 4 I/O 0

22 43 GND PIO12
I/O 0 23 42 I/O 0 I/O 0 15 37 I/O 0 DGND
23 42 GND PIO14
Sup 0
I/O 0 24 41 I/O 0 I/O 0 19 33 I/O 0

24-RESET 41GND2 GND GNDRF
Sup 0
I/O 0 25 40 I/O 0 I/O 0 21 31 I/O 0
25 40-DTR GNDRF GNDRF
Sup 0
VCC_WIFI I/O 0 26 39 I/O 0 I/O 0 22 29 I/O 0
26GND3 39-DCD DGND GNDRF GNDRF
I/O 0 27 38 I/O 0 I/O 0 24 28 I/O 0
27 38-CTS DGND GNDRF GNDRF
R36 LED9 I/O 0 28 37 I/O 0 I/O 0 25 27 I/O 0
Pas 1 Pas 0 Pas 1 Pas 0 DGND 28 37-DSR GNDRF GNDRF
I/O 0 29 36 I/O 0
VCC_WIFI 29LEDDCD 36-RI R37
80 I/O 0 30 I/O 0
35 UART0_RX VENUS634SMD Pas 1 Pas 1
Sup 0
30LEDRX 35-TXD
I/O 0 31 I/O 0
34 UART0_TX
R38 LED10 31LEDDTR 34-RXD Sup 0 0
Pas 1 Pas 0 Pas 1 Pas 0 I/O 0 32 33 I/O 0 GNDGPSANT
32LEDTX 33-RTS
DGND
80
DGND
11/3/09 12:10 AM f=0.70 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.sch (Sheet: 1/1)

94
ADS8344
AD0 I/O 0 1 20 I/O 0
VCC_SENSOR_5V
CH0 VCC2
AD1 I/O 0 2 19 I/O 0
SPI_CLK
CH1 DCLK
AD2 I/O 0 3 18 I/O 0
AD_CS
CH2 CS*
AD3 I/O 0 4 17 I/O 0
SPI_MOSI
CH3 DIN
AD4 I/O 0 5 16 I/O 0
CH4 BUSY
AD5 I/O 0 6 15 I/O 0
SPI_MISO
CH5 DOUT
AD6 I/O 0 7 14 I/O 0
CH6 GND2
AD7 I/O 0 8 13 I/O 0
CH7 GND1
Pas 1
Pas 1
I/O 0 9 12 I/O 0
VCC_SENSOR_5V
COM VCC1
VCC_SENSOR_5VI/O 0 10 11 I/O 0
C17 C18
Sup 0
SHDN* VREF
1uF 10uF
Sup 0
Pas 1
Pas 1
AGND
DGND
Pas 1
R18 Pas 1
Sup 0
Sup 0
0
RESET DGND
C20
18pF
AGND
U11
3 I/O 0
Pas 1 Pas 1
In 0 20 44 I/O 0DIO7
2
RESET PA7(AD7)
45 I/O 0DIO6
Sup 0 PA6(AD6)
I/O 0 23 46 I/O 0DIO5
XTAL2 PA5(AD5)
I/O 0 I/O 0
U15
ABMM-B2
1
24 47 DIO4
DGND
C21
18pF
XTAL1 PA4(AD4)
Pas 1 Pas 1 48 I/O 0DIO3
1
PA3(AD3)
1
VCC
49
I/O 0
I/O 0DIO2
Pas 1
Pas 1
PA2(AD2)
Pwr 0 21 50 I/O 0DIO1
Sup 0
VCC PA1(AD1)
Pas 1
Pas 1
Pas 1
Pas 1
Pwr 0
80
80 SupPas0 VCC
80
52 51 I/O 0DIO0
VCC PA0(AD0)
R20
R21
R22
C23 C24 C25 C26
Pwr 0 22 17 I/O 0 SD_CD
GND PB7(PCINT7/OC.0A/OC.1C)
Sup 0
.1uF 1uF Pwr 0 53
.1uF 1uF 16 I/O 0
GND PB6(PCINT6/OC.1B)
Pas 1 Pas 0
Pas 1 Pas 0
Pas 1 Pas 0
15 I/O 0 AD_CS
Pas 1
Pas 1
Pas 1
Pas 1
PB5(PCINT5/OC.1A)
14 I/O 0 SD_CS
LED3
LED4
LED5
LED3 LED4 LED5 DGND PB4(PCINT4/OC.2A)
13 I/O 0 SPI_MISO
PB3(PDO/PCINT3/MISO)
Pas 0
Pas 0
Pas 0
12 I/O 0 SPI_MOSI
PB2(PDI/PCINT2/MOSI)
VCC
11 I/O 0 SPI_CLK
PB1(PCINT1/SCK)
Pas 1
I/O 0 62 0
10 I/OSBT80_SW
AREF PB0(SS/PCINT0)
I/O 0
I/O 0 64
AVCC
Pas 0
Pas 0
Pas 0
Pas 0
Sup 0
I/O 0
Sup 0 Sup 0
Pwr 0 I/O 0
1
63 42 LED4
GND PC7(A15/IC.3/CLK0)
I/O 0
1
41 PWMA
R30
33K
PC6(A14/OC.3A)
IUID 40 I/O 0 PWMB
12
DGND DGND PC5(A13/OC.3B)
1uF Pas 0 I/O 0 5 39 I/O 0 PWMC
12
5 D+ PC4(A12/OC.3C)
Pas 0 I/O 0 4 38 I/O 0LED3
2
4 R27 D- PC3(A11/T.3)
C31 Pas 0 Pas 1 Pas 1 37 I/O 0EN_WIFI_PWR
2
3 R28 PC2(A10)
Pas 0 Pas 1 Pas 1
VCC
36
I/O 0
I/O 0EN_GPS_PWR
Pas 1 Sup 0 Pas 1 Pas 1

2 22 PC1(A9)
Sup 0
Pas 0 Pwr 0 6 35
I/O 0
I/O 0EN_SD_SBT80_PWR
Sup 0
DGND 1 22 UGND PC0(A8)
Pwr 0
10K
3
UVCC
Pwr 0 7 32 I/O 0 EN_SENSOR_5V_PWR
PSE_SEL = Low power mode DGND UCAP PD7(T0)
VBUS Pwr 0 8 31 I/O 0 GPS_SWUART_RX
Pas 1
VBUS PD6(T1)
ND 30 I/O 0
.1uF PD5(XCK1)
29 I/O 0 LED5
PD4(ICP1)
28 I/O 0 UART0_TX
C30 PD3(TXD1/INT3)
I/O 0
VCC
VCC
RESET 27 UART0_RX
PD2(RXD1/INT2)
Pas 1 Sup 0
SV1 26 I/O 0
Sup 0
Sup 0
PD1(OC.2B/SDA/INT1)
Pas 1 10 9 Pas 1 DGND 25 I/O 0 BATTLO
PD0(OC.0B/SCL/INT0)
Pas 1 8 7 Pas 1
Pas 1 6 5 Pas 1 54 I/O 0 2 I/O 0

PF7(ADC7/TDI) PE7(INT7/AIN1/UVCON)
Pas 1 4 3 Pas 1 55 I/O 0 0
1 I/OEXT_INTERUPT
PF6(ADC6/TDO) PE6(INT6/AIN0)
Sup 0
Pas 1 2 1 Pas 1 56 I/O 0 19 I/O 0
PF5(ADC5/TMS) PE5(INT5/TOSC2)
I/O 0 57 0
18 I/OINT_BUTTON
PF4(ADC4/TCK) PE4(INT4/TOSC1)
I/O 0 58
VBATT_AD 9 I/O 0 IUID
DGND PF3(ADC3) PE3(IUID)
I/O 0 59 0
43 I/ODFU_BUTTON
PF2(ADC2) PE2(ALE/HWB)
I/O 0 60 34 I/O 0
PF1(ADC1) PE1(/RD)
I/O 0 61 33 I/O 0
PF0(ADC0) PE0(/WR)
AT90USB1287-MU
95
IC1 External Input Power
7805T
System Power Switch
Pas 1
Pas 1
1 Pas 1 In 0 1 3 Pas 0
VI VO
2 Pas 1 C1 C2
Pas 0
D1
1N4933
GND S1
2
Sup 0
SL1 33uF 33uF
Pas 0 VCC_27
L1
4.7UH 20% 450MA 1210
LM3658SD-B 1 Vcutoff = 2.7V; 100mV Hyst.
Pas 1
Pas 0
Pas 1
Pas 0
Sup
I/O 0
Sup 0
I/O 0 1 10 I/O 0 VBATT Pas 0 2 I/O 0 4 Pas 1 I/O 0

3 Pas 1
DGND CHG_IN BATT 4-VIN 3-SW
Pas 1
Pas 1
Pas 1
Pas 0
+
3
I/O 0 2 Pas 1
R1 Pas 1 C3
VBUS DGND USBPWR U2
I/O 0
9 I/O 0 Sup 0 +
+
TS R4 10K 1206
Pas 1
Pas 1
Pas 1 Pas 1
DGND
1
2.2UF 10V X7R 0805 LTC3405SOT23-6
R2
100K 1%
R3
C4 C5 I/O 0 3 8 I/O 0 LTC1998 I/O 0 1
Pas 1
Pas 1
1 1
GND ISET 2.55K 1% 1206 1K LiPoly Batt 1-RUN
Pas 1
Pas 1
Pas
C6
0.047uF
I/O 0 4 7 I/O 0 Pas 0 Pas 1 Pas 0 Pas 1 I/O 0 4 5 I/O 0
Pas 1
Pas
USB_SEL STAT1 1K V_HA VLOGIC Pas 1 Pas 1 C7
1uF 10uFI/O 0 5 6 I/O 0 Pas 0 Pas
Pas
1 0 Pas 1 C8 C9
EN_B STAT2 LED1 R5
Pas 1
0 1
I/O 0
BATT
11 VBATT_AD
Pas 1
Pas
DAP LED2 R6 887K 1% 4.7UF 6V X7R 0805
Sup
Sup 0
Pas 1
1uF 1uF C10 I/O 0 6 5 I/OPas
0 1 Pas 1
66.5K 1% 787K 1%
6-MODE 5-VFB
Pas 1
I/O 0 3 I/O 0
6 BATTLO
Pas 1
Pas 1
V_THA BATTLO* R8
Pas 1
GND
2-GND
DGND 1uF DGND
-
Pas 1
R9
374K 1%
-
2
2
Sup 0
-
Pas 1
R10
330K 1%
R11 PasPas1 1 R7
147K 1%
I/O 0
I/O 0 Sup 0
I/O 0 Sup 0
Pas 1
Pas 1
DGND DGND
DGND
L2
I/O 0 1
+5V
I/O 0
Pas 1
Sup 0
I/O 0 1 2 I/O 0 4 I/O 0

1 2 4
I/O 0
7
3
3
VLF10040
R12
18.7K 1%
Pas 1
I/O 0 3 5 I/O 0
3-S-S 5-VSW
C11
7-VIN
Pas 1
Pas 1
Pas 1
U5 C12 C13
100uF LTC1370 6 I/O 0
6-NFB
Pas 1
100uF 100uF
Pas 1
I/O 0 8 2 I/O 0
8-GNDPAD 2-FB
Pas 1
Pas 1
4-GND
1-VC
Sup 0
4
1
R13
6.19K 1%
0 0
C14
I/O 0 Pas 1
Pas 1
DGND
SupI/O
Sup 0
0.047uF
Pas 1
Pas 1 Pas 1
DGND
2K
C15
R14
DGND
Sup 0
0.0047uF
Pas 1
Pas 1
DGND
96
U8 U6
VCC_27
+5V
Sup 0
Sup 0
I/O 0 1 I/O 0
5 VCC_SD_SBT80 I/O 0 1 I/O 0
5 VCC_SENSOR_5V
1-VIN 5-VOUT 1-VIN 5-VOUT
Pas 1
Pas 1
EN_SD_SBT80_PWR I/O 0 3 4 I/O 0 EN_SENSOR_5V_PWR I/O 0 3 4 I/O 0

3-ON 4-ISET 3-ON 4-ISET
2K
I/O 0 2 I/O 0 2
R16
R15
3.3K
2-GND 2-GND
Sup 0
Sup 0
FPF2125 FPF2125
1 Sup 0
1 Sup 0
VCC_27
Sup 0
Pas 1
VCC
Pas 1
Pas 1
Pas 1
Pas 1
Sup 0
s1 C7 JP1 SBT-80 Connector
AD6 Pas 0
1 2Pas 0 AD7
R23
47K
R24
47K
R25
47K
4.7UF 6V X7R 0805
Pas 1 RESET DFU_BUTTON INT_BUTTON P_CONT Pas 0
3 4Pas 0 SBT80_SW
Pas 1
Pas 0
1
1
1
5 6Pas 0
Pas 1 I/O 0
Pas 1 I/O 0
Pas 1 I/O 0
Pas 1
Pas 1
Pas 1
1
1
1
JP2
C27 C28 C29
VCC_SD_SBT80 Pas 0
1 2Pas 0
Sup 0
Pas 1
AD0 Pas 0
3 4Pas 0
2
2
2
220nF 220nF 220nF
C16 AD1 Pas 0
5 6Pas 0
Pas 1
Pas 1
Pas 1
DGND AD2 Pas 0
7 8Pas 0
SW1 SW2 SW3
2
2
2
.1uF Pas 0
9 Pas 0
10 AD3
1 0
Sup
0 0
Pas
Sup
I/O
I/O 0
I/O 0
+5V
1
Pas 1
Sup 0
4 I/O 0
AGND
3 DGND
R12
18.7K 1%
JP3 Analog Inputs
VCC_SENSOR_5V Pas 01 2Pas 0 AD0
Pas 1
Pas 1
Pas 1
Pas 1
VCC_SD_SBT80 AD1 Pas 03 4Pas 0 AD2
C12 C13 C19 AD3 Pas 05 6Pas 0 AD4
SD_CS I/O 0 1 AD5 Pas 07 8Pas 0 AD6
100uF 100uF NC
SPI_MISO I/O 0 2 .1uF Pas 09 Pas 0
10 AD7
Pas 1
CS
SPI_MOSI I/O 0 3
Pas 1
Pas 1
Pas 1Sup 0
DI
SPI_CLK I/O 0 4
VCC
I/O 0 5
Pas 1
AGND
SCK
I/O 0
R13
6.19K 1%
6 JP4 Digital I/O
GND C32
I/O 0 7 VCC_SENSOR_5V Pas 01 2Pas 0 DIO0
DO
Pas 1
Pas 1
I/O 0 8 DIO1 Pas 03 4Pas 0 DIO2
RSV 1uF
DIO3 Pas 05 6Pas 0 DIO4
Sup 0
Pas 1
Pas 1
0
I/OCD1 Pas 07 8Pas 0 DIO6
CD1 C22 DIO5
0
I/OCD2 DIO7 Pas 09 Pas 0
10 EXT_INTERUPT
R35
10K
CD2
DGND SD_CD I/O 0
GND1 Pas
110 Pas
12 0 PWMA
SHIELD1 .1uF PWMB
I/O 0
GND2 Pas
130 Pas 0
14 PWMC
Pas 1
SHIELD2
Pas 1Sup 0
Sup 0
DGND
DGND
97
ADS8344
AD0 I/O 0 1 20 I/O 0
VCC_SENSOR_5V
CH0 VCC2
AD1 I/O 0 2 19 I/O 0
SPI_CLK
CH1 DCLK
AD2 I/O 0 3 18 I/O 0
AD_CS
CH2 CS*
AD3 I/O 0 4 17 I/O 0
SPI_MOSI
CH3 DIN
AD4 I/O 0 5 16 I/O 0
CH4 BUSY
AD5 I/O 0 6 15 I/O 0
SPI_MISO
CH5 DOUT
98
Appendix E
SEAL V.2 Printed Circuit Board Layout

SEAL top copper layer
11/3/09 12:12 AM f=2.30 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd
99
SEAL bottom copper layer
100
D1 JP4
R18
SL1
C2 JP1 JP2
JP3
C21
U15
LED2 LED1
C32
U11
R5
R16
U8
LED3
LED10
LED5
LED4
LED9
C20
CR1
LED7
C25
LED6 R6
2
1
C23
C24
C30
R38
R22
S1
SV1
R26 R29 R36 R20R21 R27
C26
R28
X1
CR2
64 33
Multisocket
C11
C29
R25
R24
C28
R31 R33
SEAL top silkscreen layer

R34
1 32
LED8

101
1 CI
4C
1C
5C
61 C
72 C
7C 32 R
2R 1L
6U
7U
3C
01 R 01 C
+
4R
1R
22 C
91 C 51 R
41 U
2U
81 C
71 C
4U
9C
53 R
9R86
RC
8C
11 R
7R 3R
71 R
01U
51 C
73 R
41 R
21 R
9U
41 C
59
U1R
31 R
1$ U
23 R
31U
31 C
21 C
2L
04001 FL V
SEAL bottom copper layer

13 C
03 R

102
SEAL drill layer
103

Architecture Inertial Navigation and Payload Designs For Low-Cost Remote Sensing

Uploaded by

Copyright:

Available Formats

You might also like

Architecture Inertial Navigation and Payload Designs For Low-Cost Remote Sensing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architecture Inertial Navigation and Payload Designs For Low-Cost Remote Sensing

Uploaded by

Copyright:

Available Formats

Utah State University

All Graduate Theses and Dissertations Graduate Studies

Architecture, Inertial Navigation, and Payload Designs for Low-

Follow this and additional works at: https://digitalcommons.usu.edu/etd

Part of the Electrical and Electronics Commons

This Thesis is brought to you for free and open access by

A thesis submitted in partial fulfillment

Dr. YangQuan Chen Dr. Christopher Winstead

Dr. Reyhan Baktur Dr. Byron R. Burnham

UTAH STATE UNIVERSITY

Copyright © Calvin Coopmans 2010

All Rights Reserved

Vehicle-Based Personal Remote Sensing

Calvin Coopmans, Master of Science

Utah State University, 2010

Major Professor: Dr. YangQuan Chen

Based on papers presented to conferences (AutoTestCon2008 and MESA2009), as well as

(SEAL), a general-purpose wireless datalogger for small UAV applications, is presented,

to many problems of small UAV communication, sensing, and control.

To my family; to my friends; and mostly, to my enemies (if any).

continues to show me—crucial mentorship and guidance. Thank you, Gary.

the students even in these desperate economic times.

4.4.1 Inertial Measurement Unit . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 AggieNav versus other small INS solutions. . . . . . . . . . . . . . . . . . . 29

4.2 AggieNav power, mass, and cost budget. . . . . . . . . . . . . . . . . . . . . 38

6.1 SEAL R2 power and mass budget. . . . . . . . . . . . . . . . . . . . . . . . 55

2.1 Passive remote sensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.5 The Spygear ATV-360. Image copyright Toy Store Inc. . . . . . . . . . . . . 7

3.1 AggieAir Aero-team block diagram. . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 AggieAir detailed system architecture. . . . . . . . . . . . . . . . . . . . . . 12

3.3 AggieAir system complexity changes depending on mission requirements. . 13

3.6 Gain pattern of sectorial antenna. . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7 rsync data collection script flowchart. . . . . . . . . . . . . . . . . . . . . . 18

3.8 Paparazzi TWOG board: a fully autonomous autopilot system. . . . . . . . 18

3.9 Gumstix Overo computer-on-module, between a US Quarter coin, an actual

3.10 Ghostfoto CCD camera: modified Canon Powershot SX100-IS. . . . . . . . 22

3.11 AggieAir GhostFoto data flow. . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.12 Aerial image and orthorectified image. . . . . . . . . . . . . . . . . . . . . . 24

3.13 Logitech, Inc. Quickcam Orbit autofocus pan-tilt camera. . . . . . . . . . . 25

4.1 AggieNav hardware block diagram. . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 AggieNav internal data connection diagram. . . . . . . . . . . . . . . . . . . 31

4.3 6-DoF IMU: Analog Devices ADIS16354. . . . . . . . . . . . . . . . . . . . 32

4.4 ADIS1635X block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 Honeywell HMC6343 magnetic compass with tilt-compensation. . . . . . . . 34

4.7 Sample of magnetic compass data from 111609 flight. . . . . . . . . . . . . 34

4.9 GPS flight log from 111609, plotted in Google Earth. . . . . . . . . . . . . . 36

4.10 VTi SCP-1000 pressure sensors. . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.11 Selected pressure data from the 111609 flight. . . . . . . . . . . . . . . . . . 37

4.12 AVR32 processor core diagram. . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13 AggieNav main data collection flowchart. . . . . . . . . . . . . . . . . . . . 42

4.14 AggieNav EKF failover diagram. . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Gyro sensor comparison: p. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 Gyro sensor comparison: q. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Gyro sensor comparison: r. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 Acceleration sensor comparison: x. . . . . . . . . . . . . . . . . . . . . . . . 48

5.5 Acceleration sensor comparison: y. . . . . . . . . . . . . . . . . . . . . . . . 49

5.6 Acceleration sensor comparison: z. . . . . . . . . . . . . . . . . . . . . . . . 49

5.7 Roll angle estimation comparison using the AggieNav EKF. . . . . . . . . . 50