Mizzou UAV Team 2017 AUVSI Student UAS Competition Journal University of Missouri College of Engineering

Transcription

1 Mizzou UAV Team 2017 AUVSI Student UAS Competition Journal University of Missouri College of Engineering Fig. 1 - Sky Tractor Abstract This journal paper presents the design, development, and testing of the aerial systems developed by the University of Missouri UAV team for use in the 2017 AUVSI Student UAS competition. The team, comprised of diverse engineering and technology students, has focused on developing a fully functional and competitive system after a year's absence from the competition. Emphasized areas for improvement included safety, design, and development processes, and system integration over previous competition years. For the 2017 competition, a heavily tested fixed wing, gasoline powered aircraft dubbed the "Sky Tractor," was chosen from the team's collection of UAVs to serve as the competition platform. The airframe has been upgraded with new 3D printed parts and integrated with new payload systems designed from the ground up, optimized for efficiency and simplicity

2 Table of Contents 1. Systems Engineering Mission Requirements Analysis Design Rationale Programmatic Risks & Mitigations System Design Visual Imaging Airframe Type Autopilot System Flight Computer Wireless Transmission Hardware Software Ground Station Aircraft Specifications Aircraft Rationale Mission Planning Air Delivery Test and Evaluation Plan Autopilot Tests Camera Testing Wireless Communications Image Processing Air Drop Testing Mission Practice Safety Risks and Mitigations Developmental Risks & Mitigations Mission Risks & Mitigations Operational Risks & Mitigations Cyber Security Conclusion

3 1 Systems Engineering 1.1 Mission Requirement Analysis The main systems and subsystems for the UAV were designed with an emphasis on maximizing performance while staying within budget. The team focused on ensuring that the processes developed for the 2017 competition would strictly follow the official rules and regulations and be safe for all members and observers. The 2017 UAV team began system development with no records or data remaining from previous competition years, making it impossible to intentionally improve on specific aspects of the previous systems. Thus, the new systems went through rigorous cycles of design and testing since there was no platform or benchmark to begin from. Due to challenges associated with new systems and a significantly reduced budget, the team elected not to attempt every task Table 1 below displays the task expectations, labeled as "Will Not Attempt", "Will Attempt", and "Will Perform", as well as the success confidence level. Key factors that are required for success in that specific task are tabulated as well. These factors were used to help make design decisions for the systems and software, as is detailed in following sections. Task Factors for Success Performing Confidence Level Autonomous flight Waypoint Capture Waypoint Accuracy Stationary Obstacle Avoidance Moving Obstacle Avoidance Search Area -Stable airframe -Sensitive autopilot & sensors -Robust wireless connectivity -Airframe minimally susceptible to wind -Robust navigation algorithms -Accurate GPS sensors -Integration of flight computer with autopilot -Ground station mission planning integration with interoperability system -Robust mission planning software -Airframe with high ground speed Will Perform 100% Will Perform 100% Will Perform 90% Will Attempt 60% Will Not Attempt - Will Perform 100% Off-Axis Target -Gimbal with controllable roll axis Will Attempt 75% Geolocation Object Matching/Imagery -Integration of flight computer with autopilot -Robust image processing software -Powerful flight computer -Powerful ground station computer -Robust wireless data link from aircraft to ground station Will Perform 90% Will Perform 90%

4 Air Delivery -Accurate autopilot & sensors -Airframe with high payload capacity -Strong payload release mechanism Table 1 Will Perform 90% 1.2 Design Rationale Several principles were determined and at the advent of system development. These principles were developed to ensure that an inexperienced team with minimal resources would be able to create a successful and competitive aircraft within the budget and allotted time. Familiarity and experience - if choosing between options of similar capability, the option that team members have more experience with, or education on, should be selected System integration - all systems and platforms should be designed with compatibility in mind - substitutes should be found for components that will not allow easy interfacing, if possible Budget constraints - rigorous cost vs performance analysis should be completed for each system and specific item due to budget restrictions 1.3 Programmatic Risks & Mitigation To ensure project success, risks were identified that might cause the team to be unsuccessful or fail to be competitive. The team then created a plan to mitigate each risk that was identified. The risks were updated and modified as development and testing progressed. Table 2 displays the risks to safety and success that were identified and planned for. Risk Degree Risk factor Prevention Aircraft destruction during testing 5 2 Team member injury 5 1 Budgetary Overrun Much of the testing conducted with a dummy aircraft. Systems only moved into the Sky Tractor after extensive testing with dummy aircraft. Additional aircraft were developed in parallel, allowing for a backup airframe should the Sky Tractor fail. Injury would result in suspension and review by the Mechanical Engineering Department. This is mitigated by strict safety guidelines and SOPs developed to ensure member safety during testing and fabrication. To avoid project costs exceeding the allotted budget for the year, all components were planned out ahead of purchasing. Each component researched extensively to ensure that it would work as planned. Some cheaper options were selected to allow for unexpected costs

5 Timeline Overrun 3 2 Table 2 To avoid running out of time to complete the project, a gantt chart was created at the project initialization and reviewed at each team meeting. A strict deliverables and testing schedule was created that allowed plenty of time for unexpected complication 2 Systems Design 2.1 Visual Imaging Our visual imaging component is made up of two cameras, gimbal, and stabilization. Camera Selection Several key factors were determined that dictated camera choices: Field of View (FOV) Area represented by each pixel Compatibility with programmatic controls Cost Field of view is important because it determines how much ground area is captured in each image. A feasibility study was conducted to determine a range of acceptable FOVs and the maximum acceptable area per pixel. Taking into account the expected ground speed of the aircraft, it was determined that a FOV of no less than 35 degrees be allowed. Any FOV smaller than 35 degrees would require a faster aircraft or more search time. The study and testing of image recognition software resulted in a recommended 0.33 /pixel as a minimum area per pixel representation to determine the specific characteristics of the targets. Any smaller than 0.33 /pixel and the image recognition software would not be able to reliably recognize the smallest of targets presented during missions. Table 3 shows several of the cameras that were considered for use. Camera Sony NEX 5T SVS Vistek V2 Nikon D3400 RPi V2 Camera & 8mm Lens Jetson 13MP Camera & 16mm lens Price $250 $6995 $499 $29.99 $249 Resolution 16MP 11MP 24MP 8MP 13MP Network Wifi USB 3.0 PTP MIPI MIPI 300ft.344 in/pix Varies by lens.256 in/pix.5 in/pix.329 in/pix Comments Cost Effective Easiest system integration Table 3 High resolution; easy to control Easy system integration; cost effective Requires Jetson TK/X1-5 -

6 Ultimately, it was discovered that none of the options that fit all of the desired criteria could be afforded by the team. To compensate, a two camera system was developed. The functionality of a single, expensive camera could be effectively replicated by two, less costly cameras. The Raspberry Pi V2 8MP was selected as the primary camera, easily interfacing with the flight computer for a fraction of the cost of other easily compatible cameras. While not easily integrated with many of the common camera control libraries, the Sony Nex 5T was selected as the secondary camera due to its excellent image quality for a relatively low price. The compromise of the two camera system made it possible to afford other critical components while staying within budget. Gimbal and Stabilization Two methods were considered for camera mounting. Previous Mizzou UAV teams had simply pointed the camera straight down from the aircraft fuselage, with no secondary stabilization. The 2017 team elected to pursue a 2 axis camera gimbal to prevent the inaccuracies associated with a rigidly mounted camera. A custom two axis servo gimbal was embedded into the fuselage of the Sky Tractor, providing constant downward stabilization. Being powered by the Pixhawk Flight controller, the gimbal is easily controlled for viewing the off-axis target. 2.2 Airframe Type Airframe research resulted in several key requirements: Flight endurance exceeding 30 minutes Payload capacity of 3 lbs Resistance to wind speeds up to 20 mph Payload volume allowing for a gimbal and object for air drop The selection of an aerial platform was one of the largest design challenges that the team faced. It was decided that a reliable aircraft from the team's small collection of fixed wings and multirotors would be modified and developed in parallel with two new airframes. The two new aircraft, one fixed wing and one multirotor, would be kept in reserve should the reliable aircraft fail. A fixed, high wing aircraft was determined to be the ideal airframe for the competition due to the design s inherent stability. Design studies and cost analysis revealed that a multirotor aircraft of the necessary capabilities would not be affordable for the 2017 competition. The Sky Tractor was ultimately selected as the airframe of choice. Flight endurance tests revealed a cruise time of over 60 minutes and a payload capacity far exceeding the estimated requirements. Satisfying all four airframe requirements, and given that the Sky Tractor would cost the team nothing in terms of development time and expenses, it was deemed the best choice for the competition. 2.3 Autopilot System The 3DR Pixhawk was chosen to pilot the Sky Tractor. The team s extensive experience combined with the high versatility of the Pixhawk makes it the idea choice for an autopilot. The Pixhawk s compatibility with GPS/Magnetometer, airspeed, and LIDAR range finding sensors provides ample data to interface with the flight computer telemetry in addition to safely controlling the aircraft

7 2.4 Flight Computer Utilizing the 2 camera system is extremely demanding on the flight computer. The design requires the computer to be responsible for controlling two cameras, running image recognition software, and communicating with the ground station. After careful study, it was determined that all three of the flight computer options displayed in Table 4 were capable of controlling the payload components, with some software optimization required. Flight Computer Raspberry Pi 3 Odroid XU4 Jetson TK1 Cost $35 $79.24 $ CPU 1.2GHz quad-core 2Ghz octa-core 2.3Ghz quad-core RAM 1 Gb 2 Gb 2 Gb Gigabit Ethernet No Yes Yes USB 3.0 No Yes Yes Knowledge & Familiarity High Low Medium Table 4 While the Jetson TK1 was the first choice due to its versatility and larger range of camera options, budget constraints required that the Raspberry Pi 3 (RPi 3) be selected for use. Although team knowledge and experience with the RPi 3 was very high, the lower processing power and RAM meant that only the most basic image processing could be completed onboard the aircraft. This limitation aided in choosing the RPi V2 8MP camera due to streamlined integration with the Raspberry Pi Wireless Transmission Hardware Wireless connectivity is needed for the conveyance of telemetry, images, and other data from the aircraft to the ground station as well as from the safety pilot to the aircraft. Telemetry For telemetry, 3D Robotics 900 Mhz radios were selected. Onboard the aircraft, a 900 Mhz linear whip antenna was selected due to small form factor and lightweight construction. Previous experience indicated that an identical antenna on the ground only maintained reliable telemetry data at a distance of 400 yards, which was unacceptable based on the mission requirements. To extend this range, a 900 Mhz 10 dbi patch antenna was selected to provide excellent directional connectivity. This combination in the past has been tested at up to 1.5 miles, which exceeds the estimated required range for the Sky Tractor. Base Station Research indicated that data speeds of 20 Mbps would be preferred in case it became necessary for every image from the secondary camera be sent to the ground station. To satisfy this - 7 -

8 requirement, the team decided to choose a Ubiquiti Rocket M5 for the payload transmission instead of the more popular Ubiquiti Bullet M5. On the ground, an Ubiquiti Nanostation receives the images and data from the aircraft. Video Transmitter For backup video, a 1000mW 1.3Ghz analog video transmitter was selected to transmit video and telemetry to the ground station. The transmitter uses an omnidirectional, 3 lobe circular polarized antenna for transmission. The associated 1.3Ghz Lawmate video receiver on the ground uses a corresponding 5 lobe antenna. Computer Radio System The safety pilot uses a Futaba 14SG, transmitting on the 2.4Ghz proprietary frequency hopping FASST protocol. The team has exclusively used this protocol in past competitions with excellent results. Onboard the aircraft, a Futaba 7 channel sbus receiver communicates with the Pixhawk. 2.6 Software OpenCV was selected as the software of choice for powering the payload and ground station based image processing. This choice was largely based on the exceptional capabilities of OpenCV as well as team familiarity with the program. Due to the limitations of the two camera system and the low processing power of the Raspberry Pi flight computer, several optimizations had to be made. Testing As expected, testing revealed that the Raspberry Pi would not be able to handle all of the image processing that was desired. To overcome this shortfall, the team split the load between the flight computer and the ground station computer. The Raspberry Pi 3 runs basic blob detection on the images pulled from the primary 8MP camera, searching for any objects of interest. If an object of interest is identified, the corresponding high resolution image from the secondary camera is sent to the ground station. By only running blob detection onboard the aircraft, instead of identifying all of the object characteristics, the processing load and time are greatly reduced. This brings the required workload within the capabilities of the Raspberry Pi 3. Custom software on the ground station feeds the images that are downloaded from the secondary camera into OpenCV running on a dual booted Linux computer. This computer then compares the images with predetermined patterns, colors, and a full list of alphanumerics. The results of the processing are output in a format that is acceptable by the interoperability server. 2.7 Ground Station The ground station is comprised of the mission control, transmission tower, data processing, and backup power. Mission Control Mission control is largely comprised of a computer that runs open source Mission Planner software. This software communicates with the Pixhawk on board the Sky Tractor to relay telemetry and update mission parameters as necessary. All telemetry data is available for viewing by competition judges

9 Transmission Tower The Transmission Tower is the wireless connection point between the ground station and the Sky Tractor. The tower was designed for optimal connectivity in line of sight operations, including a 2 axis antenna tracker mounted atop a 10 ft mast. A small processing and servo driver on the antenna tracker is fed telemetry data from the Mission Control computer, where it calculates the angle that each servo should be rotated such that the tracker remains aimed at the aircraft. Attached to the antenna tracker is a 10dbi 900Mhz patch antenna that relays telemetry information between the Sky Tractor and Mission Control. The Ubiquiti Nanostation dual polarity patch antennas are also attached to the antenna tracker. Because both are directional antennas, connectivity is reliant upon the antenna tracker itself. Research and team experience showed that the tracker would be accurate to a minimum of 10 degrees, even when the aircraft was travelling perpendicularly at cruise speed only 100 yards away. Also attached to the antenna mast is a 1.3Ghz right hand circularly polarized omnidirectional antenna that receives live, low resolution video from the camera in the nose of the Sky Tractor. This image is overlaid with telemetry information that is also available for viewing by the judges. This system has dual benefit, allowing redundancy in telemetry transmission as well as providing a means of piloting the aircraft during test flights should the autopilot fail. Data Processing The Data Processing and Interoperability station is comprised of a computer running Debian Linux. A router connects this computer to the Ubiquiti Nanostation, where custom Python software feeds images and telemetry files sent from the Sky Tractor to OpenCV, where full image processing is completed. OpenCV compares the images against a database of shapes, colors, and alphanumerics likely to be used in competition. Another piece of custom Python software takes the results of the image processing and formats the for the interoperability server. Target position is calculated by this same software. The exact location of the objects within the frame (in reference to the center of the frame) from OpenCV is used to modify the telemetry data from the Sky Tractor to create an accurate position for the object. The image is then cropped down to the proper size and archived for review by the Data Processing Operator before being submitted via the interoperability server. Backup Power All computers are equipped with rechargeable batteries that will allow them to operate for short periods of time without external power. The transmission tower, router, and other accessories are all equipped with backup power to mitigate mission disruption should primary power fail. 2.8 Aircraft Specifications The Sky Tractor was ultimately selected as the airframe of choice. This fixed wing aircraft was based on an AMR Trainer 26 kit powered by a DLE 40cc gasoline engine and has flown in two previous AUVSI SUAS competitions. The Sky Tractor is an ideal airframe due to its track record of reliability, high payload capacity, spacious payload area, and long flight time. While it is not the most aerodynamic or efficient airframe, it has an extremely high power to weight ratio and large wingspan that enables the aircraft to withstand adverse atmospheric conditions that would disable smaller aircraft

10 Specifications for the Sky Tractor are listed in Table 5. Airframe Engine Flight Characteristics Wingspan 84.5 in Max Power 3579 Watts Endurance 60 min Wing Area 1280 in Weight 3.3 lbs Cruise Speed 30 mph Wing Loading oz/in 2 Displacement 40 cc Max Airspeed 55 mph Fuselage Length 66 in Static Thrust 20.9 lb Max climb angle 90 deg (vertical) Ground Clearance 10 in Propeller 19x8 in APC Max Flying Weight 15 lbs Fuel Usage % throttle Table 5. Materials The Sky Tractor is largely comprised of balsa/plywood and Mylar skin. The fuselage uses plywood paneling reinforced with carbon fiber sheets and rods in high stress areas. The wing is made up of a plywood spars reinforcing the ribs, which support the Mylar skin and maintain the airfoil. Permanent components were mounted in alignment jigs and adhered together using high strength 60 minute epoxy. The payload area has split level platforms and custom brackets for mounting electrical and optical components. Engine The DLE 40 gasoline engine is supplied by a 20oz fuel tank and uses a 4.8V NiMH battery for ignition and spark plugs. There is an emergency cutoff relay between the battery and the engine electronics that can be triggered via a switch on the aircraft or by the safety pilot radio control. To maintain reliability, the engine is regularly cleaned and inspected for maintenance requirements. Having a power to weight ratio greater than 1 allows the aircraft to make extremely fast takeoffs, handle very high winds, and climb rapidly in emergencies. 2.9 Aircraft Rationale For autonomous control of the Sky Tractor, the 3DR Pixhawk Autopilot was selected. This autopilot was selected for its ease of integration with other systems, customizable code, and the team s significant amount of experience with the system. To ensure maximum accuracy for navigation, multiple sensors are connected to the Pixhawk. Pixhawk Sensors - Dual GPS and Magnetometers (5Hz refresh rate) - Pitot tube airspeed sensor - Lidar range finder

11 - Barometer Dual GPS units were selected to create redundancy in the system and allow for the highest degree of positioning accuracy possible. The airspeed sensor was selected to aid in autonomous takeoffs and landings. With airspeed known by the autopilot, accurate stall speeds are determined and can then be avoided during missions. Testing has shown that the LIDAR laser range finder makes autonomous takeoffs and landings much more reliable and easier on the airframe than using GPS and barometer data alone. Figure 2. shows the basic Pixhawk and sensor setup within the Sky Tractor. Mission Planner Autonomous missions are planned and executed from a ground station laptop running 3DR Mission Planner software. This software is used to control all of the aircraft flight parameters. Communication between the ground station and the autopilot is maintained by a pair of 900 Mhz two way radios. Range testing results indicate that the 900 Mhz radios with linear whip antennas can maintain a reliable data link at up to 600 yards with a clear line of sight. To increase this range, the team developed a system that automatically points a 900Mhz high gain patch antenna at the aircraft. The telemetry signal from the Pixhawk relays the aircraft coordinates and altitude to the Mission Planner software, which then relays the information to a gimbal controller that powers the two servos on the tracking mechanism, constantly adjusting the antenna aim. Onboard the Sky Tractor, the Pixhawk relays altitude and GPS data to the flight computer via a serial port. This link supplies the imagery systems with the information necessary to pinpoint recognized targets. The image gathering and processing system is the heart of the Sky Tractor payload. A dual camera system controlled by a flight computer was developed for image gathering. Following the design principles stated earlier, a Raspberry Pi 3 was selected to serve as the flight computer (FC). The FC directly interfaces with the primary camera, an 8MP RPi V2 vision camera used with a 6mm wide angle lens. A Sony NEX 5T is used as the secondary camera, connected to the FC by WiFi direct. The Image Processing System Research and testing has shown that overall system efficiency is increased significantly by gathering as few images as possible. To this end, the frame rate for the primary camera is determined by the groundspeed and altitude of the aircraft such that each image frame will overlap the previous image by approximately 25%. The Pixhawk telemetry is read by the flight

12 computer and is used to determine a groundspeed. Based on the ground speed, a custom Python program running on the FC triggers the camera at the necessary rate. The image capture rate is determined by calculating the area visible to the camera based on the current altitude and the known field of view for the camera. The Python program then calculates how soon the camera will need to take the next image so that it covers only the area of the ground that is necessary. Extensive tests were conducted to determine the reliability of the camera control system, resulting in a 95% success rate (success determined as capturing the image at the correct time). Failures in this system are caused by high processor loads on the flight computer and primary camera. Initially, failures resulted in images being captured 0.3 seconds too late. Code optimization has brought this rate down to 0.15 seconds. This infrequent failure is seen as non critical since no gaps in ground coverage were seen during testing, even when the failure did occur. When the primary camera takes an image, the most recent telemetry data from the Pixhawk is tabulated in a file along with the image time and name for later use by the ground station software. The image is fed to a custom version of OpenCV image processing software running on the flight computer. OpenCV begins running blob detection algorithms to determine whether there are any items of interest in the frame. If an item of interest is identified, the coordinates of the image within the frame are recorded in the image telemetry file. The flight computer then requests the corresponding image file from the secondary camera via WiFi, and transmits the both the image and the most recent version of the image telemetry file to the ground station via the payload data link. This system of selective transmission decreases the load on the payload data link and the flight computer. Figure 3. is a diagram explaining the basic functions of the image gathering system. The payload data link is extremely important for mission success. Tests revealed that the average image size from the secondary camera could reach 10 Mb per frame and that the system would be unlikely to take more than 2 frames per second in most flight conditions. For this reason, the minimum acceptable data transfer rate was set to 20 Mbps in case of system failures that requires every image to be transmitted. A Ubiquiti Rocket M5 mounted on the Sky Tractor communicates with a Ubiquiti Nanostation M5 mounted on the ground station based antenna tracker. This system is rated for 24 Mbps with accurate antenna orientation. The Rocket M5 is linked to the flight computer via ethernet and is powered from the payload battery. The Ubiquiti Nanostation is connected to the ground station image processing computer via the ground station router. Third party tests have shown that data rates can drop to 6 Mbps during suboptimal aircraft

13 orientation at long range. The selective image transmission successfully reduces the amount of transmissible data that the slower transmission rates have produced negligible effects during testing. If the connection is lost, the flight computer ques the files needing to be sent and resumes transmission upon reconnection to the ground station. It is expected a lapse in connectivity will not be a critical failure. Figure 4. shows a comprehensive diagram of the integrated payload systems. Ground Control Station The ground station was ultimately designed to be operated by 2 different team members but can be managed by a single person, if necessary. The Mission Control operator controls the parameters of the mission via the Mission Planner software as well as monitors telemetry data for errors or failures that represent a safety risk. This operator is key to mission success and safety. The second operator controls the Image Processing Station. This operator monitors the autonomous image recognition and reviews the data output prior to submitting the images via the interoperability system. During test flights and mission practice, the Image Processing operator is responsible for maintaining all checklists and and running tests relating to image acquisition, transition, and processing. The third member of the ground team is the safety pilot. The safety pilot is responsible for the aircraft at all times while on the ground and in the air. During missions, this team member is constantly maintaining visual contact with the aircraft while listening for audible cues from the Mission Control operator so that manual action and control can be used in case of safety risk. While the aircraft is on the ground, the safety pilot ensures that preflight checklists area followed, the aircraft is working properly, and ensures that no other members of the ground crew are presenting a safety risk to themselves or the aircraft. Interoperability system All software that generates an output (such as telemetry and image processing) has been designed to operate with the published software associated with the interoperability system. Custom software running on the image processing computer creates an interface that automatically sorts data from the image processing software into the necessary format for the

14 interoperability system. The system does not automatically submit the target and the image until the operator checks the system output and gives the program a green light. Using MAVLink, the Mission Control station computer also updates telemetry data for the judges. This function uses the intero_cli.py command to regularly forward MAVLink messages to the interoperability server Mission Planning Before any flight begins there will be a list of checks to go through to make sure everything on the aircraft is working properly. To start the preflight checks, team members check to make sure all the components on the aircraft are safely secure to the aircraft itself. The next step will being going through all the electrical components and making sure that there are properly connected to each other. Then, all the mechanical components, such as the propeller and gimbal, are checked for proper function. The final step is to check wireless communications. Telemetry and payload data streams are checked for refresh rate and proper connectivity. The safety pilot will perform a range check via the built in function on the Futaba 2.4Ghz transmitter. Only once all components have been proved to be functioning properly, will the engine be started and the mission be allowed to begin Air Delivery As specified in the rules, the aircraft is designed to drop an 8oz water bottle as closely to a target as possible. The drop is triggered by the Pixhawk autopilot and is performed by a small pin mechanism actuated by a servo on the bottom of the aircraft. Because the bottle must retain 80% of the water, it must be slowed down upon its decent. This is performed by a parachute contained in a small plastic capsule. One end of the capsule is attached to the aircraft and the other to the water bottle. When the bottle is released by the servo, the weight pulls the capsule apart, allowing the parachute to open up. This method of delivery is also beneficial in that it slows the forward speed of the bottle immensely, to the point where wind will be the only source of forward velocity within moments of release. To account for wind, the team will perform several test drops, tabulate the results, and in future missions, will adjust the coordinates at which the bottle is dropped accordingly. 3 Test and Evaluation Results 3.1 Autopilot Tests Early in the testing process, a test aircraft with similar flight characteristics to the Sky Tractor was used for autopilot tests. This was to ensure that we would not lose our best airframe while doing experimental testing with the autopilot. To determine waypoint accuracy, flight plans with specific waypoints were set up on a practice field. The telemetry data was observed and the closest distance to the waypoint was recorded. Flight conditions during tests were recorded with specific attention paid to wind speed. Autonomous takeoffs and landings were also tested for accuracy and safety with different weather conditions and sensor arrays. Table 5 elaborates on the results of flight mechanics testing

15 Wind speed Wind speed: 0 mph Wind speed: 15 mph Sensor Load Avg. distance from target (waypoints) Avg. transition distance from takeoff to waypoint seeking Avg. distance from landing target GPS only GPS, airspeed, range finder GPS only 27 ft 32 ft GPS, airspeed, range finder 126 ft 72 ft 110 ft 68 ft 42 ft 22 ft 55 ft 32 ft Table 5. Most waypoint testing was completed at our normal flying field, which is of relatively small size compared to the competition area. A likely source of error is that the boundaries we placed on the flight controller (flying field safe area) were very close to many of the waypoints. This meant that the Sky Tractor would often have to turn sharply after completing a waypoint to avoid going outside of the boundaries. Similarly, the aircraft was rarely able to follow a straight path from waypoint to waypoint. The team suspects that the waypoint accuracy would be lower if the Sky Tractor had a larger field within which to fly. 3.2 Camera Testing After purchasing the Sony Nex 5T and the Raspberry Pi V2 8MP cameras, extensive testing was conducted to determine whether the real-world images gathered would meet the expectations of the research. The team elected to create several targets similar to those that would be encountered in the competition to use for testing. Images were taken by each camera from varying distances away from the target to simulate image gathering from the aircraft at different altitudes. Figures 5-6 show examples from the Sony Nex 5T. Fig Raw image from 250ft away As shown in figure X, using the Nex 5T at a distance of 250ft reveals an image with clearly identifiable features. While the calculations proved that, at 250ft, the Nex 5T image should be displaying the target at 0.29 inches per pixel, testing showed the true results to be 0.35 inches per pixel. Even though this is lower resolution than calculated, further tests show that the image

16 recognition software is capable of recognizing the characteristics of the target when placed against a monochrome background, such as grass. Figures 7-8. Raw RPi 8MP camera from 150ft and 200ft Figures Cropped RPi 8MP camera images from 150 ft and 200 ft Figures 7-10 show testing of the Raspberry Pi V2 8MP camera.please note that saving this document as a.pdf severely decreases the image quality. All images were taken using a Raspberry Pi 3 in an identical configuration as will be on the aircraft, having no display or user inputs. Each image was taken by an automated Python script utilizing the robust Picamera library. The script would take an image at preset intervals and que them for processing by the OpenCV program, just as will be done on the aircraft during missions. With the stock lens, the images exceeded expectations. The targets are easily distinguishable from the background, even in cloudy, low light conditions. As expected, the targets are not clear enough for the image recognition software to determine the specific characteristics of each target, but are clear enough that blob and contour detection algorithms are successful. At the time of writing, further tests are being conducted with a lens of longer focal length. Calculations show that with an 8mm focal length lens, the images will have a resolution of 0.5 inches per pixel at 300ft. Further testing will be conducted to determine if this resolution is good enough for the image recognition software to determine all target characteristics. If testing shows this theory to be true, then the two camera system will likely be abandoned, switching to the RPi V2 8MP camera, exclusively

17 3.3 Wireless Communications With the exception of the image transmission systems, all other wireless transmissions have been range tested. The safety pilot radio, Futaba 14SG, has been range tested to a distance of 1.5 miles in an urban environment with significant frequency usage by other devices. This distance is deemed more than safe for use. The telemetry radio and antenna tracker has been tested at a distance of 1 mile with minimal packets dropped. This test was done at ground level with several trees between the transmitter and receiver, leading to the belief that the range will be much further when line of sight is maintained in the air. The backup analog video signal has been tested at a range of 1 mile. This test was completed by mounting the video transmitter and a camera on a multirotor (with the safety pilot below and watching closely) while the receiver was driven a mile away. During most orientations, the video remained free of any unusual interference. While the specific hardware that will be used for the image transmission during the 2017 competition has not been tested, extensive testing with an older Ubiquiti Bullet M5 has produced ranges of 2 miles line of sight with a download rate of 10Mbps. It was this testing in part that pushed the team to upgrade to the Rocket M5 and Ubiquiti Nanostation. At the time of writing, replacement of the old Ubiquiti system is in progress, with range testing to follow. The hardware changes are not expected to be an issue due to the team s familiarity and heavy usage of Ubiquiti systems in other projects. 3.4 Image Processing OpenCV was a clear choice for image processing software due to the team s experience with it in other projects, a multitude of tutorials, and the availability of comprehensive documentation. Thus far, the team has installed OpenCV on the Raspberry Pi and has written the supporting Python scripts that interface with the camera scripts. Very basic tests show the software to be working, but further testing is needed to ensure that targets are properly recognized and tagged. Figures Example images collected for testing Figures show examples of target images that the team has collected to use for testing the image processing software on both computers. At the time of writing, the team has a battery of tests planned for the software running on the flight computer as well as the ground station computer. The team expects these tests to be completed by late April, to be followed by full scale mission tests. With the team s familiarity and experience with similar software applications, it is fully expected that the system will be completely functional by early May

18 3.5 Air Drop Testing Although the mechanism for the airdrop has been mounted on the airplane and the components have been fabricated, no full testing of the system has yet been completed. The team has two tests planned. One test will drop the bottle and parachute from a stationary multirotor with a known wind speed to determine how far the bottle will drift. After finding the drift rate in various wind conditions, the results will be tabulated for further use. The second test will be conducted in negligible wind conditions. The bottle and parachute will be released from the aircraft while at cruise speed to determine how far forward the bottle will travel after release. This data combined with the tabulated drift data will be used to determine where the bottle should be dropped such that it will land on the target during missions. 3.6 Mission Practice Throughout the academic year, the team has practiced simulated competition missions. These tests were key in each member learning their roles, conducting various hardware tests, teaching backup safety pilots to fly the aircraft, and practicing good safety habits. If a system was not functional during practices (many were still being developed), the procedures were talked through to ensure team understanding. At the time of writing, further practices are scheduled to be conducted on a weekly basis to ensure that all systems and team members are functioning as expected. 4 Safety Considerations and Approach 4.1 Developmental Risks & Mitigation The Mizzou UAV team is dedicated to the safety of its members and others in the community. Glaring lapses in safety are obvious in the journal papers submitted by the team's predecessors. For the 2017 competition, special care was taken to perform comprehensive risk analysis, develop standard operating procedures (SOPs), and contingencies plans or mitigation methods for each risk. Throughout testing and development, points of improvement were noted for future competition years. 4.2 Operational Risks & Mitigation The greatest risk that was identified by the team is the potential loss of electrical power to the payload. Because the Sky Tractor uses a gasoline engine with a throttle actuated by a servo, a loss of power to the payload and flight electronics would result in an uncontrollable aircraft with the throttle still open. To mitigate this risk, an emergency cutoff relay for the ignition switch was installed that can be operated via a physical switch on the body of the aircraft or by an auxiliary channel on the receiver (controlled by the safety pilot). To ensure that the safety pilot can kill the engine at any time, a backup battery powers the Futaba receiver. Since the Pixhawk is wired to route signals from the input to the outputs even without power, the engine can always be shut down by the safety pilot. Tests and practices have been conducted to ensure that all members of the team are aware of how to safely disarm the aircraft. The Pixhawk autopilot has been configured with specific failsafes, as required by the competition rules. After 30 seconds of communication loss, the autopilot has been programmed to return to launch point. One of the first steps after powering on the aircraft is for the team to

19 ensure that the home point has been set to the correct location, ensuring that the aircraft will not fly away upon failsafe. The second level failsafe will trigger after 3 minutes of communication loss, causing the aircraft to immediately cut engine power and apply full down elevator and right rudder. While this would cause a devastating crash, it will ensure that no damage is caused to persons or property since the aircraft will not fly away from the mission area. 4.3 Mission Risks & Mitigation As mentioned in our Programmatic Risks, injury of a team member would be harmful to the member and the team as a whole. To prevent this, procedural safety plans were put into place. One example is the procedure for starting the aircraft engine. Only the safety pilot may hold the manual transmitter and is allowed in front of the aircraft when the engine is starting or running. A flight line is established at each practice across which no bystanders or team members are allowed. No members are allowed within the mission boundary while the aircraft is in the air and all observers must be accounted for prior to beginning a mission. 4.4 Cyber Security UAVs are currently used for many sensitive procedures, including surveillance, reconnaissance, offensive roles, scientific, commercial, et cetera. Security measures must be taken to keep not just the UAV, but the ground control station and the communications link secure; that is, the entire UAS must be secured. UAVs and ground control stations are vulnerable to software attacks; communications are vulnerable to infiltration that will lead the security threat to directly attack the UAV or ground station. UAV The UAV must be protected with encryption and authentication measures between systems on the vehicle. Critical systems can be placed in conductive cages to protect against electromagnetic pulses. Ground Control Every system at ground control should be encrypted and require authentication. This is relatively easy to do, and improves security a great deal. All exposure to external networks must be eliminated. Firewalls must be set up, and network segmentation implemented Communications Link Of course, the communications link must be encrypted and require authentication. It would also be useful to use some sort of frequency-hopping measures to scatter the radio signals and make interception more difficult for another party. 5 Conclusion Over the past year, our team has worked hard to develop a competitive UAV and supporting systems. Even though the team operated with a very constrained budget and had no information and few components remaining from previous years, we believe we have accomplished the task we set out to complete. Innovations were made with 3D printed parts, excellent safety procedures, and code optimizations. With numerous test flights, component, and system tests completed, the team is confident that it can successfully complete the mission objects during the 2017 Student Unmanned Aerial Systems contest