Team Falcon Journal Paper - California State Polytechnic University, Pomona 2011 AUVSI Student Unmanned Aerial System Competition
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
California State Polytechnic University, Pomona
2011 AUVSI Student Unmanned Aerial System Competition
Team Falcon Journal Paper
AUVSI Team Composition:
Team Lead: Matthew Rose
Department of Aerospace Engineering
Ajay Bettadapura, Stephanie Guadalupe, Samira Motiwala, Joseph Wagster, Hovig Yaralian (Department of
Aerospace Engineering); Sean Conant, Derek Sorenson (Department of Electrical & Computer Engineering);
Nicholas Berezny, Malen Sok, David Stone (Department of Computer Science)
Faculty Advisor: Dr. Subodh Bhandari
Department of Aerospace Engineering
Submitted: May 23, 2011
Abstract:
This journal paper provides a brief overview of the design, development, and implementation process of Cal Poly
Pomona’s Unmanned Aerial System (UAS) for the 2011 AUVSI SUAS competition. The system design represents a
continuing effort based on a platform from the previous first-year entry design. A systems engineering1 approach
was adopted to accomplish fully autonomous flight using the Piccolo II Autopilot system, as well as autonomous
flight maneuver, real-time image acquisition, image recognition, and real-time GPS waypoint navigation. A top-
down approach was utilized to provide a more holistic view of the system and its subsystems, along with the
interdisciplinary contributions to each element. The system was primarily designed to be as simple and low-cost as
possible with the use of commercially available off-the-shelf (COTS) components while still maintaining its overall
objective. Failure analysis from the previous year enabled high levels of safety analysis and risk management, which
resulted in a new backup safety measure for manual pilot override.
Table of Contents
1.0 Introduction ........................................................................................................................2
1.1 Overview ..............................................................................................................................2
1.2 Mission Objectives and Requirements.................................................................................2
2.0 Air Vehicle Platform ..........................................................................................................3
2.1 Airframe ...............................................................................................................................3
2.1.1 Introduction ...................................................................................................................3
2.1.2 Design ............................................................................................................................4
2.2 Autopilot ..............................................................................................................................6
2.3 Camera/Gimbal System .......................................................................................................6
2.3.1 Camera Selection ...........................................................................................................6
2.3.2 Gimbal Frame ................................................................................................................7
2.3.2 Image Stabilization ........................................................................................................8
3.0 Data Link ............................................................................................................................9
3.1 Radio Module.......................................................................................................................9
3.2 Antenna ................................................................................................................................9
4.0 Ground Station .................................................................................................................10
4.1 Piccolo Command Center (PCC) .......................................................................................10
4.2 Image Processing using Open Source Computer Vision ...................................................10
4.3 Observer Command Center................................................................................................11
5.0 System Test and Analysis ................................................................................................12
6.0 Safety and Risk Management .........................................................................................13
6.1 Safety Analysis ..................................................................................................................13
6.2 Risk Management ..............................................................................................................14
6.2 Navigate, Aviate, Avert and Communicate Plan (The NAAVCOM Plan) .......................15
7.0 Failure Analysis ................................................................................................................16
8.0 Concluding Remarks .......................................................................................................18
Acknowledgments ........................................................................................................................19
References .....................................................................................................................................19
California Polytechnic State University, Pomona 3
1.0 Introduction
1.1 Overview:
Last year’s competition entry signified the team’s first attempt to participate in an autonomous
flight mission; the design served as a foundation for the current year’s design, which includes a new
airframe and camera as well as modifications and improvements from the previous design to the overall
system. The team itself has grown with greater interdisciplinary expertise and is comprised of students
from Aerospace Engineering, Electrical and Computer Engineering, and Computer Science departments.
A Work Breakdown Structure (WBS) provides a holistic overview of the system architecture:
Cal Poly Pomona Unmanned Aerial System
(CPPUAS)
0001
Systems Air Vehicle Datalink System Test & Evaluation Maintenance
Ground Station
Engineering 2000 6000
3000 4000 5000
1000
Airframe System Equipment
Design & Image Retrieval & Operations Test & Evaluation Planning
2100 6100
Development Preprocessing 4100 5100
1100 Propulsion 3100
Materials Development Testing Facilities
2200 6200
Image Processing 4200 5200
Functional Analysis
Autopilot Avionics 3200
1200 Operational Data Operational
2300 System
Testing
4300 Retirement
Safety Analysis Autopilot 5300
6300
Imagery Command
1300 Test Facilities
2400 3300
5400
Design Reviews Integration &
1400 Assembly Test Data and Reporting
2500 5500
Quality Assurance
1500
Risk Management
1600
Figure 1.1: Work Breakdown Structure (WBS) for CPP UAS
1.2 Mission Objectives and Requirements:
During the mission, the unmanned aerial system (UAS) is to perform Intelligence, Surveillance,
and Reconnaissance (ISR) and comply with Air Tasking Order (ATO). This includes autonomous flight
through waypoint navigation, in-flight waypoint re-tasking, real-time data acquisition, and actionable
intelligence – accurate identification of colored alphanumeric targets on colored backgrounds of various
shapes. The mission profile is illustrated in Figure 1.2.
California Polytechnic State University, Pomona 4
Figure 1.2: Mission Profile of Unmanned Aerial System (UAS)
2.0 Air Vehicle Platform
2.1 Airframe
2.1.1 Introduction:
Figure 2.1: 12-Foot Telemaster Air Vehicle Platform
The airframe for this year’s competition is the 12-foot Telemaster2, which was selected for its
easy assembly, stability, and high weight lift capabilities. This was a major improvement from the
previous year airframe, which was smaller in size, volume, and weightlifting ability. Aircraft dimensions
and specifications are summarized in Table 2.1.
California Polytechnic State University, Pomona 5
Aircraft Dimensions and Specifications
Parameter Specification
Fuselage Length 6 ft
Height 1.6 ft
Chord Length 1.77 ft
Wing Span 12 ft
Wing Area 21.25 ft2
Gross Weight 36 lbs
Table 2.1: 12-Foot Telemaster Dimensions and Specifications
To meet the competition requirements, the Telemaster R/C Kit was modified for the flight during
the competition. The tail wheel was attached to the rudder using fiberglass instead of a free-flying tail.
This was necessary to have more control of the aircraft on the ground as well as reduce the amount of
battery power used for taxiing on the runway. The wing sections on the Telemaster Kit are not attached to
each other; they use friction and wing loading to keep themselves from sliding. This was deemed too
risky in an ISR mission, since abnormal wind gusting could cause the wings to detach. Rubber bands
were attached to each wing section to ensure mission reliability of the platform. Tape was applied to seal
the gap between each wing section for drag reduction.This will increase the amount of flight time in air,
which enables the system to recognize more targets and increase the likelihood of meeting the
competition objectives. The camera-gimbal system was attached to the strongest frame structure in the
plane fuselage. Due to g-loading, the camera-gimbal system needed a stiffer to ensure that the most
important sensor on the aircraft remained inside the aircraft at all times. In addition, a cowling was added
to the front of the aircraft to reduce the drag of the initial Telemaster aircraft kit. The cowling increases
the amount of achievable flight time, giving the system a higher probability of finding the targets and
fulfilling the mission objectives.
A ready-to-use backup set of Telemaster Kit components is provided during the competition with
the maintenance crew to reduce the amount of down time between aircraft flights. It mitigates the risk of
inability to complete the mission due to a component failure.
2.1.2 Design
2.1.2.1 Athena Vortex Lattice (AVL) Model
The aerodynamic characteristics of the aircraft was simulated using a computer simulation open-
source program created by Mark Drela from MIT called Athena Vortex Lattice (AVL)3,4.This method of
model simulation was preferred to the wind tunnel testing that required more cost and time to build an
experimental scale model. Acquiring aerodynamic and stability coefficients through actual flight testing
of the plane also add time allocation which overall causes time inefficiency. Therefore, AVL was chosen
as the best option for finding the stability and control parmeters that described the aircraft’s motion during
flight for different flight regimes. The data retrieved from AVL was stored in a lookup table on the
autopilot system.
California Polytechnic State University, Pomona 6
Figure 2.2: AVL Model of Air Vehicle System
2.1.2.2 Mass Model
The mass and inertia of the air vehicle platform are very important parameters for modeling the
aircraft dynamics for a complete and adequate plane model. Oscillation during flight can occur if the
inertia model of the aircraft is incorrectly inputted in the autopilot system due to overcompensation of the
controller gains in the autopilot.
To establish an accurate inertia measurement for the aircraft, the inertia was computed based on
the weight of each component and then tested in a lab using a Trifilar Pendulum5. The weight of each
component was converted to mass and the corresponding mass moment of inertia was calculated using
Meriam and Kraige’s Engineering Mechanics: Dynamics6. The Trifilar Pendulum was used to verify that
the order of magnitude was correct for the computations. This pendulum uses a small angle
approximation, time, and frequency to calculate the resistance or inertia for the system. The initial given
perturbation was damped while the aircraft was on the pendulum. This experimental result demonstrated
and verified the stability of the platform vehicle, which is a very important factor to mitigate any adverse
risk due to aircraft design that can jeopardize overall mission performance. The inertia values were then
written to the autopilot for Hardware-in-the-Loop testing.
2.1.2.3 Hardware-in-the-Loop (HIL) Simulations
The data input gathered from AVL, in addition to the mass moment of inertia values accumulated
and transferred to the autopilot system, completed the final step to proceed to modeling and testing the
aircraft dynamics in simulation. This part of the process allowed the operator to visualize the aircraft’s
flight motion on the ground, thus mitigating the risk of having an anomaly due to modeling inaccuracy. If
the autopilot loses control in the air, it poses threat to the entire system that can lead to premature mission
termination. The importance of the HIL simulation is crucial before actual flight testing for validation
purposes and to avoid such incident. The aircraft was also tested in an HIL simulation as often as possible
for preparation and troubleshooting. Proper adjustment to the modeling values was made throughout the
simulation process for accuracy of the predicted result to the actual flight in the air. Revisions to both the
AVL model and the mass model were made with the help of Cloud Cap Support7,8,9 to finalize the model
used in the flight testing.
To verify that the control surfaces would not oscillate and lead to an unstable flight regime, they
were connected to the autopilot while the simulation was running. This enabled the operator to witness
the actual servo motion from the ground instead of in the air. The final validation step in the simulation
was to have the pilot fly the simulator model.
California Polytechnic State University, Pomona 7
2.1.2.4 FlightGear Aircraft Simulator
Once the plane model was finalized in the HIL simulation, the next step is to simulate manual
control. In this process, the pilot tested the transmitter in the simulator via manual control override as
opposed to autopilot control alone. In this setup, the pilot would take off manually and fly the aircraft into
the flight pattern and into cruise, where the autopilot would then be activated. After autopilot verification,
the pilot would land the aircraft and review the overall simulation.
Using an open-source computer program called FlightGear10, the pilot was able to visualize the
flight in the simulator. The pilot then rated the dynamics model in the simulator with the industry
standard Cooper-Harper scale11. From the pilot feedback, the aircraft was rated as a 2 on the scale from 1
to 10, where 1 is the best possible rating; the simulator model was rated as a 5. The model was sent to
Cloud Cap Support for validation and then the aircraft went into Flight Test Validation.
2.2 Autopilot
The CloudCap Technology’s Piccolo II7 autopilot system was selected based on the previous
year’s success with the system; the school’s familiarity with this autopilot; and its highly integrated,
inexpensive package. With its integrated avionics, communications link, and ground control station, the
Piccolo II is one of the most robust and commercially available autopilots currently on the market. This
lightweight (0.6 lbs) system is capable of full autonomy through its array of inertial, air data, and Global
Positioning System (GPS) sensors. The integrated inertial navigation system (INS) consists of tri-axial
gyros, tri-axial accelerometers, and GPS sensors that are used to determine the orientation, state, and
location of the vehicle during flight. In addition, an onboard air data system consisting of pressure port
inputs (to measure total and static pressures) can be used to calculate the true air speed of the aircraft. A
one watt data-link transmits full telemetry data to the ground control station via a 900 MHz radio
frequency for long-range communication. The Piccolo II is also accompanied with a developer’s kit that
provides needed components to operate the system in a Hardware-In-Loop (HIL) bench simulation
environment. This enables aircraft control laws and mission functionality to be tested without risking
hardware during flight, thus reducing chances of failure*.
Included in the autopilot system is the ground station, which manages the link to the Piccolo
avionics; samples the manual pilot console; and serves as a bridge to the Piccolo Command Center, an
operator interface software program used for flight path creation through waypoint construction.
Figure 2.3: Piccolo Autopilot System and Ground Station
2.3 Camera/Gimbal System
2.3.1 Camera Selection
California Polytechnic State University, Pomona 8
The AXIS 207MW network camera12 used in the previous year’s design worked well with the
UAV system; however, it lacked the desired resolution to capture clear and distinguishable images of
objects from 500 feet above the ground. This led to the selection of the AXIS P1347 5-megapixel network
camera13. The larger volume and additional 1 pound of payload weight were an acceptable tradeoff
considering the significantly larger airframe used for this year’s competition. The experience with Axis
network cameras and its easy-to-use Software Development Kit (SDK) influenced the decision to select
an Axis camera as opposed to other network cameras.
Figure 2.4: AXIS P1347 5MP Network Camera
2.3.2 Gimbal Frame
2.3.2.1 Description
A gimbal system was designed for two degrees of rotational freedom to keep the camera
constantly oriented perpendicular to the ground when the aircraft pitches or rolls. This ensures that the
camera will maintain a field-of-view of the ground at all times so target images may be acquired. The
structure for this mechanism consisted of three concentric (and hollow) rectangular boxes that are
connected with servos and rods, as displayed in Figure 2.5.
Figure 2.5: Gimbal System Structure
2.3.2.2 Downselect and Gimbal Operation
Different solutions were analyzed to design the gimbal system for the mission requirements. A
freely rotating system with the center of gravity below the rotation point and the pivot point could have
utilized the weight of the camera due to the gravity of Earth to keep the camera oriented downwards.
Although this system would be less expensive and lighter, the system would be less effective due to
unwanted reaction from the accelerations induced by the movement of the plane that occurs during turns.
California Polytechnic State University, Pomona 9
Therefore, a system of servos and inertial sensors are used in parallel so that the camera will rotate into
position and keep the lens focused at the ground.
There were multiple rotational combinations that would maintain camera position during aircraft
pitch and roll maneuvers. Originally, one servo was to rotate the camera about the z-axis and the other
was to tilt the camera off of this axis. This servo configuration occupied too much space and proved
difficult for control system designs. A system that rotates the camera about the x- and y-axes was chosen
to save room and because a similar control system had been generated by a team for the previous year’s
competition.
After choosing a servo configuration, it was determined that the gimbal system would be
composed of three holsters. The first box is designed to hold the camera. The second box holds the first
with a servo and pin system that rotates it about the x-axis, and the third box uses a similar pin and servo
system to rotate the second box about the y-axis. This box is also mounted to a bulkhead in the fuselage,
thus allowing the inner components to move while the entire system is securely mounted to the aircraft.
2.3.3 Image Stabilization
Image acquisition is also supported by the image processing software. Preliminary flight video
data demonstrated a clear need for an in-air active stabilization system. During flight, the aircraft’s bank
and climb maneuvers caused orientation changes. The image processor could not be burdened with the
complexity of compensating for a changing viewing angle.
A method was devised to correct for changes in pitch and roll in order to keep the camera’s lens
oriented orthogonal relative to the earth. A physical method of stabilization was first implemented: a dual-
servo system was built to mimic the pan and tilt function of a pan-tilt-zoom (PTZ) camera. High-torque
Hitec servos were selected to support the relatively heavy camera and its large mount. Oriented within the
designed and machined mount, the servos enable the camera to be stabilized in the yaw and pitch axes.
A microcontroller board was used to provide the stabilization commands to the servos. The
microcontroller chosen was a 16MHz Atmega328 based board called the ArduIMU V2 Flat, created by
DIY Drones14. This microcontroller has an onboard 3-axis accelerometer, 3 gyro sensors, and an Arduino
IDE bootloader, allowing the ability to integrate a 6-DoF Inertial Measurement Unit (IMU). The board
also has provisions to correct yaw drift with a magnetometer or GPS attachment, but yaw correction was
not needed. The IMU was programmed to continuously receive gyro and accelerometer data while
running the processes through a Direction Cosine Matrix (DCM) algorithm15 in order to produce the Euler
angles to command the servos. Once the data has been filtered and calibrated, the servo gimbal is
directed by pulse-width modulation (PWM) functions within Arduino’s Servo library, as shown in Figure
2.6.
California Polytechnic State University, Pomona 10
Figure 2.6: Camera Stabilization System Diagram; Diagram (Top) and Hardware (Bottom)
3.0 Data Link
3.1 Radio Module
A 5 GHz frequency range was selected to avoid the 900 MHz radio frequency of the Piccolo
autopilot and parts of the spectrum used by other RC aircrafts in public and private airfields, as well as
interference from other various electronics used during flight tests. Internet Protocol cameras were
designed for wired Local Area Networks (LAN), so the video frame rate would suffer severely once
transferred over to a wireless network. Therefore, the derived requirements to establish the data link
consist of a module that is in small form factor to fit on the aircraft, high throughput to reach near wired
LAN speeds, and long range to maintain a stable wireless connection with the moving aircraft. The
Ubiquiti Bullet M5-HP1016 was able to satisfy all these requirements with a measured 80 Mbps
throughput and rated 50 Km transmission range.
3.2 Antenna
The radio module’s connector allowed for easy switching among many different antenna types to
determine the optimum downlink performance. Since gain is inversely proportional to broadcasting
distance, a low gain omnidirectional antenna was selected from the previous year for the aircraft’s
onboard access point, while a higher gain antenna (for the ground station) was chosen for longer range
and antenna alignment. The Laird Echo 17 dBi panel antenna1117 was chosen for its 25 degrees
symmetrical antenna pattern, as shown in Figure 3.1.
Figure 3.1: Omnidirectional Antenna
A high-gain base station antenna was relied to catch a low gain-wide radiation flying antenna.
The AvaLan Wireless 5 dBi AW5-5800 omni-directional antenna18 was chosen over the in-house
manufactured quarter-wave antenna after data link flight tests.
California Polytechnic State University, Pomona 114.0 Ground Station
The ground station network consisted of the Piccolo Command Center (PCC) user interface
software program, two types of in-house developed image command centers, and a database server. The
PCC monitors and commands the Piccolo II autopilot aboard the air vehicle, and gathers flight telemetry
data that is made available to the Observer station for post-analysis operations. This includes image
recognition through determining each target’s GPS location, orientation, color composition, and shape.
The database server stores all data that is required for post-processing analysis.
4.1 Piccolo Command Center (PCC)
The Piccolo ground station uses the PCC operator interface to communicate with the onboard
avionics of the autopilot system. It is connects to the avionics system via a UHF radio link and to a laptop
computer with an RS-232 serial connector to provide a command-and-control interface for the operator.
Key features of this user-friendly interface software include flight path planning through waypoint
construction, real-time aircraft telemetry updates, and gain tuning for control loops. A screenshot of this
interface is displayed in Figure 4.1, which illustrates the typical waypoint navigation and loitering
options.
Figure 4.1: Piccolo Command Center (PCC) User Interface
4.2 Image Processing using Open Source Computer Vision
The competition requirements specify the system be capable of locating and identifying multiple
targets that are between 4’ x 4’ to 8’ x 8’ in dimensions. In addition, the software must be capable of
recognizing at least two characteristics of the target, such as alphanumeric character and background
color. Open Source Computer Vision (OpenCV)19 was chosen because it is an open sourced library. This
costs no money to the development group while allowing for the use of high level algorithms. In order to
reduce work load on the marine unit using this system, OpenCV recognizes targets on the ground and
stores them in the database. This cuts down on time to complete the mission as well as frees up more
soldiers to work on other parts of the mission
OpenCV is an Intel library that provides functions and algorithms for image processing, data
manipulation and matrices. The OpenCV program can load the video stream and analyze individual video
frames. A Haar-detection algorithm is applied to the image frame. This method uses a combination of
negative and positive frames that are converted into image features, which are compared to the analyzed
California Polytechnic State University, Pomona 12image. If they match, the object is detected. To speed up processing, a classifier is applied and a boosting
algorithm evaluates the feature stages passed by the image. Simple feature stages are evaluated against the
image first. If they do not pass, no image is detected. As more stages are voted as passed by the boosting
algorithm, the image is detected. The contours of the image are stored, and a red bounding box is drawn
around the image to notify the operator of detection.
To determine the image position and time relative to the aircraft, the image data and the Piccolo
autopilot data are stored in a database. After image detection, OpenCV stores the time before detection
and the time after detection of the image, which are linked together. The database will query the Piccolo
for the angles and GPS data at the time that the video frame is captured by OpenCV. This will allow the
coordinates of the detected target to be determined.
4.3 Observer Command Center
Observer Software allows the user to check the results of OpenCV for false positives. For the
automatic recognition of targets, the rules specify less false positives than positives. The observer proves
that the previous statement is true to the judges. In the field, the marine unit using this system will also
want to verify Intel before it reaches a higher chain of command. The observer program allows the
marines to verify that a target was found during the flight and retrieves the information from a mySQL
database that OpenCV fills with flight images and telemetry data. The images are stored in the database as
BLOBs (Binary Large Object Files) and the telemetry is stored as Strings. The BLOBs can be stored as
JPEGs that attach to the spreadsheet required in competition and the Strings fill the data lines in the
spreadsheet.
Figure 4.2: Observer Station Command Center
5.0 System Test and Analysis
Transition from ground flight simulation to in air flight simulation renders a valuable amount of
risk. Therefore, to conduct the integration testing phase for the autopilot control, the location was
intended to be in designated flight areas such as Prado Field, Chino, CA. In fact, initial flight testing
locations utilized included Coyote and Rabbit Dry Lake Bed in Barstow, CA. The desert environment
with empty, flat, and vast amount of space for emergency landing, in addition to absence of crowd was
best suited for any unexpected deviation from previously predicted results. Pre-flight planning and
briefing was exercised for safety precautions and clarity for testing objectives. Actions taken during the
flight test were predetermined by the Initial Test Card document from Cloud Cap. The system functioned
well during the flight tests, making the aircraft ready for the proof-of-concept flight in the competition.
California Polytechnic State University, Pomona 13After each autonomous flight, the data was reviewed for any possible in-flight failures that can be
fixed or heavily mitigated. Common failures during flight include loss of communication with the aircraft,
rapid accelerations, and excess speeds. These failures can be fixed by changing the communication
channel, smoothing out the flight, or flying in less wind. The data was logged and reviewed after each
flight using Microsoft Excel, which allowed for a graphical interpretation of the data. Figure 5.1 displays
the aircraft’s latitude and longitude position over time, which represents the flight path of the aircraft as
defined by the ground station.
Latitude/Longitude Position
0.65645 0.6565 0.65655 0.6566 0.65665 0.6567
-2.1356
-2.13565
-2.1357
Longitude
-2.13575
-2.1358
-2.13585
-2.1359
-2.13595
Latitude
Figure 5.1: Aircraft Latitude/Longitude Position
Figure 5.2 displays a graph of elevator deflection through the autopilot over time. During
this segment of the flight the autopilot was changing altitude. The elevator deflects only a half of
a degree in a step function form. The step function oscillates and then dampens, proving that the
system is stable. This data verifies that the autopilot is maneuvering correctly and will be able to
repeat the smooth flights witnessed during testing.
Figure 5.2: Elevator Deflection During Flight
6.0 Safety and Risk Management
6.1 Safety Analysis
California Polytechnic State University, Pomona 14The derived risks were based on previous flight test experiences and listed based from historical
research on common UAV flight risk operations. Each risk was evaluated on its impact to the flight
mission and likelihood of the issue to occur. Analysis of lessons learned were utilized and conformed. To
ensure safety during operation, a mitigation process was implemented for reduction of risk occurrence, as
seen in Figure 6.1.
Figure 6.1: Mitigation Process for Safety Analysis
Safety practices were summarized and incorporated into the UAS as the safety features below:
Trained flight crew team members with experience in conducting multiple flight tests. Each
member of the crew has the knowledge of how to monitor and evaluate aircraft operating
parameters to enable an instant identification of any impending failure inconsistent to standard
mission flight operation for efficient execution of plan of action.
Preflight Go, No-Go checklist to ensure optimum operational status of the UAS.
Preprogrammed emergency flight plan in case of flight termination. Aerodynamic flight
termination capability for minimum landing impact damage.
Redundant and independent radio control link that allow the aircraft system the ability to switch
to manual control in the case of communication failure.
Multiple electrical power supplies. Two sets: 1 set for the propeller and another for the servos. In
case of propeller failure, plane safe recovery will be manually controlled using the remaining
functional servos allowing control surfaces movement for emergency landing.
System health and status display on the ground control station autopilot computer for monitoring
aircraft status.
6.2 Risk Management
Figure 6.2 displays a flow chart of common risks and corresponding mitigation techniques. The
top portion of the flowchart displays the Fault Tree describing the failure event sequence with a top-down
California Polytechnic State University, Pomona 15approach, starting with an issue that is more direct to less direct towards mission termination. It also
includes the necessary plan of action and decision making exercised to reach the safety objectives.
Figure 6.2: Risk Mitigation Techniques
6.3 Navigate, Aviate, Avert and Communicate Plan (The NAAVCOM Plan)
Safety procedures were designed to execute precautionary action to demonstrate alleviation, if not
complete avoidance of any injuries to ground personnel and possible air flight traffic catastrophe. These
procedures were summarized in a risk mitigation action item called NAAVCOM Plan for Navigate,
Aviate, Avert, and Communicate.
NAVIGATE – Flight plan structure navigation is preprogrammed to the aircraft system to fly within no-
fly boundaries. During loss of communication, a predefined return to home waypoint is established.
When this situation occurs, the plane is to directly return to its home base waypoint. Once destination is
reached, the plane is to loiter until communication is regained. Failure to gain communication within 30
seconds initiates the safety pilot to manually take over control and terminate flight mission. If
communication is regained, the plane directly resumes its operation to its most recent waypoint
California Polytechnic State University, Pomona 16designation from the failure occurrence and carries on its previous flight path.
AVIATE – Experienced safety pilot acts as the standby safety redundant system in the case of necessary
manual control take over using the JR radio control. The pilot takes over command of the plane to fly the
plane and land it to safety.
AVERT – In case of GPS loss of link, a flight path correction is lost resulting for the plane to undergo
gyroscopic drift. In order to avoid such a consequence to occur, a failure to regain link within 30 seconds
time frame will result to execution of aerodynamic flight termination, during which the elevator deflects
completely for a nose-up configuration. Concurrently, the ailerons are deflected oppositely from each side
to allow the plane to spiral down to the ground for minimal impact during landing. Such action avoids the
aircraft to proceed flying an uncontrolled flight mission, thereby avoiding possible air traffic collisions.
COMMUNICATE – In the case of emergency call for flight mission termination, the flight crew is
trained to relay and announce to the crowd awareness and assert attention for avoidance of any injury.
7.0 Failure Analysis
Since the previous year’s team was the first team from CPP to participate in the competition,
there was a steep learning curve and many lessons were learned from conducted flight tests and
simulations. The autopilot system in particular was learned by the flight crew in a very short period of
time and was not reviewed comprehensively from the students who had previously worked with the
system, creating a large knowledge gap that led to many mistakes and oversights during flight tests.
One such anomaly was encountered on June 12, 2010 after the team had accomplished several
milestones and was making final preparations for the competition. During the full-systems flight test, the
elevator fully deflected after takeoff, which caused the aircraft to pitch upward and maneuver around in
loops uncontrollably. It was realized that the autopilot was never turned on and the pilot did not have
manual control of the aircraft; the ground station stopped receiving data from the aircraft during flight
(although communication still existed) and the ground crew lost complete control of the system. As a
result of this data loss, the aircraft had continued to fly away and crashed from 500 feet in the air, which
completely destroyed the system and compromised the team’s participation from the competition. The
aircraft’s longitude and latitude position over time can be seen in Figure 7.1.
Position
-2.05627
0.594305 0.59431 0.594315 0.59432 0.594325 0.59433 0.594335 0.59434 0.594345 0.59435 0.594355
-2.05628
-2.05629
-2.0563
Longitude
-2.05631
-2.05632
-2.05633
-2.05634
-2.05635
17
Latitude
California Polytechnic State University, PomonaFigure 7.1: Aircraft’s Latitude/Longitude Position Over Time
Post-flight analysis determined that the antenna was not receiving a proper voltage input from the
autopilot command center, which caused the elevator control surface response to be out of the nominal
range. The root cause analysis in Figure 7.2 displays the acknowledgement ratio over time for all of the
deflected control surfaces during the last flight test. From here it can be seen that all of the control
surfaces except for the elevator remained consistently within a certain range.
Surface Deflections
1
0.8
Value (rad), Ack Ratio (%)
0.6
0.4
0.2 Elevator
Ack Ratio
0
-0.2
-0.4
36 36.5 37 37.5 38 38.5 39
Time (min)
Figure 7.2: Data from Surface Deflections over Time
In addition, the number of data packets being received during flight dropped drastically with time
until there was a complete absence of data being received from the autopilot system, as indicated in
Figure 7.3, which shows the acknowledgment ratio and Received Signal Strength Indication (RSSI) over
time after takeoff.
100
dB
0
80 -20
Ack Ratio
-40
60
-60
40
-80
20 -100
0 -120
0 6 12 18 24 30 36 42 48 54 60 66 72 78
Time (secs)
California Polytechnic State University, Pomona 18Figure 7.3: Acknowledgment Ratio over Time
This anomaly could have been avoided if proper safety precautions were taken; if the pre-flight
checklist was properly followed, range checks would have been performed and the Pitot tube failure
would have indicated that the mission should have ceased to continue. In addition, post-flight analysis
was neglected from the previous flight tests, which would have displayed a similar pattern in data packet
loss during flight.
To ensure that such an incident should be avoided in the future, current team members have been
conducting many Hardware-in-the-Loop (HIL) simulations to build experience with the Piccolo autopilot
system and rigorously performing post-flight analysis after each simulation or test flight to gain thorough
perspective on the system’s functionality during flight. As an extra redundant safety measure, a JR
transmitter is being operated on a separate frequency for manual pilot override in the event that the
ground crew is not able to obtain control of the aircraft during autonomous flight.
8.0 Concluding Remarks
Through lessons learned from the previous year, the team was able to learn from past mistakes in
the areas of aircraft performance, safety, and time management in order to significantly improve on the
current year’s system design and engineering approach. Greater knowledge of system components as well
as greater diversity in academic expertise enabled the team to function better as a whole and remain on
track for the competition. Higher emphasis was placed on safety considerations and risk mitigation
techniques to establish system redundancy and ensure past failures were avoided. The newly implemented
JR radio module provided the largest safety measure for one of the highest risks possible. Although many
system components were used from the previous design, appropriate trade studies were conducted to
downselect the optimum selection for the unmanned aerial system.
The competition environment in Maryland will provide the team a unique opportunity to acquire
more knowledge (and lessons) for the upcoming year’s team as well as mark Cal Poly Pomona’s first
participation in the flight mission portion of the AUVSI competition.
California Polytechnic State University, Pomona 19Acknowledgments:
Cal Poly Pomona’s AUVSI team would like to thank the Aerospace Engineering Department for
all their help and support, and specifically faculty advisors Dr. Subodh Bhandari and Dr. Donald Edberg
for their guidance, and department technician James Cesari. The team would also like to thank Cloud Cap
for a significant amount of technical support as well as the United States Air Force and the California
Space Grant Consortium for their financial support. Recognitions also go out to the following
individuals:
Derek L. Brown of Tybrin Corporation
David R. Tangren and Firdosh K. Choskey of USAF
Dr. Mike Wiskerchen and Tehseen Lazzouni of CaSGC
Stephen Wong and Spondon Saha, CPP Alumni
References:
[1] Dobbs, Steven K., “Project Plan”. California State Polytechnic University, Pomona CA. 2009
[2] Hobby-Lobby, International, Inc., “Instruction Manual 12Foot Telemaster ARF,” Hobby-Lobby,
International, Inc., Brentwood, TN, 2010
[3] Selig, Michael S., “UIUC Airfoil Data Site,” UIUC Airfoil Coordinates Database [online
database]. < http://www.ae.uiuc.edu/m-selig/ads/coord_database.html>.
[4] AVL, Athena Vortex Lattice, Software Package, Ver. 3.27, Mark Drela, Boston, MA 2008.
.
[5] Structural Dynamics Research Lab, “Moment of Inertia Test Lab.” University of Cincinnati, Ohio
4522.< http://www.sdrl.uc.edu/academic-course-info/docs/ucme571/moment_inertia.pdf>.
[6] Meriam, J. L., Kraige, L. G. Engineering Mechanics: Dynamics. John Wiley & Sons Inc. 2008.
[7] Vaglienti, Bill, Hoag, Ross, Niculescu, Mark, Becker, John and Miley, Doug. “Piccolo User’s
Manual.” Cloudcap Technology. Hood River, OR. 2010
[8] Niculescu, Marius, "Steps to Autonomous Flight." Cloudcap Technology, Hood River, OR. 2009.
[9] Vaglienti, Bill, “Initial Flight Test Cards,” Cloudcap Technology, Hood River, OR. 2006.
[10] Basler, Michael et.al., “The FlightGear Manual.” The FlightGear Manual, 2010.
.
[11] Harper, R. P., Cooper, G.E., “Handling Qualities and Pilot Evaluation,” Wright Brothers
Lectureship in Aeronautics, 1984.
[12] “Axis 207MW Network Camera Specification” [online datasheet]. Axis Communications.
.
[13] “Axis P1347 Network Camera Specification”. Axis Communications.
.
[14] Anderson, Chris. DIY Drones. N.p., n.d. < http://diydrones.com>.
[15] J07rdi, Analogue...@gmail.com, "ardu-imu." Google.Code. N.p.
.
[16] “Bullet M5 High Power Data sheet.” [Online Datasheet]. Ubiquiti Wireless.
.
[17] “Echo Series Antenna ES24-14” Laird Technologies, Chesterfield, MO. 2009.
[18] “AW5-5800 Antenna Data sheet” [Online Datasheet]. AvaLAN Wireless.
[19] Open Source Computer Vision Library Reference Manual. Intel Corporation. Santa Clara, 2000.
pp. 21-1, 21-21.
California Polytechnic State University, Pomona 20You can also read
