Kevin Ortega, David Stone Department of Computer Science, California State Polytechnic University, Pomona, CA 91768

Transcription

1 Cal Poly Pomona's Unmanned Aerial System Design Approach and Implementation for Use in the 2012 AUVSI Student Unmanned Aerial Systems (SUAS) Competition Dr. Subodh Bhandari (Advisor), Jake Dayton, Kelechi Ezekwo, Mathew Gan, Richard Picard, Matthew Rose, Joseph Wagster, Hovig Yaralian Department of Aerospace Engineering, California State Polytechnic University, Pomona, CA Kevin Ortega, David Stone Department of Computer Science, California State Polytechnic University, Pomona, CA Sean Conant Department of Electrical Engineering, California State Polytechnic University, Pomona, CA California State Polytechnic AUVSI SUAS Competition Team This paper describes the system design and development of California State Polytechnic University, Pomona's unmanned aerial system (UAS) for use in the 2012 AUVSI SUAS competition. The aerial vehicle platform used for the competition is a 12' Telemaster airplane from Hobby Lobby, which is a highly stable aircraft. It has a wingspan of feet, a distance from the center of gravity to the tail of 5.6 feet, and a gross weight of pounds. The vehicle is equipped with a Piccolo II autopilot for autonomous flight. High resolution video of the targets is captured using a network camera and transmitted to the ground using a wireless transmitter. The objective of the UAS is to have an autonomous aerial vehicle (UAV) transmit images of the targets to be identified by another system on the ground. A router on the ground transfers the video to the image recognition computer as well as distributes necessary image recognition telemetry data from the autopilot ground station. The image recognition system has been developed by modifying OpenCV image recognition software. The UAS uses 2.4 GHz, 900 MHz, 5.8 GHz, and 1.5 GHz for manual control, autonomous control, video transmission, and GPS, respectively. These components work together to safely provide intelligence and surveillance of the stationary targets on the ground.

2 Table of Contents I. Introduction... 2 i. Cal Poly Pomona AUVSI SUAS Competition Team... 2 ii. Systems Engineering... 2 a) Mission Objectives and Requirements... 2 b) Design Rationale... 3 c) Expected Performance... 3 II. UAS Design... 4 i. Method of Autonomy... 4 ii. Air Vehicle... 5 a) Air Vehicle Dimensions... 6 b) Components... 6 c) Payload... 8 d) Vehicle Flight Capabilities... 8 iii. Ground Systems... 8 a) Ground Station and Autopilot System... 9 b) Mission Planning... 9 c) Data Link iv. Image Recognition a) Blob Detection b) Surf Identification III. Test Evaluation and Results i. Approach to Flight Testing ii. Flight Testing a) Simulation b) Verification c) Tuning iii. Data Link Testing a) Autopilot Data Link b) Video Data Link iv. Image Recognition Testing IV. Safety Considerations/Approach i. Risk Mitigation ii. Redundancy iii. Safety Pilot Override iv. Autopilot Failsafe v. Recovery V. Conclusion VI. Acknowledgements Bibliography ~ 1 of 20 ~

3 I. Introduction i. Cal Poly Pomona AUVSI SUAS Competition Team The AUVSI SUAS competition team of California State Polytechnic University at Pomona (Cal Poly Pomona) was trained to operate the unmanned aerial system (UAS) in accordance with the statement of work outlined in section L-3.3 of the request for proposals (RFP), which required that each team arrive on the competition site prepared to begin flight operations. Hovig Yaralian, team safety pilot, has been a remote control pilot for fifteen years and an unmanned aerial vehicle (UAV) safety pilot for six years. Autopilot operator Matthew Rose has been Cal Poly Pomona s autopilot operator for Association for Unmanned Vehicle Systems International s (AUVSI) Student Unmanned Aerial Systems (SUAS) competition team for the last three consecutive years and is, therefore, very familiar with the system. Assistant autopilot operator Kelechi Ezekwo has been trained to operate the autopilot in the event Mr. Rose is unable to operate the system. David Stone and graduate student, Kevin Ortega, are the authors of the image recognition software and are trained to handle necessary mission changes. Sean Conant has been working on the electronics of the aircraft all year and is prepared to conquer any unexpected challenges. Mathew Gan has been training as chief systems engineer with the traveling team to ensure that everyone goes through their checklists. Figure 1 below shows the responsibilities of the traveling team and the individuals responsible for completion of each component. Figure 1: Traveling Team Organizational Chart ii. Systems Engineering Systems engineering is utilized to determine our mission objectives and requirements, design rationale, and expected performance in accordance with the statement of work (SOW) in the section C3-3.3 of the RFP. a) Mission Objectives and Requirements In accordance with the SOW on section C1-3.5 of the RFP, the objective of the UAS is to takeoff, locate and identify targets while autonomously navigating waypoints, search an area defined in flight for additional targets, and land within forty minutes. The UAS is to identify targets along a predefined flight path as well as within a search area designated during flight. The image recognition system is to identify target. ~ 2 of 20 ~

4 The SOW was used to derive the primary and secondary requirements. The primary requirements used to derive the system requirements and architecture are related to the SOW in Table 1. Table 1: Primary Requirements SOW Section # Requirement # Description C UAS shall be designed using a systems engineering approach C UAS shall take off from one of two designated locations C UAS shall autonomously navigate waypoints C UAS shall perform an enroute search C UAS shall land completely within the designated landing area C Mission time shall not exceed 40 minutes C Risk mitigation shall be used in UAS design to maximize safety b) Design Rationale The system was designed to meet the criteria set out in the SOW by meeting all of the primary and derived requirements. This top down approach utilizing system requirements was a large part of meeting the SOW criteria in section C1-3.1 requiring that the system be designed using a systems engineering approach. Manual takeoff and landing were decided upon to meet the SOW criteria C and C without excessive cost to the system. An autopilot capable of waypoint navigation with the ability to add additional waypoints in flight was chosen to satisfy the SOW requirements from the sections C and C It was decided that a swift aircraft and image recognition system were required to satisfy the SOW requirements in the section C In order to satisfy the requirements in the section C1-4.1 of the SOW, it was determined that at least two individuals would be in charge of systems engineering and risk mitigation. Trade studies were conducted in order to determine the exact hardware used in the UAS. c) Expected Performance The aircraft is expected to take off manually and then transition into an autonomous flight as illustrated in Figure 2. The aircraft will then navigate through the mission waypoints while sending videos to the ground. The video will be picked up by the image recognition system, which will analyze each frame determining whether or not a target is present. When the image recognition system identifies a frame containing a target, it will then move to the second phase of the recognition software and determine the target s heading, GPS location, alphanumeric, shape, and respective color. The aircraft will then be redirected to the search area and identify targets in the same manner. Upon completion of both the search area and specified waypoints, the aircraft will then return to manual flight for landing. ~ 3 of 20 ~

5 Figure 2: System Mission Design II. UAS Design The unmanned aerial system was designed by determining the desired method of autonomy and then developing the air, ground, and image recognition systems to meet the criteria required by the statement of work. i. Method of Autonomy Autonomous waypoint navigation was decided upon in accordance with the requirements in the section C of the SOW stating that air vehicles shall autonomously navigate waypoints. However, the degree of autonomy for takeoff, landing, and image recognition were not specifically stated and, therefore, trade studies were conducted to ensure the optimum UAS design developable within the time constraint. Although takeoff and landing each have a flight demonstration bonus, they were grouped together due to the increase in the cost of hardware required to perform either one. Due to the limited accuracy of related autopilot sensors, an aircraft undergoing automatic takeoff and landing has a high chance of performing a maneuver that would result in a propeller strike. In addition to decreasing system safety, automatic takeoff and landing requires months to develop and expensive hardware. Manual takeoff and landing requires no hardware in addition to that necessary for flight and as the safety pilot is always physically watching the vehicle, last minute maneuvers or touch and go's can be performed to prevent crash landings. A trade study was done to determine whether or not the UAS would implement automatic takeoff and landing as shown in Table 2. Manual takeoff and landing was determined to be the best choice as it improved overall safety of the system as well as reduced time to completion. Table 2: Automatic Takeoff and Landing Trade Study Chance of Prop Strike Development Time Cost of Hardware Flight Demonstration Bonus Auto Takeoff/Landing High High High Yes Manual Takeoff/Landing Low Medium Low No The image recognition software was selected from the following options: manual graphical user interface, automatic cueing, and fully autonomous. A manually operated graphical interface would require a person to physically click on each of the desired pictures and type in all the identifying information. Although the accuracy of this system was determined to be much high, the operational efficiency was ~ 4 of 20 ~

6 determined to be very low. An automatic cueing system would slightly increase efficiency over a manual graphical interface however, as a human would still have had to type in all of the identifying information, the system was determined to be only moderately efficient. A fully autonomous system would have less accuracy than a human, however, the elimination of the necessity for a human to be included in the system greatly increases efficiency resulting in the possibility of active intelligence. In order to enhance the ease of the decision making process, these trade study arguments were tabulated as shown in Table 3. Fully autonomous image recognition was chosen for its high efficiency, flight demonstration bonus, and ability to be downgraded to automatic cueing if the schedule overran. Efficiency Table 3: Image Recognition Trade Study Accuracy Development Time Flight Demonstration Bonus Manual Graphical Interface Very Low High Medium No Automatic Cueing Medium Medium Medium No Fully Autonomous High Medium High Yes ii. Air Vehicle Choices of air vehicle included a 12' Telemaster from Hoby Lobby, a Sig Kadet Senior, and a scratch built aircraft. The Telemaster has a high adaptability due to its larger payload and ample room for wiring. The Telemaster airframe costs $1,000, but this was neglected as the Telemaster was used for the previous year's competition and was available for modification. The Sig Kadet's low payload capacity resulted in low adaptability and the necessity of ordering new parts increased the time for completion. A scratch built aircraft could easily have been designed to have high adaptability, high payload capacity, and ample space for wiring; however, it would take longer to design and build all the parts needed for a new airplane. A trade study was conducted to determine the aircraft most suitable for competition as shown in Table 4. Table 4: Air Vehicle Trade Study Adaptability Payload Space for Cost Availability Time to Capacity Wiring (Fuselage) of Parts Completion 12' Telemaster High 40 lb High At School Weekly Weeks Sig Kadet Low 12 lb Low $209 Weekly Month Scratch Built High any any Medium Weeks Months Although the Sig Kadet and scratch built aircraft were smaller and therefore easier to integrate with the autopilot system, the 12' Telemaster, Figure 3, was chosen as the air vehicle due to its high adaptability, low time to completion, and high ample room for wiring. ~ 5 of 20 ~

7 Figure 3: 12 Foot Telemaster Air Vehicle a) Air Vehicle Dimensions The aircraft dimensions, weights, and inertia are given in Table 5. The Telemaster aircraft is not easily pushed around by the wind due to its pound weight and relatively large inertia. With a moderate aspect ratio, the Telemaster is capable of a cruise speed of thirty knots while maintaining the ability to glide. With a distance from center of gravity to tail of 5.6 feet, the Telemaster is very stable and ideal for integration with an autopilot. Table 5: Aircraft Dimensions, Weight, and Inertia Parameter Value Units Gross Weight Pounds Wingspan Feet Aspect Ratio Wing Chord Length 1.77 Feet Wing Surface Area Feet 2 Distance CG to Tail 5.6 Feet Horizontal Stabilizer Span 4.25 Feet Horizontal Stabilizer Chord Feet Horizontal Surface Area Feet 2 Ixx Slug*ft 2 Iyy Slug*ft 2 Izz Slug*ft 2 b) Components The Telemaster was modified to carry a complex payload in order to achieve the mission objectives. Trade studies were conducted in an attempt to maximize mission effectiveness. Various types of cameras were considered for use for the image recognition system. The most promising components were the Sony DSLR, AXIS P1347 network camera, and SONY network camera. ~ 6 of 20 ~

8 The Sony DSLR had a much higher resolution, however, implementation of the camera was much more complex than that of the other cameras. There was concern that due to the very high resolution, the data transfer system would not be capable of transferring down the images at a rate high enough to ensure that every target is captured. The AXIS P1347 network camera was chosen because if it was determined that five megapixels could not be analyzed fast enough, it could be easily configured to stream video with less data. Table 6: Camera Down Select Ease of Implementation Resolution Configuration Software Sony DSLR Very Complex 10 Megapixels No AXIS P1347 Very Easy 5 Megapixels Yes Sony Network Cam Very Easy 3 Megapixels No Many data link systems were considered in search for a wireless bridge solution. The two main competitors were the Bullet M5 5.8 GHz Antenna and the Xbee wireless modules. The Bullet M5 had approximately the same range as Xbee, however, it was much easier to connect to the network camera and much more reliable than the Xbee modules. Table 7: Data Transfer Mechanism Trade Study Ease of Ethernet Connection Range Reliability Bullet M5 Very Easy 1 mile Very Reliable Xbee Diffacult 1 mile Known Failures An inertial measurement unit was included in the system in an attempt to stabilize the camera during flight. The inertial measurement unit is programmable and has been encoded so that it moves servos on the gimbal system in such a way that the camera always points straight down despite varying pitch and roll attitude of the airplane. This capability greatly reduces the required trigonometry and distortion correction necessary to determine the location and other target parameters. A gas engine would have a high endurance and performance, but would also vibrate much more than an electric engine. These vibrations introduce noise into the inertial measurement unit. Failure of the aircraft to accurately determine its accelerations is a mission critical event. For this reason, the electric engine was chosen over the gas engine despite the slightly lower endurance and performance. Table 8: Engine Trade Study Endurance Performance Vibrations Fuel Movement Gas Engine High High High Yes AXI 5360/20 Electric Engine Medium Medium Low No ~ 7 of 20 ~

9 c) Payload The payload is composed of a stabilized gimbal system, AXIS P1347 network camera, bullet M5 antenna, and GPS antenna. An inertial measurement unit is used for image stabilization, which makes it possible for the camera to always point down as the pitch and/or roll attitudes of the aircraft change. The bullet M5 antenna creates a wireless network bridge between the aircraft and the ground allowing the network camera to wirelessly transmit video to the ground with minimal wiring complications. The autopilot, autopilot antenna, and GPS antenna are essential to the controlled flight of the aircraft. Figure 4 shows the aerial vehicle work breakdown structure. Figure 4: Aerial Vehicle Work Breakdown Structure d) Vehicle Flight Capabilities Flying at full throttle, the air vehicle for the UAS has an endurance of twelve minutes at a root mean square velocity of thirty knots. This gives the aircraft a range of approximately six nautical miles. The high lift Clark-Y airfoil on the Telemaster allows for a payload capacity of forty pounds. iii. Ground Systems The ground system component of the UAS is composed of a ground station, video antenna, autopilot antenna, network switch, and image detection station. The relationship between these components is further broken down in Figure 5. ~ 8 of 20 ~

10 Figure 5: Ground Systems Work Breakdown Structure a) Ground Station and Autopilot System Three autopilots were considered for the autonomous navigation of the aerial vehicle. The paparazzi autopilot system was quickly eliminated as it was difficult to find the hardware in stock. The Piccolo II and ardupilot autopilot systems had already been obtained by the school. The Piccolo II autopilot system was found to be known for its control, both of the aircraft and in the ground station. The ardupilot was found to have moderate control of the vehicle. The ardupilot had an easier integration, however, it was found that Cloud Cap Technologies provides great support to its customers and the integration complexity was negated. The Piccolo II autopilot was chosen for its advanced aircraft and ground station control. Table 9: Autopilot Down Select Availability Control Ground Station Integration Support Paparazzi Known Issues Moderate Difficult Hard Good Piccolo II School Owned High Simple Hard Very good Ardupilot School Owned Moderate Simple Moderate Poor b) Mission Planning Cloud Cap's mission planning system allows the swift implementation of new waypoints while maintaining previously set waypoints. This allows for the mission to be planned at an earlier date as specified by the competition rules. The waypoints are integrated into Piccolo Command Center (PCC) by clicking the lasso button, selecting the desired points, and closing the loop by double clicking the original waypoint. Waypoints can be added in the degrees, minutes, and seconds (DMS) or decimal GPS format, as chosen by the autopilot operator. All attributes of any existing waypoint is easily modified by right clicking on the waypoint. By clicking the boundary creator button, an airspace, which the aircraft will know not to leave, can be specified by clicking the desired boundaries. ~ 9 of 20 ~

11 Figure 6: Ground Station Waypoint Creation c) Data Link The components of the ground data link concerning the acquisition of the video are the same as those in the air. This is because the data link components work as network bridge, where two of the same component are required to complete the bridge. However, the ground system does additionally have a network switch. As there have been few notable changes in the technology involved in switches, an arbitrary Netgear switch was chosen for its low price and high availability. The switch on the ground is necessary because the image recognition computer requires both the video coming from the bullet and the telemetry coming from PCC. iv. Image Recognition The image recognition system was designed such that it would identify the general location of the targets first. The image would then be cropped such that each target would be passed to the identification algorithm with less noise and less extraneous data. After identification of the target shape, letter, and color, the target location, orientation, and heading are determined through the autopilot software development kit. This data is then written to a text file and the pictures saved to a flash drive for judging. Target parameters compatible with the image recognition software are given in Table 10. ~ 10 of 20 ~

12 Table 10: Image Recognition Capability Shapes Colors Alphanumeric Size Circle, square, triangle, plus, half circle, etc. All All All (2ft side and larger) a) Blob Detection The blob detection algorithm takes each frame from the camera and transforms it into a binary, black and white, image by setting all of the pixels corresponding to possible target colors and turning them to white while turning all other pixels to black. In this way, the algorithm can determine the color of a target. Using a double histogram method, the location of the target within the frame is identified. The first histogram pulls all of the pixels to the side of the image and then by using another algorithm to check the number of coagulated pixels, the top and bottom boundaries of the target are identified. The original binary image is then again used to perform a histogram, where the pixels are pulled to the bottom of the screen identifying the left and right image boundaries. At this point, the target color and boundaries are identified. The target is then cropped and passed to the next step in the algorithm. b) Surf Identification The surf algorithm begins by taking in the cropped target from the blob detection algorithm. This image is then compared to multiple libraries containing different fonts of different alphanumeric characters. After the character is determined and recorded, the location based characteristics of the target are taken from the Cloud Cap Technology s software development kit and recorded. The pictures and collective data are then exported onto a flash drive in the format described in the competition rules. III. Test Evaluation and Results Through flight, data link, and image recognition testing, it was determined that the UAS is ready and capable of identifying targets autonomously. i. Approach to Flight Testing Flight testing incurs the highest risk to the system. In order to deal with the large chance of complete loss of the vehicle, steps have been put in place to mitigate risks, which meet the requirements in the section C-4.1 of the SOW. The first step to mitigate the risk is to review past experiences. The experiences gained from previous testing are shared through lessons learned. These lessons help prevent the repetition of the same mistakes. The incidents have been properly documented so that future teams from Cal Poly Pomona will be able to avoid unnecessary risks to the vehicle. The next step to mitigate risks in flight testing is to use a checklist. The Piccolo Autopilot comes with a checklist for the autopilot as shown in Figure 7. ~ 11 of 20 ~

13 Figure 7: Autopilot Checklist Beyond the autopilot checklist, there is a vehicle checklist that checks the vehicle health before flights. There is also a payload checklist to ensure that the payload works throughout the flight. If there is a point that cannot be checked because an incident has occurred, a go-no go decision is made. Whether it is mission critical or flight critical, it must be reviewed before the checklist continues. The system meets the requirements in section C of the SOW using an airspace boundary in the autopilot ground station. Figure 8 shows the airspace boundary in the ground station. Figure 8: Airspace Boundary ~ 12 of 20 ~

14 After flight testing, a post flight brief takes place to review incidents in the mission or in the vehicle operation. Telemetry from the flight is also reviewed in case streamed data was missed by the ground station operator that could lead to a future failure. ii. Flight Testing A total of thirty-six flight test hours have been logged on the aircraft with the autopilot system onboard. An average of three autopilot initiation sequences take place in each flight. The process for integrating the autopilot to the aerial vehicle started with the development of flight dynamics model for the vehicle, computer simulation, flight verification, and tuning. It was necessary to develop the vehicle dynamics model before the autopilot was capable to fly the aerial system. The Piccolo Autopilot is a commercial-off-the-shelf (COTS) autopilot. Each aircraft that it flies is different, so there are vehicle parameters that have to be entered into the autopilot for it to fly the vehicle autonomously. The controller gains are first tuned in the Hardware-in-the-Loop simulation to make sure that the vehicle meets performance requirements. The performance characteristics are specified in the SOW. Since the vehicle will perform manual takeoff and landing, the focus of the performance is in climb, cruise, and descent. As specified by the requirements in the section C of the SOW, the aircraft must maintain ± 50 feet of designated altitude. The vehicle shall fly within ± 100 feet from the flight path. The air vehicle has a large weight and wing span and must be flight tested away from populated areas. The air vehicle also needs enough room to recover from upsets in flight. Based on the restrictions of the system, the closest flight location to campus is 90 minutes away. This restricts the amount of time that can be spent at the test location. For every flight test day, three hours are lost in transit and further restrictions are in place because of the operator scheduling issues. In order to make up for the time lost, it was determined that accurate flight dynamics model of the vehicle would be necessary. An accurate flight dynamics model facilitates the gain tuning process. To develop the dynamics model of the vehicle, the Athena Vortex Lattice (AVL) software was used. AVL is a free software program developed at MIT. The software requires mass, moment of inertia, geometry, and aerodynamic characteristics of the aircraft for the determination of vehicle stability and control characteristics and dynamics model. In order to verify the developed model, it is necessary to compare the model response with flight data. Several open-loop flight tests were conducted for doublet inputs in pitch-, roll-, and yaw-axes and flight data was recorded. Doublet input, shown in Figure 9, is usually used to excite the flight dynamics modes of the aircraft. The method is also used by NASA to identify the vehicle stability and Control characteristics. ~ 13 of 20 ~

15 q(deg/sec) Figure 9: Doublet Input a) Simulation Finally, the model response was compared with the flight data. Mathwork s MATLAB and Simulink environment were used for simulation and comparison. Figure 10 shows the pitch rate (q) and pitch attitude angle (θ) compared with flight data for a doublet input in elevator (δ e ). e (deg) (deg) time (sec) Figure 10: Comparison of the Flight Data (Solid) with the Simulation Results for Pitch Rate and Pitch Attitude Figure 11 shows the roll rate (p) and roll angle (φ) compared with the flight data for a doublet input in aileron (δ a ). ~ 14 of 20 ~

16 a (deg) p(deg/sec) (deg) time (sec) Figure 11: Comparison of the Flight Data (Solid) with the Simulation Results for Roll Rate and Roll Angle The results of this comparison showed that the vehicle output for given commands was very similar to actual results. This verified that the aircraft model was correct. The Cloud Cap s Software-in-the-Loop (SIL) simulator was then used in conjunction with flight gear to ensure the airworthiness of the aircraft model. This step is an important milestone in the program since the autopilot must have the accurate vehicle aerodynamic, mass, geometry, and inertia characteristics in order to fly the aircraft in simulation. The Cloud Cap s Hardware-in-the-Loop (HIL) simulator was then used in conjunction with flight gear to verify the expected movement of the aircraft as determined by the aircraft model for given control inputs. In the HIL simulation, the control surfaces were also checked to ensure that the autopilot commanded the correct deflection for specific maneuvers. If there was any jitter in the surfaces, it would be observed in the HIL simulation. Jitter is a flight critical issue that must be resolved before autonomous flight. b) Verification A total of thirty-six flight test hours have been logged on the autopilot system with an average of three autopilot initiation sequences in each flight. The autopilot's capability to control the aircraft was verified in steps. First, automatic control of steady level flight was achieved. Next, the aircraft was commanded to turn and was able to maintain pitch control and altitude for a two hundred and seventy degree coordinated turn. ~ 15 of 20 ~

17 c) Tuning Throughout the flight testing of the UAS, the autopilot's gains were changed to enhance the performance of the autopilot. The autopilot gains were tuned such that the aircraft would not deviate from target waypoints more than 100 feet in any direction in order to meet the performance requirements specified in the section C of the SOW. iii. Data Link Testing a) Autopilot Data Link The autopilot data link was tested over the range of one mile. The strength of the signal did not drop more than three percent and the signal was, therefore, determined to be sufficient for the competition. The connection between the ground station and the autopilot was also tested with multiple obstacles on the way including a chain linked fence with a cover. The results of the obstruction test proved that the connection between the autopilot and ground station will remain solid at ranges under one hundred feet despite various obstacles. However, at ranges closer to one mile, it was found that the ground station required line of sight with the autopilot antenna. b) Video Data Link The video data link was tested at a range of one mile and was still capable of receiving sufficient packets to support the image recognition system as shown in Figure 12. The data link for the video system was also intentionally dropped and regained, allowing assurance of reconnection of the video stream to the image recognition system. The data link drop test resulted in a reconnection time of approximately ten seconds. Figure 12: Video Downlink Bandwidth Bench Test ~ 16 of 20 ~

18 iv. Image Recognition Testing Many bench tests were conducted for the image recognition software. Initially, there was trouble identifying the different colors of objects through the blob detection algorithm because the algorithm used traditional green, red, and blue color information. However, the algorithm was later changed to use hue, saturation, and illumination. After the change, the algorithm consistently was able to identify the color of objects with much less sensitivity to glare. The algorithm was run again later, while the aircraft was on the ground, using the video that was recorded during flight. The video was taken over a dry lake bed, where there are many green bushes. The algorithm originally detected around 90% false positives, however, the algorithm was fine tuned and now picks up less than 10% false positives. The actual letter identification of the target proved to have 50% accuracy. The image was then changed to a binary format, black and white, and the accuracy of identification was improved greatly. At this point, the image recognition software was run in real time during flight testing. The algorithm was able to correctly identify and box the locations of multiple targets simultaneously as shown in Figure 13. Figure 13: Multiple Object Recognition IV. Safety Considerations/Approach The primary concern for the team is that the safety of the team, bystanders, public, and system should not be compromised. Risk mitigation, redundancy, safety pilot override, autopilot failsafe, and recovery measures have all been considered to ensure the maximum system safety. ~ 17 of 20 ~

19 i. Risk Mitigation System risks were given a risk level using a risk cube method. In this the severity of the risk was determined by multiplying the level of likelihood and level of severity together. Risks in the red region were in great need of mitigation, risks in yellow were recommended for mitigation, and risks in green were not in need of risk mitigation. Sample risks have been calculated into the risk mitigation cube in Figure 14. Figure 14: Sample Risk Levels in Risk Cube As indicated by the green line in the risk cube diagram, Figure 15, the risk involving cutoff of power supply to the ground station. In an incident when the gas for the generator powering the ground station ran out, this risk mitigation was involuntarily tested and proven to be successful as control of the aircraft was taken by the safety pilot and the aircraft safely landed. ~ 18 of 20 ~

20 ii. Redundancy Figure 15: Ground Station Cut Power Supply Risk Mitigation The aircraft is equipped with two batteries for all the servos on board, which provide an independent 6 Volt source strictly for use by servos only. This ensures that the servos have their own source of power and that in case one battery gets depleted or fails, there is still another to safely land the aircraft. iii. Safety Pilot Override Two JR radio receivers were integrated with JR radio level shifter, which is shown in Figure 16. This allows communication between the manual 2.4 GHz JR 12X Transmitter and receiver on the aircraft in case the communication between the ground station and the autopilot is lost. This provides additional redundancy for safety pilot override and is independent of the ground station/autopilot communication link, which transmits on 900 MHz. We have tested these separate communication links between the aircraft and the ground station/pilot by having a manual override on the pilot s transmitter. This allows the pilot to engage and disengage the autopilot with the flip of a switch. If at any point the aircraft becomes unsafe, the pilot can quickly take over the aircraft safely. The pilot also has a redundant system, which has two satellite receivers on board as mentioned above. The receivers are linked to the autopilot wiring harness and have continuous communication with the pilot s transmitters. If one receiver fails, the other simply remains in communication with the transmitter. Figure 16: JR Level Shifter Board ~ 19 of 20 ~

21 iv. Autopilot Failsafe There is a return to home feature in the ground station of the autopilot system. The feature has a lost comm. waypoint that the aircraft will go to in case the communication is lost. The aircraft then slowly rolls right, pitches up, and kills the throttle to try to come down to a safe location. v. Recovery The aircraft is a bright red color and is distinguishable from top and bottom, which can easily be seen from a good distance for the pilot to take over no matter what orientation the aircraft is in. All battery packs on board are brightly colored pink so that they can easily be seen/found in the event of a crash. V. Conclusion This paper has shown that Cal Poly Pomona's AUVSI SUAS team has designed a UAS system that has encompassed all of the requirements given in the competitions RFP. By communicating with the previous year's competition team and understanding their lessons learned, a robust system highly capable of completing the mission objective. Additionally, this paper shows that redundancy and safety were of primary concern in the system and mission operations development. VI. Acknowledgements Cal Poly Pomona's 2012 AUVSI SUAS team would like to thank its sponsors, Northrop Grumman and Cloud Cap Technologies. We would also like to thank James J. Cesari for donating so much of his time to drive us out to a safe test flight location. Thank you Carol Christian for all of your help with paperwork for travel and for equipment purchase. Finally, we would like to thank Dr. Subodh Bhandari for all of his help in guiding our project to success. Bibliography 1. Shafer, M., Flight Investigation of Various Control Inputs Intended for Parameter Estimation, NASA, Edwards, CA, Athena Vortex Lattice (AVL), 3. "Piccolo User s Guide." Cloud Cap Technology: Unmanned Systems, Autopilots, Payloads, Sensors. Hood River, OR: Cloud Cap, ~ 20 of 20 ~