Technical Journal Paper

Transcription

1 Technical Journal Paper CUAir: Cornell University Unmanned Air Systems Aeolus May 2011 Abstract The AUVSI Student Unmanned Air System (SUAS) competition presents the goals of autonomous navigation, surveillance, and real-time actionable intelligence. Aeolus, the system developed by CUAir for this year s competition, is able to conduct successful missions through the integration of mechanical, imagery, and navigation systems. The air system itself is an off-the-shelf Senior Telemaster kit, which has been reinforced for better flight integrity and modified for carrying a payload. A Canon Power- Shot SX110 IS camera is used for gathering imagery up to 9 megapixels. Image telemetry is controlled on-board the aircraft through a fit-pc2 computer, which can be remotely accessed through a 2.4GHz wireless bridge. The autopilot used is the Kestrel v2.4 Autopilot from Procerus Technologies. CUAir has developed additional software that interfaces with Virtual Cockpit, the software included with the autopilot by Procerus Technologies, to add functionality needed during the mission. Images are sent through the 2.4GHz wireless bridge to a ground station computer running targeting software developed by CUAir. It matches telemetry information received from Virtual Cockpit to images and can recognize and classify images through both manual and automatic recognition. Ground and flight tests have shown that this system is capable of the goals laid out by the AUVSI SUAS competition. Team Lead: Jesse Thompson Airframe Leads: Matthew Lordahl, Michael Romanko Navigation Lead: Jesse Thompson Imagery Lead: Jesse Thompson Safety Pilot: Matthew Lordahl Safety Officers: Corey Oses, Chris Jewison 1

2 Cornell University Unmanned Air Systems 1 Introduction 1.1 Competition Goals Critical design objectives of CUAir s system, as defined by the competition rules, are takeoff (rule 3.5.1), waypoint navigation (rule 3.5.2), area search (rule 3.5.3), landing (rule 3.5.4), mission completion time (rule 3.5.5), and actionable intelligence (rule 3.5.6). Takeoff and landing are accomplished through manual control for the safety of the aircraft, ground crew, and spectators. The autopilot controls flight for waypoint navigation. The area search uses waypoints assigned by team software. A camera on board the aircraft records images of the ground and sends them to the ground station, controlled by a compact computer on the aircraft communicating with the ground station via a wireless bridge. The ground station receives these images and processes them with telemetry data from the autopilot to produce actionable intelligence, which can be facilitated through both manual and automatic recognition. Missions will be completed safely within a 25 minute flight time window. Since images can be received at the ground station while the aircraft is still flying, the amount of additional time needed to complete target recognition after the flight has ended is minimal, making the total mission time fit well within 40 minutes. 1.2 System Design Overview Figure 1 shows the complete system structure. The autopilot is the main component of the navigation system, sending telemetry and receiving commands to and from the ground through a 900MHz radio. The autopilot directly controls the servos, but a switch on the safety pilot s controls triggers a manual override through software. A GPS unit connects to the autopilot as the primary source of position and velocity information. The autopilot controls the flight surfaces, gimbal system, and speed controller through a standard servo interface, and is commanded through software running at the ground station. The vision system is controlled from the ground station through a fit-pc2 compact computer that controls the operation of the digital camera via USB. A high-power radio on the aircraft and on the ground facilitates the wireless bridge formed to network the air and ground computers. All computers are connected virtually on the same network, so the image processing software is able to obtain telemetry information from the autopilot software. The airframe, which is not shown in the figure, is designed to easily carry the vision system and navigation system payloads for stable flight with simple setup before missions. CUAir - 2

3 Cornell University Unmanned Air Systems Figure 1: Overview of the system. 2 Airframe System Design Aeolus is an electric powered, tail dragging, high-wing aircraft with full aerodynamic control. It has an eight foot wingspan with 1330 square inches of wing area, an empty takeoff weight of 17 pounds, a payload takeoff weight of 21 pounds (below the 55 pound limit per rule 4.1.1), and a maximum flight duration of 30 minutes. Cruising speed is 41 knots indicated airspeed (KIAS), while the maximum and minimum flight speeds are 60 and 30 KIAS, respectively, all well below the maximum 100 KIAS per rule Aeolus meets all the requirements of the Academy of Model Aeronautics and the AUVSI Seafarers Chapter. 2.1 Design Methodology The Senior Telemaster kit chosen as the airframe of Aeolus is composed almost entirely of balsa and plywood. Along with a simple and efficient design, the Senior Telemaster has a large fuselage volume, a relatively slow cruising speed and low wing loading. About 4 degrees of dihedral promotes favorable roll stability and cross-wind performance. An electric propulsion system is utilized in place of a combustion engine to reduce potential vibrations. An electric motor also does not produce any exhaust that could compromise the vision system and is much less likely to stall or stop mid-flight. These characteristics are key advantages towards Aeolus s role as a surveillance aircraft. To successfully achieve the goals of the AUVSI competition, CUAir identified key mission performance parameters: flight stability, payload volume and accessibility, flight endurance, ease of (dis)assembly and overall safety. Meeting these parameters facilitates the unmanned aerial system s survivability, maintainability, and flexibility during any type of mission. Aeolus, a heavily modified Senior Telemaster, is CUAir s air system that meets and exceeds each of these design parameters. CUAir - 3

4 2.2 Modifications and Payloads Cornell University Unmanned Air Systems 2.2 Modifications and Payloads The critical mission payloads onboard Aeolus are the Kestrel autopilot, fit-pc2, Bullet WiFi radio, and camera-gimbal system. The team demanded that the integration of these components into the airframe would allow for system modularity (see Figure 2). The stock Senior Telemaster airframe is heavily reinforced in order to safely lift these components. For example, the wings are bolted onto the fuselage with additional support from a custom reinforcement rib and elastic bands, and the wing struts and landing gear are bolted to the fuselage using metal hardware. The motor mount firewall and forward bulkheads are reinforced to support the excessive forces from the wings and electric motor, and the electronic speed controller is mounted outside the aircraft in the airstream for optimal cooling. A custom-made holder with soft impact foam situated directly under the wing safely secures the Kestrel Autopilot, making it easy to remove if necessary. The on-board computer and all batteries except the main flight pack are secured in the forward-most cavity of the plane with Velcro. This cavity is easily accessible at any time by a hinged flap and provides access to all navigation and vision system power switches. The Bullet WiFi radio is affixed to the bottom of the aircraft, between the landing gear, with custom removable brackets. Figure 2 identifies some of these onboard payloads. 2.3 Power System Figure 2: On-board payloads. With a payload takeoff weight of 21 pounds, Aeolus must be equipped with a power system that can provide enough thrust to keep the aircraft aloft for at least 25 minutes with ample reserve power for emergency situations. Additionally, all payloads must be adequately powered to ensure no loss of control or communication. To meet this demand, Aeolus is powered by an AXi 5320/28 brushless electric motor that turns a 17x10E APC propeller. This motor was chosen based on its ability to continuously deliver 35 Watts per pound nominally in cruise, as well as 70 Watts per pound of burst, reserve power. Coupled with the AXi motor is an 85 Amp Phoenix ICE high voltage electronic speed controller and two nine-cell, 5 amp-hour lithium polymer batteries wired together in parallel offering 10 amp hours of total capacity. After extensive analysis, the propulsion requirements of Aeolus were more efficiently (in terms of weight) met by supplying the power via current instead of voltage, as higher voltages are achieved by adding more battery cells. Following safety conventions for lithium polymer batteries, only 80% of battery capacity should be discharged to prevent permanent battery damage, leaving a total effective capacity of 8 amp-hours at 33.3 volts. CUAir - 4

5 Cornell University Unmanned Air Systems Current draw at maximum and minimum throttle is 45 and 22 amps, respectively, based on lift calculations. This range of current draw predicted a maximum endurance of approximately minutes at the payload takeoff weight. Test flight data recorded by the speed controller, however, projects maximum flight times exceeding 25 minutes because Aeolus yields a more efficient cruise than initially expected, thus requiring less throttle input. Data logs from test flights are given in section 5.2. The 33.3 volt lithium polymer battery packs are only utilized for propulsion power. All other systems critical to control, navigation and vision operation of the aircraft, such as the servos, Kestrel Autopilot, fit- PC2, and Bullet WiFi radio, are powered by individual battery packs with different voltages and capacities. For control safety, the team selected all other battery packs to have at least twice the capacity than needed during a mission. This provides a degree of safety against longer-than-expected power draw that may occur during flight standby, as well as eliminates the need to recharge batteries between two consecutive flights, decreasing turn around time. The propulsion system was kept independent from other electronic systems on board the aircraft to ensure that a reliable power source without noise or occasional surges could be supplied to the critical flight control electronics (e.g. servos), regardless of the state of the propulsion batteries. Having separate and distinct systems mitigates the risk of failure in one system from affecting the other systems. Table 1 summarizes aircraft and propulsion parameters. Table 1: Performance parameters. Design Parameter Specification Unit Length 64 Inches Wingspan 94 Inches Wing Area 1330 Inches 2 Aspect Ratio 6.63 Payload 4 Pounds Empty Takeoff Weight 17 Pounds Nominal Takeoff Weight 21 Pounds Maximum Takeoff Weight 26 Pounds Wing Loading Pounds/Inches 2 Stall Speed 30 Knots Cruise Speed 41 Knots Maximum Speed 60 Knots Maximum Flight time 30 Minutes Electric Motor AXi Gold 5320/28 Outrunner Propeller 17x10E Batteries 33.3 V LiPo at 5000 mah ( 2) 3 Imagery System Design The overarching design requirement for the imagery system is the ability to locate, recognize, and classify targets on the ground visible from the air (rule 3.5.2, 3.5.3). In addition, real-time acquisition of targets better accomplishes the mission objectives (rule 3.5.6, 4.4.2). Furthermore, at least one target will need to be located at an angle up to 60 degrees from underneath the aircraft (rule 4.5.2). To achieve each of these goals, the imagery system consists of a digital camera mounted on a single-axis gimbal. This camera is controlled by a fit-pc2, a compact computer on-board the aircraft running Linux, through USB. The fit-pc2 itself is controlled via a wireless network with the ground station. Images taken by the camera are sent to the ground station for manual and/or automatic target recognition and are tagged with telemetry information retrieved from the navigation system. CUAir - 5

6 3.1 Gimbal Cornell University Unmanned Air Systems 3.1 Gimbal Aeolus employs a single-axis gimbal, shown in Figure 3, which is capable of rotating the camera along the aircraft s roll axis. This rotation allows for the camera to stay focused on the same area while banking in a turn, and to provide a wider field of view in level flight. The single-axis gimbal on Aeolus can rotate at least 60-degrees in either direction to achieve the required viewing angle specified in rule This makes the imagery system capable of viewing all targets. To minimize weight, the gimbal and its mount are primarily constructed of a lightweight polycarbonate. The gimbal s mount and servo configuration permit quick camera removal and calibration, and a hatch allows the lens to extend outside the bottom of the fuselage and rotate freely, while still protecting the camera from debris during take-off and landing. The hatch also prevents high velocity airflow from entering the fuselage, which would result in significant aerodynamic drag, and in the event that the camera detaches from the gimbal, it will prevent it from falling out of the fuselage. The gimbal was tested and calibrated both on a portable test stand and in the plane during test flights. See testing, section 5 for more detail. Figure 3: Camera gimbal system, in the aircraft (left) and CAD (right). 3.2 fit-pc2 The fit-pc2 is a nettop computer running an Intel Atom (x86) processor clocked at 1.6 GHz. The computer is fanless and is protected in-flight by an anodized aluminum casing. The camera is connected via one of the four USB ports located on the back of the fit-pc2. Power is supplied by an 11.1V lithium polymer battery shared with the autopilot, and uses only 5W of power, which helps to reduce payload weight. It contains an 8GB solid-state hard drive, which was chosen for its reliability handling the expected vibrations of the aircraft. The camera is controlled by USB through the libgphoto2 library. gphoto is a set of open-source software applications compatible with hundreds of cameras. Its core purpose is to manage photo files and perform diagnostic tasks on the camera while also capable of accessing camera functions remotely. Most remotecontrollable cameras fall into the category of digital SLRs which are too large and heavy for use onboard our aircraft. However, the software supports a select few point-and-shoot devices (such as the SX110 IS). The camera s zoom, focus, shutter speed, and several other settings can be modified through gphoto. 3.3 Camera The camera chosen by CUAir is a Canon PowerShot SX110 IS. The camera has a 9MP sensor and is capable of capturing images at a sustained rate of 1.5 frames per second. This choice was based on the ability to control the camera remotely via the gphoto library and for its picture quality and high frame rate for a CUAir - 6

7 3.4 Wireless Bridge Cornell University Unmanned Air Systems point-and-shoot camera. Table 2 shows the technical specifications of the camera, and Figure 3 above shows it mounted on the gimbal. Table 2: Camera specifications for the Canon Parameter Specification Weight (with batteries) 10.7 Dimensions Maximum frame rate 1.2 Sensor type CCD Shutter speed range 15-1/2500 Zoom range Up to SX110 IS. Unit Oz. Inches FPS sec. Wireless Bridge The wireless telemetry system was designed for ease of operation and reliability. Several factors influenced the radio selection: Output Power Receiver sensitivity Antenna gain Size and form factor Bandwidth The Bullet M2 and Nanostation M2 by Ubiquiti Networks were chosen as the radios for the aircraft and ground station respectively. These radios use the 2.4 GHz IEEE n (WiFi) standard and provide high transmit power (up to 29 dbm) and low receiver sensitivity (as low as -96dBm) in a compact package. The Bullet is connected to a 3dBi antenna, while the Nanostation contains an 11 dbi cross-polarized antenna, which can be directed towards the aircraft during flight. While the Bullet has a reasonably small size, there is not enough space within the front cavity of the aircraft, so it is attached to the underside, between the landing gear. Figure 4 shows the mounting positions of the aircraft s antennas. There is an inverse relationship between bandwidth and range. Section 5.4 describes how the bandwidth was selected. Figure 4: Antennas for GPS, WiFi, and autopilot. 3.5 Target Recognition The target recognition system accurately classifies targets on the ground and exports all information to the AUVSI judges. As specified in the competition rules (rule 4.4.9), targets are classified by their position, orientation, shape, background color, alphanumeric and alphanumeric color. This is accomplished by processing both images and telemetry data generated in flight. CUAir - 7

8 3.5 Target Recognition Cornell University Unmanned Air Systems Figure 5: Data flow overview. A two component system is used to classify targets. First, there is a manual system that ensures identification accuracy and completeness. Second, there is an automatic system that performs autonomous classification. Together they create a system that allows for real-time classification of targets. This system is designed to survive both application and station failures through software redundancy and data preservation. Figure 5 shows an overview of the target recognition system. Telemetry data is forwarded from Virtual Cockpit, running on the navigation computer at the ground station. While in flight, the aircraft also sends images from the camera to the manual system. Once the data is received by this system, it sends the images to the automatic classification system for automatic target recognition. If a target is found, it then sends the target classification data back to the manual system. Upon completion of the mission, the manual classification system formats the data to AUVSI s specifications and exports it for the judges Manual Classification System The purpose of the manual classification system is to collect data and allow the imagery operator to manually classify targets while the aircraft is in flight. Its responsibilities include communicating with the autopilot software to receive telemetry data, loading and manipulating images, identifying targets manually, and exporting data to the judges. Figure 6 shows a screenshot of the system with labels in red. The target display shows a list of target instances, the places in images where targets have been found. The target data sheet window is launched when the user requests to create or edit a target or instance. This form allows the user to enter all critical information about a target. Once all data is entered, the target display automatically groups instances to targets based on common properties in the data sheets. The image display allows a user to rapidly view the images taken by the air system. Once a target has been identified, a user can create an instance in that section of the image. The display also allows for zooming and panning of the image. The telemetry display communicates with the autopilot software to receive and display the state of the air system at the time of the picture. Finally, the export display launches the geo-tagging algorithm (transformation from pixel coordinates to GPS coordinates), toggles uploading to the automatic classification system, and exports the data to the judges (rule 4.4.9). CUAir - 8

9 3.5 Target Recognition Cornell University Unmanned Air Systems Figure 6: Manual classification application Automatic Classification System The purpose of the Automatic Classification is to perform autonomous target recognition to determine the object s shape and color. To complete target recognition in flight, the system is distributed to achieve real time processing. Shown in Figure 7, the manual classification system uses its node controller to send images to automatic classification nodes. These nodes then send back the targets that are found in the images. A node is accessed through on-site networking or through Wireless 3G communications to off-site nodes such as Amazon EC2 Cloud Servers. As images are received from the air system, they are forwarded to a free node. If enough nodes are used, the nodes will finish processing images before the system runs out of nodes to send images to. CUAir - 9

10 Cornell University Unmanned Air Systems Figure 7: Node Control. The automatic target recognition system performs edge detection and oriented edge comparison detailed in [1]. The program loads in target packages created prior to the mission that contains example edge data. It compares these packages to edges within the image currently being processed. If the example edges match a given image, a target has been found. This process handles occlusion, noise within the edge data, and other error handling. 4 Navigation System To accomplish the objectives of waypoint navigation, area search, and imagery control (see section 1.1 and rule 4.5.2), the team uses a navigation system consisting of an autopilot, its ground station software, and software the team has developed to add necessary functionality not provided by the autopilot s software. 4.1 Autopilot The autopilot used is the Kestrel 2.4 by Procerus Technologies. It is controlled through a 900MHz radio and is small, lightweight, contains pressure sensors for airspeed and altitude, a 3-axis accelerometer for attitude, a magnetometer for heading, and interfaces with a GPS unit as the primary source of position and velocity data. It directly controls the servos and speed controller through a standard servo interface, and while it supports several modes of operation, the two most important modes to mission operation are navigation and manual override, which is part of an integral safety system in the autopilot. The autopilot mounted in the aircraft is shown in Figure 2. In all modes when the autopilot is on and communicating with the ground station, position and attitude telemetry packets are routinely sent to Virtual Cockpit at the ground station. This data is also forwarded to the team s targeting software (see section 3.5) and navigation software (see section 4). The manual override system is used for manual takeoff and landing during the mission, and is triggered through a switch on the safety pilot s RC transmitter, which communicates with the autopilot indirectly through the autopilot s software, Virtual Cockpit. This mode allows the safety pilot to regain control of the aircraft at his discretion and follows safety rule Even in navigation mode, RC transmitter stick deflections will still produce an immediate response, which supports system safety since the safety pilot always has immediate control of the aircraft. During any time while the autopilot has a GPS lock on its position and the ground crew loses sight of the aircraft, the autopilot can be commanded to fly back to its home position, which is initially acquired by the aircraft s position any time before takeoff, following safety rule Failsafes are also set following safety rules and 4.1.5, maintaining level flight until a loss of communication for 30 seconds, when the aircraft will attempt to fly home. Loss of communication after 3 minutes will result in flight termination as defined by rule Since the GPS unit is critical for safe navigation operation, flight navigation will not be performed unless a lock on six GPS satellites has been achieved, which is a safety recommendation given by the autopilot manufacturer. CUAir - 10

11 4.2 Autopilot Control Software Cornell University Unmanned Air Systems Navigation mode can be enabled by a ground station operator once desired waypoints have been uploaded to the autopilot. The autopilot uses a set PID feedback loops to control the precise operation of the autopilot. The ground and flight tests performed for tuning and verifying these parameters is described in section Autopilot Control Software Since the autopilot system easily interfaces with included software, Virtual Cockpit, direct control of the autopilot is performed through this software. Virtual Cockpit provides a graphical interface for setting a flight path, but is not the best interface for maintaining the flight plan during the mission. A solution to this problem is to control the autopilot through a separate GUI developed by the team. Virtual Cockpit features a socket-based development interface designed to facilitate exactly that. CU Autopilot, the software developed by the team, provides useful tools and hides Virtual Cockpit s limitations. It is essentially a software wrapper around operations in Virtual Cockpit, but does not replace Virtual Cockpit, which can always be used as a backup in the event of a failure. Figure 8 shows a screenshot of CU Autopilot during a development test. Figure 8: The CU Autopilot interface. CU Autopilot is designed to provide the user with only necessary controls. The primary need for it is for visually representing modifiable no fly zones (rule 4.4.4) and search areas (rule 4.4.5), the aircraft s position in relation to the boundaries (rule 4.4.6), ease of waypoint addition and editing, generating waypoints to create an efficient flight pattern for the area search, and displaying altitude (rule 4.4.7) and airspeed (rule 4.4.8) information needed during the flight and required by the judges. To keep the implementation simple, all configuration and calibration settings are accessed in Virtual Cockpit. CUAir - 11

12 Cornell University Unmanned Air Systems 5 Testing and Analysis A series of system tests were conducted for the airframe, vision and navigation systems. These test flights were a culmination of extensive ground testing on the individual components of each sub-system. Test flights were structured to systematically build up from basic analysis to more complex and integrated system tests. Due to the unreliable and inclement nature of the weather in upstate New York, only three full test flights were preformed in the spring of 2011 at an Academy of Model Aeronautics sanctioned field (a photograph of the aircraft landing is shown in Figure 9). All flights were supervised by a safety officer and licensed model aircraft pilot. CUAir operates within AMA rules for autonomous flight, because the aircraft is always under immediate control of the safety pilot. 5.1 Flight-Worthiness Tests Two test flights conducted on April 9, 2011, verified the flight-worthiness of the airframe and flight power system, and the operation of the navigation system. To rigorously evaluate airframe stability and aerodynamic control, an initial flight was conducted without imagery payloads or critical navigation equipment. However, dead weight was added to the aircraft to simulate the payload components in their proper locations. This was done in order to eliminate any risk to the navigation and vision system equipment while still fully examining the flight envelope of the aircraft in a mission-ready state. Prior to taxi-out and takeoff, various pre-flight checks were conducted. Once the airframe was assembled, static loads were applied to the control surfaces and control linkages to ensure that they were securely attached to the aircraft (part of the standard pre-flight check developed by the team). The aircraft was then lifted off the ground, suspended by the main wing, and loaded such that the effective wing loading was four times its nominal wing loading specified in Table 1. This verified that the aircraft s weight can be supported by its wings, struts and custom mounting brackets in a level, cruise configuration (1G) as well as during more strenuous procedures such as turns, takeoff, and landing. Taxi tests were also preformed to ensure safe ground handling characteristics, and a throttle run up was done to verify maximum calculated RPMs for takeoff were being produced by the motor. Once the entire team was briefed and all systems were go, the pilot climbed to about 250 feet above ground level (AGL). Racetrack patterns were flown while the pilot trimmed the aircraft until it was capable of sustaining straight and level flight without any control inputs. Aeolus s stall characteristics were tested by intentionally stalling the wing at a high altitude; stalls resulted in smooth, stable recoveries instead of potentially catastrophic spin. The control throws on the surfaces provided more than adequate authority and maneuverability for the airframe. Aeolus was successfully landed in cross-winds of 18 knots, gusting up to 23 knots, demonstrating its ability to fly slow and stable within the flight conditions specified by competition rule The duration of this flight was 16 minutes. CUAir - 12

13 5.2 Propulsion System Tests Cornell University Unmanned Air Systems Figure 9: Landing from the second system test flight on April 9, Propulsion System Tests The first flight described above qualitatively validated that the airframe was flight worthy and that the power system created enough thrust to sustain lift. However, more quantitative data was necessary. The Navigation system components were integrated into Aeolus for the second flight. In addition to testing the autopilot functionality of Aeolus, critical flight data such as airspeed could be recorded throughout the flight. The pilot preformed a manual takeoff and climbed to 300 feet AGL. With the autopilot operator manning virtual cockpit, the pilot stalled Aeolus and the stall speed was recorded. The maximum dash speed was determined by inputting maximum power to the motor while maintaining level flight. Lastly, to obtain the cruise speed of Aeolus, the pilot slowly reduced the throttle to a setting which allowed the aircraft to maintain altitude and be able to climb and maneuver without an imminent risk of a stall. The remainder of the flight was flown at this cruise to maximize flight time and performance. Since the electronic speed controller being used on Aeolus includes a data logging feature, critical propulsion data (such as current draw, battery voltage, power out, etc.) was downloaded at the conclusion of the flight. The orange line in Figure 10 shows battery capacity consumed (in Amp hours) throughout the flight. This flight was 18 minutes long, and only used 55% of the 8 Amp-hours of total effective battery capacity. Extrapolating this data actually projects a maximum flight time of approximately 30 minutes, which is 5-7 minutes greater than original projections. This is due to Aeolus s superb aerodynamic efficiency, large wing area, and low wing loading. The blue line in Figure 10 is a graph of power produced (in Watts) throughout the flight. With the motor producing an average of 500 Watts throughout the flight to maintain cruise, Aeolus is actually able to fly at 25 Watts per pound, 10 Watts per pound less than was accounted for when choosing the propulsion system. Aeolus was also able to deliver a maximum of 72 Watts per pound. The data from the aforementioned flight was consistent with that from the third flight during which the imagery system was tested. The airframe can be assembled and broken down in less than 10 minutes, requiring only a screwdriver to tighten the bolts that secure the main wing to the fuselage. The main wing separates into two 4-foot sections, making the transportation of the three wing and fuselage pieces possible in a sedan with its back seats down. The sole change that was made to the airframe after the first two flights was hard mounting the struts to the underside of the wing using metal brackets, nuts and bolts. The original design utilized nylon hinges CUAir - 13

14 5.3 Navigation/Autopilot Tests Cornell University Unmanned Air Systems with a small cotter pin to fix the struts to the wing; vibrations during flight caused the pin to back out of the hinge. Figure 10: Capacity and power consumed as a function of time. 5.3 Navigation/Autopilot Tests Before the autopilot s navigation mode was tested in actual flight, sufficient hardware-in-the-loop (HIL) and software-in-the-loop (SIL) testing, using an estimated model of the aircraft, was performed to gain experience in setting correct feedback parameters that dictate autopilot operation. HIL and SIL testing involves the use of an open source simulator called Aviones, which has full support in Virtual Cockpit. In SIL testing, only the simulator is used to model the aircraft virtually. In HIL testing, the autopilot system is used and replaces its telemetry with data from the simulator via a serial cable. Figure 11 shows the screen in Virtual Cockpit where PID feedback parameters can be modified to produce stable flight. CUAir - 14

15 5.3 Navigation/Autopilot Tests Cornell University Unmanned Air Systems Figure 11: SIL test roll PID loop showing stability after a turn. Figure 12: Virtual Cockpit flight pattern, recorded on April 9, Figure 11 shows an example graph in the PID feedback tuning window. The green line is the response the feedback loop is attempting to achieve, the yellow line is the actual measured response, the blue line is the CUAir - 15

16 5.4 Image Telemetry Tests Cornell University Unmanned Air Systems control output from the loop, and the pink lines indicate the safety limits of the output. The test flight on April 9th showed that the aircraft maintained stability surprisingly closely to the models simulated in SIL and HIL tests. Figure 12 shows the actual data recorded from the autopilot at the April 9th test flight. Note that the autopilot recognizes a 6.3 m/s wind (12.25 KIAS). The flight pattern does not appear to be entirely stable due to turbulence from this wind. 5.4 Image Telemetry Tests A test flight was conducted on May 13, 2011, to verify the imagery system. Prior to this test flight, a number of development tests had been performed to prepare for the integrated system. Figure 13 shows the terminal output from the fit-pc2 when capturing a stream of images. The same terminal interface is used through remote login via ssh to configure the camera before flight. Camera configurations are not usually modified during flight, but can be if necessary. Figure 13: Remote capture and download. The test flight on May 13, 2011, demonstrated successful transfer of images from the camera to the fit-pc2 while in the air and transfer of images from the fit-pc2 via the wireless bridge to the target recognition system in real time. Command over the camera was actively controllable from the ground throughout the flight, and the gimbal was also able to be controlled through software. Figure 6 shows an image that was taken from the air during the flight appearing in the manual classification software, clearly showing a test target on the ground. However, there were a few challenges faced at this test flight. The GPS unit never produced a lock on GPS satellites despite the fact that it was a clear day and mobile devices indicated a normal number of satellites in clear view. This prevented the ability to adequately tag images with location data. This problem was most likely due to a defective GPS unit, because the manufacturer was unable to find a solution to the problem at that time. Another challenge faced was that the bandwidth locked to a low value shortly after takeoff and would not climb back to the device s maximum rate even when the aircraft was well within range of the ground station after it had landed. Post-flight testing discovered that an auto-ranging setting for both of the radios had locked the bandwidth to the lowest setting immediately once the aircraft had flown to its farthest distance from the ground station. Nevertheless, the telemetry from the flight never dipped below 1.5 megabits per second and averaged 2 megabits per second. This was solved by configuring the radios to approximately 20 megabits per second, which transfers a single image in less than a second when there are no dropped packets. Since range and bandwidth are inversely related, this will still provide good range and ample bandwidth in CUAir - 16

17 Cornell University Unmanned Air Systems future flights. The final problem discovered with the system during this flight was that there were conflicting date codes arriving from the autopilot, camera, fit-pc2 and ground computer. The camera had not been adjusted for daylight savings time and each had time codes that were at least minutes apart. Future flights will solve this problem by synchronizing date and time information before the flight begins. 6 Flight Safety Precautions Proper safety precautions must be observed while operating any aircraft, especially unmanned systems. Neglecting safety in design and testing can lead to serious personal injury and vehicular damage when operating Aeolus. For this reason, safety of the flight vehicle, payloads and most importantly, personnel, are strongly emphasized throughout all phases of CU Air s systems and operations. CU Air has designed a system with redundancies, failsafes and appropriate factors of safety that eliminate potential risks before testing the aircraft in the air. The team has implemented rigorous system test flight procedures and checklists that are strictly followed by all members of the team. The checklists ensure that every system is analyzed, and given the go/no-go before the airplane ever leaves the ground. Before each test flight, the entire team is briefed on mission objectives in order to assign specific roles to each member. The airframe, imagery and navigation system leads, as well as the AMA licensed pilot and safety officer are present at all test flights. Based on previous experience in testing and risk identification, the team conducted a failure modes and effects analysis (FMEA), seen in Appendix A. Each scenario, ranked by severity, is accompanied by the proper corrective action to uphold mission safety. 7 Conclusion CUAir will continue to test Aeolus up until the competition, responding to the lessons learned through the test flights mentioned in section 5. CUAir has designed, fabricated and tested an unmanned air system, using a systems engineering approach, that is capable of successfully completing the 2011 competition mission objectives set forth by AUVSI. Based on that approach and numerous system tests, CUAir feels confident that autonomous waypoint navigation, area search, real-time target recognition for actionable intelligence, and automatic target recognition can be accomplished at the 2011 competition. Appendix A: Responses to In-Flight Scenarios Table 3: Severity index Index Severity 1 Temporary or permanent reduced performance 2 Autonomous navigation with vision failure 3 Manual control with vision and/or navigation failure 4 Abort Mission or Total Failure CUAir - 17

18 REFERENCES Cornell University Unmanned Air Systems Scenario Symptoms Corrective Action Severity Continue Mission Possible? Servo Failure Unresponsive controls, erratic Manual control override, at- 4 No behavior tempt immediate landing Loss of Manual Manual override controls Immediately attempt landing 4 No Control unresponsive through navigational control, Override initiate failsafe Structural Failurtrol, Visible damage, loss of con- Manual control override, land 4 No erratic behavior immediately Propulsion System 4 No Failure Loss of Kestrel Autopilot Communication GPS Signal Loss Waypoint Navigation Failure Payload Power Failure Ground Computers Crash Fit-PC2 failure Bullet WiFi Radio Failure Digital Camera Failure Loss of WiFi Communication Loss of Line of Sight Aircraft Stalls Sudden decrease in airspeed/altitude, no motor noise Virtual Cockpit notification Manual control override, bring throttle to zero position, attempt to re-input power and override soft cut-off, land immediately Attempt manual control override, attempt system restart Waypoint navigation ceases, Manual control override, fly Virtual Cockpit notification flight path manually, attempt communication re-link Erratic behavior, deviation Manual control override, fly from flight path flight path manually Loss of vision system, Continue mission navigating Kestrel Autopilot, or servos manually, terminate flight Unresponsive computers, Manual control override, attempt navigation or vision system computer restart, use al- loss ternate computer Loss of image transfer and Attempt restart of system, Land camera control to regain image system control Loss of image transfer, radios Attempt restart of system abort will not connect real time target recognition, con- tinue navigating search area, fly at closer range Loss of image transfer and Attempt restart of camera camera control through fit-pc2, land and reset camera if necessary Loss of image transfer and Realign 2.4GHz ground antenna camera control at aircraft, restart imagery computers, fly at closer range Cannot see aircraft Notify judges, Autonomously navigate towards home position Aircraft suddenly loses altitude, Manual override, level wings and enters spin lower nose to gain airspeed 3 Yes 3 Yes 3 Yes 2-4 Yes 2-4 Yes 2 Yes 2 Yes 2 Yes 1 Yes 1 Yes 1 Yes if References [1] Huttenlocher, D., with Olson, C., Automatic Target Recognition by Matching Oriented Edge Pixels, IEEE Trans. Image Processing, 6(1), pp , CUAir - 18

19 REFERENCES Cornell University Unmanned Air Systems Acknowledgments CUAir would like to thank the following for their support of the team: Professor Ashutosh Saxena, Faculty Advisor, Computer Science, Cornell University Matt Ulinski, Mechanical and Aerospace Engineering, Cornell University The Ithaca Radio Control Society Sponsors CUAir would like to thank our sponsors for their generous contributions to our team: CUAir - 19