University of Maryland Maryland UAS Team AUVSI 2017 Competition Journal Paper. University of Maryland Maryland UAS Team Page: 1

Transcription

1 University of Maryland Maryland UAS Team AUVSI 2017 Competition Journal Paper University of Maryland Maryland UAS Team Page: 1

2 Table of Contents SYSTEMS ENGINEERING APPROACH MISSION REQUIREMENTS ANALYSIS 3 DESIGN RATIONALE 3 PROGRAMMATIC RISKS AND MITIGATION METHODS 4 SYSTEM DESIGN AIRCRAFT 4 AUTOPILOT AND GCS SOFTWARE 6 OBSTACLE AVOIDANCE 7 IMAGING SYSTEM 8 OBJECT DETECTION, CLASSIFICATION, LOCALIZATION 9 COMMUNICATIONS 11 AIR DELIVERY 12 CYBER SECURITY 12 TEST AND EVALUATION PLAN DEVELOPMENTAL TESTING 13 INDIVIDUAL COMPONENT TESTING 13 MISSION TESTING PLAN 15 SAFETY, RISK, & MITIGATION DEVELOPMENTAL RISKS & MITIGATION 16 MISSION RISKS & MITIGATION 16 OPERATIONAL RISK & MITIGATIONS 16 University of Maryland Maryland UAS Team Page: 2

3 Systems Engineering Approach Mission Requirements Analysis The systematic approach the Maryland UAS team took to design our unmanned aerial vehicle can be divided into two parts: (1) understanding competition requirements and (2) designing, building, and testing an unmanned aerial system capable of meeting these constraints. The Maryland UAS team had to first focus on the changes in competition requirements and mission tasks to analyse what systems needed to be altered or added to allow the vehicle to successfully generate the maximum number of points in the competition. The design process was divided amongst four sub-teams: Flight systems (previously autopilot and mechanical), communication systems, imaging, and obstacle avoidance systems. The team implemented a continual feedback loop of adjusting competition mission goals based on team progress and timeline. The team s leadership continually assessed what could actually be accomplished based on competition timeline and sub-team progress and interdependencies. Once in the construction and testing phases, internal timelines were constructed based on safety. It was crucial that each part of the system was safely constructed, inspected, and tested. The team put safety in the forefront of construction, inspection, and testing by ensuring that all systems met competition safety requirements. Design Rationale This year s system was built with the intention of completing autonomous takeoff, landing, and navigation, as well as obstacle avoidance, air delivery, actionable image capture, transmission, and object detection. Starting from these goals, the team assessed its current position in terms of available assets, time, money, manpower, and skills in order to make design decisions. The team had a good starting point in the system last used in the 2015 competition. Unfortunately due to a variety of factors the team did not fly in the 2016 competition, so this was the most recent version we had to expand from. Some changes were made in 2016, and these will be discussed along with changes made this year. Primarily because of budget restrictions it was decided that we would re-use the airframe, power system, and camera from the 2015 system, as these are big ticket items that would have cost too much to replace with different components. With those primary components decided upon, the team reworked the rest of the system around them and the new requirements for Several large changes were made to the setup of both the vehicle and ground station. To create more space inside the UAV for the new payload drop bay, we combined the autopilot and imaging computer into a single unit using the Navio 2 autopilot mounted on a raspberry pi single board computer. This unit was then relocated and stacked with other equipment in order to create even more room while moving critical components toward the front of the UAV where they could be easily accessed for maintenance. In order to complete the off axis target, a single axis servo gimbal was designed into the back of the aircraft. This gimbal rotates the camera on the roll axis to allow imaging of the off axis target while remaining within the flight boundary. Because the UAV was already operating near max weight, adding new components such as the gimbal required us to reduce weight elsewhere. One method used to accomplish this was stripping the ubiquity Bullet University of Maryland Maryland UAS Team Page: 3

4 onboard the plane down to its circuit board to eliminate the weight of its casing and connectors, and installing a lighter antenna that is also better suited to our particular application. Changing the weight of components also required changing their locations in order to preserve the correct center of gravity location. Because the antenna on the vehicle was changed to reduce weight and give better performance, a high dbi directional antenna of matching polarization was procured for the ground station, mounted on a servo pan/tilt gimbal, and the old pixhawk autopilot was reused to control the gimbal with the ArduTracker software. On the software development side of the team, the imagery ground control team is currently experimenting with two methods for autonomous target detection which will be discussed later in the report. The team is also planning to complete the classification manually for redundancy. Programmatic Risks and Mitigation Methods Based on the feedback received at the 2015 competition, the team has continued to use the simplified risk management strategy introduced in our previous paper. We divided risks into two categories. The first category was showstoppers. These were risks that had a reasonable chance of preventing completion of a mission task or worse. Any showstopper was mitigated immediately before any further flight-testing. The next category was projects. These were issues that would not prevent flight, but would make it easier to complete existing tasks or complete additional ones. Further discussion of the team s risk management strategies can be found in the Safety, Risks and Mitigations section. System Design Aircraft The RMRC (Ready Made RC) Anaconda was chosen due to its simplicity in setup and the built-in capability to carry a variety of payload items, such as FPV and belly-mounted cameras. Since the airframe was purchased as an Almost Ready to Fly (ARF) PNP kit, it only required the team to set up the power system and chosen payloads, reducing the amount of time necessary for setup and increasing the amount of time the team had to conduct test flights. Competition requires that the UAS be able to fly for extended periods of time while carrying relatively large payloads to take images and complete other tasks. The Anaconda airframe meets these requirements. Modifications to the airframe include openings cut into the floor of the fuselage for the payload bay, cameras, antennas, and other sensors. Some of these modifications are still being worked out, so some sections do not have photographs of the modifications, but describe what we currently plan on attempting. These modifications will be examined in further detail in the system overview. University of Maryland Maryland UAS Team Page: 4

5 Overview of electronics aboard aircraft. Airframe specifications: Wingspan in. Wing Area in. 2 Length Flying Weight Propeller Servos Battery Motor ESC 55.5 in. 10lbs APC 15x4E 3x30g, 2x17g, 2x16.44g metal gear digital 2x Li-Po 4s 5100 mah RMRC Tiger Motor Brushless Outrunner AT3520-5, 800 kv RMRC Tiger Motor 80A ESC with switch mode BEC and 10A Castle Creations BEC University of Maryland Maryland UAS Team Page: 5

6 Autopilot and GCS Software The autopilot in the plane is centered around the Navio 2 flight controller. This system was chosen for its ability to fully autonomously control the vehicle through the ArduPlane flight stack. This year we switched from the Pixhawk autopilot system to the Navio 2 system. The Navio 2 runs the exact same flight stack code as the Pixhawk so integration is almost seamless. The new system provides better processing power, connectivity, size, and weight over the previous Pixhawk system. It effectively combines the capabilities of a raspberry pi computer and pixhawk autopilot into a single lighter, smaller package. Navio 2 board mounted on a Raspberry Pi 3B computer Mission Planner, the ground control software we have chosen to use, is also an open source platform that is free. Those two factors, as well as our team members familiarity with the program, were the primary reasons that this program was chosen. With the open source nature of the program, we felt that Mission Planner would be a much more long-term system to maintain since we would be able to continuously update the program as the competition evolves. The system connects with numerous external systems to control the vehicle, including GPS, airspeed sensor, gyroscope, RTK GPS, compass, accelerometer, magnetometer, current sensor, and barometer. These sensors allow the plane know exactly where it is and its dynamics, allowing it to execute missions reliably and safely. The Navio 2 s flight stack is Arduplane Arduplane has the capabilities to replan the plane s path while it is in the air. This is not only crucial for the waypoint navigation and obstacle avoidance tasks, but also adds another layer of control to the plane, making it safer to fly. University of Maryland Maryland UAS Team Page: 6

7 Obstacle Avoidance One of our goals this year was to accomplish the obstacle avoidance mission task. In order to do this we implemented an obstacle navigation algorithm which is capable of traversing obstacles in a field. The algorithm is version of D*lite which was rewritten in C. The algorithm outputs a dense set of nodes, which is then put through another algorithm that converts the path in a smaller set of waypoints. The algorithm refines the set of node by eliminating redundant nodes so the waypoints that are uploaded are a set of points that define the path to the goal. The refined set of waypoints are then uploaded to the autopilot. While flying through the nodes the autopilot is constantly checking for possible collisions with objects or changes of velocities of the moving obstacles. If it detects the current path will collide with a stationary or moving obstacle it will rerun the path planning algorithm to get a new set of waypoints. A path output from the algorithm over a simplified field and the refined set of waypoints that would be uploaded the vehicle. In order to react to the moving obstacles, we plan on modeling the moving objects as static objects within our algorithm. The data from the interoperability server is read and interpreted to obtain the trajectory of the obstacles. Then the algorithm will interpret the moving object s velocity to define the object as a stationary object at the potential collision point. This redefined stationary obstacle can be read by the path planning algorithm which will use this data to create a path that can avoid the moving obstacles. The algorithm we used, D*lite, was chosen for its quick computational time and node output. The algorithm creates a D grid space between the start and goal and marks any node in the grid that the vehicle is not allowed to travel to, be it an obstacle or flight restricted zone. The algorithm is an incremental heuristic planner, meaning it traverses the node space by repeatedly calculating the cost and value of moving to each node around it to determine the path to take. The fast computational time allows the vehicle to respond quickly to the moving obstacles. This system is still under development as of the time of writing this paper, so the results it gives during competition may vary from what we expect. University of Maryland Maryland UAS Team Page: 7

8 Imaging System The camera chosen for our system is the Nikon J4 mirrorless DSLR with an 18.5mm fixed lens. This camera was the final choice due to its lightweight build, overall small size, and ability to exchange lenses for optimal image capturing. The team wanted a camera that took relatively high-quality images to be able to accomplish autonomous image recognition tasks as well as being able to zoom in on the image without losing a large amount of resolution. The team also wanted a camera that had a manual mode since autofocusing during flight would result in a delay in taking pictures, which could potentially lead to missed targets. The lens was picked because of its fixed focal length so that the camera would not try and auto-focus when taking a capture. Gphoto2 is a powerful command line interface (CLI) tool that allows remote control of a camera tethered to the system running it. Using this interface allows the team to write scripts to control the operation of the camera. These scripts are run from a Navio 2. The Navio, which also handles navigation tasks, runs a modified version of Ardupilot, or more specifically, arduplane. When Mission Planner directs the Navio (and arduplane) to capture a picture, a bash script is called that takes a picture via Gphoto on the Nikon. This script is utilized to capture a picture map of the field with overlap as defined in Mission Planner flight plan search area parameters. Gphoto2 also provides us with the ability to not only control the image capture but also download the images from the camera to the Navio 2 while in flight. These images are then placed into a folder, which is synced with a folder on the ground control station using the SSHFS command to mount the Navio picture folder to the ground station s folder. In order to use the SSHFS mounting command, a public/private key exchange method was implemented using RSA encryption. The keys were created using ssh-keygen and secure copying over the public key to the Navio. Once the keys were in place, a mounting point on the host machine could then be created using SSHFS. At this point, a simple script which uses the sudo -s command to become root can access the pictures taken on the Navio for a matlab script to then take those pictures and do the necessary image processing. There are other programs that provide a similar functionality, however they do not make use of a CLI, creating difficulties when trying to run it while connected to the Navio via a SSH connection. The imaging system operates on a local area network, powered by a Netgear Nighthawk R700 Router, as well as a LAN between the computers at the ground control station.. The LAN allows for all three ground control station computers to quickly images and data between each other for seamless operation. In order to extend the range of our Wi-Fi capabilities beyond those provided by the Nighthawk router, two Ubiquiti 5GHz Bullets were purchased. The Bullet is rated for 100+Mbps over a distance up to approximately 50km, depending on the antenna. To save weight and allow for the installation of a different antenna, the bullet main circuit board was removed from its weatherproof plastic housing, and the large heavy antenna connector de-soldered from the from the front of the board. A much lighter connector that interfaces with VAS GHz Cloverleaf Whip Antenna (RHCP) we decided to use was the soldered back on. This antenna is more suited for aerial applications as it provides equal signal coverage to a 360-degree sphere, instead of a cone or plane as more common directional and linear antennas provide. Connected to the Ubiquity bullet on the plane via an Ethernet cable is a Raspberry Pi 3 single-board computer that controls the camera and data link. The Raspberry Pi 3 runs a basic Debian operating system as well as the gphoto2 command line interface, which allows the ground control station to remotely operate the camera from either a command line script or through a Secure Shell (SSH) connection to the ground control station.the camera that was chosen for the system was the Nikon 1 J4 mirror-less DSLR camera. This camera takes 18.4MP images, and the body weighs only 6.8oz, compared to other DSLR s at a similar quality coming in at 18oz before a lens. Along with this body, the 1NIKKOR 18.5mm f/1.8 lens was purchased to replace the default 10-30mm adjustable University of Maryland Maryland UAS Team Page: 8

9 lens. This lens has a 47-degree field of view, allowing us to see a large portion of the ground below the plane without distortion. Once the camera captures the photos, they are stored in a folder which is mounted to the ground station via the SSHFS command. This ensures that when our photos are taken, they are immediately synced to the ground control station over the Wi-Fi connection for immediate processing and classification. Given the 47 degree field of view of the camera lens, and the 5232 pixel length of that axis of the image, we can compute that the pixel size is related to altitude by the formula: pixel_side_length=((tan(47/2)*altitude)*2)/5232 For an altitude of 150ft (slightly above minimum altitude), this results in a pixel side length of feet, or 0.30 inches, enough to resolve the 1-inch wide lettering on the targets, the smallest feature the camera needs to resolve. Object Detection, Classification, Localization The imaging team is currently developing two independent autonomous detection algorithms. The first one involves taking the field images discussed previously and running a MATLAB k-means clustering algorithm to separate the shape, letter, and background, where the background is the first and largest cluster, the shape is the second largest cluster, and the character is the third largest, as shown below. The shape and letter clusters are saved as new, separate images. These images are then loaded into another program which identifies the color by removing the null pixels then averaging the RGB values for the remaining pixels and then classifying the color based upon preset threshold values. While this method may not be the most reliable due to environmental effects such as lighting, it has not proven to be a problem thus far. Another method under consideration includes classifying the color based upon hue value which is more resilient to changes in lighting and saturation. We plan to do further testing and refinement of this method once it is fully integrated into the overall system. K-means clustering algorithm output. Next, the images are loaded into a shape identification program based upon the number and position of edges, the results are shown below. The original image is then copied, and the copied file is cropped to just outside the identified shape, and saved according to the rules. This program has parts written in both MATLAB and python programming languages in an effort to move some specific processing tasks over to python to decrease the time University of Maryland Maryland UAS Team Page: 9

10 needed to classify images. These results are then compiled into a json file and saved into a folder with the cropped image to be uploaded just before landing. Shape detection algorithm output. The second method involves running a MATLAB histogram of oriented gradients function and a Hough circle transform. The oriented gradients would dissect the image into smaller regions, orient the image in different orientations and correlate the gradients to a line to determine where an edge of an object lies. This is another form of edge detection and will be used as opposed to the k-clustering to determine where the targets are located. After the targets have been located, the image will be cropped and then the previously described functions will be run to classify the object where a color filter will be applied before running the shape identification function. The modular approach to the classification was taken to allow for parallel processes, both in terms of developing the code and running the classification functions, as well as allowing the process to be easily modified or replaced based upon new methods or improved techniques for identifying and classifying images. The team also plans to manually characterize the targets and emerging target to maximize scoring possibilities. This will be done by taking the images captured autonomously by the aircraft, visually identifying and cropping the targets, and submitting the cropped image and json file (containing the target characteristics and locations) to the interoperability server. University of Maryland Maryland UAS Team Page: 10

11 Communications The imagery system uses a 5.8GHz b/g/n Wi-Fi network between the Navio 2 and GCS laptop using a Netgear router and two Ubiquiti Bullets. This link is secured using WPA2 security to ensure that it meets the competition standards. The autopilot communicates on a 915MHZ link with one of the ground control station computers. The RC Controller operates at the 2.4GHz band. The controller uses the DSMX 2.4GHz protocol to communicate with the AR8000 receiver and avoid radio interference from other transmitters to maintain full control of the aircraft at all times. The ground control computers also have access to a private ethernet-based network that allows them to share image data when necessary. As previously stated, we are using 5GHz Ubiquiti Bullets to communicate between the aircraft and the ground station as opposed to the 2.4GHz Ubiquiti Bullets and Nano-stations used when we last competed 2 years ago. This switch was also made in order to free up the 2.4ghz frequency range so that the 2.4GHz RC control link would have fewer signals competing for bandwidth. We also changed the antenna used on the aircraft from an omnidirectional stick antenna to an omnidirectional right-hand circular polarized cloverleaf antenna that has fewer dead zones. Bullet Connector modification Moving from 2.4 to 5.8GHz will decrease the usable range, so in order to ensure a reliable connection, the ground based communications radio has changed as well. A matching 5.8GHz Bullet is mounted on a servo operated pan/tilt gimbal along with a 17dBi helical right hand polarized directional antenna. The ground based directional antenna is continuously pointed at the aircraft using a spare Pixhawk autopilot running the ArduTracker antenna tracking code to control the servo gimbal. The link from the Bullet onboard the aircraft to the ground Bullet is secured via a WPS2 encryption key as is the router that the ground Bullet piggybacks off of. Connected to this network, the Navio2 pi then transmits competition data back to the base computer via the bullet connection as prompted by the script operator on mission planner. This data is then uploaded to the AUVSI site through the username testuser and the password testpass. This network is also used for the automatic transfer of image data taken in flight to the ground station for analysis (that process is described in detail on page 9). University of Maryland Maryland UAS Team Page: 11

12 Network Diagram Air Delivery The air delivery system consists of a payload bay on the vehicle with a servo actuated payload release and bottom doors. The payload consists of the required 8-oz water bottle, as well as a small drag parachute and foam bottom cushion. The payload bay allows the payload to be carried internally to reduce drag on the aircraft, and the parachute and foam cushion allow the water bottle to fall as fast as possible without breaking when it hits the ground. Maximizing this speed means wind and inaccuracy in drop timing will have as minimal an effect as possible on drop accuracy. Additionally, because the parachute will stabilize the bottle as it falls, the foam can be very thick on the bottom and thinner on the sides because the bottle is guaranteed to hit first in that location. The drop itself is hard-programmed into the mission as a flight event. The lead distance from the drop will be initially analytically and then later experimentally found and verified. Cyber Security All wireless signals used by the team employ encryption to secure the system against any outside influence. The RC radio uses unique id s and spread spectrum frequency hopping to secure its connection, the RFD900 Plus telemetry radios use hardware AES encryption, and the 5.8GHz wifi network uses a WPS2 encryption for protection. In the event that the team has reason to believe a cyber attack is taking place against the UAS, the UAV will be immediately brought back under manual control, and all systems immediately shut down. University of Maryland Maryland UAS Team Page: 12

13 Test & Evaluation Plan Developmental Testing All wiring, electronics and structural elements of the aircraft were tested to verify basic operation and safety as the vehicle was assembled. Batteries and BEC s have been checked to make sure they provide the correct voltage to all equipment, Wiring harnesses have been inspected for shorts and cold solder joints, servos have been checked for stripped screws and bad bearings, screws and nuts have been secured with locktite where appropriate, and the aircraft was checked to make sure it complies to manufacturer weight and balance. The only changes made to the system during this time were fixes to minor damage from shipping and assembly. Individual Component Testing Autopilot and Autonomous flight Early flight testing involved setting up the autopilot for autonomous flight. This consisted of several test flights to tune the attitude control system and altitude control system. During this time, takeoffs and landings were performed solely under manual control. After the vehicle was capable of conducting autonomous waypoint navigation, several more test flights were conducted to tune the auto-take off and landing functions. After tuning was finished, during all subsequent flights the vehicle has obtained a 100% success rate for auto takeoffs and landings under a variety of wind conditions and mission setups. We plan to continue to test as many combinations of variables as possible before competition to ensure the vehicle is more than capable. The most recent flight testing consisted of testing autonomous mid flight waypoint replanning. The vehicle was tasked to replan the current path depending on a set of variables. After a number of test the vehicle could follow an iterative flight plan that was created during the flight. Future testing of the autopilot will link the obstacle avoidance algorithm and the vehicles ability to replan routes. This testing will define a number of obstacles identical to those possible in the competition, and will test the vehicles ability to navigate around these obstacles to a set goal. On top of this, testing will include the classification of moving obstacles. We will test the feasibility of our method to define the moving targets as stationary by once again creating a mission scenario which tasks the vehicle to avoid moving targets. Imaging System The primary goals of testing the imaging system are to make sure that the images are taken precisely when needed, and that any additional code running on the raspberry pi does not risk crashing the autopilot, and that the images are of sufficient quality to allow targets to be analyzed properly. In order to verify the timing of the photos, we will command photos to be taken by the system in the lab setting. With the camera viewing a monitor displaying the time since the command was sent, we will be able to determine exactly how much lag there is in the process. We can then set this lag time in the mission planner survey grid window, and it will compensate for the delay so that the pictures are taken at the correct moment. University of Maryland Maryland UAS Team Page: 13

14 In order to verify additional code does not crash any flight-critical software, we will conduct full mission ground tests while monitoring the telemetry signals and status of the autopilot. Another function of these flight tests will be to test the the timing and resolution of the photos taken of test targets. Object detection / Classification / Localization The object detection, classification, and localization algorithms will be tested by running a set of sample photos, taken from the aircraft, of mock targets against a grass background through the different programs, one at a time in order, in order to determine the accuracy of each programs intended function. For example, a set of mock target images will be first run through the k-means cluster program. Then the output from each will be analyzed by a team member to determine if the output matched the intended output, and if any problems arose. If a problem arises, the program will be adjusted and retested. An accuracy percentage will be calculated for each iteration of the code in order to determine whether the code reliably outputs the intended result. Any results that pass the first programs test will then be fed into the next program, the color detection program. The process repeats until all programs are tested. Once each program s output provides a reliable, consistent, positive result, the entire system will be tested by calling each program successively to ensure the results match the expected output from running each program individually. The elapsed time will also be recorded to determine whether the image processing can be completed during flight. Once this has been verified, the algorithms will be integrated with the imaging system for integrated testing at the local airfield. Currently, the team has tested mostly hand-cropped images of targets against the programs due to limited access to full scale images. The k-means clustering program has a 75% accuracy of identifying the shape, character, and background. Success was determined by whether the shape and character were both correctly separated from the background and labelled correctly (the shape as the shape cluster, the character with the character cluster). One issue that arose with the k-means clustering program was the random nature of identifying cluster, where the program can be run multiple times with different results. The team is currently working on fixing this issue by rerunning the program numerous times, comparing the results, and reporting the result that occurred the most often, as the majority of the time, the correct result is outputted. The color detection program has reliably identified the correct color; however, this has not been tested thoroughly yet to include different saturations or lighting conditions. The shape identification program has also had limited tested and can report 6 shapes (triangle, square, rectangle, pentagon, star, and hexagon) correctly. A success is defined by the correct boundary and shape identification label. One problem the team encountered with the shape detection program is that it relies on edges. When a real image (as opposed to a computer generated one) is fed into the program, the edges of the target are rough and therefore the program recognizes additional edges. This is currently being addressed through a lower sensitivity, but as a result, the circle can no longer be identified correctly. The boundary for the circle is correct, but the label is not. To fix this, an alternative method is being developed to include both the number of edges as well as the position of the edges with relation to one another in order to determine the target s shape. Another option that was considered was to use a machine learning approach by training classifiers, but this was determined to be beyond the scope of this year s competition goals. The team plans to conduct further testing and refinement of all of the programs before competition. Communications Communications testing will consist of running a mock interoperability server to simulate communicating the telemetry, obstacles, image data, and flight area. In flight we will test posting telemetry and image data reliably to ensure that we send a telemetry packet at a minimum of 1 hz and the image data is successfully transmitted to be University of Maryland Maryland UAS Team Page: 14

15 considered actionable. We will call for the flight boundaries along with the obstacle data so that we can reliably get crucial mission data during the mission. These testing sessions will also test for signal strength and reliability in the 5GHz WiFi network that transfers photo data between the Navio-controlling Pi and the ground station. This will be done by transmitting large amounts of data during field tests conducted in extreme communication conditions, such as large measured distances. As mentioned before, we will use these tests to note any potential conflicts between the airborne autopilot and imaging processes. Air Delivery Testing of the payload system will consist of ground release testing to verify the system physically works, followed by air testing under very controlled conditions to ensure the payload does not hit the propellor as it exits the aircraft. This risk of a collision between the payload and propellor is the greatest safety risk posed by this system, so it will be first tested while the aircraft is at low altitude over the runway. This will allow the aircraft to be safely landed in the event that the propellor breaks as a result of this test. If prop collision does turn out to be a problem, the release mechanism can be redesigned to lower the payload below the propellor before release. Mission Testing Plan To test full mission tasks, the team plans to create our own standard objects from cut and painted plywood. We will then arrange them at the RC field we conduct tests at, and build a practice mission as close to the real competition as we can manage given the limited room available due to the RC field s own no -fly zones. By rearranging the targets, direction of takeoff and landing, order of waypoints and air drop location, we hope to find any issues the system has performing a full mission routing prior to coming to competition. If issues with any specific subsection of the mission persist, and we find we cannot fix the issue before competition, we will attempt to fly the mission without completing that subsection of the mission, providing it is not a mandatory one. Safety, Risk, & Mitigations The team did not have a formal risk evaluation and mitigation process this year. The overall process followed included risks observed or calculated by members informally, alerting relevant team members of said risk, evaluating methods of mitigating risk, and deciding upon mitigation method based on time and money necessary to mitigate risk. Some risks were unable to be mitigated based on the time available to be completed versus severity level. These risks were always a low threat level with a low frequency of occurrence. In these cases, if they were flight critical, the team noted such to appropriate staff at the test field and had backup systems available in case of a damaging landing. University of Maryland Maryland UAS Team Page: 15

16 Developmental Risks & Mitigations The team assessed that the primary risks posed by the development process were making inadequate equipment choices, such that some critical system might fail, and not having proper manual control takeover control in case a software bug occured during flight. At every stage of the development process, both of these risks were addressed by implementing redundancy in critical systems, such as power supply to the autopilot and controls, and consulting expert opinion on or over engineering structural modifications to the airframe itself. Mission Risk & Mitigations The team assessed that the primary risks posed by the mission were loss of control of the air vehicle and inadvertent payload drop. Both of these have been addressed. Any single servo on the airframe can fail and the vehicle can still be controlled and landed manually due to the inverted v-tail arrangement. As previously addressed there are redundant power sources to the autopilot and servos. In the event of the GCS transmitting erroneous commands to the vehicle, disconnecting the ground telemetry radio and/or switching to manual mode will allow the vehicle to be safely landed. If the RC radio dies, then the GCS computer can command the vehicle to come back and land. To summarize, as far as we can tell, there is no single point of failure in the system that would cause the vehicle to be uncontrollable or unrecoverable, except complete failure of the autopilot itself Operational Risks & Mitigations The team assessed that the primary risks posed by the flight operations procedures are improper assembly and/or setup of the air vehicle and ground station and miscommunication between flight members. To mitigate the risks these pose to operational safety, the team employs setup and operations checklists for the GCS equipment, aircraft, and mission. These checklists have been created in part by adapting and taking inspiration from procedures used by the UMD UAS Test site, who operate UAV s professionally and to very high operational safety standards. University of Maryland Maryland UAS Team Page: 16