Multi-Disciplinary Senior Design Conference
Kate Gleason College of Engineering
Rochester Institute of Technology
Rochester, New York 14623
Project Number: P09233
OPEN SOURCE, OPEN ARCHITECTURE UNMANNED
AERIAL VEHICLE FOR IMAGING SCIENCE –
MEASUREMENTS BOX
Mike Skube / Team Lead (ME)
John Isely / ME
James Hunt / Team Lead (ME)
Bill Atkinson / ME
Joe Peters / EE
Kevin Li / EE
Heidi Morgan / EE
ABSTRACT
The objective of the project was to provide a
measurements box that would be able to retrieve flight
data that is pertinent to operating an unmanned aerial
vehicle (UAV) for use in conjunction with the
Airframe groups to provide the College of Imaging
Science a cheaper alternative for their research. The
scope involved making one complete box capable of
measuring all the necessary data, along with some
spare parts in the event of mishaps. The box is capable
of retrieving flight data of all the necessary parameters
for unmanned flight, but not from all the sensors at
once. This data is stored on by the micro-controller
onto the removable SD memory card. This data can
then be retrieved by a computer for post processing
and analysis.
INTRODUCTION
The design objective was to provide a small,
light box that could measure all the necessary
parameters for unmanned flight accurately and
reliably.
The College of Imaging Science currently
uses a manned aircraft to do their research which is
expensive and time consuming. Their equipment is
very large and heavy, making it necessary to use this
manned aircraft to physically fly over their target of
research. Therefore, they requested a roadmap of
Senior Design projects to build a UAV to replace this
manned aircraft, along with a group working on the
reduction of size and weight of the camera system.
Stemming from this request, four first year groups
emerged, Airframe A (P09231), Airframe B (P09232),
the Measurements Box (P09233), and the Camera
(P09561) group. From the Airframe A, Airframe B,
and Camera groups, came the constraints,
requirements, and goals for the measurements box.
The first phase of the measurements box is to
simply decide what measurements are needed and
acquire the required sensors to obtain these
measurements to fly a UAV. This is very important
because the plane must know its orientation, direction,
location, altitude, and velocity. Each sensor that was
selected serves a specific purpose and measures a
specific flight characteristic. The first phase platform
will be used to simply acquire data for the postprocessing of individual flight data.
SENSOR SELECTION
The costumers’ needs were established
through the other three teams and what was needed to
successfully fly an UAV. There are as follows:
1.
2.
3.
GPS Measurement (in real time)
Velocity Measurement (in real time)
Altitude Measurement (in real time)
Copyright © 2008 Rochester Institute of Technology
Page 2
Proceedings of the Multi-Disciplinary Senior Design Conference
4.
5.
6.
7.
Roll, Pitch, Yaw (& rates) (in real time)
Vibration Dampening
Power Source
Microprocessor
3.
4.
From these costumer needs, specs or
engineering metrics were set up to meet these
costumer needs. There are listed below:
1. Resolution of 5 units for each sensor
2. Weight less than 1lb
3. Sample Rate of no less than 1 Hz
4. No bigger than 3.5" x 2" x .5"
5. Memory of 1GB
6. Software to process Data
7. Crash survivable
8. 15 min Battery Life
The first important step in designing and
producing the measurements box was to first layout
the necessary measurements that are needed for
unmanned flight. These measurements are as listed
below:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Position (GPS location)
Heading
Altitude
Total Pressure
Static Pressure
Total Temperature
Pitch
Roll
Yaw
Pitch Rate
Roll Rate
Yaw Rate
1.
2.
GPS
Altimeter
The GPS takes care of measurements 1 and 2,
while the Altimeter takes care of measurement 3. The
Pitot-Tube satisfies measurements 4-6. Then the IMU
takes care of measurements 7-12.
In addition to these sensors, a microcontroller
unit (MCU) was added to sample, store, and provide
power to the sensors, and dump the data to a computer
for post-processing purposes. This MCU will also be
used to feed data to the control system when the
control system is created and implemented by a group
further down the project road map.
For each type of sensor that is required to fly
a UAV, a group of possible choices was compiled and
through a Pugh Analysis of ratings and weights, was
narrowed down to one sensor for each sensor type.
This sensor, through the Pugh Analysis was deemed to
be the best sensor of that sensor type that met the
requirements of that sensor type. The sensors that were
chosen for this measurements box are as follows:
1.
2.
3.
4.
From these measurements, a flight control
system is able to tell where the UAV is, its current
orientation, and velocity so the flight control system
can make adjustments accordingly.
Once these required measurements where
organized and agreed upon; how to measure these
flight parameters was raised. This was simply done by
the background knowledge of the team. From our team
discussions on what instruments were need to measure
these flight parameters, a list of the sensors need to
make these required measurements was made to
follows:
Pitot-Static Tube w/ Temperature
compensation
Inertial Measurement Unit (IMU)
GPS – 32 Channel San Jose Nav
Altimeter – Zlog
Pitot – Static Tube – Eagle Tree Systems
(ETS) Pitot-Tube
IMU – Analog Device (ADI) S16350
With all the sensors selected, the placement
of those sensors was the next topic to be addressed, as
the placement of some of the sensors is crucial to the
sensor reading accurately and reliably. The IMU was
given the highest priority of sensor placement because
it needs to be as close to, if not right on the Center of
Gravity (Cg) of the aircraft. This is because the IMU
reads angles and angle rates and the measurements
will be thrown off if it is not at the Cg. With the ADI
IMU however it is possible to correct for the IMU not
being at the Cg, if the IMU cannot be placed at the Cg.
The Pitot-Tube as well needs some special placement.
Because the Pitot-Tube is reading the incoming flow
of the air as the plane flies through, it is important that
the flow is not disturbed or if need be, disturbed very
little. If the air is disturbed around the Pitot-Tube, it
will not read the correct Static and Total Pressure and
Total Temperature. This is why the Pitot-Tube is
placed as far out on the wing, preferably just shy of the
wing tip because this is where the least disturbed air is.
At the tip of the wing, the Pitot-Tube is not in any
prop and jet wakes, as well as being away from the
boundary layer and turbulence created by the aircrafts
body.
The GPS and the Altimeter were the lowest
priority sensors in terms of placement, because they
had very little restrictions in terms of what would
Project P09233
Page 3
Proceedings of the Multi-Disciplinary Senior Design Conference
affect their measurements. The Altimeter only
required that there be a .25in2 (1.6x10-4 m2) hole that
allowed the static pressure of the atmosphere into the
box so that the pressure sensor on the Altimeter could
read the static pressure. The GPS had even fewer
restrictions. The only restriction would be that the
GPS cannot acquire and track satellites through dense
materials like metal. However metal is not being used
because of weight restrictions. Both sensors’
measurement accuracy and reliability is independent
of orientation.
Finally, since all of these sensors are just
acquiring/receiving data and not transmitting/sending
out data, how close they are to each other in terms of
interference is not an issue and not measures are
needed to account for this.
MICROCONTROLLER SELECTION
MCU features: During the selection process a few key
attributes were weighed before the final decision was
made on which micro-controller was to be used in the
design. These factors included performance, price,
developing environment and interface capability.
The Olimex SAM7-256 board utilizes an
Atmel AT91SAM7S256. This board contains 256k
Bytes of Program Flash, and 64K Bytes of RAM. The
fact that it is considered to be the leader in MIPS per
watt and has the capability of communicating with two
SPI and two UART peripherals makes it not only cost
effective, but highly functional. Additionally, the
development board had the SD/MMC connector
hardware needed to expand the available needed to
store all data collected at the determined sampling
rate.
SPI interface: The SPI (Serial Peripheral Interface)
interface allows the Atmel AT91SAM7S256 to
communicate with one or more slave devices. The
ability to share the same data bus is made possible by
utilizing a chip select signal. By setting the chip-select
to logic low the Atmel AT91SAM7S256 permits
communication to and from a connected peripheral
device. The SPI interface is used to communicate with
both the IMU and additional external SD/MMC card.
In order to drive communication, the SPI
clock has to be generated. The SPI clock frequency
must be less than or equal to the maximum frequency
the peripheral can handle. Each bit transfer is
dependent upon the rising or falling edge of the clock.
The Atmel AT91SAM7S256 had to configure the
clock polarity and phase so that it was in sync with the
peripheral it was interfacing with. In order to establish
the appropriate polarity and phase for successful
transmission, the CPOL and CPHA have to be set
properly during initialization. The CPOL determines
the base value for the clock or when to sample the
data, while the CPHA sets whether or not the
transmission is performed on the rising of falling edge
of the clock.
During a single SPI clock cycle, there is a full
duplex data transmission. A full duplex data
transmission occurs when data is both transmitted and
received simultaneously. For example, the MCU sends
16 bits in a single frame, which includes the address of
the register it wants to read of the IMU on the MOSI
line. The data received is always a single frame behind
the address that is sent. In order to read the contents of
6 registers, it takes 7 frames to receive.
These transmissions are made possible with
two shift registers that have the same width. This size
is dependent upon the size of data frame. In the case of
communicating with the IMU, a 16 bit frame was
required by the specifications laid out by Analog
Devices, while an 8 bit frame is standard when
communicating with and SD/MMC card.
Figure 1 shows the timing diagram necessary
to communicate effectively with the IMU. The timing
diagram for the MMC has a similar pattern.
Figure 1: IMU SPI Timing Diagram, from the
ADIS16350 data sheet
The UART (Universal Asynchronous
Receiver/Transmitter) is a common I/O peripheral
available on many devices. The Atmel SAM7P256
microcontroller includes 2 UART peripherals with a
variety of settings to allow interfacing with different
peripherals.
The most common setting that needs to be
configured is the baud rate. To configure the baud
rate, the clock source, and the baud rate must be
selected. In order to set this appropriately, the main
clock was used which was running at approximately
48MHz, however the two sensors dictated the baud
rate that was used. For example, the GPS was
configured to run at 38400 Baud while the altimeter
was configured to run at 115200 baud by the
manufacturer. The UART uses a baud rate generator
to create the clock source.
𝐵𝑎𝑢𝑑 𝑅𝑎𝑡𝑒 =
𝑆𝑒𝑙𝑒𝑐𝑡𝑒𝑑 𝐶𝑙𝑜𝑐𝑘
(8(2−𝑂𝑣𝑒𝑟)𝐶𝐷)
(1)
Both the altimeter and GPS were configured
to send and receive 8 bits with no parity and 1 stop bit.
Any data received is placed on the receiver holding
Copyright © 2008 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference
register. Data that needs to be transmitted is placed on
the transmitter holding register and gets shifted out.
The UART is capable of generating interrupts to
handle any outgoing and incoming data with minimal
overhead.
The UART is not only useful for
communicating between peripherals but is a
serviceable tool when developing programs since
many computers include serial ports that can read a
UART through a rs232 converter.
USB/UART
converters are also very common and can be used to
interface the microcontroller to a PC via USB port.
Page 4
of the parts as well as 3-D models of the box can be
found on our EDGE website, as well as complete
instructions for assembling the box and the
components into the box.
BOX DESIGN FOR SENSORS
The box design was based off of the sensors
that were purchased to fulfill the needs of the project,
as well as maintain low weight and ensure that the
final design would fit within the confines of the
fuselage of Airframe A. The external memory source
needed to be removable from the exterior of the
airframe without removing the box enclosure. To meet
these requirements the box was constructed out of
light aircraft plywood and the components were
attached to the box with 4-40 bolts and t-nuts. To
ensure that the box fit completely within the confines
of Airframe A, a model of Airframe A was used while
modeling the box and mock ups of the sensors were
used to ensure that the components would fit in and
out of the box. Because of the size constraints for
fitting into Airframe A, some components, specifically
the MCU needed to be modified to fit. Because of the
requirement that the IMU be near the Cg of the
Airframe, its mounting was pre determined, and the
box design accommodates for this.
Picture 2 - Measurements Box Inside Airframe A
The Pitot-tube and its sensor were placed in
the wing tip, because the Pitot-tube needed to be
outside of the prop wash, and outside of the wings
boundary layer, and turbulence created by the fuselage
as the aircraft flies through the air. The sensor was
placed on a removable plate in the wingtip as shown
below, so that the sensor could be moved from wing to
wing without having to re-run the wires and tubing
required to be the input into the sensor for every wing.
Because of the sensors moderate cost, it was chosen to
make this sensor easily accessible. By mounting the
sensor in the wing tip, we have cut down the time
delay seen in the tubing between the sensor and the
Pitot-static tube.
Picture 3 – Pitot Static Tube Inside Airframe A
Picture 1 - Measurements Box
The box was designed in Pro/E Wildfire 3.0
and prototyped in the laser cutter in the Aero Design
Lab at RIT. The box consists of 7 parts all cut out of
light aircraft plywood. The original design was refined
after the first prototype to accommodate changes in
mounting as well as added access holes to make the
assembly of the components easier. Drawings of each
TESTS, TESTS RESULTS, AND DISCUSSION
Several tests were setup for each sensor to
test its attributes as stated by their manufacturer. This
included such attributes as accuracy, reliability,
operational range, and start up time.
Project P09233
Page 5
Proceedings of the Multi-Disciplinary Senior Design Conference
Pitot-Tube Tests:
Test #1: Wind Tunnel Test of ETS Pitot-Tube in small
and large wind tunnel at RIT. This will be done
against a hot wire probe (large wind tunnel), and an
anemometer (small wind tunnel). These tests will help
to verify that ETS Pitot-tube is accurate, ±1 mph; can
hold a steady velocity reading without outside noise,
like wind; find the lower limit of the Pitot-tube, ETS
claims 2 mph; and that the sensor can measure up to
100 mph, ETS claims an upper limit of 350 mph. This
test will be done against observations not time.
The results of the small wind tunnel test are
shown in Table 1, while the large wind tunnel test is
shown in Figure 1.
m/s
mph
1
2.2
1.3
2.86
1.5
3.3
2
4.4
Table 1 – Small wind tunnel test
ETS PitotTube
mph
0~2
1~3
3~4
4
Figure 2 – Car Test Comparison
Table 1 shows that the lower limit is indeed
around 2 mph as claimed by ETS in which the PitotTube is reaching its stall point and can no longer
provide accurate readings.
Large Wind Tunnel Test
150
Speed (mph)
Pitot Tube
Hot Wire Probe
100
50
0
0
5
10
15
20
Event
Figure 1 – Large Wind Tunnel Test
Figure 1 shows how accurate the ETS PitotTube is to the hot wire probe, even up to 120 mph,
which is well above the UAV top speed. The small
discrepancies are from the fact that the hot wire probe
mount was not entirely level and therefore, not exactly
perpendicular to the flow.
From Figure 2 it can be seen that the two
curves almost lye one on top of the other. The reason
for some of the discrepancies is that the anemometer
would get stuck and had a slight delay when
accelerating or decelerating.
Test #3: This test is a time delay test. With a certain
length of tubing there is going to be a certain time
delay as the column of air in the tubing changes and
that change is picked up by the Airspeed chip. It is
important to determine this time delay to know how
much tubing can be used to achieve a reasonable time
delay. This is also important for the future knowledge
of the Controls Team so they can account for or if
necessary, change the length of the tubing to achieve a
desired and acceptable time delay. Figure 3 shows the
theoretical time delay with was created from using a
1st order pneumatic system with a step input and
Figure 4 shows the empirical time delay through
testing. Each test was run on 5ft of tubing presenting a
worst case scenario where tubing would be run
through the whole wing.
1
P1
P2
Psensor
0.9
0.8
0.7
0.6
Magnitude
Anemometer
along with the anemometer. Both were fixed to the
outside of the vehicle. One person drove and called out
when to record, while one person recorded the live
data off of the computer with the ETS system attached
while another person recorded the data off of the
anemometer. This test will also be against
observations not time. Figure 2 shows the results of
this test and how the ETS Pitot-Tube matched up to
the anemometer.
0.5
0.4
Test #2: “Car test” of ETS Pitot-tube against
anemometer. This test helped to see the Pitot-tube’s
delay through live telemetry, also how the Pitot-tube is
across changing speeds and higher speeds, along with
the addition of possible winds, angle of attacks and
side slip angles to check that the Pitot-tube will work
with these angles. This will be done on a car with the
Pitot-tube pointing forward directly into the flow,
0.3
0.2
0.1
0
0
1
2
Time (sec)
Figure 3 – Theoretical Time Delay
Copyright © 2008 Rochester Institute of Technology
3
4
-11
x 10
Page 6
Proceedings of the Multi-Disciplinary Senior Design Conference
1.5
1.3
1.1
0.9
0
0.5
1
1.5
Time (sec)
Figure 3 – Empirical Time Delay
From Figures 3 and 4, it can be that there is
some difference between the theory and empirical time
delays. The theory gives a time delay is on the order of
tens of nanoseconds while the empirical time delay is
on an average of 0.01 seconds. This difference is
caused by the fact that the tube was considered
perfectly smooth in the theory and that the release of
the column of air in the experiment was not perfect,
meaning that the column of air was not all released at
once.
Altimeter Tests:
Test #1: The stair test was used to determine the
accuracy of the altimeters on a small scale. The
altimeter was attached to a length of string marked
every foot and lowered down a stairwell. At the
bottom of the stairwell, the sensor was zeroed and the
test was started. The string was slowly raised the full
height of the stairs, and readings were be taken from
the sensor and was graphed against observations to
show the altitude increase. In this particular test, two
flights of stairs were used with a known height of 30’.
Figure 4 shows the results of the stair test.
Test #2: The vacuum chamber testing consisted of the
altimeter being put into a vacuum chamber. The
vacuum chamber will then be sealed after the altimeter
is placed inside and the pressure will be reduced over a
short period of time. The pressure in the chamber will
be reduced to that of atmospheric pressure around
1500 ft. The pressure from the vacuum chamber will
be recorded with a pressure sensor (gauge pressure)
and outputted on a multi-meter. Due to the nature of
the pressure sensor, the data will be taken over a
period of events and not based on time. The pressure
data will then be converted to altitude. After the data
test, the vacuum chamber data will be plotted against
the altimeter as plot of altitude versus the taken data at
each event which is shown in Figure 5.
Vacuum Chamber Pressures
Altitude (Ft)
Voltage (V)
Pitot Tube Time Delay
2000
1500
1000
500
0
Zlog
0
Pressure
Sensor
10
20
30
Data Collect Event
Figure 5 – Vacuum Chamber test
As Figure 5 shows the altimeter is very
accurate. The pressure sensor falls off after 1000ft
because the vacuum chamber is very hard to control
and getting a consistent steady pressure for the
altimeter and pressure sensor to read was difficult.
This led to the spike at 1000ft. Below 1000ft the
altimeter and the pressure sensor lye right on top of
each other with small variations. Since this was an
event based test, human error does come into play
when reading what the sensor is currently displaying,
leading to the small variations in the data.
GPS Tests:
Test #1: An accuracy test of the GPS was done by
simply starting up the GPS and then driving around
the RIT loop. After the data was collected, it was then
plotted on Google Earth to see how the GPS read data
matched up to already know GPS coordinates. Figure
6 shows a slice of the data around the RIT loop.
Figure 4 – Stair Test of Altimeter
The Zlog was almost dead accurate and
recorded the 1ft intervals to within less than an inch.
The small discrepancies lye in the fact that the string
was not held completely still while it was being pulled
up; the string was wavering around as it was being
pulled up.
Project P09233
Page 7
Proceedings of the Multi-Disciplinary Senior Design Conference
Test #4: At start-up time test of the GPS was
conducted to see the effects of a cold, warm, and hot
start up. The effect that the start-up has on the GPS is
not on the accuracy of the measurements, but the time
it takes for the GPS to acquire at least four satellites,
so the GPS will work properly. Figure 7 shows the
results of the start-up test with the GPS.
Time (sec)
Satellite Time Fix Test
250
25th
Percentile
Minimum
200
Figure 6 – GPS around RIT loop
As Figure 6 displays, the GPS is very
accurate; following the road exactly. The red points
indicate where the car had to slow down and stop. At
the RIT loop, there are stop signs and a crosswalk
where the red points are, giving an indication the GPS
is off by only a couple of feet at most.
Will the test around the RIT Loop was
conducted; altitude measurements were also taken
around the loop and then also compared to Google
Earth altitude measurements. The GPS altitude
measurements when compared with Google Earth
altitude results, there was a 1% error from the GPS
altitude according to Google Earth measurements.
Test #2: This test consisted of an orientation test of the
GPS to ensure that the orientation of the GPS did not
affect the number of satellites acquired and the
accuracy of the measurements. During this test the
number of satellites acquired were 13, 9, and 11. This
is consistent and the number of satellites depends
more on the local weather and how many satellites are
actually overhead at the time of start up.
Test #3: A material test was done to ensure that the
wood and mono-coat fuselage of the airplane did not
interfere with the GPS being able to acquire satellites
and its accuracy. This test was done with balsa wood
with mono-coat, and then in a car which simulated
varying metals and glass.
The GPS had no problems with the balsa
wood with mono-coat, as it started up, acquired
satellites, and recorded data with no significant, if any
changes. However, the GPS did show some signs of
error when in the car. The metal and glass body of the
car did not affect the start up time or acquisition of
satellites, but did add some error of 1-2%, which is
well within the error limits of the GPS as stated by the
manufacturer. It is suggested though, that if the GPS
will be covered by metal, as inside a metal box, that it
should be placed outside the box to ensure that the
dense metal does not affect the measurements, start up
time, and satellite acquisition of the GPS.
Mean
150
100
50th
Percentile
50
Maximum
0
Cold
Warm
Hot
Start-up mode
75th
Percentile
Figure 7 – GPS Start-up Time Results
From Figure 7, it can be seen that the hot
start-up is the quickest way for the GPS to start. The
maximum cold start up time was 3 minutes and 22
seconds and the minimum was 53 seconds. On average
the cold start up time was 1.9 minutes. The maximum
warm start up time was 2 minutes and 49 seconds and
the minimum was 27 seconds. The average warm start
up time was 1.7 minutes. The maximum hot start up
time was 3 minutes and 4 seconds and the minimum
was 17 seconds. The average warm start up time was
1.4 minutes. It is clear from these results that it takes
the longest time to start up if it is in cold start up
mode, less time if it is in warm start up mode, and the
fastest start up time when it is in the hot start up mode.
However, the fast start-up time of the hot start-up
means more power is consumed leading to a shorter
battery life.
CONCLUSIONS AND RECOMMENDATIONS
The boxed worked as expected and met the
goals that were set out at the beginning of the project.
The box is able to use one sensor in conjunction with
the microcontroller to capture flight data while in
Airframe A. The box met the weight requirement with
all the sensors in place so that Airframe was not
overweight for flight. The sensors themselves were as
another high point. The original sensors that were
picked through the Pugh analysis, and then put
through testing to see if they did what the
manufactures claimed they did and in some cases
exceeded what was expected of them. The original
sensors that were picked work so well that these
sensors are recommended for the rest of the Roadmap
Copyright © 2008 Rochester Institute of Technology
Proceedings of the Multi-Disciplinary Senior Design Conference
projects. There is no need for other sensors to be
picked, since the originally picked sensors meet and
exceed the specs required of them, while
accomplishing this at a very inexpensive cost. The
biggest success of the project was with the SD card.
The microcontroller can read all the sensors and store
to its internal memory, but this is small and volatile
(data is wiped if power is lost). With the SD card on
the microcontroller, code for the microcontroller was
successfully written so that the data the
microcontroller pulls from the sensors can be written
to the SD card in the form of a Text file. This Text file
makes post processing of the data much easier for the
end user.
There were no significant failures, but there
were some low points. The IMU works as expected,
but little actual testing was done on this sensor. This
was due to the fact that the sensor was waiting on a
test stand that was designed and being built by the
MAV Controls Team. However this test stand had a
very long lead time (6 weeks) and this lead time
continually increased as the project went on. The test
stand was not built in time for complete and thorough
testing of the IMU. Therefore in the future, more
complete testing of the IMU needs to done.
Page 8
relevant assistance when needed. These consultants
include: Dr. Jeffery Kozak, Mr. John Wellin, and Dr.
Agamemnon Crassidis.
Finally the team would like to thank the following
companies for their assistance and contributions to the
project. This includes: Foxlite for their helpfulness in
cutting our box and ADI for their donation of the
ADIS16350 IMU.
FUTURE WORK
Future work will be done on the measurements
box in terms of the data storage and then with the
conjunction of the control system.
First, the data storage will be made more userfriendly so that less post-processing of the data will
need to be done and the flight data is more easily
accessed.
The second and final end goal is to have this
measurements box not necessarily record data, but be
interfaced with the flight control system that will be
developed later in the road map process. This is most
important because the measurements box will be
feeding the measurements of the sensors the control
system so the control system can take the necessary
actions to accomplish the tasks that the UAV has been
given.
ACKNOWLEDGMENTS
The team would like to express its sincerest
gratitude to those who have made invaluable
contributions to this team and project as it has gone
through its many stages. Many thanks go to our
Faculty Advisor Dr. Jason Kolodziej who has
provided invaluable oversight and guidance for our
team in our individual project, as well as fostering
strong lines of communication between the several
UAV groups. The team would also like to extend
thanks to all consultants who provided prompt and
Project P09233