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 VehicleBased Personal Remote Sensing Calvin Coopmans Utah State University

Follow this and additional works at: http://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. Paper 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 [email protected].

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 Major Professor

Dr. Christopher Winstead Committee Member

Dr. Reyhan Baktur Committee Member

Dr. Byron R. Burnham 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, modified, or studied, providing excellent cost to performance ratios in most cases. First, the overall PRS UAV architecture, AggieAir, is presented with a motivating examples (GhostEye 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 support, 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 everrewarding 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 Engineering 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 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2

2 Personal Remote Sensing . . . . . . 2.1 Sensing at a Distance . . . . . 2.2 Personal Sensing . . . . . . . . 2.3 PRS Outlook . . . . . . . . . . 2.4 Thesis Contributions to PRS . 2.5 Chapter Summary . . . . . . .

3 3 4 6 8 9

..... . . . . . . . . . . . . . . . . . . . .

.... . . . . . . . . . . . . . . .

.... . . . . . . . . . . . . . . .

. . . . . .

.... . . . . . . . . . . . . . . .

.... . . . . . . . . . . . . . . .

.... . . . . . . . . . . . . . . .

. . . . . .

.... . . . . . . . . . . . . . . .

.. . . . . .

3 AggieAir: An Integrated and Effective Small Multi-UAV Command, Control, and Data Collection Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 2.4GHz Wi-Fi Communication Link . . . . . . . . . . . . . . . . . . . . . . 3.4 JAUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Coven-Ready Multi-UAV Capabilities . . . . . . . . . . . . . . . . . . . . . 3.6 rsync for Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 AggiePilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Gumstix Embedded Computer System . . . . . . . . . . . . . . . . . . . . . 3.9 AggieNav Navigation Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Example Payload 1: GhostFoto . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 Example Payload 2: EagleEye . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 AggieNav: AggieAir Inertial Measurement and Navigation Design 4.1 UAV Flight Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Low-Cost UAV Navigation Solutions and AggieNav Comparison . . . 4.3 Enter AggieNav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 AggieNav Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

... . . . . . . . .

10 11 11 12 13 15 16 17 19 20 21 23 25 26 28 28 30 30

viii

4.5 4.6 4.7 4.8 4.9

4.4.1 Inertial Measurement Unit . . . . . . . . . . . . . . . . 4.4.2 Magnetic Compass . . . . . . . . . . . . . . . . . . . . . 4.4.3 GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Pressure Sensors . . . . . . . . . . . . . . . . . . . . . . Power System and Temperature . . . . . . . . . . . . . . . . . . Microprocessor and Embedded Software . . . . . . . . . . . . . The Gumstix Processor and AggieNav Extended Kalman Filter Software Failover . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

31 33 33 35 36 36 39 39 40

5 Design and Implementation of Sensing and Estimation Software in AggieNav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 UAV Attitude Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Attitude Representation . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Implementation of an Extended Kalman Filter (EKF) . . . . . . . . 5.1.3 Attitude Estimation using EKF . . . . . . . . . . . . . . . . . . . . . 5.2 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Raw Sensor Data Comparison . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Preliminary Results for Attitude Estimation using Kalman Filter . . 5.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 43 43 44 45 47 47 50 50

6 A Generic UAV Payload: Modular Design . . . 6.1 Related Work . . . . . . . . . . . . . . . . . . . 6.2 SEAL Design Details . . . . . . . . . . . . . . . 6.2.1 Power System . . . . . . . . . . . . . . . 6.2.2 SEAL Sensor Interfaces . . . . . . . . . 6.2.3 GPS Integration . . . . . . . . . . . . . 6.2.4 Data Memory . . . . . . . . . . . . . . . 6.2.5 USB Interface . . . . . . . . . . . . . . . 6.2.6 Optional Wi-Fi Interface . . . . . . . . . 6.2.7 User Interface . . . . . . . . . . . . . . . 6.3 Data Storage . . . . . . . . . . . . . . . . . . . 6.4 Sensor Options . . . . . . . . . . . . . . . . . . 6.5 Results . . . . . . . . . . . . . . . . . . . . . . . 6.6 Applications . . . . . . . . . . . . . . . . . . . . 6.6.1 UAVs . . . . . . . . . . . . . . . . . . . 6.6.2 Fleet Vehicles . . . . . . . . . . . . . . . 6.7 Chapter Summary . . . . . . . . . . . . . . . .

52 53 53 56 56 57 58 58 58 59 59 60 61 62 62 65 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

30

AggieNav hardware block diagram. . . . . . . . . . . . . . . . . . . . . . . .

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 lowlevel programming and software design. • Chapter 5 is about the progress made on AggieNav state-based Kalman filter estimation software. • Chapter 6 covers SEAL, a general geo-spatial UAV payload datalogger, and applications. • 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 hardware. • 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 organisms 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 feedback; 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 perceptions 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). Passive 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 headmounted, 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 incidental 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 navigate 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 (autopilot) 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 University, 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 (Navigator)

Papazazzi (Pilot)

Command + Telemetry Link

Payload Data Link

Flight Commander

Payload Team(s)

Ground

Fig. 3.1: AggieAir Aero-team block diagram.

12

Airframe AggieNav

Gumstix Flight Software (Separate Processes)

IMU, Compass, GPS, Pressure, Temperature SPI

AggieCap

Payload #1

{Fractional, Extended} Kalman Filter GPos+LPos Data Server

GhostFoto

UART

AggiePilot (PPRZ)

GCS + Payload Message Bus UART

Autopilot

GCS C+C Downlink Radio

Ethernet + Local JAUS GPos+LPos+Payload Message Socket Interface UART

PPRZ C+C Link

High-Bandwidth WiFi Datalink

Ground Control Station

GCS C+C Uplink Radio

UART

Payload #2 BlackBox Flight Recorder/ Thermal Camera/ Other Payload

GCS Computer #1 PPRZ GCS + JAUS GCS + Payload Message Bus

Ethernet + Local JAUS GPos+LPos+Payload Message Socket Interface

GCS Computer #2 • GhostEye Interface • gRAID Interface GCS Computer #3 • Thernal Camera 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 Payload Payload #1 #2

Offboard Payload(s) via Mesh Network

AggieCap AggieNav AggiePilot AggieAir Groundstation

Payload 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. DDWRT 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 architectures 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 datatransfer 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 highvalue 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 opensource 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 Sleep 5 Seconds

2 ICMP Responses?

Yes Start rsync 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 systemlevel 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 ˚ Angstr¨om 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 ˚ Angstr¨om 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 lowcost 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. However 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 operates 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, establishing 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 realtime 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 lowcost. 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 connection 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 inexpensive, small fixed-wing UAVs use infrared thermopiles which sense the relative heat differential 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 attitude 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 highaccuracy 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 consumerlevel devices such as the Apple iPhone, Nintendo Wii, and Sony PlayStation 3 [36] have integrated accelerometers into their hardware for more immersive user-experiences. Several 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.

INS Unit Max Gyro Bandwidth Max Gyro Dynamic Range Accelerometer Dynamic Range Accelerometer Resolution Accelerometer Bandwidth Magnetics Rate Magnetics Accuracy GPS Rate Max GPS Accuracy Pressure Rate Pressure Accuracy (Abs) Power Draw

AggieNav 700Hz (unfiltered) ±300deg/sec ±10g 14bit 700Hz (unfiltered) 5Hz heading solution ±3deg 4Hz 2.5m 1.8Hz 1.5Pa 600mW

Stock Microstrain 3DM GX2 250Hz ±300deg/sec standard ±5g 16bit 250Hz 250Hz 0.001Gauss No GPS No GPS No Pressure No Pressure 470mW (minimum)

Crossbow MNAV 25Hz ±150deg/sec ±2g NA 25Hz 1-100Hz NA 4Hz 3m NA NA 400mW

Table 4.1: AggieNav versus other small INS solutions. Procerus Kestrel 9Hz ±300deg/sec ±10g 14bit 9Hz NA NA NA 5m NA 2.44Pa 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 development of filtering for AggieNav’s sensor data) require the use of a Gumstix Linux computer, a mounting footprint and connector has been included, as well as a 5V-powered USBhost 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 Verdex Linux System

5.0V; 3.3V Switching Regulators

uBlox LEA-5H GPS Receiver

User Interface (LEDs, Buttons)

Atmel AVR32A256B Microcontroller

External Data Interfaces (TTL-Serial; SPI Slave)

Honywell HMC6343 3-axis Magnetic Compass

Analog Devices ADIS1654 6-DoF IMU

VTI SCP-1000 Pressure Sensors (x2)

Papazazzibased Autopilot Board (AggiePilot)

Fig. 4.1: AggieNav hardware block diagram.

31

Gumstix Linux Computer

IMU Compass

TTL Serial

AggieNav

SPI Data 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 Measurement 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 AggieNav 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 (ground)

1000

Takeoff event!

Motor off

Acceleration (mg)

500

0

−500

−1000

−1500

200

220

240

260 Time (sec)

280

300

320

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 tiltcompensated 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

Heading (deg)

250

200

150

100

50

0 600

620

640

660

680

700 720 Time (sec)

740

760

780

800

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 Gumstix 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 converters 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)

Pressure (Pa)

8.8

8.75

8.7

8.65

0

200

400

600 800 Time (sec)

1000

1200

Fig. 4.11: Selected pressure data from the 111609 flight.

Totals

AggieNav Budget AT32UC3B0256 CPU ADIS16355 IMU HMC6343 Digital Compass u-Blox LEA-5H GPS GPS Antenna SCP1000-D11 Pressure Sensor SCP1000-D11 Pressure Sensor Misc Electronics Hardware PCB @ 30cm2

Voltage (V) 3.3 5 3.3 3.3 3.3 3.3 3.3 3.3 0

Current (mA) 23 57 13 60 110 0.03 0.03 20 0 1030.97

Power (mW) 75.9 285 42.9 198 363 0.08 0.08 66 0 64.02

Mass (g) 0.2 16 0.32 2.1 10 0.2 0.2 15 20 $739.00

Cost (USD) $12.00 $357.00 $175.00 $100.00 $10.00 $20.00 $20.00 $25.00 $20.00

Table 4.2: AggieNav power, mass, and cost budget. Source Sample from Atmel Analog Devices Digikey u-Blox America Digikey VTI.no VTI.no Estimate Estimate

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 programming 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 realtime 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 coprocess, 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

Gumstix Timeout?

No

Failover Mode?

Yes No

Data from Gumstix?

Enter Failover Mode

Yes

Enter Normal 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 technique 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= ,    q2    q3

q02 + q12 + q22 + q32 = 1.

where

(5.1)

The conversion back from unit quaternion to Euler angles can be written as: 2(q2 q3 + q0 q1 ) ), q02 − q12 − q22 + q32

(5.2)

θ = arcsin(−2(q1 q3 − q0 q2 )),

(5.3)

ψ = arctan(

2(q1 q2 + q3 q0 ) ). + q12 − q22 − q32

(5.4)

φ = arctan(

5.1.2

q02

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 measurement 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 Fk =

5.1.3

∂f |xˆ ,u , ∂x k−1|k−1 k

Gk =

∂g |xˆ . ∂x k|k−1

(5.8)

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]:           q=        

q0 q1 q2 q3 bp bq br

          ,        





 ax     y=  ay  .   az

(5.9)

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. 

q˙ =

       1   2        

0 −ˆ p −ˆ q −ˆ r 0 0 0 pˆ

0

qˆ −ˆ r

−ˆ q 0 0 0

rˆ 0

pˆ

0 0 0

rˆ

qˆ

−ˆ p

0

0 0 0

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 ) g(q02 − q12 − q22 + q32 )

where

   + vk ,  

           q + wk ,        

wk ∼ N (0, Q),

vk ∼ N (0, R),



    p ˆ    p   bp       qˆ  =  q  −  b      q      rˆ r br

(5.10)

(5.11)

   .  

(5.12)

A more general dynamic case from Beard [46] can be represented as follows:    yˆ =   

qVa sin θ g

 + sin θ

  − cos θ sin φ   + vk ,  − cos θ cos φ

rVa cos θ−pVa sin θ g −qVa cos θ g

vk ∼ N (0, R),

(5.13)

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 Microstrain 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

p (deg/s)

50 0 −50 −100 −150 −200 80

90

100

110

120 time (s)

130

140

150

160

Fig. 5.1: Gyro sensor comparison: p.

250 aggienav gx2

200 150 100

q (deg/s)

50 0 −50 −100 −150 −200 −250 80

90

100

110

120 time (s)

130

140

150

Fig. 5.2: Gyro sensor comparison: q.

160

48 200 aggienav gx2

150 100

r (deg/s)

50 0 −50 −100 −150 −200 80

90

100

110

120 time (s)

130

140

150

160

Fig. 5.3: Gyro sensor comparison: r.

10 aggienav gx2

8 6

ax (m/s2)

4 2 0 −2 −4 −6 −8 −10 80

90

100

110

120 time (s)

130

140

150

160

Fig. 5.4: Acceleration sensor comparison: x.

49

10 aggienav gx2

8 6

ay (m/s2)

4 2 0 −2 −4 −6 −8 −10 80

90

100

110

120 time (s)

130

140

150

160

Fig. 5.5: Acceleration sensor comparison: y.

0 aggienav gx2

−2 −4

az (m/s2)

−6 −8 −10 −12 −14 −16 −18 −20 80

90

100

110

120 time (s)

130

140

150

160

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

phi (deg.)

20 10 0 −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

the (deg.)

5 0 −5 −10 gx2 kalman

−15 −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 Windows 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.

SEAL LiPoly Power System

Venus634FLPx GPS Receiver

User Interface (LEDs, Buttons)

Atmel AT90USB1287 Microcontroller

Analog Devices ADS8344 A/D Converter

Optional Wi-Fi Interface

MicroSD 2GB Flash Memory Storage

Digital Data and Event Sources

USB Interface

Fig. 6.3: SEAL system diagram.

Analog Sensors • EasySen SBT80 • N H3 • CO2 • Etc.

Part Atmel CPU ETEK GPS ETEK GPS Cable Assy LiPoly Cell MicroSD Card MicroSD Card Holder Mini-USB Plug PCB @ 30cm2 LEDs Misc. Electronics EasySen SBT80 Total

Current @ 3.3v (mA) 20 50 0 0 20 0 0 0 5 10 8 113

Power Draw (mW) 66 165 0 0 66 0 0 0 16.5 33 26.4 372.9

Mass (g) 3 25 10 22 1.5 3 5 20 1 10 15 115.5

Table 6.1: SEAL R2 power and mass budget. Est. Cost (USD) $5.00 $60.00 $0.00 $10.00 $12.00 $3.00 $1.00 $40.00 $2.00 $15.00 $190.00 $338.00

EasySen LLC

Digikey

Sparkfun Digikey

Source Digikey Sparkfun Sparkfun Sparkfun

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 Wall Power

3.3V LM3658 LiPoly Charger

+

LTC1998 Low-Batt Detect

EN

TPS63001 Buck-Boost Converter

Power Shutdown Interrupt Fig. 6.4: SEAL power diagram.

57

Atmel AT90USB1287 Microcontroller

SEAL LiPoly Power System

uBlox LEA-5H GPS Receiver Power

TI TPS2097 MOSFET Power Switch

WiFi Interface Power

Sensor Power System

Fig. 6.5: SEAL power distribution diagram. • A Texas Instruments ADS8433 analog-to-digital converter [64] (bearing the BurrBrown 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 applications. 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 standard 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 precess; • 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 () in a single Track (). 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 1 2008−02−04 T 0 3 : 2 2 : 5 6 . 1 6 4 Z 1 3 6 1 . 7 9 8 0 . 0 0 1 132 2 11 502 ....

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 monitoring 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 produces 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 runtime, given that the transmit power required decreases as a function of

1 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.

SE

A

L

UAV: Lat:1 Lon:2

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” passengers 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, inexpensive 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 accurate 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 documented, 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, modified, or studied, providing excellent cost to performance ratios in most cases. First, the overall PRS UAV architecture, AggieAir, is presented with a motivating examples (GhostEye 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. Development 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-onmodules; • 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 integrated. 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 ARCTAS,” 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, “Forest 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 oconnor.JPG].

Foundation,

[http://en.wikipedia.org/wiki/File:Gumstix_

[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 Engineering Technical Conferences & Computers and Information in Engineering Conference IDETC/CIE, 2009. [31] R. Klopfenstein Jr., “Air velocity and flow measurement using a Pitot tube,” Proceedings 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 measurements,” 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 Intelligence, 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, microprocessorbased, 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 Technology 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 development,” 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 understanding 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,” sd-reader/index.html].

[http://www.roland-riegel.de/

[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 International 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, AggieNav 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 designed 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 necessity 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 functional. 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 recommended 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 hardware 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 realtime 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 environment 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 device 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 implementation 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 lessthan-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

+3V3

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

10 8 6 4 2

RESET

JTAG

9 7 5 3 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

+3V3

Sup 0

+3V3

+3V3

Sup 0

Sup 0

DGND

Sup 0

DGND

DGND

Pas 1

C13

C20

C21

470pF

C25

C26

2.2uF 100nF 33nF

C24

2.2uF 100nF 33nF

C19

2.2uF

DGND C16 C17

47nF 100nF 33nF

C12

DGND

Pas 1 Pas 1

53

8 22 56

20

32 48 64

21

C36

I/O 0

19 18

3 4 5 2

DGND

I/O 0

I/O 0

I/O 0

17 23 49

100nF I/O33nF 0 1

C35

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0 63 RESET

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

AVR32UCB

C44

13pF

1-GND1 17-GND2 23-GND3 49-GND4

19-VDDANA 18-ADVREF

3-TDI 4-TDO 5-TMS 2-TCK

63-RESET_N

53-VDDPLL

8-VDDCORE 22-VDDCORE 56-VDDCORE

20-VDDOUT

32-VDDIO 48-VDDIO 64-VDDIO

21-VDDIN

AVR32B_TQFP64 U3

Pas 1

Q1 Pas 1 2 13pF

1

C45

DGND

9-PA03 10-PA04 11-PA05 12-PA06 13-PA07 14-PA08 28-PA09 29-PA10 30-PA11 31-PA12 33-PA13 34-PA14 35-PA15 36-PA16 37-PA17 39-PA18 40-PA19 44-PA20 45-PA21 46-PA22 47-PA23 59-PA24 60-PA25 61-PA26 62-PA27 15-PA30 16-PA31 6-PB00 7-PB01 24-PB02 25-PB03 26-PB04 27-PB05 38-PB06 43-PB07 54-PB08 55-PB09 57-PB10 58-PB11

52-VBUS 51-DM 50-DP 9 10 11 12 13 14 28 29 30 31 33 34 35 36 37 39 40 44 45 46 47 59 60 61 62 15 16 6 7 24 25 26 27 38 43 54 55 57 58 I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

22 Pas 0

LED1_EN LED2_EN

LOBATT_5.55V LOBATT_5.96V EX_SPI_SS SENSOR_P2_CS

EX_SPI_MOSI EX_SPI_MISO SENSOR_MISO EX_UART2_TXD EX_UART2_RXD

IMU_RST* DFU_BUTTON SENSOR_MOSI SENSOR_SCK SENSOR_IMU_CS SENSOR_P1_CS UART0_RXD_GPS UART0_TXD_GPS EX_SPI_CLK

ADC_00 DGND ADC_01 MAG_X_SR MAG_Y_SR MAG_Z_SR GS_DETECT MAG_I2C_SCL MAG_I2C_SDA

22

Pas 0

Pas 0 Pas 1

AVR_USB-1 AVR_USB-2 AVR_USB-3 AVR_USB-4

AVR32 USB 53047-04 Pas 0

52 I/OVBUS_AVR32 0 R14 51 I/O 0 Pas 1 R15 50 I/OPas 0 1 Pas 1

11/2/09 10:31 PM f=0.85 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.sch (Sheet: 1/1)

DGND

C30

Sup 0

.1uF

Pas 1

Pas 1

Sup 0

Sup 0

Pas 1 Pas 1 Pas 1

Pas 1

Pas 1 Pas 1

Pas 1

Pas 1

Pas 1 Sup 0

Pas 1

Pas 1 Pas 1 Pas 1

Sup 0

Sup 0

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1 Pas 1 Pas 1

Pas 1 Pas 1

Pas 1

C11

+3V3

Sup 0

C10

Sup 0 Sup 0

Pas 1 Pas 1

Pas 1 Pas 1

Pas 0

Pas 0

DGND

Pas 1

Pas 0

Pas 0

DGND

Pas 1

Pas 1

Pas 1

T1B 220

R16

Pas 1 Pas 1

T1A

Pas 1

Pas 1

T2B 220

R17 Pas 1 Pas 1

DGND

T2A

Pas 1

Pas 1

T3B 220

R18 Pas 1 Pas 1

DGND

Pas 0

Pas 0

DGND

Pas 1

DGND

T3A

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Compass Set/Reset Control

C18

C9

41

Sup 0

Sup 0

47nF 100nF 33nF

Pas 1 Pas 1

42 I/O 0

41-PA28 Sup 0

I/O 0

42-PA29 Pas 1

Pas 1

Pas 0

1uF Pas 0

Pas 0 Pas 0

Pas 0 Sup 0 Pas 0

1uF

Pas 0

Pas 0

Pas 0 Pas 0

+5V

C31

1uF Pas 0 Sup 0 Pas 0

Sup 0

C39

Pas 0

Pas 0

Pas 0 Pas 0

+5V

+5V 0.1uF 0.1uF

Pas 0 Sup 0 Pas 0

Sup 0

0.1uF 0.1uF Sup 0

C22 C23

C33 C37 C41 C43

Sup 0

0.1uF 0.1uF

Sup 0

In 0

In 0

In 0

23 19 15

24 20 16

In 0

I/O 0

Out 0

In 0

Out 0

22 35

34

33 1

In 0 32 MAG_I2C_SCL In 0 36 MAG_I2C_SDA

DGND

In 0

In 0

In 0

U4 HMC6343

22-CS 35-CS_CTRL

34-SDO

33-TX 1-RX

32-SCL 36-SDA

23-XOFF19-YOFF15-ZOFF-

24-XOFF+ 20-YOFF+ 16ZOFF+

29-GND1 25-GND2

2 4 5 6 7 8 9 10 12 13 14 17 18 26 27 28 30 31

3-VDD1 21-VDD2 11-VDD3

3D Magnetic Compass

+3V3

29 25

2 4 5 6 7 8 9 10 12 13 14 17 18 26 27 28 30 31

3 21 11

Sup 0 Pwr 0

Pwr 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

Pwr 0

Pwr 0

Pwr 0

DGND

Sup 0

DGND

1uF

C28

Pas 1 Pas 1 Sup 0

C8

83

L

29-GND1 25-GND2

2 4 5 6 7 8 9 10 12 13 14 17 18 26 27 28 30 31

3-VDD1 21-VDD2 11-VDD3

netic Compass

+3V3

29 25

2 4 5 6 7 8 9 10 12 13 14 17 18 26 27 28 30 31

3 21 11

P$10 P$11 Pwr P$12 0

Pwr 0

Pwr 0

DGND

Pwr 0

Pwr 0

Pwr 0

P$13 P$14 Pwr P$15 0

P$8

In 0

Pwr 0

IMU_RST*

1uF 0 SENSOR_IMU_CS In P$6 0 DGND SENSOR_MOSI In P$5 0 SENSOR_MISO Out P$4 In P$3 0 SENSOR_SCK

C29

NC 0

DGND

1uF

C28 +5V

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

NC 0

Pwr 0

Pwr 0

Pwr 0

Pas 1

Pas 1 Sup 0

U4 HMC6343

Sup 0

Sup 0

Pas 1 Pas 1 Sup 0

Sup 0

DGND

6DoF IMU

13-GND1 14-GND2 15-GND3

8-RST*

6-CS* 5-DIN 4-DOUT 3-SCLK

10-VCC1 11-VCC2 12-VCC3 21-AUX_ADC 20-AUX_DAC 9-DIO2 7-DIO1

IMU1 ADIS1635X P$21 In 0 P$20 Out 0 P$9I/O 0 P$7I/O 0

Pas 1

1K Pas 1 Pas 0 Pas 0

R10

+3V3 LED1 0.1uF

0.47uF C34

C32

DGND

0.1uF

0.47uF C42

C40

DGND

I/O 0

I/O 0

I/O 0

I/O 0

P_DRDY2 I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

P_DRDY1 I/O 0

I/O 0

I/O 0

LED2_EN

R11 LED2

Pas 1

1K Pas 1 Pas 0 Pas 0 Pas 1

47K AVSS AVDD CSB MISO MOSI SCK PD

AVSS AVDD CSB MISO MOSI SCK PD

Pressure Sensor 2 ATST TRIG DRDY CLK DVDD DVSS DVDDS

P2

ATST TRIG DRDY CLK DVDD DVSS DVDDS

P1

C15

220nF

Sup 0 I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

DGND

SWB

RESET

Pressure Sensor 1

C14

220nF

Pas 1

1

R12 Pas 1 Pas 1

Pas 1 I/O 0

1 2 2 I/O 0

1

+3V3 Sup 0

Pas 1

R13 Pas 1

47K SWA

DFU_BUTTON

DGND

C27 DGND 0.1uF SENSOR_P1_CS SENSOR_MISO SENSOR_MOSI SENSOR_SCK

Pas 1

Pas 1 I/O 0

1 2 2 I/O 0

Sup 0

+3V3 +3V3

Sup 0

Sup 0 Sup 0

Sup 0 Sup 0

C38 DGND 0.1uF SENSOR_P2_CS SENSOR_MISO SENSOR_MOSI SENSOR_SCK

Pas 1 Pas 1

Pas 1 Pas 1 Pas 1 Pas 1 Pas 1 Pas 1 Pas 1

Pas 1 Pas 1

Sup 0 Sup 0

Sup 0

DGND

Sup 0

LED1_EN

84

+3V3

+3V3

Sup 0

Sup 0

C8

Pas 1

C9

C10

1-SPI_GND 2-TWOG_3.3V 3-SPI_CLK 4-SPI_MISO 5-SPI_MOSI 6-SPI_SS 7-SPI_DRDY

C12

C13

DGND

47nF 100nF 33nF

C11

DGND

47nF 100nF 33nF

Sup 0

Pas 1 Pas 1 Pas 1

Pas 1 Sup 0

I/O 0

DGND

Sup 0

DB2 PPRZ_TWOG

Sup 0

21

AVR32B_TQFP64 U3

21-VDDIN

PWR_GND I/O 0

PWR_VBATT I/O 0

+VBATT 52-VBUS

DGND

AVR32UCB

PWR_GND

PWR_VBATT

GNDVIA1 GNDVIA2 GNDVIA3 GNDVIA4 GNDVIA5 GNDVIA6 GNDVIA7 GNDVIA8

GNDVIA1 I/O 0 GNDVIA2 I/O 0 GNDVIA3 I/O 0 GNDVIA4 I/O 0 GNDVIA5 I/O 0 GNDVIA6 I/O 0 GNDVIA7 I/O 0 GNDVIA8 I/O 0

Sup 0 Sup 0

Pas 0

Pas 0

Pas 0

+3V3

Sup 0

+VBATT

AVR_USB-1

DATA_OUT-1 DATA_OUT-2 DATA_OUT-3 DATA_OUT-4

Pas 0 Pas 1

AVR32 USB 53047-04 Pas 0

DGND

Pas 0

52 I/OVBUS_AVR32 0 R14 51 I/O 0 Pas 1

EX_UART2_TXD EX_UART2_RXD

D1 Pas 0 MMBD1501-TP Pas 0

Pas 1

DGND

22uF 1210 X5R

C7

DGND

22uF 1210 X5R

C3

Pas 1

In 0

Pwr 0

Pwr 0

In 0

In 0

Pwr 0

Pwr 0

In 0

3.3V_POWER_EN Pas 1

R2 Pas 1 Pas 1

R4

Pas 1 Sup 0 Pas 1 Pas 1 Sup 0

750K 1% 220K 1%

768K 1% In 0

In 0

Pwr 0

Pwr 0

9 7 5

Pas 0

SW1 SW2

PG FB LBO AGND PGND1 LBI SYNC PGND2

VIN1 VIN2 EN VINA

GPS_UART-1 GPS_UART-2 GPS_UART-3 GPS_UART-4

Compass Set/Reset Control

DGND

Pas 0

PG FB LBO AGND PGND1 LBI SYNC PGND2

SW1 SW2

L1

6.8mH Pas 1

L2

Pas 1

10 In 0 6 OutLOBATT_5.96V 0 1 Pwr 0 16 Pwr 0

13 Out 0 3.3V_POWER_EN

14PasOut1 0 15 Out 0

6.8mH

13 Out 0 10 In 0 6 OutLOBATT_5.55V 0 1 Pwr 0 16 Pwr 0

14PasOut1 0 15 Out 0

U2 5.0V Power Rail TPS62112

1uF

C5

2 3 4 8

9 7 5

VIN1 VIN2 EN VINA

U1 3.3V Power Rail TPS62111

1uF

C1

2 3 4 8

UART0_TXD_GPSPas 0 UART0_RXD_GPSPas 0

205K 1%

22uF 1210 X5R

C6

22uF 1210 X5R

C2

+3V3 +5V

Pas 1

Pas 1

Pas 1

Pas 1 Pas 1

R8 Pas 1 Pas 1

R9 Pas 1

TWOG_3.3 EX_SPI_CLK DGND EX_SPI_MISO EX_SPI_MOSI EX_SPI_SS EX_SPI_DRDY

Pas 1

Pas 1 Pas 1 Pas 1

Pas 1 Pas 1 Pas 1 Pas 1

+3V3

Pwr 0 Pwr 0

SPI_GND I/O 0 SPI_3.3V I/O 0 SPI_SCK I/O 0 SPI_MISO I/O 0 SPI_MOSI I/O 0 SPI_SSEL I/O 0 SPI_DRDY I/O 0

Pas 1

Sup 0 Sup 0

Sup 0 Sup 0

PPAD GND1 GND2 Pwr 0

17 11 12 Pwr 0

PPAD GND1 GND2 Pwr 0

17 11 12 Pwr 0

R7

Pas 1

1M Pas 1

Sup 0 Sup 0

Pwr 0

DGND

+5V

Pas 1 Pas 1 Pas 1 Pas 1

Sup 0 Sup 0

Pwr 0

85

F

E U

S S E

U E

G

DGND

+5V

Sup 0

Sup 0

+3V3

+5V

22uF 1210 X5R

C6

Sup 0 Sup 0

+3V3 1M Sup 0 Pas 1 FF_TXD

EX_SPI_MISO USB_OTG_ID

SDA SCL EX_SPI_CLK

USB_DP EX_UART2_TXD

Pas 1

R1 Pwr 0

Pwr 0

Pwr 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

Pwr 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

VERDEX60H4

GND GND USBH_N1 GPIO67_L_DD09 GPIO28_BITCLK GPIO77_L_BIAS GPIO76_L_PCLK GPIO61_L_DD03 GPIO30_SDATA_OUT GPIO73_L_DD15 GPIO72_L_DD14 GPIO66_L_DD08 GPIO34_FF_RXD GND GPIO65_L_DD07 GPIO71_L_DD13 GPIO63_L_DD05 GPIO70_L_DD12 GPIO68_L_DD10 GPIO69_L_DD11 GPIO59_L_DD01 USBH_P1 GPIO46_IR_RXD GPIO113_NACRESET GPIO47_IR_TXD GPIO60_L_DD02 GPIO62_L_DD04 GPIO100_FF_CTS GPIO31_SYNC GPIO9_CLK_32 GPIO11_SSPRXD2 GPIO75_L_LCLK GPIO14_SSPSFRM2 GPIO17_PWM1 GPIO29_SDATA_IN0 GPIO58_L_DD00 GND GPIO118_SDA GPIO74_L_FCLK GPIO117_SCL GPIO64_L_DD06 GPIO19_SSPSCLK2 GPIO27_FF_RTS GPIO87_L_DD17 GPIO101 GPIO13_SSPTXD2 N_MANUAL_RESET GPIO41_SSPRXD3_OTG_ID GPIO16_PWM0 GPIO2_SYS_EN GPIO43_BT_TXD GPIO39_FF_TXD GPIO45_BT_RTS GPIO86_L_DD16 GPIO42_BT_RXD V_BATT GPIO44_BT_CTS V_BATT GND V_BATT Pwr 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

Pwr 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

Pwr 0

BT_RXD

BT_TXD

EX_SPI_MOSI EX_SPI_SS

EX_UART2_RXD

FF_RXD

USB_DM DGND

DGND

Sup 0

DGND

Sup 0

Pwr 0

Sup 0

LED1_EN

+3V3

Pas 0

Pas 0

Pas 1

22

R3

RESET

FF_UART-1 FF_UART-2 FF_UART-3 FF_UART-4

220nF

DGND

Pas 0

Pas 0

Pas 0

Pas 0

Pas 1

VBUS_GUMSTIX

22

USB_OTG_ID Pas 1 R5 Pas 1

FF_UART Breakout

Pas 0

Pas 0

Pas 0

Pas 0

Pas 0

DGND

Sup 0

FF_TXD FF_RXD

Pas 0

Pas 0

LED2_EN

5 4 3 2 1

+3V3

Sup 0 Pas 1

1K Pas 1 Pas 0 Pas 0

R10 LED1

1K

Pas 1 Pas 1 Pas 0 Pas 0

Sup 0 Sup 0

GS_DETECT

47K

Gumstix Verdex Interface

1

R12 Pas 1

R11 LED2

Pas 1 Pas 1 I/O 0

1

+3V3

DB1

220nF

Sup 0

I/O 0

1

I/O 0

1

+5V DGND

ZLLS500TA R6 Pas 0 Pas 1 Pas 0 10uF D2 600 C4

USB_DM

USB_DP

BT_TXD Pas 0 BT_RXD Pas 0

Pas 0

DFU_BUTTON

DGND

Pas 0

BT_UART-1 BT_UART-2 BT_UART-3 BT_UART-4

BT_UART Breakout

DGND

47K 1

22uF 1210 X5R

Pas 1

12 12 2 2

R13

1

Pas 1 Pas 1 Sup 0

+3V3

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

Sup 0 Sup 0

C2

Pas 1

86

Sup 0

87

Appendix C AggieNav V1.2 Printed Circuit Board Layout

11/2/09 6:52 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd

88

AggieNav top copper layer

11/2/09 6:54 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd

89

AggieNav bottom copper layer

11/2/09 6:53 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd

90

AggieNav top silkscreen layer

11/2/09 6:47 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd

91

AggieNav bottom copper layer

11/2/09 6:51 PM f=2.50 /home/coopmans/eagle/AgNv_r2/agnv_r1_2.brd

92

AggieNav drill layer

93

Appendix D SEAL V.2 Electronic Schematics

80

R38 Pas 0 Pas 1

Pas 0

LED9

Pas 0 Pas 1

LED10

80

R36 Pas 0

I/O 0

I/O 0

I/O 0

I/O 0

1 2 3 4 I/O 0 5 I/O 0 6 I/O 0 7 I/O 0 8 I/O 0 9 I/O 0 10 I/O 0 11 I/O 0 12 I/O 0 13 I/O 0 14 I/O 0 15 I/O 0 16 I/O 0 17 I/O 0 18 I/O 0 19 I/O 0 20 I/O 0 21 I/O 0 22 I/O 0 23 I/O 0 24 I/O 0 25 I/O 0 26 I/O 0 27 I/O 0 28 DGND I/O 0 29 I/O 0 30 I/O 0 31 I/O 0 32

EN_WIFI_PWR

I/O 0

I/O 0

I/O 0

I/O 0

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24-RESET 25 26GND3 27 28 29LEDDCD 30LEDRX 31LEDDTR 32LEDTX

DGND

2

3

1

DGND

2

4-ISET

4-ISET

5-VOUT

4 I/O 0

4 I/O 0

5 VCC_WIFI I/O 0

DGND

Pas 0

Pas 0

Pas 1 Pas 0

DGND

LED7

Pas 1 Pas 0

LED6

VCC_WIFI

64 I/O 0 63 I/O 0 62 I/O 0 61 I/O 0 DGND 60 I/O 0 59 I/O 0 58 I/O 0 57 I/O 0 56 I/O 0 55 I/O 0 54 I/O 0 53 I/O 0 52 I/O 0 51 I/O 0 50 I/O 0 49 I/O 0 48 I/O 0 47 I/O 0 46 I/O 0 45 I/O 0 44 I/O 0 43 I/O 0 42 I/O 0 41 I/O 0 40 I/O 0 39 I/O 0 38 I/O 0 37 I/O 0 36 I/O 0 35 UART0_RX I/O 0 34 UART0_TX I/O 0 33 I/O 0

DGND

64 63GND 62 61VCC 60 59 58-LEDLINK 57-LEDACT 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41GND2 40-DTR 39-DCD 38-CTS 37-DSR 36-RI 35-TXD 34-RXD 33-RTS

FPF2125

2-GND

3-ON

1-VIN

U10

FPF2125

2-GND

3-ON

DGND

11/3/09 12:10 AM f=0.70 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.sch (Sheet: 1/1)

Pas 1

VCC_WIFI

Pas 1

VCC_WIFI

VCC_27 +5V

Pas 1

3.3K Pas 1 Sup 0

Sup 0

Sup 0 Sup 0

Sup 0

R16 R19

Pas 1

374 Pas 1 Sup 0

3

Sup 0

I/O 0

Pas 1

Pas 1

80

VCC_27 LED8

Pas 0 Pas 1

Pas 1

R34

R29

80

R26 VCC_WIFI

80

VCC_WIFI

Pas 0

I/O 0

1

ANT

EN_GPS_PWR

10K GPS_SWUART_RX

DGND

I/O 0

2

3

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

32 38 39 43 41 40 42 44 7 10 11 15 19 21 22 24 25

U6

U9

4-ISET

5-VOUT

GPS

GNDGPSANT

VENUS634SMD

RFIN MOSI MISO CSN CLK PPS RX TX LED GND GND GND GND GNDRF GNDRF GNDRF GNDRF

VCC REGEN RSTN BTSEL VBAT RTC GPIO1 GPIO2 GPIO20 GPIO24 PIO12 PIO14 GNDRF GNDRF GNDRF GNDRF GNDRF

FPF2125

2-GND

3-ON

4-ISET

5-VOUT

FPF2125

2-GND

3-ON

1-VIN

1-VIN

U13

DGND

I/O 0

I/O 0

I/O 0

1

DGND

2

EN_SENSOR_5V_PWR I/O 0 3

P$1

5 VCC_SD_SBT80 I/O 0

VCC_27

P$1 I/O 0

5-VOUT

Sup 0

+5V VCC_27

U8

Sup 0 Pas 1

R31 Pas 1

Sup 0

Sup 0 Sup 0

Sup 0

4 I/O 0

5 VCC_SENSOR_5V I/O 0

4 I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

Pas 1

2 36 1 9 18 17 6 5 14 8 4 37 33 31 29 28 27

DGND

0

R37

VCC_GPS

5 VCC_GPS I/O 0

DGND

R15

Pas 1

2K Pas 1 Sup 0

R17

Pas 1

3.3K Pas 1 Sup 0

1-VIN

VCC_27

EN_SD_SBT80_PWR

Sup 0

Pas 1

DGND

1uF

DGND

C31

33K PSE_SEL = Low power mode DGND

10K R33

Pas 1 Pas 1 Sup 0 Pas 1 Pas 1

1

Sup 0 Sup 0

Sup 0

Sup 0Pas 1 Pas 1

R32 Sup 0

Pas 1 Pas 1 Sup 0

R30 10K

I/O 0

94

Pas 1

R30

33K

DGND

Pas 1 Sup 0 Pas 1 Pas 1

PSE_SEL = Low power mode ND

10K

C31

1uF

Pas 1

80 Pas 0

5 4 3 2 1

Pas 0

Pas 0

Pas 0

80 SupPas0 VCC 1 LED4

Pas 0

Pas 0

Pas 0

Pas 0

DGND Pas 0

R21 LED4

R20 LED3 Pas 0

Pas 1 Pas 0 Pas 0

Pas 1 Pas 0

LED3

Pas 1

DGND

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

10 8 6 4 2

Pas 1

Pas 1

Sup 0

.1uF 1uF

C23 C24

22

R28

SV1

Pas 1 Pas 1

RESET

22

R27

DGND

IUID

LED5

Sup 0

VCC

Sup 0

Pas 1 Pas 1 Pas 0 Pas 0

R22 LED5 Sup 0

Pas 1 Pas 1

DGND Pas 1 Pas 1

80 Sup 0

I/O 0

1 2

18pF

Pas 1

VBUS

I/O 0

U15 18pF

9 7 5 3 1 Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

3

Pas 1

ABMM-B2

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

Pwr 0

Pwr 0

I/O 0

I/O 0

In 0

22

21 52

23 24

20

6 3 7 8

5 4

54 55 56 I/O 0 57 I/O 0 58 VBATT_AD I/O 0 59 I/O 0 60 I/O 0 61 I/O 0

I/O 0

I/O 0

DGND

C30

Pwr 0

Pwr 0

Pwr 0

Pwr 0

I/O 0

I/O 0

62 64 63

DGND

Pwr 0

I/O 0

I/O 0

DGND

.1uF 1uF Pwr 0 53

Pwr 0

C25 C26

.1uF

AGND

Sup 0

Pas 1

ADS8344

0

R18

20 19 18 17 16 15 14 13 12 11

VCC_SENSOR_5V SPI_CLK AD_CS SPI_MOSI

I/O 0

I/O 0

10uF

PA7(AD7) PA6(AD6) PA5(AD5) PA4(AD4) PA3(AD3) PA2(AD2) PA1(AD1) PA0(AD0)

1uF

VCC_SENSOR_5V C17 C18

I/O 0

I/O 0

I/O 0

SPI_MISO

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

PE7(INT7/AIN1/UVCON) PE6(INT6/AIN0) PE5(INT5/TOSC2) PE4(INT4/TOSC1) PE3(IUID) PE2(ALE/HWB) PE1(/RD) PE0(/WR)

PD7(T0) PD6(T1) PD5(XCK1) PD4(ICP1) PD3(TXD1/INT3) PD2(RXD1/INT2) PD1(OC.2B/SDA/INT1) PD0(OC.0B/SCL/INT0)

PC7(A15/IC.3/CLK0) PC6(A14/OC.3A) PC5(A13/OC.3B) PC4(A12/OC.3C) PC3(A11/T.3) PC2(A10) PC1(A9) PC0(A8)

PB7(PCINT7/OC.0A/OC.1C) PB6(PCINT6/OC.1B) PB5(PCINT5/OC.1A) PB4(PCINT4/OC.2A) PB3(PDO/PCINT3/MISO) PB2(PDI/PCINT2/MOSI) PB1(PCINT1/SCK) PB0(SS/PCINT0)

DGND

Pas 1

CH0 VCC2 CH1 DCLK CS* CH2 DIN CH3 CH4 BUSY CH5 DOUT CH6 GND2 CH7 GND1 COM VCC1 SHDN* VREF

AT90USB1287-MU

PF7(ADC7/TDI) PF6(ADC6/TDO) PF5(ADC5/TMS) PF4(ADC4/TCK) PF3(ADC3) PF2(ADC2) PF1(ADC1) PF0(ADC0)

UGND UVCC UCAP VBUS

D+ D-

AREF AVCC GND

GND GND

VCC VCC

XTAL2 XTAL1

RESET

RESET U11

1 2 3 4 5 6 7 8 9 10

Sup 0

I/O 0

Sup 0

Pas 1

Pas 1

VCC_SENSOR_5VI/O 0

2 1

1

C20 C21 I/O 0

1

VCC

I/O 0

Pas 1 Pas 1

Pas 1 Pas 1

VCC VCC VCC

12 12 2 I/O 0

Sup 0

Sup 0 Sup 0

Sup 0 Sup 0 Sup 0 Pas 1 Pas 1 Sup 0

Pas 1

Pas 1

I/O 0

AGND

DIO7 DIO6 DIO5 DIO4 I/O 0DIO3 I/O 0DIO2 I/O 0DIO1 I/O 0DIO0 I/O 0

I/O 0

I/O 0

I/O 0

LED4 PWMA PWMB PWMC LED3 I/O 0EN_WIFI_PWR I/O 0EN_GPS_PWR I/O 0EN_SD_SBT80_PWR EN_SENSOR_5V_PWR GPS_SWUART_RX

BATTLO I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

LED5 UART0_TX UART0_RX

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

2 I/O 0 1 I/OEXT_INTERUPT 0 19 I/O 0 18 I/OINT_BUTTON 0 9 I/O 0 IUID 43 I/ODFU_BUTTON 0 34 I/O 0 33 I/O 0

32 31 30 29 28 27 26 25

42 41 40 39 38 37 36 35

17 I/O 0 SD_CD 16 I/O 0 15 I/O 0 AD_CS 14 I/O 0 SD_CS 13 I/O 0 SPI_MISO 12 I/O 0 SPI_MOSI 11 I/O 0 SPI_CLK 10 I/OSBT80_SW 0

44 45 46 47 48 49 50 51

DGND

Sup 0

AD0 AD1 AD2 AD3 AD4 AD5 AD6 AD7

95

VI

VO

GND

2

Pas 0

3

Pas 1

Pas 1

I/O 0

1

I/O 0

I/O 0

DGND

I/O 0

3 4

11

10uFI/O 0 5

C5

I/O 0 2 DGND

33uF

C2

1uF

C4

DGND

Pas 0

D1 Pas 0 1N4933

Sup Pas 0

Pas 1

Pas 1

VBUS

33uF

Sup 0

Pas 1

Pas 1

Pas 1

Sup Pas 0 1

SL1

TS

BATT

ISET GND USB_SEL STAT1 STAT2 EN_B DAP

USBPWR

CHG_IN

LM3658SD-B

8 7 6

Pas 1

9

10 Pas 1

I/O 0

I/O 0

Pas 0

1K

R6

Pas 1 Pas 1

VBATT

1uF

C8

EN_SD_SBT80_PWR

Pas 0 Pas Pas 1 0 R5 LED1 LED2

1K

DGND

Pas 1 Pas 0

Sup 0

Pas 1

10K 1206

Pas 1

R1

2.55K 1% 1206

I/O 0

R4

I/O 0

I/O 0

Pas 1 Pas 1

IC1 External Input Power 7805T

I/O 0

I/O 0

I/O 0

2

3

1

4-ISET

FPF2125

2-GND

3-ON

5-VOUT

Pas 0

2

Pas 0

Pas 0

1 3

4

I/O 0

5 VCC_SD_SBT80 I/O 0

S1

System Power Switch

U8

1-VIN

DGND

-

LiPoly Batt

+

-

1

VCC_27

1uF

VBATT_AD 1uF C10

C9 I/O 0

I/O 0

3

4

V_THA

V_HA

BATTLO*

VLOGIC

LTC1998 I/O 0

I/O 0

1

4 4-VIN

3

I/O 0

I/O 0

1

DGND

8

U5 LTC1370

I/O 0

I/O 0

6

2

6-MODE

1-RUN

4-ISET

5-VOUT

FPF2125

2-GND

3-ON

1-VIN

U6

DGND

1

3-SW

3

2

5

I/O 0

I/O 0

I/O 0

5 6 2

I/O 0

3

1

4

I/O 0

5 VCC_SENSOR_5V I/O 0

DGND

I/O 0 I/O 0

0.0047uF

C15

0.047uF

C14

2-FB

6-NFB

5-VSW

2

R8

887K 1%

I/OPas 0 1

Pas 1

Pas 1

4

3

1

Pas 1

Pas 1

LTC3405SOT23-6

U2

Pas 1 I/O 0

VLF10040

1

L2

5-VFB

DGND

I/O 0

8-GNDPAD

3-S-S

DGND

I/O 0

I/O 0

2.2UF 10V X7R 0805

C3

EN_SENSOR_5V_PWR I/O 0 3

100uF

C11

6 BATTLO I/O 0

5

Vcutoff = 2.7V; 100mV Hyst. Pas 1 Pas 1

I/O 0

+ + I/O 0 Sup 0

Pas 1

Pas 1

Pas 1 Pas 1

100K 1% R3 Pas 1 Pas Pas 1 1

Pas 1

R2 R10

66.5K 1% 787K 1% 147K 1%

Pas 1 Pas 1 Pas 1

330K 1% R11 PasPas1 1 R7 Pas 1

I/O 0

1 BATT GND

2 I/O 0

Sup 0

In 0

2

4.7UH 20% 450MA 1210 0.047uF

C1

Pas 1 Pas 1

2-GND I/O 0 Sup 0

I/O 0

7 7-VIN

R9

C6 374K 1%

Pas 1

Sup 0 Sup 0

1

L1 Pas 1

Pas 1

4

I/O 0

Pas 1 Pas 1

VCC_27 4.7UF 6V X7R 0805

C7

C13

DGND

100uF 100uF

C12

DGND

Sup 0 Sup 0

Sup 0 Sup 0

Pas 1

R16

Pas 1

3.3K 1 Sup 0

+5V

4-GND

4 SupI/O 0 0

Sup 0 Sup 0 Sup 0

I/O 0 Pas 1

1-VC

R14 Sup 0 Pas 1

2K 1 Sup 0

2K Pas 1 Pas 1 Pas 1

Pas 1

Pas 1

R15

18.7K 1% 6.19K 1%

Pas 1

R12 Pas 1 Pas 1

R13 Pas 1

Pas 1 Pas 1

+5V Pas 1 Pas 1

1 2

96

3

1

4

I/O 0

Sup 0

VCC_27

4.7UF 6V X7R 0805

C7

+5V

C13

Sup 0

DGND

100uF 100uF

C12

47K

220nF

C27

1

Pas 1

Pas 1

Sup 0

Sup 0

DGND

18.7K 1%

6.19K 1%

Pas 1

R12

Pas 1

Pas 1

R13

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

Pas 1

R23 Pas 1

DGND

SD_CD

SD_CS SPI_MISO SPI_MOSI SPI_CLK

Pas 1

Pas 1 I/O 0

1

2

2 I/O Sup 0 0

DGND

1 2 3 4 5 6 7 8

I/OCD1 0 I/OCD2 0 GND1 I/O 0 GND2 I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

47K

CD1 CD2 SHIELD1 SHIELD2

NC CS DI VCC SCK GND DO RSV

SW2

1uF

C32

DFU_BUTTON

220nF

C28

VCC_SD_SBT80

SW1

RESET

Pas 1 I/O 0

1

s1

10K

47K

Sup 0

VCC INT_BUTTON

SW3

220nF

C29

1

Pas 1

R24 Pas 1 Pas 1

Pas 1 I/O 0

1 2

1 2 2 I/O 0

Pas 1

R25

Pas 1 Pas 1

Pas 1

Pas 1 Pas 1

R35 Sup 0

Pas 1 Pas 1

AD0 AD1 AD2 AD3 AD4 AD5

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

1 2 3 4 5 6

5

Pas 0

1 Pas 0 3 Pas 0 5 Pas 0 7 Pas 0 9

JP2

Pas 0

2Pas 0 4Pas 0 6Pas 0 8Pas 0 10 Pas 0

6Pas 0

AD3

JP1 SBT-80 Connector Pas 0 1 2Pas 0 AD7 Pas 0 3 4Pas 0 SBT80_SW

JP3 Analog Inputs 2Pas 0 VCC_SENSOR_5V Pas 01 AD0 Pas 0 3 4Pas 0 AD1 AD2 C19 Pas 0 5 6Pas 0 AD3 AD4 Pas 0 7 8Pas 0 AD5 AD6 .1uF Pas 0 9 10 Pas 0 AD7

DGND

VCC2 DCLK CS* DIN BUSY DOUT

20 19 18 17 16 15

VCC_SENSOR_5V SPI_CLK AD_CS SPI_MOSI I/O 0

SPI_MISO

I/O 0

I/O 0

I/O 0

I/O 0

I/O 0

JP4 Digital I/O 2Pas 0 VCC_SENSOR_5V Pas 01 DIO0 Pas 0 3 4Pas 0 DIO1 DIO2 Pas 0 5 6Pas 0 DIO3 DIO4 Pas 0 7 8Pas 0 DIO6 C22 DIO5 Pas 0 9 10 Pas 0 DIO7 EXT_INTERUPT Pas 11 0 12 Pas 0 PWMA .1uF PWMB Pas 13 0 14 Pas 0 PWMC

ADS8344 CH0 CH1 CH2 CH3 CH4 CH5

AD6 P_CONT

VCC_SD_SBT80 AD0 C16 AD1 AD2 .1uF AGND AGND

2 I/O 0

Pas 1

Pas Sup 1 0

Pas 1

Pas 1Sup 0

Pas 1

Pas 1Sup 0

Pas 1

97

98

Appendix E SEAL V.2 Printed Circuit Board Layout

11/3/09 12:12 AM f=2.30 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd

99

SEAL top copper layer

11/3/09 12:12 AM f=2.30 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd

100

SEAL bottom copper layer

64

S1

SEAL top silkscreen layer 2 1

SV1

R22

11/3/09 12:13 AM f=2.30 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd

1

Multisocket

R26 R29 R36 R20R21

LED7 R5 LED9 LED10 R38 LED3 LED4 LED5

LED2 LED1 LED6 R6

U11 C26

C25 C30

C21

C24 C23 32

33

R18

C20

U15 R31

C28

C2

JP4

C32

R33

C29

R16 R27 R28

U8

JP1 JP2 JP3

R34 LED8

R24 R25

SL1 C11

CR1 CR2

D1

X1

101

4C

1R 4R 4U 1$ U

71 R

21 R 31 R

+

32 R 7U

9U

13 C

31U

53 R

59 U1R

RC 9R86

7C

71 C 81 C

51 C 41 R

1L

2U

3C

9C 8C

2R 01 R 01 C

5C 72 C

11 R 7R 3R

1C 61 C

03 R

6U

41 U

91 C 51 R

2L

04001 FL V

01U

41 C

SEAL bottom copper layer

11/3/09 12:13 AM f=2.30 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd

1 CI

102

22 C 73 R

23 R

31 C

21 C

11/3/09 12:26 AM f=1.90 /home/coopmans/eagle/SEAL_r2/seal_v2freeroute.brd

103

SEAL drill layer