STORC: SEARCH TO RESCUE CRAFT FINAL TECHNICAL PAPER

Transcription

1 MEAM Senior Design Project - Final Report April 26, 2012 Department of Mechanical Engineering and Applied Mechanics School of Engineering and Applied Science The University of Pennsylvania Philadelphia, Pennsylvania, USA STORC: SEARCH TO RESCUE CRAFT FINAL TECHNICAL PAPER Sarah Clark 1 Sydney Jackopin 1 Timothy Hennelly 2 Jacob Orloff 1 Michael Posner 1 Michael Siegel 1 Bruce D. Kothmann PhD 1 faculty advisor Robert L. Jeffcoat PhD 1 instructor 1 Department of Mechanical Engineering and Applied Mechanics, University of Pennsylvania 2 Department of Electrical and Systems Engineering, University of Pennsylvania ABSTRACT In the event of a natural disaster, communication and transportation networks are often disabled, rendering victims stranded and in need of supplies. Similarly, remote military outposts are hard to reach but frequently find themselves in need of resupply. The danger of these missions for pilots and aircrew can be eliminated through the use of unmanned aerial vehicles (UAVs). Currently, these products are typically used only for surveillance and attack missions. However, this system explores the use of an aircraft to autonomously, accurately, and safely deliver a payload to a specified GPS location, thereby completing a resupply mission without sending a crew into poor weather conditions or dangerous military environments. The system requires the GPS coordinates of the target location, which are provided before the mission. After a human-assisted take-off, the plane ascends to cruising altitude under manual control, recording data and constructing a wind profile along the way. This wind data is used to determine the payload release location that is predicted to result in the most accurate delivery. The pilot then engages autonomous control, which allows the plane to navigate itself to the desired drop location. Once in the vicinity of the drop location, the payload release mechanism deploys, allowing the package and parachute to safely drift to the ground. A physical depiction of this procedure is shown below. Although our plane is a reduced scale model of a real UAV, our plane dynamics model, controls model, and drop location model can be used on larger UAVs with only minor adjustments. The dynamics model allows users to see how the plane will react to an updated controls model, reducing the need for risky test flights. The controls model uses an appropriate combination of throttle and rudder control to maintain level flight and appropriate turns toward our drop location. Finally, the drop location model uses wind data collected during the ascent, parachute characteristics, and the physical release delay to determine when the payload release mechanism should be deployed. By changing only plane-specific parameters, these models can be used in real life UAV applications. MEAM page 1 Copyright 2012 by the authors

2 1. INTRODUCTION AND BACKGROUND Natural disasters and military operations often leave hikers or military personnel stranded and in need of supplies. Current technology involves delivery of such supplies by helicopter, which can endanger the lives of the pilot and crew in either dangerous weather conditions or crossfire. UAVs are currently used to perform many missions considered dangerous for pilots, but these are typically limited to surveillance and attack situations. Our project explores the use of a UAV to autonomously deliver a payload, such as military or survival supplies, to specified GPS coordinates. Since our resources are limited, our aim is to show the viability of such a system by creating the necessary subsystems and testing them on an RC model airplane. These subsystems include a controls model for navigation and autonomous steady flight, a dynamics model to ground test controls schemes, and a payload drop model to account for parachute drift depending on wind conditions. The goal is for these systems to be easily adaptable for full scale UAVs to further the objective of autonomous supply delivery in real rescue situations. 2. REQUIREMENTS AND OBJECTIVES Objectives for this project, in addition to the completion of the goals listed below, include elegant design of the electronics package, the plane itself, and the controls structure. A clean code with easily manipulated variables was preferred so that the code could easily be transferred from plane to plane by simply updating plane-specific parameters. 2.1 Requirements Autonomous Flight (excluding take off and landing) Construction of wind profile from data recorded during ascent Autonomous Payload Release Mechanism Accurate Payload Landing (distance to target within 50ft) Safe Payload Landing 2.2 Desirable Goals Ability to drop useful payload package (ability to carry substantial weight) Efficient Payload Delivery (within 10 minutes of signal) are the four major options that were considered at the onset of the project: Full autonomy A fully autonomous system would involve no pilot control during the entire flight, including takeoff and landing. Partial autonomy with beacon detection A pilot would perform a manual takeoff and landing and would engage autonomy only when level flight was achieved. This plane would detect a radio signal from a ground beacon and navigate toward the GPS coordinates of that signal as its target. Partial autonomy with predetermined target This system would also involve manual takeoff and landing, but would be assigned the GPS coordinates of the target location before takeoff. Autonomous flight with separate search plane An autonomous, lightweight plane would circle, searching for the target beacon. Once detected, the first plane would transmit the target s coordinates to the plane on the ground with the payload inside. Other, more complicated and creative solutions were explored but only briefly. Time and budget constraints determined these concepts as the most viable. 3.1 Comparison and Down-selection Since all of these concepts would satisfy our autonomous and accurate payload delivery system, the decision of which option to pursue was based on the following considerations: Material cost Would this project be feasible within the constraints of our budget? Energy consumed Is this the most efficient way the task can be performed? Timely delivery Will the package reach the target in the proposed ten-minute time limit? Success Feasibility Are we likely to finish this project within the school year? Degree of autonomy Does the project eliminate as much danger to human crews as possible? 3. CANDIDATE CONCEPTS There are various methods to autonomously and accurately deliver a payload, each differing in its creativity and practicality. The following design concepts MEAM page 2 Copyright 2012 by the authors

3 Table 1 summarizes the overview of each option, while the explicit thought process is explained in more detail below. Material cost Energy consumed Timely delivery Success feasibility Degree of autonomy Table 1: Design Concept Comparison Full Autonomy Moderate- High Moderate Beacon Detection Moderate- High Moderate GPS Before Takeoff Moderate- Low Moderate- Low Search plane High Low Quick Quick Quickest Slowest Low Medium Medium- High Low Highest Medium Medium High The fully autonomous concept is attractive because of its complete independence from manual control. However, both takeoff and landing are complicated processes with very little margin for error. This level of complexity results in a low likelihood of success within the duration of the project. The beacon detection system with partial autonomy (excluding takeoff and landing) is much more feasible, while still providing a high degree of autonomy. However, inputting the GPS coordinates manually increases the feasibility of the project a great deal because wireless communication between the beacon and the plane is no longer required. Eliminating the beacon technology also decreases the hardware required and the energy consumed. The plane will know exactly where it is headed from takeoff, removing circling and search time that could drain the battery life, as would be the case in the other concepts. Finally, the concept of using two planes would also be quite difficult to achieve due to technical complexity and time constraints. This option would also take the longest to deliver the package. However, it is appealing due to its efficient process of searching with a lighter plane and delivering the payload once the GPS coordinates are known. The design concept we selected was the partially autonomous plane (excluding takeoff and landing) with the GPS coordinates of the target programmed in before flight. This option employs most of the benefits of the search plane option without the added complexity. The search plane option is beneficial because it allows the payload plane to navigate directly to its target without wasting time and power circling for a signal. However, having two planes is too complex for this project and the same results can be achieved by simply inputting the GPS coordinates ahead of time. Additionally, many stranded hikers now carry equipment that can transmit their GPS coordinates to park rangers pre-existing radio equipment. The addition of a beacon in our system might necessitate investing in new transmitting and receiving equipment for rangers and hikers. For this reason, the extra beacon feature is unnecessarily complicated and does not add any value to the real-world applications of this project. 4. DESIGN DESCRIPTION 4.1 Overall System The final design of the project involves a model airplane that autonomously navigates and delivers a payload package to a designated target. The system process begins with a manual launch of the aircraft, piloted during the ascent via radio controller (RC). During the plane s ascent to constant altitude, the Pitot probe and GPS sensor compute wind speed data and construct a three-dimensional wind profile. The average values of the wind components are input into the payload trajectory model, which then calculates the expected drift during the parachute's descent. From this information, the necessary offset is calculated, and the plane s target release coordinates are computed. When the aircraft has this destination and is at its constant cruise altitude, autonomous flight is engaged and the aircraft navigates to its drop coordinates. Once within a small radius of these coordinates, the servo on the payload door is activated and the payload releases, ideally landing within 50 feet of its intended target. At the completion of the project, the systems produced include tested and validated components of the above design with full system integration left for future work. A controls model was made to implement autonomous rudder and throttle control, allowing for planned turns and controlled climb rate, respectively. A payload model was constructed based off of drift data for several manual test drops, and this model was integrated into the navigation scheme. Together, these individual systems have the potential to be integrated for a complete payload delivery mission. The design plan for each of these subsystems involved using theory to construct the initial model framework, and then validating and updating these models through the use of experimental flight data. The following sections detail the theory design approach of each subsystem, while validation is presented in Section 6, Evaluation and Testing. 4.2 Electronics As shown in Figure 1, the electronic hardware of StoRC consists of an ArduPilot Mega microcontroller with sensors, a radio controller system, an electronic speed controller (ESC), motor, servos, and a telemetry system. MEAM page 3 Copyright 2012 by the authors

4 Figure 1: StoRC Hardware The key component of the StoRC electronic hardware is the ArduPilot Mega, an Arduino-based microcontroller. This microcontroller has a built-in inertial measurement unit (IMU) composed of an accelerometer that measures linear accelerations and a gyroscope that measures angular velocities. Furthermore, the ArduPilot Mega is built to easily interface with a GPS unit, a Pitot probe to measure airspeed, and a magnetometer to detect orientation with respect to the Earth's magnetic field. This microcontroller is also capable of reading commands from a radio controller, sending commands to servos, and logging data on-board the aircraft. quicker, more efficient adjustment of the control gains to achieve the desired airplane flight behavior. 4.3 Controls The controls system is the algorithm that utilizes a variety of sensors to autonomously navigate and control the airplane without any pilot assistance. An overview of the final controls system implemented on the StoRC aircraft is shown in Figure 2 below. An eight-channel radio controller is used to send commands to the airplane during manual flight. This controller utilizes three channels to control the airplane s elevator deflection, rudder deflection, and throttle output. Another channel is used to turn the autonomous flight control on and off. Additionally, three more channels are used during test flights to turn on various portions of the autonomous algorithm and to adjust the control gains. An XBee-based telemetry system was implemented in order to transmit sensor data from the airplane to a computer on the ground in real time. This system was used in the testing and validation of the project. In addition to the on-board logging, data-logging on a remote computer created a redundant data acquisition system. In the event that the ArduPilot Mega's on-board data logging malfunctioned, flight data was still saved on a remote computer. Also, the ability to view live sensor data during autonomous flight tests allowed for a Figure 2: StoRC Controls System Overview The controls system consists of two components the navigation algorithm (outer loop) and the steady flight algorithm (inner loop). The navigation algorithm (Figure 3) compares the airplane s target coordinates to its current location. Based on this information, it determines the appropriate heading, turn rate, and bank angle that are necessary for the plane to reach its target. It then sends these desired parameters to the controls inner loop. MEAM page 4 Copyright 2012 by the authors

5 Figure 3: Navigation Algorithm The inner loop attempts to achieve the desired airplane commands that it receives from the navigation outer loop. This algorithm utilizes proportional, integral, and derivative (PID) control to minimize the difference between the desired and the actual values. Rudder PID control (Figure 4) is used to achieve the desired turn rate. Airplane turn rate is directly proportional to its bank (roll) angle. Therefore, for a given target turn rate, the rudder must deflect appropriately in order to make the plane roll and thus turn. Similarly, throttle PID control is used to achieve a desired climb rate. Figure 4: Autonomous Rudder PID Control Figure 5: Autonomous Throttle PID Control A Simulink controls model was created and developed in conjunction with the MATLAB dynamics model. In the early stages of the project, the controls model was used to determine qualitative effects of control algorithms. However, once the dynamics model was adjusted to very closely simulate real life airplane behavior, as discussed in Section 4.5, it was used to quantitatively analyze control algorithms and to determine the nominal controls gain values to be used on the aircraft. 4.4 Software With the exception of the pin-level libraries, the software structure and functional code was developed from scratch. The software schematic is shown in Figure 6. The software requires two inputs to operate: radio controller commands and sensor readings. During manual flight, radio controller commands directly control the airplane s elevator, rudder, and throttle. When the autonomous flight is engaged, however, the software relies solely on sensor data to autonomously control the plane. During this portion of the flight, sensor data is processed by the navigation algorithm and the steady flight algorithm. This determines how to appropriately adjust rudder and throttle to navigate the plane to its target, as well as when to drop the payload. Figure 6: StoRC Software MEAM page 5 Copyright 2012 by the authors

6 The main software is implemented in Arduino on the ArduPilot Mega. The ArduPilot Mega s pin-level libraries were kept in order to read raw data from the sensors, but the rest was written from scratch. The software consists of three main loops that run at varied intervals. The slow loop runs at a frequency of 5 Hz and is responsible for reading sensors such as GPS and barometer that take longer to update, as well as running components of our code that are not speed-essential like the navigation loop. The medium loop runs at a frequency of 25 Hz and is responsible for updating more essential sensors such as the accelerometer, gyroscope, magnetometer, and Pitot probe. This loop also runs portions of our algorithm such as our controls inner loop and wind profile generation. The fastest loop runs at the full speed of the board and is responsible for dictating when the other loops run, updating the plane s current orientation estimate, reading RC commands and sending servo commands. There are also loops that transmit telemetry data and log data in the on-board flash memory that run at 5 and 15 Hz, respectively. flight. Additionally, more accurate geometric and theoretical plane parameters were calculated that are specific to the Super Cub. The result is a completed dynamics model of the Super Cub that is used in conjunction with the Simulink model to test the control scheme without the need for extraneous test flights. The same flight dynamics can be used to estimate the safe takeoff weight for our plane. By calculating the excess power of the plane for a given speed of the propeller, maximum takeoff weight can be calculated, as shown in Figure 7. Since our propeller typically operates around 5000 rpm in flight, the maximum takeoff weight is estimated to be kg. The Super Cub weighs kg with all of the electronics; thus, it is possible to safely carry up to kg of payload. All test drops were conducted with a kg mass attached to a parachute. A MATLAB script was written in order to receive and process telemetry data transmitted from the plane. This allows a wide variety of sensor data and other information to be viewed through real-time text and graphs. This is important to make sure that the system is correctly functioning before a flight test as well as to see how the plane is reacting to pilot or controls changes during flight. The script reads in data using a serial protocol over USB from the ground XBee module and processes it for display. This script also logs data to text files (in the same format as the on-board logging) in order to provide a backup method of data collection in case of failure of the on-board logging system. A second MATLAB script was implemented in order to process flight data from either the flash memory logs or the telemetry logs. This script generates a wide variety of graphs, from sensor and RC data to the state of the navigation and controls algorithms at all times during the flight. This enables flight data to be reviewed in detail at a later time in order to gain information about how the plane reacted and how the software performed so that adjustments can be made. 4.5 Flight Dynamics From past MEAM Senior Design projects, Airtonomy I & II, we inherited an incomplete MATLAB dynamics model, which calculates the forces and moments on an RC model airplane due to the plane s current state and inputs. Through motor characterization and thrust testing, the model was improved to more accurately reflect the roll moment and thrust of the plane during Figure 7: Maximum Payload Capacity 4.6 Payload Drop Model The payload drop model is based on a linear approximation of drift that is used in military applications [3]. The model takes into account the altitude of the drop and the velocity of the wind in both the longitudinal and latitudinal directions. The wind speed is calculated by taking the difference between the GPS ground speed and the airspeed as measured by the Pitot probe. In order to form a payload release model, this linear approximation was first calibrated with real test data to find the drift coefficient, which is a function of the parachute and payload parameters. This linear equation allows for the drift of the parachute in each direction to be calculated. The drop coordinates are then offset from the target coordinates by this calculated drift. MEAM page 6 Copyright 2012 by the authors

7 When starting to form a model, the question of varying wind speeds during the descent of the payload was a point of concern. According to our stakeholder, Captain James Gillespie, who does payload deployment for the U.S. military, the wind gradient below 500 feet is accepted as negligible. Based on this advice, an average of the wind components in each direction was used to predict drift. We confirmed this approximation to be appropriate by constructing a wind profile that showed minimal variation of wind speed with altitude. Figure 9: Determination of Drift Coefficient Several test flights were conducted to find the relationship between wind speed and drift and to extract the drift constant. The following formula, found in our literature research [3], was used: Five different test payload drops were conducted to determine the drift coefficient, K. A map of these test drops is shown in Figure 8. These test drops were conducted under various wind speeds and resulted in a wide distribution of drift radius, making our model more comprehensive. The plot in Figure 9 shows the linear relationship between drift and the product of wind speed and altitude, the slope of which is experimental drift coefficient (K = ). Figure 8: Aerial View of Test Drops In order to use this model in test drops, wind speed data is recorded during the entire ascent of the aircraft. Once a constant cruise altitude is reached, the average wind speed vectors in the east-west and north-south directions are used to calculate the drift the parachute is expected to undergo in each direction according to the linear model. The magnitude and direction of each drift component is then added accordingly to the target location, computing the drop location that will have the highest probability of landing the cargo on its intended target. The plane then navigates to the new coordinates and activates the servo to release the payload. 5. PROTOTYPE REALIZATION Our final prototype is a software package containing three separate validated models with the potential for full system integration. These models include control architecture for steady flight, a dynamics model for controls testing, and a payload release model. The plane dynamics model simulates the plane s response to control inputs, providing a good estimate for the necessary gain values and allowing the controls schemes to be ground tested before test flights are conducted. The control scheme only relies on throttle and rudder control and does not incorporate pitch as originally designed. Pitch rate control was found to make the plane unstable and a loss of altitude during turns could more easily be compensated for by adding throttle. The navigation scheme is a necessary component of autonomy and guides the plane towards pre-programmed GPS coordinates rather than waiting for a beacon signal. The payload release calculation accounts for parachute drift by offsetting the release location from the preprogrammed coordinates. This software is designed such that it is only dependent on plane-specific variables, and thus can be easily transferrable between planes. The physical test unit is a Super Cub model airplane, equipped with a GPS, XBee wireless module, Pitot probe, ArduPilot Mega board, and IMU shield. The plane itself is unmodified and has a payload capacity of approximately 20% of its weight. Although the proposal expressed desire for an improved wing and a payload bay secured by retracting double doors, it was found that MEAM page 7 Copyright 2012 by the authors

8 the plane flew reliably with a 100g payload and there were no aerodynamic consequences of using the provided, single-door compartment. This payload release door is operated by a single servo mechanism with consistent results. 6. EVALUATION AND TEST 6.1 Dynamics Model Validation Before using the plane dynamics model to choose gain values and settle on our controls scheme, validation of the theory through comparison with test data was necessary. Figures 10 and 11 show actual elevator and rudder input from ten seconds of a test flight. The red and black lines compare the actual pitch and roll rates measured by the plane s gyroscopes and the plane s reactions as predicted by the model. It is clear that the model predicts the pitch response of the aircraft very well. The model does not correlate exactly with every feature of the roll response, but overall the correlation is strong enough for the model to be useful in testing and validating the controls. While elevator is directly correlated to pitch, rudder is typically used to control yaw. More sophisticated aircrafts use ailerons to control roll, but since the Super Cub does not have ailerons, rudder is used as a substitute. Therefore, the relationship between rudder and roll is less direct. After validating the model with several segments of test flight, it was used as an effective way to test different controls schemes and their effects on the plane. Using this model gave insight into the results of tweaking gains or overhauling the architecture without dangerous test flights. This portion of the project was one of the most valuable aspects and has the ability to be adapted for use on large scale UAVs with only minor changes to the motor model and certain physical characteristics of the plane. 6.2 Controls Evaluation The model provided an excellent starting point for estimating gain values. However, since no model is perfectly accurate, it was important to be able to finetune these controls gains in real-time flight tests. As seen in Figure 12, dial knobs on the radio controller were used when needed in flight tests to adjust the control gains around their nominal value. Figure 10: Model Validation: Pitch Response Figure 12: Tweaking of Gains in Flight Figure 11: Model Validation: Roll Response In Figure 13, the red line shows bank angle commands that were sent to the airplane during one test flight. The blue line shows the actual airplane bank angle that was measured by the on-board sensors. The close match between these two graphs shows that the autonomous rudder PID control algorithm provides satisfactory results in flight. MEAM page 8 Copyright 2012 by the authors

9 Figure 13: Autonomous Rudder Results 6.3 Software Evaluation Numerous ground tests were conducted to ensure that software and hardware adjustments were performing as expected without risking the entire system in a flight test. These ground tests were performed on each component and iteration of the system individually. Tests included measurements of GPS position and speed accuracy, orientation, Pitot airspeed, on-board and telemetry logging, navigation, controls and servo deflections, and servo release mechanisms. 7. DISCUSSION This project has produced three main functional components an airplane dynamics model, a controls model, and a payload drop model. All of these project components can be applied to other autonomous flight and/or payload delivery aircrafts. Each of the simulation models is highly scalable and can be applied to larger aircraft; all that is required is to adjust the model parameters that are plane-specific. A major challenge of this project was the initial choice of the aircraft platform the RQ-11 model airplane. The manufacturer of this particular model does not sell individual airplane parts and the plane itself went out of stock during the second half of the project. This became a significant problem when multiple test flight crashes resulted in irreparable plane damage. When selecting a new aircraft, it was desirable to select a plane more durable than our initial, highly fragile plane, and also had individual spare parts readily available for purchase. This led to the choice of the Super Cub aircraft by HobbyZone, since it satisfied all of the criteria above. Apart from alleviating the durability problem of the plane, switching to this plane also validated the scalability of our models. It was relatively easy to adjust the parameters specific to the plane in the models in order for them to be applicable to this new airplane. The drawbacks of this change included a loss of time spent selecting a new aircraft. Additionally, the Super Cub has limited power and packaging space. The expected payload capacity of the aircraft decreased significantly as a result of the brushed motor and lighter fuselage, and the mechanical design of the payload bay required reassessment. 8. RECOMMENDATIONS In the future, our goals include further refining throttle control with more flight tests. Additional payload drops are also necessary for model validation and increased accuracy. After these improvements, the system will be ready for full integration and implementation. 9. ACKNOWLEDGEMENTS We would like to express our sincerest gratitude to all the members of the Penn community who have helped to make the StoRC project a reality. We thank our advisor, Dr. Bruce D. Kothmann, for his logistical support and educational mentorship of our team throughout the year. We would like to thank Dr. Robert Jeffcoat and Dr. Ken Laker for their feedback on the project development and helping to keep the project on track. We also thank William Etter and Matthew Piccoli for their help and expertise in our work with electronics. Finally, we would like to thank the Posner family for helping us with transportation to our test flights. MEAM page 9 Copyright 2012 by the authors

10 10. NOMENCLATURE AND DEFINITIONS Accelerometer: This sensor measures the linear acceleration of the aircraft in each of the three aircraft axes. Ailerons: The horizontal surfaces on the trailing edges of the wings of some aircraft that are moved up and down to control roll. Arduino: A popular open source project including a programming language incorporating elements of Java and C, as well as compatible hardware. ArduPilot Mega: A custom Arduino microcontroller board and sensor package designed and produced by the DIY Drones group. Barometer: This sensor measures static air pressure and on the ArduPilot Mega this term is used to also refer to an air temperature sensor as well. Climb rate: The speed at which the aircraft is gaining or losing altitude, typically measured in feet per minute. ESC: An Electronic Speed Controller is a device that takes a signal as input and quickly switches an attached motor on and off using an external power source in order to control the speed of the motor. Elevator: The horizontal surface on the tail of the aircraft that is moved up and down to control the pitch of the plane. Gains: The constants used in control models that scale signals and are tweaked in order to perfect the controls scheme. The most important gains in PID control are typically designated K P, K I, and K D for proportional, integral, and derivative components respectively. GPS: The Global Positioning System is a satellite-based system that allows ground receivers to collect data on their position, velocity, heading, etc. on the Earth s surface. Position data is typically returned in longitude and latitude coordinates. Gyroscope: This sensor measures the angular velocity of the aircraft around each of the three aircraft axes. IMU: An Inertial Measurement Unit is a sensor package that typically includes accelerometer and gyroscope sensors. The term is used in this project to refer to this grouping of sensors. MATLAB: A software application and programming language that allows for easy manipulation and representation of data (integrates with Simulink). Magnotometer: This sensor measures the strength of the Earth s magnetic field in each of the three aircraft axes. Microcontroller: A printed circuit board typically consisting of a processor, input and output pins, timers, and other electronics to be used as a programmable platform for controlling electronic systems. PID control: Proportional, Integral, and Derivative control is a control method that uses the current state of a system and error between desired and actual state to control the plane s dynamics. Pitch: An angular position describing a nose-up or nose-down rotation of the plane. Pitot probe: A device that measures the air pressure, both static and dynamic, at the leading edge of the aircraft. This data is used to calculate oncoming airspeed and, when paired with the plane s velocity, wind speed. RC: A Radio Control system describes a radio transmitter with joysticks, knobs, and switches, as well as a radio receiver which receives the transmissions and outputs PWM signals to be read by the microcontroller. Roll: An angular position describing the right wing-up or wing-down rotation of the plane. Rudder: The vertical surface on the tail of the aircraft that is moved left and right to control the yaw of the plane and can be used to influence the roll of the plane when ailerons are not present. Simulink: A software application (part of MATLAB) that facilitates the development and simulation of controls models. Telemetry: A term for any wireless communication using radio signals. Our system implements this using XBee modules and this allows real-time data to be tracked on a ground computer while the aircraft is engaged in test flights. Throttle: A term used to describe the percentage of voltage sent to the motor that results in a given propeller speed and power output. UAV: An Unmanned Aerial Vehicle is typically an airplane that is either remotely controlled or controls itself autonomously to perform a variety of tasks. XBee: A brand of radio modules made by Digi International, which can be used to transmit data wirelessly using radio signals. Yaw: An angular position describing the rotation of the plane about an axis perpendicular to the wing and plane body. MEAM page 10 Copyright 2012 by the authors

11 11. REFERENCES 1. Awan, Asadullah, Sher Zaheer, Nasir Ahsan, and Javaid Iqbal. "Autonomous Control for a Karlet MKII RC Airplane." International Conference on Emerging Technologies (2008). Print. 2. Chao, HaiYang, YongCan Cao, and YangQuan Chen. "Autopilots for Small Unmanned Aerial Vehicles: A Survey." International Journal of Control, Automation, and Systems 8.1 (2010): Print. 3. "Drop Zones." GlobalSecurity.org. Web. 25 Apr < y/army/fm/57-38/ch6.htm>. 4. Gillespie, James. Telephone interview. Oct Spinka, Ondrej, Ondrej Holub, and Zdenek Hanzalek. "Low-Cost Reconfigurable Control System for Small UAVs." IEEE Transactions on Industrial Electronics 58.3 (March 2011): Print. 6. Udoewa, Victor. "Three-Dimensional Aerodynamic Simulations of Jumping Paratroopers and Falling Cargo Payloads." Journal of Aircraft 46.5 (2009): Print. INTELLECTUAL PROPERTY Sections and features of this report may be used and reproduced at will, so long as the source properly acknowledged. CORRESPONDING AUTHOR Queries and requests for additional information should be directed to: Michael Posner 104 Brookhollow Drive Downingtown, PA, USA posnerml@seas.upenn.edu MEAM page 11 Copyright 2012 by the authors

12 APPENDIX A MATERIALS AND COST SUMMARY Recoverable Items Qty Description Source Cost (ea) Cost (total) 2 Speed Controller HobbyKing $34.58 $ Brushless Motor HobbyKing $36.32 $ V Battery 3000mAh HobbyPartz $17.70 $ V Battery 5000mAh HobbyPartz $27.00 $ LiPo Charger HobbyPartz $44.70 $ Solenoid 12 DC Grainger $31.65 $ LiPo Bags HobbyPartz $5.75 $ CH Transmitter NitroPlanes $89.00 $ Parachute 12" JonRocket $6.00 $ Parachute 18" JonRocket $7.75 $ Control Horns HobbyKing $2.08 $ Foam Knife Amazon $12.17 $ V Battery 1350 mah HobbyZone $34.99 $34.99 Total: $ Embedded, Expended, and Consumed Items Qty Description Source Cost (ea) Cost (total) 3 RQ-11 Drone NitroPlanes $70.00 $ Complete Tail- Super Cub HobbyZone $11.39 $ Fuselage-SuperCub HobbyZone $25.99 $ Wing- Super Cub HobbyZone $18.99 $ Servo Extension Leads HobbyPartz $1.85 $ Wing Set TowerHobbies $62.99 $ Metal Servo HobbyKing $5.90 $ Airspeed Kit DIYDrones $24.95 $ Magnotometer DIYDrones $44.90 $ Gold Connectors HobbyKing $3.64 $ x7 Propellers HobbyKing $0.95 $ Prop Adapters 9x4.7 RcDude $2.69 $ Prop Adapters 8x3.8 RcDude $2.79 $ mm Prop Adapter RcDude $7.95 $ Gear Servo HobbyKing $5.90 $17.70 Total: $ MEAM page 12 Copyright 2012 by the authors

13 APPENDIX B ADDITIONAL DIAGRAMS Telemetry Software Screenshot Sample Wind Profile and Data MEAM page 13 Copyright 2012 by the authors

14 Simulink Controls Model ArduPilot Mega 8-Channel RC XBee PRO XSC Super Cub Airplane and Electronics MEAM page 14 Copyright 2012 by the authors