Mission and Design
Systems Engineering Approach
Mission Requirements Analysis
The SUAS competition has three main sections [1]: The technical paper, the flight readiness review, and the mission demonstration. The competition is scored out of 100% in which the first two sections are worth 20% of the final score, and the final section is worth 60% of the final score. All scores are presented as their percentage of the final score.
The purpose of this portion of the document is to determine the sections of the mission demonstration on which to focus in order to maximize the competition score. The intent is to create hardware requirements for the vehicle design process. Table 1 breaks down the mission demonstration sections and highlights the aspects of the vehicle required to effectively complete those sections. Operational excellence is omitted as it is highly subjective.
Design Rationale
Prior to the start of the design process for the AUVSI SUAS competition, the UCF Robotics Club intended to create a multirotor vehicle. The aerial team deemed that a multirotor platform would provide the most utility to future club endeavors compared to other vehicle types such as fixed-wing, quad plane, helicopter, etc. This decision was made due to the nature of multirotor vehicles, notablynotably, the ability to hover, decoupled yaw, pitch, and roll control, and relatively ease of upgrade mechanically and electrically. As previously shown in Table 1, the ideal vehicle for the AUVSI SUAS competition will be onone that has high maneuverability, long range, and the ability to hover. The tradeoff is that the vehicle will not be relatively fast. The only competition element that suffers from reduced speed is the Timeline, but this portion is worth the least of the Mission Demonstration score. The team’s decision to create a multirotor vehicle and the values of the competition were well aligned, and as such a multirotor vehicle was designed for the purposes of the competition.
From the decision of creating a multirotor vehicle, preliminary research was conducted as outlined in section 1.1.1 From the preliminary research, the project budget, and preliminary mass budget were created. The budgeting process is largely ignored in this document as it was not a major contributor to the design and construction of the vehicle. From the mass budget and preliminary research, appropriate batteries, motors, and propellers were selected. With the majority of the vehicle systems determined, the vehicle frame was designed and constructed. In tandem with the physical design process, the vehicle software was begun. The first stages of software development focused on flight flight-critical items such as the flight controller implementation and basic autonomy. Further development was then done for more advanced software systems such as path planning, computer vision, etc.
Systems Design
Aircraft
Vehicle Configuration
The team began the vehicle configuration generation by creating scripts to calculate the thrust given the propeller diameter, propeller pitch, motor RPM, and vehicle speed. The intention was to create a system optimizer with these parameters and other necessary vehicle parameters as inputs in order to output vehicle performance estimates. The thrust script was based on theoretical equations [12, 14, 16, 18, 20, 21, 23] as well as empirical data from the University of Illinois at Urbana-Champaign (UIUC) Propeller Data Site [11]. During the development process of the optimizer, an online resource xcopterCalc [17], was discovered. This resource inputs multirotor parameters and outputs expected performance data. xcopterCalc boasts 9000 motors and 7 million visitors [17]. The team independently verified results using data from the UIUC Propeller Data Site as well as the beginnings of the system optimizer. Values tested in the calculator matched the UIUC data as well as the system optimizer within a reasonable degree. The decision was made that because xcopterCalc was deemed reliable, in the interest of time xcopterCalc would function as the team’s system optimizer.
It was at this time that the decision was made to utilize NCR battery chemistry. NCR cells are roughly 15% lighter per unit energy, at the cost of decreased power per unit capacity, and increased volume per unit capacity. Typical multirotor vehicles and especially racing drones require relatively high power [24] and suffer significantly from increased drag due to increased volume. The intended mission for the vehicle has a particularly enhanced range of requirements. Due to this, any battery option selected will have a required capacity on the order of 80,000 mAh. Additionally, due to the enhanced range requirements, minimizing weight is of significant concern. Since the NCR cell chemistry is lighter per unit energy, an estimated 1.2 kg can be removed from the vehicle assuming an 80,000 mAh battery at 6S. The lower power per unit capacity can be sidestepped by the shear capacity required. Additionally, the increased volume of the cells can be ignored as the planned mission for the vehicle does not require speeds such that drag is of significant concern, and the size of other components makes the battery volume not the driving factor.
A preliminary mass estimate for the vehicle was created in order to properly scale the vehicle for the required mission. Research was conducted for all components necessary for the vehicle and mass estimates for each component were tabulated. The base weight is the same as that previously defined. The mass of the UGV was assumed to be the entirety of the allotted 1.36 kg (3 lb) by the competition rules. Table 2 shows the mass estimated for the valid vehicle types (quad, hex, octo) both with and without the UGV.
Table 2: Estimated System Masses
From preliminary mass and range estimates, it was found that the vehicle would need a propeller diameter between 15 and 21 inches. It was at this time that the team decided to purchase consumer off the shelf (COTS) propellers in lieu of manufacturing custom components. Experimental data for COTS propellers is largely unavailable on both general hobbyist and propeller manufacture sites. Possible vendors of these large hobbyist propellers included Quanum, XOAR [13], and Falcon, etc. Of these vendors considered, only XOAR provided significant experimental data [23]. Performance estimates from the team's calculations, the UIUC Propeller Data Site, xcopterCalc, and XOAR all matched within a reasonable tolerance.
It was decided that the number of rotors would need to remain under 8 in order to ensure compatibility of the system with available and well characterized flight controllers. Additionally, there were concerns with power distribution, frame size, and vehicle weight, should the number of rotors exceed 8. The number of rotors was further constrained to only the even numbers in order to again ensure compatibility with the available flight controller software. Therefore, the number of rotors on the vehicle is to be 4, 6, or 8.
From this concept space, consisting of 13 motors, 10 propellers, and 3 vehicle types, there were a total of 390 potential vehicle configurations available. For each of the 3 vehicle types, a matrix was created to show a rough battery percentage required to complete the 4 mile waypoint traversal. The goal of this phase of the concept selection was to narrow the search space from 390 to some more manageable number. The quadcopter concept matrix is omitted as none of the quadcopter configurations were able to lift off within the ratings of the selected motors. Additionally, only 10 of the propellers are shown as none of the other 10 were able to lift off within the ratings of the selected motors. These matrices are shown in Tables 3, and 4.
Table 3: Hexacopter Setup Motor and Propeller Configurations
Table 4: Octocopter Set Set-Up Motor and Propeller Configurations
Within each matrix, there was an envelope of configurations that were able to complete the waypoint traversal. Most configurations suffered from excessive power required to hover, low thrust resulting in no maneuverability, excessive current required at cruising speed, or excessive power required at cruising speed. Of the initial 390 configurations, only 55 were deemed feasible.
An additional requirement was placed on the vehicle at this time to ensure than in the event of a single rotor failure the vehicle is able to continue controlled flight. With this requirement considered, only 16 configurations remained viable. All of these configurations were octocopters. The remaining configurations were ranked based on the estimated post waypoint traversal range. Six of the configurations had approximately 3 miles of post traversal range and the remaining 10 had under 2.5. This was a clear separation that narrowed the configurations available to 6.
Of the 6 remaining configurations, there were 2 propellers options: 18.5 x 6.7 and 19.5 x 7. Given that all the performance estimates are based on the preliminary mass estimate, a margin of safety should be considered in the event that the mass estimate was an underestimate. Therefore the 19.5 x 7 propeller was selected. With the 19.5 x 7 propeller selected, only 4 configurations remained with only the motor differentiating them.
The motors remaining were the 5010, 5012, 5015, and 6012. The 6012 was removed as it is significantly oversized for the propeller selected. The remaining 3 motors had performance estimates from xcopterCalc that were too similar to make a final decision upon. Therefore, the empirical data from XOAR was used as more accurate source. Ultimately, the 5010 motor was selected because it had the lowest power requirements.
Therefore, the final vehicle configuration is an octocopter with XOAR 5010 motors and XOAR 19.5” x 7 propellers. From this systems level design of the vehicle, all further vehicle properties can be determined and designed. Further CFD analysis was conducted on the propellers to confirm these thrust and power calculations, but the details of this analysis are omitted for brevity.
Materials
The materials in aerospace engineering must fit a very specific set of requirements in order to be used for the construction of aerospace parts. One of the main concerns is that the material be capable of handling the loads associated with flight while also being lightweight. This ratio is known as specific strength ratio and gives an idea of the materials ability to hold loading per density of the material. Another important factor is a high stiffness modulus, or the stiffness of the material per density. Lastly, manufacturability and resistance to corrosion direct materials choice. This leaves certain classes of composites and metals for the manufacturing of aerospace parts, such as: carbon fiber reinforced polymers (CFRP), aluminum alloys, and titanium alloys.
For this application, rigidity and weight are the two most crucial factors and will make up the selection criteria. As the preliminary research showed, carbon fiber is often chosen because it has the highest strength to weight ratio of these materials. The Table 5 [39] compares the specific tensile strength and specific tensile modulus of carbon fiber, aluminum, and titanium.
Table 5: Specific Tensile Strength/Modulus of Discussed Materials
The final decision on material for the chassis plates is to use carbon fiber with Nomex cores due to the high strength to weight ratio and rigidity of the carbon fiber. Additionally, the decision was made to utilize circular carbon fiber tubes for the vehicle arms for similar reasons.
Finite element analysis (FEA) was conducted on both the chassis plates and arms in order to ensure the structural integrity of the vehicle. The details of this analysis are omitted for brevity. Additionally, material samples of the carbon composite sandwich were testing in bending tests, and tensile tests to confirm manufacturer data and analytical calculations.
The manufacturing process of the carbon fiber was completed in two main phases, the plate manufacture and machining process. The plate manufacture was done with pre-preg and the nomex honeycomb core in an autoclave. The plates were oversized for the chassis plates for later machining. The machining process was completed by a third-party manufacturer on a CNC in a water bed for safety reasons.
Frame Design
The design of the aircraft frame was driven by the results of the aerodynamics analysis and electronics selection. The size of the chassis plates were determined as the minimum size possible while still able to package all electronics with appropriate space. Some key requirements of other structural components were derived from the team’s intent to make the aircraft easily transportable, which requires ease of disassembly due to its large size. These include the arm clamps remaining attached to the plates and in alignment when the chassis is disassembled to access the electronics, as well as the need to ensure the entire system can be taken apart with minimal tooling in less than 10 minutes. It was decided that having two plates would allow for these goals to be accomplished. The lower plate allows for mounting of hanging components, such as the UGV and camera gimbal. The majority of the electronics and the arm clamps are housed in the middle layer, between the two plates, and the top deck allows for space to mount the batteries and GPS receivers. The two plates, joined together by the arms clamps and threaded standoffs, also create a very rigid chassis that can resist the bending moments the arms are subjected to by the rotors and landing gear. The frame layout can be seen in figure 3. The fully equipped aircraft is also shown in figure 4.
The length of the arms was determined with CFD such that the increase in thrust due to propeller efficiency due to the increase in arm length is equal to the increase in weight due to the increased mass of the arm. A more detailed view of one of the arms and rotors can be seen in figure . The clamp designs for the rotor mounting plate and the landing leg mounting plate are the same. The clamp design for mounting the arm to the chassis differs. All clamps are custom machined from 6061 aluminum. Multiple clamps are used to mount each component and are spaced out so as to limit the effects of stress risers when subject to high loading, such as a rough landing or crash. Test flights have shown the ability of the current design to withstand substantial impacts without major damage. The modular design of the system also allows for easy replacement or repair of parts in the case that serious damage does occur. For example, when a landing leg fails, the weakest point is the small carbon fiber tube, which can simply be pulled out and replaced with a spare 
Flight Autonomy
Autopilot
The autopilot/flight controller for this UAV is ArduCopter 3.5 running on the BeagleBone Blue. The BeagleBone Blue was donated to us by Texas Instruments and supports 8 servo PWM outputs, has an IMU, and has serial ports for dual GPS and a telemetry radio. The BeagleBone Blue also has a USB port that allows us to connect it to the image processing computer.
Laki2 is equipped with two GPS modules with compasses included. Both GPS receivers are connected to the BeagleBone Blue, but only one of the compasses is. ArduCopter is set to blend both GPS positions together, and to use the external compass on the GPS receiver as the primary compass to reduce magnetic interference from the propulsion system.
The job of reacting to obstacles is handled by uploading waypoints to the flight controller through MAVLink, which can happen either through the telemetry radio when run on a ground station computer or from the onboard image processor through an IP over USB connection.
Flight Computer and Flight Controller
Start here
Software
Obstacle Avoidance
The competition has two main missions that require path planning to be done efficiently, the waypoint traversal, and the area search. The nature of the paths for these missions are very different: the waypoints necessitate efficiency while the area search necessitates maximum coverage. Due to these vastly different requirements, two different path planning, and obstacle avoidance, approaches have been designed.
The focus of the waypoint traversal path planning is generate as efficient a path as possible through the given waypoints, while avoiding obstacles. While an algorithm such as A* exist to determine the optimal path in a discrete environment, Ref [26], the paths generated would not be optimal for the aircraft due to the amount of sharp turns inherent in discretizing a continuous environment. Instead, the team has opted for a spline-based monte carlo method of pathfinding, Ref [27]. This was implemented by generating a spline through the given waypoints, finding an intersection with an obstacle or boundary, then iteratively improving [28] the path by semi-randomly adding intermediate waypoints to the path to guide the aircraft away from the obstacles and boundaries. This process is completed numerous times in parallel, then each path is scored based on the estimated energy consumption and time to complete the path traversal and the best path is selected. While the algorithm does not guarantee the most efficient path, the team has found that it has generally been more efficient than alternative methods. An image of the progression over iterations is shown in figure __. In this figure the orange lines represent a sample boundary, the red circles represent no fly zones, and the ‘x’ symbols represent waypoints.
The area search mission requires the maximum coverage of the given search area, including areas covered by obstacles, to guarantee that no object is missed. This led the team to develop a path planning algorithm distinct from the waypoint traversal algorithm. After researching past teams, Refs [2-10], and similar applications, Ref [25], it appeared that a lawnmower sweep would be the most simple to implement pattern on which to create initial the paths. An algorithm was developed to generate a preliminary sweeping path that runs along the longest side of the search area. This path was then run through the obstacle avoidance algorithm, which resolves obstacle intersections by traversing the edges of the obstacles and returning the shortest path. The intermediate path returned by the obstacle avoidance algorithm will then be smoothed and pushed to the flight controller as the final path. A completed sweep of a sample area is shown in figure __. In this image the blue lines represent the search area boundaries with a boolean subtraction of the no fly zones, and the black lines represent the generated path.
Object Detection, Classification, and Localization
The team's initial method of computer vision intended to heavily leverage OpenCV’s tools [29] to perform classical computer vision techniques for object classification. Due to recent advancements in widely available machine learning libraries, the classification algorithms of OpenCV were traded for the more robust and accurate Convolutional Neural Networks (CNNs), see Ref [26]. The detection algorithms to segment potential objects in the original, large image still implements more classical computer vision techniques. Additionally, due to the nature of the competition, objects will remain in view for multiple frames. The team has thus implemented a Bayesian Network [26] that scores the probability of a correct classification over multiple observations. Once the probability of a correct classification has reached some threshold, the image and related information is sent to the ground station via the high bandwidth antenna for competition submission.
In order to segment regions of interest (ROIs) in the camera images, the team have implemented ORB, see Ref [32], a keypoint detection method. Once a ROI has been created, the smaller images are passed through a CNN. The CNN has been implemented with Keras [30] using the Tensorflow-GPU [31] backend for fast training times, and to fully utilize the onboard flight computer, the Nvidia Jetson TX2. The team is simultaneously training two different networks, one for shape and shape color, the other for letter and letter color. The CNN was implemented by modifying the architecture and retraining portions of the VGG-19 network [33]. Currently, the shape and color network has reached 90% accuracy on generated images and 80% on flight test images. The team will continue to tweak and train the network with a goal of 95% accuracy.
In concurrency with the classification, the object will be localized. ROS features efficient tools for coordinate transformations given the appropriate relation matrices. The localization procedure is shown in Figure xx.xx. Errors in the localization of objects accumulate from errors in the various attitudes and position values. For this reason, high quality as well as redundant sensors have been implemented and combined with data filtering to reduce such errors.
Cyber Security
Electronic warfare is emerging as the most serious threat to UAVs today, due to the difficulty of attacking such small and numerous targets by conventional means. UAVs should have mitigations against attacks that would disrupt mission completion and against data from the UAV being stolen. As such, the systems on board Laki2 are selected and configured with best practices in mind, but is limited by the features offered by the COTS parts within. Broadly, there are 3 main classes of attacks to be considered:
GNSS disruption and spoofingCommunication link jamming and spoofing/hijackingStealing data directly from computers in the event of a crash
The most prevalent attacks seen against UAVs are GNSS disruption and spoofing, since control links are widely varied but GNSS systems all use the same limited set of protocols. GNSS spoofing can make the GNSS receiver believe it is at any position the attacker desires, which may let them manipulate the autonomous flight to land or crash the UAV. Due to the limitations of civilian GNSS receivers and engineering hours available, Laki2 has no specific defense against GNSS spoofing, but will land immediately if GNSS spoofing causes a fault in the EKF system.
The communications links for Laki2 use AES with non default passwords where available to secure the image downlink and MAVlink communications. The main limitation here is that the R/C link security is questionable at best since it is not advertised to use encryption, and frequency hopping is of limited effectiveness given modern software defined radio technology. Mitigating this would require purchasing all new radio transmitters and receivers since good security is relatively new to R/C control.
Stealing data via physical access in the event of a crash is another risk. Laki2’s computers use non-default passwords to resist login attempts, but a determined adversary could steal data by removing the memory from the image processor and using the MAVLink telemetry port to get data from the flight controller. Mitigating these risks would require extensive work to lock down the Linux operating systems on the vehicle, given that if the vehicle is recovered while still booted up the computers will by necessity have the data in memory where it could be extracted using the developer features on the TX2. A secure MAVLink would also have to be created to protect the serial link between the flight controller and radio from hijacking to extract configuration and GPS history data.
Other Electronics
Imaging Systems
The driving forces behind selecting imaging system components were maximizing the width of the field of view and keeping weight to a minimum. The frame width is important since it determines how many passes must be made over the search area, while weight is important to keeping propulsion and power requirements reasonable. Our review of past designs showed that many teams utilize point-and-shoot cameras like the Sony A6000, which offer excellent resolution and good optics with low integration requirements. Our reason for rejecting this approach was that point-and-shoots have poor support for getting image data off in real time, and are rather heavy due to the design for human operation and another battery. Cameras operating over USB3 and gigabit ethernet were considered, but our final choice was made by our decision to use an NVIDIA Jetson TX2 on board. The TX2 has support for CSI-2 cameras, and e-cam systems offers a developer kit which connects 3 13MP color cameras to the TX2 with CSI-2. The 3 13MP cameras offer the widest image available when set side-by-side, even beating a 41MP camera offered by AUVIDEA. The drawback of this system is that the sensor size is small, which requires high-quality optics to make good use of the resolution, and the cameras must be connected to the TX2 through cables which are very difficult to obtain and are of limited length. After checking that the mechanical design would permit the cable length to reach the cameras underneath the drone, and finding suitable lenses for our desired altitude, we settled on these cameras as the best available for the area search task. For the purpose of computing frame width, it is assumed that 10% of each camera’s frame will be overlapped and is only counted once. The flight altitude and lenses were initially selected around a pixel ground size of approximately 1 inch in line with other teams’ designs, but after testing we found this to be quite optimistic and adjusted our flight level based on experiments with test targets of varying sizes at the opposite end of our lab.
Gimbal Systems
A GoolRC 2D gimbal is used to provide vibration protection and smoother capture. The inclusion of a gimbal is imperative for camera direction and higher quality image processing. Weight minimization was the primary factor taken into consideration for gimbal selection.
Communication Systems
Communication systems are comprised of multiple data links as outlined in the figure above. The information transmitted and associated hardware are denoted by numerical values.
Unmanned Ground Vehicle
Air Drop
The UGV required some form of braking during the descent. If simply dropped from an altitude of 100’ (and air drag is assumed to be minimal), the vehicle will land at a speed of roughly 24.5 m/s (~55 mph). The forces exerted on the vehicle landing at that speed would be far greater than those acceptable by the structure.
Possible descent mechanisms considered were inspired by NASA Mars Rover missions and consisted of a parachute, sky crane, and cushioning device, see Refs [35-37]. A parachute for an equivalently sized model rocket would be on the order of 24 inches in diameter, see Ref [38]. The sky crane consists of a tether with some controllable braking device. A cushioning device would inflate either during the drop or near the ground to absorb the energy of impact.
Ultimately the decision was made to implement the sky crane. It has been assumed that the landing speed must be low in order to ensure a ‘gentle’ drop by the competition judges. The cushioning device was immediately ruled out due to this assumption. The parachute was ultimately ruled out due to the concern of the sensitivity to wind.
The sky crane will be implemented with a fishing line as the tether. The line will be stationary on the drone side and reeled on a spool on the UGV side. The spool will be in line with a BLDC motor with its 3 terminals connected together. The dimensions of the spool are tuned such that when the line is all wound up the effective diameter is larger, allowing the vehicle to drop faster. As the vehicle drops and line is unwound, the effective diameter decreases and the vehicle slows down. In flight testing has proved that time of descent around 5-6 seconds from the time it is released to landing. The teams have assumed that since model rockets typically land at speeds of 4 m/s to 6 m/s, those speeds will be deemed ‘gentle’ by the competition judges. From encoder data the vehicle is estimated to land with a velocity of 3 m/s should easily be deemed a gentle landing.
Vehicle Design
The most significant parameter in the design of the UGV is mass. Since the most difficult requirement for the vehicle is the range, minimizing the mass of the UGV maximizes the range of the aircraft. Due to this all design choices revolve around minimizing the mass.
Possible archetypes for the UGV included 4 wheeled vehicle, 3 wheeled vehicle, 2 wheeled vehicle, and tank. The tank archetype was immediately ruled out as tracks are relative heavy, and mechanically complex. It was decided to implement the 2 wheel system as it will have the lowest mass. The UGV will be front wheel drive with a sled on the rear. The 3 wheeled option is essentially the 2 wheels option with an additional wheel instead of the sled. It was deemed the sled would be lighter and thus the 2 wheeled option was chosen over the 3 wheeled option. The 4 wheeled option would require some steering system or pivoting wheels which would be relatively heavy. As such the 2 wheeled option was chosen over the 4 wheels option leaving the 2 wheeled option as the ideal vehicle archetype.
The majority of the sky crane components are mounted on the UGV. The position of the sky crane on the UGV is such that the point at which the tether acts upon the vehicle is slightly aft of the UGV center of mass. This causes the UGV to pitch down slightly during the descent and land wheel first.
Safety, Risks, & Mitigations
Safety is a fundamental aspect to the design, fabrication, and operation of the vehicle. The appropriate safety procedures have been researched and implemented by the team in order to ensure personal safety. The team has a designated safety officer present during all testing sessions, as well as proper training of all team members. Respective safety and personal protection equipment is used whenever necessary. Table zz outlines a sample of the vehicle risks and the associated mitigations.