A Distributed Avionics Package for Small UAVs - CiteSeerX

AIAA 2005-6984

Infotech@Aerospace 26 - 29 September 2005, Arlington, Virginia

A Distributed Avionics Package for Small UAVs Jack Elston ∗ , Brian Argrow † , Eric Frew‡ University of Colorado, Boulder, CO, 80309, USA This paper presents the design and implementation of a distributed computing architecture used to accommodate a wide range of operational environments. The architecture’s advantages include fault-tolerance and redundancy through an abstracted high and lowlevel bus protocol, and significant system scaling enabled by its modular nature. The current implementation was created for use in an avionics context, where it accommodates many payload sizes, levels of complexity, and configurations. Each of these advantages are evident in one of the many RECUV (Research and Engineering Center for Unmanned Vehicles at the University of Colorado) sponsored projects that use this system. This paper will describe some of these projects and how each maintains very different system requirements, ranging from providing a full-featured avionics system, to enabling control of a micro-UAV.

I.

Introduction

sing a modular architecture for an embedded system provides many advantages over a single board U solution. Customization and system-reconfiguration are simplified, and upgrading the system is significantly less expensive and time consuming. Modular architectures enable piecewise development and testing of a system, so long as a well defined interface exists between modules. Tasks can be decentralized within a group, and each component can be later added to the final system. Each subgroup is able to maintain “ownership” of one particular node, and can be responsible solely for its development and maintenance. In the case of multi-stage projects, modularity ensures a smooth transition from a finalized deliverable to the next step in the development process. A modular architecture also allows for each system to be studied and understood within its own context, and therefore lends itself well to teaching applications. A course may be be constructed of separate units which focus on a single subsystem of an avionics package. An example division of these topics may be: sensor fusion and interface, control algorithms, communication protocols, and filtering. Each subsystem can be taught, constructed and verified without requiring full knowledge of the rest of the system. Not only does a modular approach allow the benefit of focusing on one part at a time, it also enforces the correct method of designing and testing complex systems. The functionality of a modular system relies heavily on the definition and adherence to a strict interface. Each component can be designed and constructed independently, but must conform to set guidelines to perform as a system. This encourages a fairly high level approach to the design phase, and a significant amount of time must be spent on defining separate subsystems and their interfaces before any work is done. Similarly, modular design highlights the value of developing a good testing algorithm. Each component should be tested independently before integration to simplify and reduce system level problems. Focusing on the specific example of avionics systems, two main alternatives exist to constructing a modular system. In the past, many avionics packages were designed using a federated architecture, where aircraft control is managed through several essentially independent systems. Some inter-system communication is performed in this architecture, but is kept to a minimum to decrease each system’s complexity and interdependence1 (which could lead to multiple failures). Not only does this architecture require a tremendous amount of resources, but it also makes reconfiguring the system very difficult. Another common architecture, especially for use in very small UAVs, is the single board solution.23 A single board avionics package requires ∗ Graduate

Research Assistant, Department of Aerospace Engineering Sciences. Student Member Professor, Director Research and Engineering Center for Unmanned Vehicles. Senior Member. ‡ Assistant Professor, Department of Aerospace Engineering Sciences. † Associate

1 of 10 Institute of Aeronautics Copyright © 2005 by Jack Elston. Published by the AmericanAmerican Institute of Aeronautics and Astronautics,and Inc., Astronautics with permission.

fewer resources than the federated architecture, but provides many points of failure. Single board systems are typically very hard to scale, and might prove to be impossible to interface to certain components. Given the restrictions of a federated or single board solution, an increasing number of avionics packages have been implemented which employ modular characteristics. UAV systems such as Stanford’s Dragonfly1 and Georgia Tech’s GTMax4 each feature avionics packages containing many qualities of a modular architecture. The GTMax uses a rack-mount system connected to a backplane to allow different flight modules to be inserted or removed from the system. The Dragonfly avionics uses a COTS PC-104 architecture to enable the construction of their avionics package in a stackable manner. Whenever more functionality is needed, another PC-104 form factor card is “stacked” on the avionics package. Each system enables the user to interface COTS components to a particular module, and the GTMax avionics package even allows for hot-swapping so components can be added or removed while the system is running. Furthermore, although some modularity is lost in both systems by reliance on a centralized computer, physical and software barriers have been constructed so as to increase the modularity, and therefore reduce the dependency between each system. The presented architecture (Figure 1) provides many key benefits over these and other modular systems, and significantly simplifies the approach to system implementation. While maintaining the ability to easily add and remove subsystems, it lacks the restrictions that classify other modular architectures as less than an “open” modular system. As an example, consider the aforementioned PC-104 architecture.51 While this architecture allows components to be added in a modular fashion, the system maintains constraints such as a required size and shape due to the PC-104 interface. Furthermore, it cannot be considered a truly “open” modular system in that the components added must be PC-104 compliant. A further advantage of the presented architecture and in particular its current implementation, is the ability to place components at any location within a given vehicle. This enables interface boards to be placed adjacent to the sensors they are acquiring data from. Since many sensors have interfaces that are very susceptible to noise, for instance an analog voltage level or TTL serial communication, proximity becomes important to measurement accuracy. In a PC-104 system this means that the sensor must be placed near the rest of the avionics stack, which is usually not an ideal location, or that a separate board be constructed to sample the signal and output it in some other format. Unlike a PC-104-based system, or even the customized GTMax solution, the presented architecture does not require a centralized computer. By enabling each node to maintain some intelligence, systems may continue functioning despite failure of particular subsystem. A level of fault tolerance is achieved equivalent to the nearly independent subsystems of the federated architecture while maintaining the advantages of the modular systems. In addition, by eliminating the need to have a central module perform all computations, modules can be added and removed from the system without requiring changes to any other component in the system. The absence of a central computer also allows for significant system scaling from a single node to several hundred. Bus protocol is also affected by decentralization in that the protocol is no longer limited Figure 1. Disributed network architecture. Naiad is the designation for the interface nodes to be to a publish/subscribe architecture that has become prediscussed in more detail later. dominant in most modular avionics systems.

II.

System Architecture

odularity and node independence are achieved by maintaining intelligent system nodes, and providing M a bus protocol that guarantees message transmission utilizing a typed addressing scheme. Each node is responsibile for the interface to a particular set of sensors, devices, or a computational task. Each of these subsystems can be replicated several times across a system and broadcast either simultaneously or in a controlled manner. Control of message transmission can be provided by using per-node decision making, or control by a supervisory health-and-status subsystem. Additional nodes may be added to provide

2 of 10 American Institute of Aeronautics and Astronautics

interfaces to other devices such as to a wireless communication system. Computationally intensive tasks such as filtering can be abstracted to a set of nodes tasked with data processing. Figure 1 illustrates the distributed architecture. Dashed lines indicated areas of system expansion, and colored blocks represent possible subsystems. Alternative bus connections using other protocols, may be added to prevent system failure due to primary bus contention. A.

Processor

The system’s capacity for data manipulation and its power usage is heavily determined by each node’s computational power. A system with well divided tasks rarely requires more than a simple eight bit microcontroller per node, and the use of such a chip significantly cuts down on power usage. There have been some tasks encountered that pushed the limits of the microcontroller’s computational capacity, but the problem can solved by abstracting the task to several nodes, or interfacing to a single board computer such as the gumstix platform.6 B.

Bus Protocol

The message-type-based CAN (Controller Area Network) protocol provides for inter-node communications. A CAN controller coupled with a fault-tolerant transceiver provides the reliability that is needed from the system. Very high differential voltage levels protect the bus from interference, while the transceiver guarantees message delivery and allows the system to run on a single wire in the case of a separated bus line. Beyond being robust, the CAN protocol utilizes a message-based addressing system. This method was particularly suited to our application Figure 2. The Modular Avionics as it enables scaling of the system without significant modifications, lend- System and Test Plane. ing itself nicely to the multi-group project paradigm. In addition, single node interfaces can be changed to communicate with a newer version of a sensor, and still transmit the same message type. From the perspective of the rest of the system, the use of any particular sensor, old or new, bears no significance, and both could be used at the same time. In the case of both being used, the message based addressing allows use of several subsystems as a redundancy scheme. Furthermore, senors generating the data for each particular message type may be widely varied. As an example, aircraft altitude may come from GPS, pressure sensors, or an IMU estimate. Table 1.

Node Name Servo Control Command and Control IMU Interface Communications Wind Calculation and Compensation GPS Interface Health and Status

Node Number∗ 2 4 6 8 10 12 14†

∗ Nodes †

are arranged from highest priority to lowest priority. User may select an even node id between 16 and 126 for any further nodes.

At the software protocol layer, a high level interface to the bus allows for simplified user interface and a more defined node interaction scheme. Message addressing is limited to the standard CAN identifier of 11 bits, which was broken into a message number (per node), message type identifier, and node identifier. Each message relies upon these 11 bits to establish priority, and therefore node numbers were predefined in some

3 of 10 American Institute of Aeronautics and Astronautics

cases to allow a higher priority to mission critical nodes. The predetermined priority is shown in table 1 on the preceding page. Message numbers similarly add to the priority of the message, with the first message type transmitted per node being higher priority than the second. Lastly, the message type identifier is used to differentiate between message flow. Messages being transmitted to the entire system for use are given an transmit type. Examples of these types of messages include the periodic transmission of IMU data, and GPS data. Messages that are broadcast to be received by a specific node are given a receive type. Examples of these messages include Servo commands and control system gains. The protocol adds to the system the capability to perform health and status monitoring. Each node emits a heartbeat at a given rate that is analyzed by the health and status node. Should a heartbeat be absent for a given amount of time, each node has a reserved set of received message types that enable the health and status system to command a restart of the node. Should the heartbeat remain absent, the node can then be assumed to have been removed or in a state of failure, and the system can reconfigure as necessary. Furthermore, in a scheme similar to openCAN,7 the message creation protocol can accommodate a system with periodic messages. By selecting either an inhibit or event time, the user has full control over the flow of data from the node. Given an event time for a particular set of data, the data will be transmitted periodically at this interval. Given an inhibit time, the protocol will wait until the inhibit time has expired, and then only transmit upon a change in the value of the data. Once the data has been transmitted, the inhibit timer is reset and the process begins anew.

III.

Implementation and Testing

he goals of designing a truly “open” modular system have been realized in the first implementation of T the system. While there were a few minor changes to be made to the original implementation such as the addition of a TTL UART, the system has been extensively tested and is used in several projects at the University of Colorado. A.

First Revision (NAIAD)

The presented architecture and original motivation for use in avionics packages is realized in the first prototype node, Naiad, named for the innermost moon of Neptune (Figure 3). In the schematic, Thalassa is a meteorological sensor board developed from the basic Naiad. Particular details about the design of the node include the use of the SJA1000 CAN controller and TJA1053 fault-tolerant transceiver for inter-node communications, and use of the Atmel ATMega128 microcontroller to provide each node’s intelligence. The microcontroller provides the added benefit of including PWM output for servo control, an ADC for sensor signal acquisition, and various buses (I2C, SPI, UART). A system diagram for the node can be seen in Figure 4. A Naiad node is approximately an inch and a half on each side, weighs about 0.5 ounces, and nominally uses 50 mA at 5V. The node contains a watch-dog timer with brown-out detection, Figure 3. A photo of two of the Naiad and using a 14 MHz clock the microcontroller is capable of about nodes. a 14 MIPS throughput. The node was constructed using a 4 layer board to minimize onboard signal noise and decrease footprint. Each has mounting holes to enable easy placement about the aircraft, or to be stacked in a convenient location using very small standoffs. B.

Testing

After completion of the system, iterative testing was performed using a small RC trainer aircraft (see Figure 2 on the preceding page). The aircraft was selected based upon availability, but turned out to be a ideally sized testbed.

4 of 10 American Institute of Aeronautics and Astronautics

Table 2 provides a brief overview of the test configurations to date for this particular use of the Naiad system. C.

Timeline of Testing

Control of the aircraft was given in small steps to the system to ensure functionality and safety. The very first test of the system was to determine whether the addition of the system between the pilot commands and servo control would cause any noticeable loss in performance of the system. Two Naiad nodes simply acted as a passthrough where the PWM from the 72 MHz receiver was sampled, interpreted by the Naiad, fed through the CAN bus as servo commands, and then reproduced as PWM signals to the servos by another node.

Figure 4. System diagram for Naiad and Thalassa Nodes.

Table 2.

Date 12 08 02

Test Overview Initial test of system

# of Nodes 2

12 22 03

GPS and recording test

3

Spring 03

Joystick control test

2

04

USB controller and rate based stability test

3

?

GPS downland, rate based filtered control test

5

Tasks Interpret R/C commands Output servo commands Interpret R/C commands Output servo commands Log GPS Record servo commands Play back servo commands Communication with modem Output servo commands Communication with modem Output servo commands IMU interface Stability calculations Mix user input and control input Communication with modem Output servo commands IMU interface and filtering Stability calculations Mix user input and control input Control over stability and filter gains GPS interface

Table defining flight test configurations.

Successive tests added further sensors and eventually to a 900 MHz link where the pilot would talk to the plane directly through a laptop link instead of through a standard R/C console. Once this was established, small control algorithms were added where the plane made some simple rate-based corrections based upon IMU values. A second user on the ground was in control of setting the gain for this control, and could therefore slowly transition the plane into a “stabilized” mode.

5 of 10 American Institute of Aeronautics and Astronautics

Testing was also performed on the processing bandwidth of a single node. The IMU node was made to perform a 2nd order Butterworth filter to the incoming data from the sensor and only submit the filtered data to the rest of the system. The cutoff frequency and gain of the filter remained in control of the ground system, and once again, the component was slowly introduced to ensure safety and functionality.

IV.

Other Projects Using the Naiad System

ollowing the Naiad’s use in its original project, it has been used in subsequent semesters by other groups. F These groups include both the orignally targeted senior-level projects, and also complex graduate level research projects. Most of the senior-level projects have limited scope in order to be completed within a two semester course sequence. Many of these projects require interfaces to electronic systems, thus often groups choose to use to use the Naiad system so that they might focus on the particular work they desire to research. This has also provided the opportunity to refine the Naiad software and documentation to provide for a simple interface that requires little prior experience with embedded systems. Below is a list of the projects that have used the Naiad system to date, along with a short description and an explanation of their use of the system. A. 1.

AUGNet Project Overview AUGNet (Ad-hoc UAV and Ground Network) is a communication concept that combines small ( 10 kg) lowcost, custom-made UAVs with ad hoc wireless (mesh) networking. The UAVs might be used individually to support applications such as commercial remote sensing, scientific data collection, and tactical military operations. The low cost also enables multi-UAV cooperative swarming and flocking missions such as long baseline sensing, atmospheric gradient following, and wide area searches.89 2.

Naiad Application

The integration of the Naiad system aboard the networked UAVs expanded the AUGNet system from a communication network to a system capable of providFigure 5. Ares Platform used in AUGNet Project. ing command, control and communication to a group of autonomous UAVs. Each plane previously contained two independent systems, a single board computer used for maintaining a node on the 802.11b network, and a Piccolo avionics package from Cloudcap Technology.2 The Naiad system provides a standardized interface between these two and enables the addition of a “high-level” flight computer and a scientific payload. Mission level decisions are made by the flight computer given network metrics and operator specified parameters. These parameters can be changed through the ad-hoc network using a GUI on a remote monitoring station. Data from the scientific payload is passed through a socket interface to a ground station, and can be displayed in near real-time to researchers located within range of the ad-hoc network. Given that the Naiad system had been originally developed as a sensor interface, it suits itself well to this application. The current project implementation requires a set of three nodes to be added to the systems in each of the planes, two used to interface to the communications board and avionics, and the other to provide the abstracted flight computer. The transfer of messages between these nodes through the CAN bus enabled the group to eliminate a GPS antenna, as previously both the communications system and Piccolo required one, and to enable the control of the Piccolo unit to be performed either by the flight computer, or through the 802.11b interface. Furthermore, the addition of the flight computer creates the opportunity for a investigating fairly complex control, including cooperative algorithms.

6 of 10 American Institute of Aeronautics and Astronautics

B. 1.

Fire UAV Project Overview

Effective wildland fire management is currently limited by the lack of real-time micrometeorological data. Most fire weather data is acquired through ground-based sources or weather balloons, both of which are usually only safely deployed far from the fire site. The project objective is to develop a Fire Management UAV for acquiring and relaying critical, real-time information during wildland fire incidents. This data includes relative humidity, temperature, pressure, wind speed and direction, and dew point. We intend to demonstrate that such a product designed specifically for the needs of fire management would be faster and could provide more valuable data than existing systems. 2.

Naiad Application

The Naiad was intended to be the avionics package for this particular project, and all of the initial testing was performed to meet its goals. It should be noted that a subgroup of the Fire UAV team was tasked with implementing an engine tuning controller using a single Naiad node. The system will enable the UAV to increase its flight profile, by adjusting the carburetor screws to accommodate significant altitude change. While this subsystem was successfully implemented, it has not been integrated into the rest of the system. C. 1.

Micro Air Vehicle Project Overview

Release of contaminants in urban areas can lead to severe public health consequences. This project develops an integrated Sensor Flock to enable rapid characterization of toxic plumes for contamination prediction and source location. A Sensor Flock consists of semi-autonomous micro air vehicles (MAVs) transporting miniature toxin sensors throughout the atmosphere above populated areas, networked to a base station providing toxin dispersion modeling and flock supervision, using novel lightweight, real-time, data-reactive wireless information routing. MAV platforms lower manufacturing costs, reduce risks of collision damage, and reduce visibility and noise that might create public alarm.10 2.

Naiad Application

Figure 6. Colorado Micro Air Vehicle Project.

A single Naiad node was used as the central computer and sensor interface in this project. Weight and space were significant constraints, and the Naiad lent itself well to this application. Onboard the small craft was an IMU and primitive wireless transmitter, along with two servos and a motor speed controller. The Naiad was tasked with downlinking flight data while providing a control uplink for the pilot of the craft. Although the first iteration of this craft proved to be too unstable for the pilot to manage, the Naiad was able to perform its tasks as desired. D. 1.

Heavy Lift Vehicle (HAVUC) Project Overview

HAVUC (Heavy-lift Aerial Vehicle for the University of Colorado) is the University’s entry into the Society of Automotive Engineers’ Annual Aero Design competition. The goal of the competition is to challenge students to design, fabricate, and fly a small UAV that can meet stringent empty weight and takeoff distance requirements while carrying aloft as much payload weight as possible. The competitions attract dozens of colleges and universities from around the world, with student members ranging from freshman to doctoral candidates. The benefit that the HAVUC project offers is the versatility of the airplane to be used in other

7 of 10 American Institute of Aeronautics and Astronautics

projects. The airplane has a relatively large fuselage volume and is capable of carrying a payload that weighs more than 300% that of the empty airplane weight. This capacity allows other projects to use the airplane as a test vehicle for a wide variety of mission-specific payloads. In addition, a flight data acquisition system that was designed and developed to verify the performance metrics of the HAVUC airplane could be easily adapted to fit other similar aircraft.8 2.

Naiad Application

The HAVUC team used the Naiad primarily for platform testing and verification. A suite of sensors including an angle of attack sensor and pressure sensor were installed in the vehicle, and the Naiad was used to initialize and read the sensors. All of the flight data was logged to the Naiad’s I2c EEPROM, and read out later. Using this data the team was able to verify the plane’s performance matched what was expected from the design. E. 1.

SAE Car Project Overview The Formula SAE competition is for engineering students to conceive, design, fabricate, and compete with small formula-style racing cars. The restrictions on the car frame and engine are limited so that the knowledge, creativity, and imagination of the students are challenged. The cars are built with a team effort over a period of about one year and are taken to a host institution for judging and comparison with approximately 140 other competitors from across the nation. The end result is a great experience for young engineers in a meaningful engineering project as well as the opportunity of working in a dedicated team effort.11 2.

Figure 7. Current Formula SAE project developed in the Department of Mechanical Engineering. The rear-moutned wing is a contribution from a joint effort with the Department of Aerospacke Engineering Siences

F.

Smart Sondes

1.

Project Overview

Naiad Application

A single Naiad was used as the entire control system for an airfoil (as can be seen on the back of the car in Figure 7) that would adjust its angle of attack according to the speed and angular accelerations of the car. This enabled better handling at high speeds while cornering, while reducing the drag induced by the airfoil in the straightaways.

The current availability of meteorological sondes is primarily limited. Most current sondes are available only as dropsondes, which limits their functional descent and directionality. Conversely, there also exists a fully autonomous and maneuverable UAV with similar data gathering capabilities, the Aerosonde. Even though these vehicles are small (on the order of 30-lb maximum takeoff weight), they are too expensive to be considered expendable. A specific need thus exists to create low cost sondes with a controlled descent capability and the ability to operate successfully in severe conditions such as those that exist in storm and polar environments. This senior project group will investigate the dispersal and communications issues of a distributed sensor system of low-cost, maneuverable sondes with the design and test of a system that demonstrates the feasibility of a system that might be deployed in severe environments.12 2.

Naiad Application

8 of 10 American Institute of Aeronautics and Astronautics

In order for the group to meet their desired specifications, they needed to test and select a wireless protocol. The Naiad was used as a communications node which linked the wireless transmitter to a ground based computer. The modules were sent aloft using weather balloons (Figure 8), and the distance between them was varied to determine maximum throughput per protocol at a given distance. The project is currently only on its first phase, and consideration has been given toward using a single Naiad as the sonde flight computer, instrument interface, and communications arbiter.

V.

Conclusion

Figure 8. Smart Sonde Project. Modularity has recently become a desired trait for most avionics systems, however, current implementations maintain limitations that keep them from being truly “open” modular systems. Furthermore, current systems rely on the insertion of software and hardware barriers to maintain some functionality should one part of the system fail. Need for a new system has been presented in this paper that maintains the advantages of using a modular architecture while providing enough subsystem independence to avoid dependence on any one part of the system. Considerations for size, proximity to sensors, and the need for modularity led to the design of a distributed system. Each component of the system is a small interface board with some computational power. The board can be mounted next to sensors, or anywhere space can be found in the vehicle, and then wired to the rest of the system through a more robust communications method. These interface boards are responsible for initialization of their specific device, along with signal conditioning and interpretation. This allows for the bulk of the computations to be done at the sensor, and eliminate the need for a centralized flight computer. This design effectively reduces the need for a large amount of computing power, and a similarly large battery supply or alternator. The presented distributed architecture has been demonstrated to fit well into undergraduate senior-level project, enabling the focus of the project to remain high level, rather than on constructing the base hardware that will enable them to achieve their goals. In addition to the system’s usefulness as an electronics package for multi-disciplinary or multi-phase projects, it provides many of tools necessary to teach the complexities of an avionics system in a limited amount of time. A relatively simple autonomous system may be constructed out of a small number of nodes that would allow for a student to construct a similar system for use in the limited time-frame of a single course. Applications for the AUGNet program demonstrates how the system is also implemented into the research programs of the Research and Engineering Center for Unmanned Vehicles.

Acknowledgment Thanks to Kyle Bygott, Kiran Murthy, and Stephan Esterhuizen for working on the development of the original system. Thanks to Cory Dixon for software additions and for flying all of the test aircraft. Thanks to Tom Brown for his continued support of the project.

References 1 Jangy, J. S. and Tomlin, C. J., “Design and Implementation of a Low Cost,Hierarchical and Modular Avionics Architecture for the DragonFly UAVs,” Aug. 2002. 2 “The Cloudcap Website,” http://cloudcaptech.com, 2005. 3 Beard, R., Kingston, D., Quigley, M., Snyder, D., Christiansen, R., Johnson, W., McLain, T., and Goodrich, M. A., “Autonomous Vehicle Technologies for Small Fixed-Wing UAVs,” JOURNAL OF AEROSPACE COMPUTING, INFORMATION, AND COMMUNICATION , Vol. 2, 2005, pp. 92–108. 4 Johnson, E. N. and Schrage, D. P., “The Georgia Tech Unmanned Aerial Research Vehicle: GTMax,” Aug. 2003. 5 Kahn, A. D., The Design and Development of a Modular Avionics System, Master’s thesis, Georgia Institute of Tech-

9 of 10 American Institute of Aeronautics and Astronautics

nology, Georgia, April 2001. 6 “The gumstix Website,” http://www.gumstix.com, 2005. 7 “The openCAN Website,” http://www.canopen.org, 2005. 8 “The RECUV Project Website,” http://recuv.colorado.edu/projects, 2005. 9 Brown, T. X., Argrow, B., Dixon, C., Doshi, S., Thekkekunnel, R.-G., and Henkel, D., “Ad Hoc UAV Ground Network (AUGNet),” Proc. AIAA 3rd Unmanned Unlimited Technical Conference, Workshop and Exhibit, Chicago, Illinois, Sept. 2004. 10 “The CMAV Project Website,” http://enstrophy.colorado.edu/ mohseni/ActiveResearch/MAVForPlumeCharacterization1.html, 2005. 11 “The Formula SAE Website,” http://students.sae.org/competitions/formulaseries/, 2005. 12 “The Meteorological Aerial Research Sonde Project Website,” http://67.174.185.17, 2005.

10 of 10 American Institute of Aeronautics and Astronautics