Delivering Emergency Supplies via Drone
06 May 2019
VIP University of Hawaii Drone Technologies
Maritime Team
Final Report
May 6, 2019
Kaita Tsuchiya [KT] (ME 482) 2590+1153 words (12%)
Lauryn Pang [LP] (ME 482) 1846+1687 words (9 %)
Sean Osurman [SO] (ME 482) 1740+1144 words (8 %)
Dagan DeWeese [DD] (ME 482) 862+1302 words (4 %)
Aesha Higashi [AH] (ME 482) 1316+1250 words (7 %)
Christian Rieta [CR] (ME 482) 1384+1320 words (7 %)
Michael Shibata [MS] (ME 482) 1510+920 words (7 %)
David Harris [DH] (EE 496) 4,098 words (14%)
Grace Hayashi [GH] (EE 496) 1053+1194 words (5 %)
Matthew Iwane [MI] (EE 496) 4,817 words (17%)
Cole Jamila [CJ] (ENGR 196) 379 words (2 %)
Edmond Chong [EC] (ENGR 296) 317+1289 words (2 %)
Peyton Young [PY] (ENGR 296) 379+1332 words (2 %)
Jason Chan [JC] (ENGR 396) 360+1351words (2 %)
Brandon Hewitt [BH] (ENGR 396) 379+783 words (2 %)
Kenji Rutter [KR] (ENGR 396) 305 words (2 %)
VIP UHDT
Department of Electrical Engineering, University of Hawaii
Department of Mechanical Engineering, University of Hawaii
Submitted to---
Dr. A Zachary Trimble
Department of Mechanical Engineering, University of Hawaii
Dr. Wayne Shiroma
Department of Electrical Engineering, University of Hawaii
Final Report Scoring Table
Section | Max | Score |
Executive Summary | 5 | |
Introduction | 3 | |
Technical Overview | 60 | |
Management & Cost Overview | 10 | |
Conclusion | 2 | |
Appendices | 10 | |
Overall Quality, Conciseness, and Effectiveness | 5 | |
Compliance | 5 | |
Total | 100 |
Executive Summary [LP, GH]
The University of Hawaii Drone Technologies (UHDT) team is a member of the Vertically Integrated Project (VIP) network, composed of undergraduate students from various engineering disciplines and multiple class standings, in which freshman to senior-level students from electrical, computer, and mechanical engineering collaborate to accomplish a common mission. UHDT utilizes Unmanned Aerial Systems (UAS) for specific applications such as Search and Rescue (SAR) and delivering payload objectives. This year, UHDT has split into two teams: UHDT Maritime Team (UHDT-M) and UHDT Competition Team (UHDT-C). This report will focus on UHDT-M and its efforts. UHDT-M also seeks to widen the scope of the previous year’s research and development by working in parallel with the Applied Research Laboratory (ARL) and introducing an additional delivery component capable of being delivered to maritime vessels. The 2019 UHDT Maritime UAV, Moltres, is carefully designed and developed through a systems engineering approach. Moltres is a commercially purchased and modified MyTwinDream fixed-wing drone which features the necessary components to successfully, safely, and professionally accomplish the following mission demonstration tasks within the time allotted: semi-autonomous flight, object detection, and air delivery. At the beginning of the 2018-2019 academic year (AY) based on the 2018 ME-481 rules and guidelines, VIP UHDT-M established its mission statement, from which a set of general Mission Requirements (MRs) were created, and an exhaustive set of specific Functional Requirements (FRs) were defined. Currently, UHDT-M has successfully met all mission requirements. Moltres is the successful integration of three subsystems (delivery, electronics and communications, and aircraft) with a completion of 17 flight tests. It is believed the implementation of semi-autonomous flight, object detection, and air delivery will result in a precise and accurate air delivery system called Moltres.
After extensive testing and troubleshooting, UHDT-M has proven that Moltres can successfully deliver a 2.3 kg total payload over a body of water. Although the final system was not tested to the extent of all its capabilities, all mission requirements were satisfied. MR-1, MR-3 and the MC were met and displayed during the final mission demonstration, MR-2 was met analytically due to federal regulation restraints. With the successful integration of the electronics, aircraft, and delivery subsystems, UHDT-M is confident in the capabilities of Moltres in completing the mission of delivering a 2.3 kg payload to a maritime vessel.
Table of Contents
1.2 Objectives and Requirements [KT, LP] 9
2.1.1 Water-Drop Delivery [SO, LP] 11
2.1.3 Concept of Operations [DH] 12
2.2.1 Aerodynamics [MS, CR, JC, KR] 13
2.3 Electronics [BH, DH, MI] 20
2.3.4 Object Detection [MI] 22
2.3.5 Communication [BH, CJ, DH, MI] 22
2.4 Water-Drop Delivery [SO] 23
2.4.1 Payload compartment [DD] 24
2.4.2 Payload Drop System [AH, SO, PY] 24
2.4.2.1 Payload Drop System Design Iterations [AH, SO] 24
2.4.3 Paracord Drop System [AH] 27
2.4.4 Stability with Full Delivery System [AH, SO] 27
3.0 Testing and Evaluation Results 30
3.3.1 Payload compartment [DD] 32
4.0 Safety, Risks, & Mitigations 34
4.1 Developmental Risks & Mitigations [KT] 34
4.2 Mission Risks & Mitigations [KT] 34
5.0 Technical Suggestions for Improvement 35
5.2.1 Object Detection [MI] 36
5.3.1 Payload Compartment [DD] 37
5.4 Project Management and Systems Engineering 37
5.4.1 Flight Test Procedures [KT, KR] 37
6.0 Final Budget and Schedule 37
List of Acronyms
ARL: Applied Research Laboratory
AUVSI: Association for Unmanned Vehicle Systems International
AC: Aerodynamic Center
AY: Academic Year
BVLOS: Beyond Visual Line of Sight
CDR: Critical Design Review
CG: Center of Gravity
CNC: Computer Numerical Control
COTS: Commercial Off the Shelf
EPO: Expanded PolyOlefin
FAA: Federal Aviation Administration
FMEA: Failure Modes & Effects Analysis
FPV: First-Person View
FR: Functional Requirement(s)
FTP: File Transfer Protocol
GCS: Ground Control Station
GPU: Graphics Processing Unit
MC: Mission Constraint
ME: Mechanical Engineering
MR: Mission Requirement(s)
MTD: My Twin Dream
NP: Neutral Point
OBC: Onboard Camera
ODLC: Object Detection, Localization, Classification
PDR: Preliminary Design Review
RDP: Remote Desktop Protocol
RPM: Revolutions per Minute
RPN: Risk Priority Number
RSSI: Received Signal Strength Indicator
RTL: Return to Launch
SFTP: Secure File Transfer Protocol
SSH:w Secure Shell
SUAS: Student Unmanned Aerial System(s)
TBS: Team Black Sheep
TLS: Transport Level Security
UAS: Unmanned Aerial System(s)
UH: University of Hawaii
UHDT: University of Hawaii Drone Technologies
UHDT-M: University of Hawaii Drone Technologies Maritime
VIP: Vertically Integrated Project
List of Figures
- Zipline UAV is observed to be bigger than the person carrying it. The Airbus Skyways is showcased where it can be observed to be a larger scale multi-rotor. Amazon Prime Drone is seen being fixed by a person half the size of the drone.
- AY 2018-19 UHDT-M System Architecture
- Simple diagram of mechanical control surfaces and dimensions in meters of the MTD
- Boeing-103 vs MTD Airfoil Profile
- Boeing-103 Lift Curve Slope
- Aircraft Performance
- Amp drawn vs Thrust
- Thrust vs Throttle Percent
- Maximum theoretical wing deflection as airspeed increases.
- Electronics Functional Block Diagram with External Interfaces
- Balsa wood model of payload drop mechanism.
- Laser cut acrylic pieces (left) and 3D printed ABS attachment piece (right).
- First design iteration with components labeled. Note that the acrylic pieces were fitted and glued into the ½” hose clamp brackets.
- Final design iteration of the servo-pushrod release system.
- Free body diagram for moment calculations about the AC location.
- Front and side view of stabilizers fabricated from spare payload attachment pieces.
- Front and side view of 3D printed stabilizers (left). Stabilizer orientation on hose clamp (right).
- Isotropic view of PixHawk and bracket (left); bottom view (middle). Integration on base (right).
- Screenshots of the test drop showing the trajectory path of the payload compartment and its corresponding measurements. The experimental path is shown in red and the modeled path is shown in blue.
- Project Expense Chart.
- Gantt chart for the UHDT-M academic year
List of Tables
- Description of Mission Requirements.
- Main Wing and Tail Wing Specifications.
- Minimum speeds and thrust required for the MTD without the payload.
- Minimum speeds and thrust required for the MTD with the payloa.
- Radius of turns at different velocities when the MTD banks at 30 degrees.
- Aircraft performance.
- Data from flight logs and calculated values.
- CG placements and required thrusts for added weights with the payload compartment. *[cm] from the leading edge of the wing.
- Flight test logs and theoretical voltage drop.
- Table showing flight parameters taken from the flight log, experimental horizontal distance travelled, and the predicted horizontal distance travelled from the trajectory model.
- Risk Matrix.
- Project Budget.
1.0 Introduction
1.1 Background [KT]
Due to the spacial limitations of maritime vessels, only a limited amount of supplies can be stored at one time. This sometimes requires the vessel to restock supplies as they run low. Items such as spare parts, food, documents, cash and other smaller items do not have an efficient way of being transported. Currently, the common practice to deliver goods from land to sea, without docking and transferring the goods, is to deploy a manned launch vessel or aircraft. The problem is that this costs around $1,500 per vessel, and even more depending on the travel distance [1]. Wilhelmsen Ship Services recently teamed up with Airbus to bring shore-to-ship drone deliveries in Singapore. They utilize the Airbus Skyways UAV, a multi-rotor drone capable of delivering a 4-kg payload up to a 3 km away [2] [3]. Wilhelmsen says it is expected to cut operation costs to about $150, which is about 90% more cost efficient than a launch vessel [1]. By utilizing drone technologies, the cost for shore-to-ship deliveries can be significantly reduced.
1.2 Objectives and Requirements [KT, LP]
UHDT-M is working in parallel with the Applied Research Laboratory (ARL) to design and manufacture a payload delivery system to a vessel via a semi-autonomous UAV. UHDT-M’s mission statement is: The mission of the UHDT-M is to produce an Unmanned Aerial System (UAS) capable of transporting a payload to a maritime platform. To accomplish this mission, Mission Requirements (MRs) are established with Functional Requirements (FRs) for each of the three subsystems: delivery, electronics, and aircraft. Each of these requirements drives subsystem tasks and success criteria. The MRs for the AY 2018-2019 UHDT-M can be seen in Table 1. From these MRs, a set of FRs were derived at the subsystem level to realize each MR.
Table 1: Description of Mission Requirements
Mission Requirement | Description |
Mission | |
MR-1 | The UAS shall be capable of flight with a 2.3 kg payload. |
MR-2 | The UAS shall have the ability to reach the maritime platform 8 km offshore. |
MR-3 | The UAS shall deliver the payload without damage to any component of the UAS. |
MC | The UAS shall adhere to laws set by the government. |
MR-1 was derived to ensure that payload size and weight would be adequately considered in the airframe design. Investigating available current solutions, it became evident that a payload weighing 2.3 kg falls into the upper maximum load range to which a UAV is capable of transporting. The Zipline UAV can carry up to a 1.8 kg payload [4], the Amazon prime air drone can carry up to 2.3 kg [5], and the Airbus Skyways UAV can carry up to 4 kg [3]. However, as shown in Figure 1, the commonality between these UAVs are the increased size in the airframe which is larger than typical hobby-grade airframes such as the MyTwinDream (MTD). Deep consideration should be made in the decision of the aircraft with the needed flight capabilities.
Figure 1: From left to right: Zipline UAV is observed to be bigger than the person carrying it [6]. The Airbus Skyways is showcased where it can be observed to be a larger scale multi-rotor [7]. Amazon Prime Drone is seen being fixed by a person half the size of the drone [8].
MR-2 ensures that the efficiency and range of electronics on the aircraft are thought out properly as 8 km is not easily achieved by typical delivery drones of similar payload weight. The fixed-wing Zipline UAV has a delivery radius of 80 km [4], the Amazon VTOL UAV has a delivery radius of 12 km [9], and the multi-rotor Airbus UAV has a delivery radius of 3 km [2]. This is an important consideration when thinking about design tradeoffs as some aircrafts capable of accurate delivery may not have the efficiency needed to achieve the distance required.
MR-3 ensures that there is adequate thought put into the delivery system as this is the emphasis of the mission. The vessel dynamics were heavily considered as the dynamic motion could cause impact to the UAV or payload. Payload weight was considered as another factor since this affects survivability of a drop method. Recovery methods that rely on damping the fall of the payload can be problematic due to possible damage to the payload. Looking at many delivery drones, hovering capabilities are favored such as those in the Amazon or Airbus UAVs. The Zipline UAV incorporates a parachute system to ensure the payload is delivered safely. Consideration to reduce the impact of the payload must be incorporated as one of the decision criteria to ensure the success of the mission.
MC is a constraint which ensures that the operations will adhere to the laws and regulations set by the Federal Aviation Administration (FAA). This is a necessary constraint to ensure the safety and correct practice of unmanned flight. Violating the laws may result in damage to manned vehicles and their passengers, structures, or even pedestrians within the area.
Research into the prior art and each MR show that different specifications are necessary for different missions. Looking at how state-of-the-art technology fulfills the MRs, the Amazon UAV can fulfill MR-1 and MR-2 but not MR-3 in our specific task. MR-3 considers concerns such as maritime platform dynamics as this is a major issue when trying to safely deliver the payload. The novelty of UHDT-M’s mission is the following: where current commercial delivery drones are capable of delivering to stationary delivery points, UHDT-M has the ability to deliver directly to a dynamic platform out at sea.
1.3 Design Rationale [LP]
The AY 2018-2019 UHDT-M system design is the product of environmental factors, MRs, and major design decisions. Major design decisions were made at multiple levels of the system to fulfill the MRs listed in Table 1. Three subsystems were created within the team to meet these MRs: aircraft system, delivery system, and electronics/communications. Figure 2 shows the UHDT-M system architecture which is comprised of the Ground Control System (GCS), aircraft system, and delivery system. The electronics/communications subsystem is incorporated in both GCS and aircraft system. In order to meet all MRs, adjustments to each of these systems were made throughout the year, including, but not limited to, adjustments to the aircraft frame and aircraft components, delivery system and individual components, and the electronic system components used for object detection.
Figure 2: AY 2018-19 UHDT-M System Architecture
2.0 Final System Design
2.1 Major Design Decisions
2.1.1 Water-Drop Delivery [SO, LP]
The water-drop delivery method was one of the most impactful design decisions for the UHDT-M project, as it was a pivotal factor for many components that were selected. The water drop method is completed by first attaching a waterproof payload compartment to the UAV. The actual payload is placed into the compartment where it is contained within the front cone portion of the compartment. A retrieval cord is then attached to the underside of the payload compartment on one end, and to an external servo arm located on the side of the UAV on the other end. During flight, after the maritime vessel has been detected and is within delivery range, the retrieval cord is released and dragged toward the vessel for optimal placement. As the cord is being placed across the maritime platform, the payload compartment is released so that its trajectory allows a water drop landing on the opposite side of the maritime vessel. Once the compartment impacts the water personnel located atop the maritime platform retrieves the payload compartment via the retrieval cord.
The selection of the water-drop delivery method is the result of comparing multiple delivery methods. The comparison is based on each method’s effectiveness in fulfilling the FRs and in the ability to complete the mission objective. After selecting the water-drop method, water-drop delivery concept iterations were compared based on the same criteria. The water-drop delivery system is currently comprised of a 3D-printed payload compartment, a metal hose-clamp, a 3D-printed payload attachment piece, a paracord as a retrieval cord, and two servo-based release mechanisms (one for the retrieval cord and another for the payload compartment). Ultimately, the water-drop delivery method had been selected due to its unique ability to use the benefits of the ocean to give us an increased chance in success.
The 3D-printed payload compartment and payload attachment piece are selected for the customization and rapid prototyping abilities that 3D-printing offers. The payload compartment is designed to reduce drag during flight and reduce the impact force associated with water impact. The payload attachment point is designed based off of specifications and dimensions used in calculations from servo analysis. A metal hose-clamp is selected because its durability and adjustable fitting.
A retrieval cord is selected because it allows the payload to be reclaimed from an extended distance, which enables a greater water drop radius to which the payload can be placed.
Servo-based release mechanisms for the retrieval cord and payload compartment is selected due to successful servo-based releases and system integration observed in the competition UAV. Due to an increase in payload weight with regard to previous payloads released from a servo, an increase in torque for the releasing servo was necessary. After calculations a decision was made to increase the releasing servo for the payload with the specifications of 25 kg/cm torque at 0.17 s per 60 degrees operational speed. Due to the payloads relatively high weight, the payload will be released using a metal pushrod and the retrieval cord will be released using a strap. Flight tests have shown that weight at the end of the retrieval cord may not be necessary for the cord to drop or perform correctly.
2.1.2 Aircraft [MS]
The selection of the MyTwinDream (MTD) aircraft stemmed from the FRs of the mission and the team's familiarity with the frame itself. Through the analysis of the frame and airfoil profile the MTD frame meets all requirements and the only modifications necessary for the integration of the delivery system and the propulsion system.
For the current and previous competition UAV, the propulsion system is comprised of two 720 KV brushless motors. These motors operate at high efficiency but lack the thrust needed for the requirement of operating at a max takeoff weight of 9 kg (aircraft weight + payload weight). An additional amount of thrust is also needed for the new delivery system. This increase in thrust will help overcome the increased weight as well as the extra drag from the paracord and the moment created by the tension force. The new propulsion system includes two 1100 KV brushless motors with a max thrust of 3200 g each (1000 g more thrust per motor). A recent flight test revealed that reinforcement of the motor mounts will also be needed, especially for damaged airframes.
The method of the delivery introduced the need for a drop mechanism to be integrated into and/or under the fuselage of the MTD. Through multiple iterations and new design concerns that arose during the testing process, the final design for the drop mechanism housing contains two separate sections. The first section attaches to the payload compartment through a pin mechanism and all components are within the fuselage. The second section secures the paracord using a velcro strap that is released by a single servo.
2.1.3 Concept of Operations [DH]
In order to prove that we are able to accomplish all of our MRs, the mission demonstration will consist of 3 stages. The first stage takes place before take off. In this stage, Mission Constraint (MC) will be completed on the ground where the relevant legal and safety precautions will be demonstrated and followed. The second stage is the takeoff. UHDT-M will have completed MR-1 as soon as the UAV is able to lift off with the payload on board. This stage will be complete when the UAV climbs to the cruise altitude and begins to head towards the platform. The third and final stage is when the UAV reaches the platform. Upon approach of the GPS location, visual identification will be completed. When the platform is identified, UHDT-M will have completed MR-2 and will attempt its final approach. The UAV will fly towards the platform, releasing the retrieval cord, laying a line out across the platform, and then dropping the package. Once the payload is onboard the maritime platform and both the platform and the payload are confirmed to be intact, MR-2 and MR-3 will be completed. The UAV will now have completed all four of its MRs. At this point, UHDT-M will have accomplished its mission statement and the UAV will begin its flight back to the launch point.
2.2 Aircraft [MS]
The main mechanical components for the MTD include the control surfaces (ailerons, rudder, and elevators), the motors, and propeller assembly (see Figure 3). Each of the control surfaces is controlled by a servo which is given commands by the Pixhawk Flight Controller. The MTD frame is made of polystyrene making it lightweight yet durable. To add to the structural integrity of the wings two carbon fiber spars support both wings [11]. The outer diameter of the spars is 0.9 cm and the inner diameter is 0.8 cm.
I
Figure 3. Simple diagram of mechanical control surfaces and dimensions in meters of the MTD
2.2.1 Aerodynamics [MS, CR, JC, KR]
The MTD has two lifting surfaces: the main wing and the tail wing. Both surfaces create positive lift, because the Center of Gravity (CG) lies behind the main wing’s Aerodynamic Center (AC). This may appear as though the MTD is tail heavy. However, the motors are located higher than the vertical Aerodynamic Center (AC) and the tail wing creates an upward force. The thrust from the motors and the force from the tail wing create nose-down moments which prevents the MTD from pitching nose-up. The lifting surfaces’ specifications are summarized in Table 4. Note that at zero angle of attack the tail wing does not create lift as its coefficient of lift (
) is zero.
Identification of both the main and tail wing’s airfoil were essential as it is a necessary step in finding the angle of attack (Alpha) that dictates both values of coefficient of lift () and coefficient of drag (
). Both and are necessary parameters in predicting the MTD’s performance. The main wing’s airfoil profile was determined by past UHDT members. They compared the SolidWorks model with the airfoil types on the Airfoil Tools website. The main wing’s airfoil was identified to be resembling Boeing-103 airfoil (see Figure 4). The tail wing’s airfoil was determined to be resembling the HT05-il.
The lift curve slope of Boeing-103 airfoil (see Figure 5) predicts that the MTD should be able to produce lift even in negative Alpha. This is helpful as the MTD would have a tendency to nose-down due to the thrust created by the motors. The lift curve slope of HT05-il is also shown in Figure 6.
Figure 4: Boeing-103 vs MTD Airfoil Profile Figure 5: Boeing-103 Lift Curve Slope [11]
Figure 6: HT05-il Lift Curve Slope [12]
Table 2: Main Wing and Tail Wing Specifications
Lifting Surface | Airfoil | Area [m2] | Span [m] | Aspect Ratio [m2/m2] | Mean Aerodynamic Chord [m] |
Main Wing | Boeing 103 | 0.42 | 1.80 | 7.71 | 0.268 |
Tail Wing | hT05-il | 0.09 | 0.605 | 4.06 | 0.168 |
Reanalysis of the performance of the MTD had to be repeated. This is due to the weight of the system being overestimated and wrongfully using the planform area rather than the frontal area of the wings for the drag calculations. The new analysis shows that the aircraft is much more capable than initially thought.
For the reanalysis of MTD’s performance, the following assumptions were made. It was assumed that the MTD was in a quasi-equilibrium state. This was so that environmental disturbances such as wind gusts and changes in air density and temperature could be assumed to be negligible. Two weights were used for the analysis, 62.78 N, which is the full operational weight of the aircraft, and 37.28 N which is the weight of the aircraft when the payload compartment and the rope are not attached to the aircraft. As the airfoil of the tail wing was also identified, the lift from the tail wing was no longer ignored and included in the calculations. The minimum speeds at different angles of attack, alongside the thrust required for the two weights are summarized in Tables 3 and 4.
Table 3. Minimum speeds and thrust required for the MTD without the payload
Aircraft weight = 37.28 N (No Payload) Aircraft mass = 3.8 [Kg] | ||||
Angle of Attack (Aoa) [°] |
|
| Velocity [m/s] | Thrust Required [N] |
0.00 | 0.39 | 0.00 | 18.84 | 14.05 |
1.00 | 0.46 | 0.10 | 17.08 | 11.54 |
2.00 | 0.54 | 0.23 | 15.42 | 9.41 |
2.50 | 0.72 | 0.28 | 13.42 | 7.12 |
5.00 | 0.93 | 0.54 | 11.58 | 5.31 |
7.50 | 1.16 | 0.80 | 10.28 | 4.18 |
10.00 | 1.32 | 0.77 | 9.74 | 3.75 |
12.50 | 1.47 | 0.70 | 9.32 | 3.44 |
15.25 | 1.55 | 0.60 | 9.16 | 3.32 |
Table 4. Minimum speeds and thrust required for the MTD with the payload
Aircraft weight = 62.78 [ N] (With Payload) Aircraft mass = 6.4 [Kg] | ||||
Angle of Attack (Aoa) ° |
|
| Velocity [m/s] | Thrust Required [N] |
0.00 | 0.39 | 0.00 | 24.45 | 31.89 |
1.00 | 0.46 | 0.10 | 22.17 | 26.22 |
2.00 | 0.54 | 0.23 | 20.02 | 21.37 |
2.50 | 0.72 | 0.28 | 17.41 | 16.18 |
5.00 | 0.93 | 0.54 | 15.04 | 12.07 |
7.50 | 1.16 | 0.80 | 13.35 | 9.50 |
10.00 | 1.32 | 0.77 | 12.64 | 8.53 |
12.50 | 1.47 | 0.70 | 12.11 | 7.82 |
15.25 | 1.55 | 0.60 | 11.89 | 7.54 |
The stall speed occurs at the critical angle which is 15.25 degrees. The stall speed of the MTD with a mass of 3.80 kg and no payload compartment attached is 9.16 m/s, while the stall speed of the MTD with a mass of 6.4 kg and the payload attached is 11.89 m/s. Technically the aircraft’s cruising speed can be anywhere within the minimum speeds where the angles of attack ranges from 0 - 2.5 degrees. This is because at these angles the aircraft will remain in steady-level flight and will not climb. However, the pilot’s mannerism in handling the throttle stick will likely dictate the cruising speed. If the throttle percent input is 50 percent, the MTD with a weight of 6.4 kg will likely cruise at 25 m/s where the thrust required is 33 N. If the throttle percent input is 35 percent, the MTD with a weight of 3.8 kg is projected to cruise at 19 m/s where the thrust required is 14 N. For the max speed of the MTD, due to the motors capability of supplying 61.2 N of thrust, the MTD with a mass of 3.8 kg is capable of flying at a velocity of 39 m/s, as the thrust required for that speed is 60.2 N. While with a mass of 6.4 kg, the MTD is capable of flying at approximately 34 m/s as the thrust required at that speed is 61.7 N. However, as will be discussed in the flight parameters section, the aircraft’s max speed should not go higher than 32 m/s.
The importance of the bank angle and the radius of turn was omitted for most of the school year. Its importance presented itself when UHDT-C experienced a turning stall that resulted in a crash. For UHDT-M, the max bank angle is set to 30 degrees. Finding the radius of turn at different velocities is a must to prevent the aircraft from crashing due to a turn stall. Table xx shows the radius of turns at different velocities when the MTD banks at 30 degrees. The turn should be aborted if the radius of turn is not big enough, as there is a tendency for the flight controller to override the max roll angle to a higher value. This tendency can cause the aircraft to crash as the max bank angle can be surpass, thus, over banking and stalling the aircraft. To prevent turning stall, the aircraft must be sped up so that the radius of turn is big enough.
Table 5. Radius of turns at different velocities when the MTD banks at 30 degrees.
Velocity [m/s] | Roll Angle [°] | Radius of turn [m] |
10.00 | 30.00 | 17.67 |
12.00 | 30.00 | 25.45 |
14.00 | 30.00 | 34.64 |
16.00 | 30.00 | 45.24 |
18.00 | 30.00 | 57.26 |
20.00 | 30.00 | 70.69 |
22.00 | 30.00 | 85.54 |
24.00 | 30.00 | 101.80 |
25.00 | 30.00 | 110.46 |
The take-off phase also had to be reanalyzed because the initial takeoff model did not incorporate the flight path angle (
) and angle of attack . Scalar equations 1 and 2 which are taken from Fundamentals of Airplane Flight Mechanics are used to analyze the aircraft’s velocity, altitude, and pitch attitude of the aircraft during takeoff,
(1)
(2)
Where 
is the angle of attack plus the thrust angle of attack . However, due to the motors being parallel to the body axis of the aircraft, the thrust angle of attack is zero and thus is equal to the angle of attack.
The thrust provided by the motors, pitch attitude, and the angle of attack will dictate whether or not the aircraft is able to takeoff. The higher the angle of attack is, the higher the lift the wings are able to provide. However, the aircraft will also be slower in picking up its required takeoff speed.The thrust and initial flight path angle has a huge influence on the pitch attitude, as they will dictate whether or not the aircraft will pitch down or up. An initial flight path angle of ten degrees almost ensures that the aircraft will not pitch down, as long as the thrust is big enough.
The performance and takeoff analysis of the MTD s indicates that the MTD is able to fulfill all of the six functional requirements. The MTD should be able to carry and takeoff with a 2.3 kg payload, and have enough available thrust to overcome the added drag from winds of 6 m/s. The MTD should also able to reach the maritime vessel. Table xx summarizes the calculated aircraft performance values of the MTD.
` Table 6. Aircraft Performance
Aircraft Mass [Kg] | Max Speed [m/s] | Stall Speed [m/s] | Cruise Speed [m/s] | Bank Angle [°] | Turn Radius at Cruise Speed [m] |
6.40 | 32.00 | 11.89 | 25 | 30.00 | 110.46 |
3.80 | 32.00 | 9.16 | 19 | 30.00 | 63.80 |
2.2.2 Propulsion [CR]
To properly size the propulsion system, the thrust required for the MTD’s operational weight of 6.4 kg at steady-level and takeoff phases of flight were calculated. The thrust required for the takeoff is at 55 N, while the thrust required for steady-level-flight is 31.9 N, assuming that the aircraft is cruising at its minimum speed at zero angle of attack. The reason for such a high thrust required for takeoff is to ensure that the aircraft will still be able to takeoff at initial flight path angle of negative five degrees. If the aircraft’s initial flight path angle becomes lower than negative ten degrees, the takeoff should be aborted right away. The rope and the payload compartment should be released as it will take the aircraft at least two seconds to recover back a positive pitch attitude or a nose-up pitch. Although the aircraft will have the speed required for takeoff, by the time the aircraft achieves positive pitch, the aircraft will be too close to the ground.
To fulfill the thrust requirements, the chosen components for the propulsion system are two 1100KV brushless motors, two 12x6 in props, two 60 A ESCs and a 4-cell 16000 mAh lipo battery. A static thrust test done on March 31, 2019 showed that the chosen motor and prop combination could produce 3.1 kg of thrust. Therefore with this propulsion system setup, 61.2 N of thrust can be produced. It must be noted that during the test, the throttle level only went up to 8 out of the 9 levels of the servo tester. The reason for this is that the nameplate power and amp of the motor are only at 888 watts and 60 amps, respectively. At throttle level 8 or 88.89 percent throttle, the motors were already drawing 68 amps and consuming 1037 watts. For this reason, the current propulsion system should not be set higher to 80 percent throttle to prevent breaking either the ESCs or the motors. Some of the results from that test, which are necessary to verify the aircraft’s level flight speeds and thrust required are shown in the following Figure 7, which shows the amp drawn vs thrust, and Figure 8, which shows the throttle percent vs thrust.
Figure 7. Amp drawn vs Thrust
Figure 8. Thrust vs Throttle Percent
2.2.3 Stability [MS, CR]
Due to the high wing configuration of the MTD, its lateral stability has not been a concern. The dihedral effect which is an effect that creates a restoring rolling moment is inherent to high wing aircrafts. However, the MTD’s longitudinal stability is a different matter. For much of the flight tests, there has been an issue on the pitch stability and control of the MTD.
During the February 14, 2019 flight test, the attachment point of the paracord on the aircraft was placed in front of the main wing’s AC. As a result, when the MTD was tested to drag the paracord during takeoff, it nosedived and crashed. The calculated moment from the paracord being dragged was 0.42 N-m which is equivalent to adding 40% of the weight of the battery (the battery was placed in front of the main wing’s AC). This was fixed by placing the attachment point of the paracord and the CG behind the AC.
During the February 24, 2019 flight test, the MTD was able to drag a considerable length of the paracord. However, during that test, two new problems arose. The MTD suddenly became nose heavy and couldn’t take off, and at certain higher indicated airspeeds the plane experienced flexing of the wings resulting in vertical oscillations. Ultimately, the oscillations caused the MTD to be unstable during takeoff and resulted in a crash. There were three assumed reasons why these problems occurred: problem with PID tuning, a hardware or software problem, and bad CG placement.
During the March 06, 2019 flight test, the culprit for the MTD being unable to takeoff was inadequate aircraft tuning (more on this in Appendix A). The oscillations were most likely caused by bad CG placement. The CG was moved forward and the CG aft limit was found. The CG aft limit was found by finding the location of the Neutral Point (NP). NP is the CG location where the aircraft will be neutrally stable so that the aircraft will remain at its orientation until an outside or an input force is applied on the aircraft. Anytime the CG is placed behind the NP, the aircraft will be unstable. The aircraft will now be truly tail heavy. If the aircraft is flown in such a configuration, the aircraft will most likely crash. For these reasons, the NP can be considered the practical CG aft limit. The location of the NP was calculated to be 12.18 cm behind the leading edge of the main wing. This was verified during the March 09, 2019 flight test. On this test the aircraft had been tuned properly, and when the CG was placed just 3 mm behind the NP the oscillations occurred once again. The targeted forward CG limit is 10 % of the Mean Aerodynamic Chord (MAC) in front of the NP. The CG should lie behind the main wing’s AC and in front of the NP. Therefore, it can be placed anywhere between 9.50 cm to 12.18 cm behind the leading edge of the main wing to have pitch stability.
2.2.4 Flight Parameters [MS]
Through multiple flight tests two main parameters of our flight parameters came into concern. The bank angle and airspeed when performing any turns and the maximum airspeed our aircraft can withstand while still remaining in stable flight. On March 29th the main objective of the flight test was to test the new propulsion system the 1100 KV SunnySky motors. The first take off was successful as the MTD elevated in altitude at a much faster rate. The update rate on Mission Planner made it difficult for ground station to communicate the quick altitude changes of the aircraft and the MTD reached a height of about 750 ft. As this is in restricted air space the pilot throttled up and pitched nose down to reduce altitude back under 400 ft to be within FAA regulations. In this descent the plane reached speeds of up to 50-60 m/s. As the pilot tried to generate lift and return to level flight the left wing of the MTD broke off. Following this event analysis was done on the wing loading and the max deflection that the wings experienced at these airspeeds seen in Figure 9.
Figure 9. Maximum theoretical wing deflection as airspeed increases.
At 50-60 m/s the wings would have experienced deflections of up to 55 cm. From in lab testing the maximum deflection the wings can withstand is 20-25 cm. The corresponding airspeed to a 20 cm wing deflection is 32 m/s. Another consequence of the wings deflecting 20 cm up and down is that oscillations of the entire aircraft will occur. This was observed at a flight test on April XX while travelling out to Waimanalo river to perform a test water drop. The plane reached an airspeed of 38 m/s, and during this time the plane began to oscillate. At this time the pilot had switched to FPV and ground station had to notify him that oscillations were occurring and that airspeed had to be reduced. After dropping back down below 30 m/s the oscillations stopped, and the UAV was able to perform the water drop successfully. Immediately following this incident, a maximum 32 m/s parameter was set, and ground station audibly informs the pilot as this airspeed is approached. Stall speed in relation to bank angle is addressed in Section 2.2.1.
2.3 Electronics [BH, DH, MI]
The onboard electronics hardware is composed of a system of flight controllers, sensors and communications components. For the general system, most electronics are connected directly to the Pixhawk, as shown in the functional block diagram in Figure 10. The Pixhawk 2.1 cube is the main component that is capable of autonomous flight, sensor fusion, and relaying information back to the GCS via radio system. For the airspeed sensor, the UAV will be equipped with a mRo I2C Airspeed Sensor JST-GH MS4525DO which is connected directly to the Pixhawk through I2C. For GPS and barometer, the UAV will be equipped with the Here+ GNSS. This GNSS is capable of RTK integration into the ground station. However, UHDT determined that the use of the RTKs Centimeter level accuracy was unnecessary until the autonomous object identification and alteration of flight path was completed. For similar reasons the UAV will not have a LightWare SF20 as a LiDAR sensor used to detect altitude with respect to the ocean’s surface as opposed to simply the MSL at the aircrafts specific location. This would allow the Pixhawk’s altitude hold mode to be leveraged, flying a consistent distance from the water and not from the MSL. Since we are flying above land and non-moving water for all flight tests, it will not need to be used until after image processing is fully integrated. The UAV will be equipped with a Caddx Turbo Micro SDR2 Plus Freestyle Camera Hot Fire to give a video feed back to the ground station allowing the pilot to manually align the drop. The SunnySky X2820-5 1100 kV Motors of the UAV will be controlled by the 60A electronic speed controller. The HXT900 Micro Servos will be used to operate the control surfaces of the UAV and the cordage drop. The Fan Model FS-25W Waterproof High Torque Metal Gear Coreless Digital Servo will drive the pin that releases the payload. For the power system, the UAV will use a 16000 mAh 4S LiPo battery to power all if its electronics. A simple 12v BEC will be used to power the FPV transmitter. For the radio system, the UAV will be equipped with the DragonLink V3 Advanced SLIM Complete System to handle all of the UAVs radio transmission. Figure 10 shows the functional flow block diagram for the electronics system. The following is a complete list of onboard electronics:
- Pixhawk 2.1 cube
- Power distribution board
- Dragonlink v3 system
- Here+ RTK GNSS Set
- Digital Airspeed sensor w/ compass
- LightWare SF20
- 1100 KV Motor
- Caddx FPV camera
- 16 Ah Battery
- FPV transmitter
- Servos (4-flight control, 2-delivery)
- mRo I2C Airspeed Sensor
- 60A electronic speed controller
Figure 10. Electronics Functional Block Diagram with External Interfaces
2.3.1 Autopilot [DH]
UHDT-M uses a combination of mission planner and Pixhawk 2.1 Cube for its autonomous functionality. The Pixhawk 2.1 Cube is brand new to UHDT-M as of this year and has been implemented into the aircraft. Multiple flights have been successfully completed after complications with the initial tune of the UAV. All sensors have been successfully implemented into the autopilot. Through testing it was found that the LiDAR was not required if it is not utilizing the image processing algorithms to autonomously identify the boat. Although the capability of altitude hold mode is useful, the complications with installation outweighs the added functionality that it gains. Furthermore, due to swinging of the cordage on the aircraft, the LiDAR was often blocked until after the payload had been dropped.
In essence, UHDT-M is using semi-autonomous modes built into the pixhawk 2.1 Cube For UHDT-M’s demonstrations. The fly-by-wire flights stability mode and return-to-launch modes were used. If this system were to be used to deliver a payload to somewhere five miles offshore, the waypoints navigation functionality would be used. All of these modes have been tested and work as planned.
2.3.2 Firmware [DH]
As in previous years, UHDT-M is using the Ardupilot autopilot firmware. This autopilot firmware allows for high customizability and fast integration with the Pixhawk flight controller. Ardupilot can be connected to the ground station Software, Mission Planner, which allows for nearly all aspects of the flight controller to be accessed. The flight controller itself is the Pixhawk 2.1 Cube. This is a distinct upgrade from previous years’ flight controllers. The integration of the pixhawk 2.1 Cube with the Ardupilot firmware has been completed
2.3.3 Software [DH, MI]
Mission Planner allows for extreme customization of every aspect of the flight controller’s control over the aircraft and the aircraft flight characteristics. If needed, Mission Planner can be programmed to perform complex operations through Python scripting. UHDT-M is using Mission Planner’s Waypoint navigation functionality for the aircraft's journey to the maritime platform. The UAV will then use Mission Planner’s Return to Launch command, which allows the Pixhawk to take over and fly the aircraft back to the location it took off from.
2.3.4 Object Detection [MI]
Object Detection is still in very preliminary stages as it was an added task to the Electronics subsystem. An initial approach is currently being worked on, but full functionality and improvements will come in future semesters. To fulfill the FR of the UAS being able to identify the target for the delivery method, a Raspberry Pi and Raspberry Pi Camera will be used. An advantage of using a Raspberry Pi and Raspberry Pi Camera is that they are compact and lightweight, thus having minimal effect on CG. Object Detection will be implemented using the software OpenCV and TensorFlow. TensorFlow is an open source machine learning library that will be used to identify the maritime platform. The use of OpenCV is ideal as it is designed for real-time applications as well as efficiency, which aids in satisfying the FR.
2.3.5 Communication [BH, CJ, DH, MI]
All communications with the ground station are handled over 2 radio connections. The RC and telemetry link are both handled by a 433 MHz link through the DragonLink system. The telemetry and RC is passed from the aircraft to the RC transmitter where the DragonLink sends the telemetry to the ground station computer via a Bluetooth Link. The first person video feed is currently handled by a 5.8 GHz video transmitter and receiver. In order to actually manage 8 km of range, a 900 MHz video transmitter will be required. UHDT-M has only continued use of its 5.8 gigahertz transmitter because it allows for the use of first person view goggles. The goggles allow the pilot to be more accurate in the dropping maneuvers. A 900 MHz video receiver could be purchased for use with the first person view goggles, however the expense was deemed unnecessary as we could not do tests up to that distance. However, a 900 MHz video transmitter was tested successfully at 1.5 km using a non-goggle video receiver on the ground. The theoretical range on the 900 MHz module is 15 km.
The DragonLink system has an advertised range of 24 km. A higher speedlink will be utilized to allow for the telemetry to pass all of its data in a timely manner. According to the manufacturer, this will decrease the range by 70% for an actual range of 16.8 km. This range is notably more than the crafts projected maximum video range. If for some reason the ground station starts losing video, it will act as an early warning sign for telemetry and control link loss. Although these ranges were not tested and are based on ideal circumstances with minimal interference, the UAV will be flying over water with no obstacles between the transmitter and the receiver. Minimal interference should be expected as these are similar to the test cases that manufacturers use to get the advertised maximum range.
2.3.6 Battery Life [KT]
The theoretical battery usage of the mission was calculated utilizing data from static thrust test with the 1100 KV Sunnysky motors. LiPo battery discharge is not linear and at 80% of the total capacity the voltage drops significantly. The calculations for the total battery life was taken at 12.8 Ah which is 80% of the actual capacity of 16 Ah. The in lab thrust test showed a linear trend in current draw versus thrust so interpolation was used to find values not recorded through testing. Looking at the flight logs from numerous test flights the average cruising airspeed and throttle percentage for the conditions with and without the payload were found. Considering the worse case scenario of flying with headwind 6 m/s was subtracted from the average cruising airspeed to calculate the total time needed to fly 8 km. Using this calculated value along with the interpolated results of the current draw at the found throttle percent, the current draw in amp hour can be found. Results are shown in Table 7.
Table 7. Data from flight logs and calculated values
With Payload | Without Payload | |
Average Cruising Airspeed | 25 m/s | 20 m/s |
Average Throttle | 56% | 20% |
Current Draw at Throttle % | 26 A | 2.1 A |
Time to fly 8 km | 7 min | 10 min |
Current Draw to fly 8 km | 6.8 Ah | 0.7 Ah |
The total current draw in amp hour results in a total of 7.5 Ah drawn out of the 12.8 Ah. This analysis is dependant on throttling values which corresponds to the current drawn by the motors and is subjected to change in dynamic thrust. Validation of this model is discussed in the results section.
2.4 Water-Drop Delivery [SO]
The water-drop delivery system consists of a type IV paracord, a 3D-printed ABS payload compartment, a 3D-printed ABS attachment piece, a steel hose-clamp, two servos, a steel push rod, and velcro strap.
The delivery system is primarily responsible for the 5 lbs. payload to be safely retrieved directly by the maritime platform. The delivery system will be attached to the underbelly of the MTD’s fuselage and will perform two release phases via channel triggers on the MTD controller to deliver the payload to the maritime platform.
First release phase is after the MTD locates and identifies the maritime platform. Once the MTD is in first-release-position, the retrieval cord is released via servo. The retrieval cord dangles below the MTD while the MTD gets into second-release position. Once the MTD is in second-release-position, the payload compartment is released via servo. If performed correctly, the retrieval cord can now be intercepted by the maritime platform. The payload compartment can be pulled in via retrieval cord and can be extracted for its contents.
On May 1, 2019, the water-drop delivery method proved to be a valid method with its success in releasing the 40 m paracord and 5 lbs payload.
2.4.1 Payload compartment [DD]
The payload compartment is responsible for housing the payload and protecting it from impact forces as well as water damage from being dropped in the ocean. Originally the compartment was designed to 3D print in ABS plastic, however due to failed prints because of inadequate nozzle temperature, the payload compartment was printed in PETG. The payload compartment was designed to survive impact into water at an impact velocity of 21.26 m/s, which is the resultant velocity vector magnitude adding aircraft cruising speed of 16 m/s and freefall from a 10 m height. Modeled in ABS, with a 2.3 kg payload impacting nose first, the factor of safety was 57.4. Changing to PETG which has a yield strength of 16.9 MPa compared to 42.5 MPa of ABS reduced the factor of safety to 22.8. This factor of safety is still considerably high which was pre-planned in the event the payload does not impact the water nose first, resulting in an increase of the impact force applied to the payload. Water impact force from the payload landing on its side could not be modeled, therefore a high factor of safety and testing were important to mitigate the risk of damage to the payload compartment. Fin attachments to the back of the payload compartment were also modeled incase a nose down penetration was deemed crucial to the survival of the payload compartment upon testing. To waterproof the seal of the compartment, a layer of silicon was applied.
2.4.2 Payload Drop System [AH, SO, PY]
The payload drop system consists of a Fan Model 25 kg/cm torque servo attached to 2 mm stainless steel pushrod. A 3D-printed attachment point is used to integrate the pushrod and the hose clamp which fastens the payload compartment to the 3D printed attachment point.
The Fan Model servo is selected because of its high torque to angular speed ratio. It is essential for the payload to release as quickly and consistently as possible to reduce the complexity of the drop timing and accuracy. The 3D-printed attachment piece and hose-clamp are selected because of its ability to easily adjust the attachment point location given changes to payload content. It is important to have an adjustable attachment point location in case placement modifications are needed in order to achieve flight.
With the payload compartment weighing approximately 2 lbs and a FR of a 5 lb payload, the servo-pushrod system needed to be capable of holding and releasing at least 7 lbs. Tests have confirmed that the final servo-pushrod system can successfully hold and release at least 11.5 lbs of static loading and 5 lbs during flight. Note that there is at least a 4.5 lb margin to account for potential external forces such as air resistance caused by the payload compartment and tension caused by the paracord.
2.4.2.1 Payload Drop System Design Iterations [AH, SO]
The payload drop system went through two major design iterations, each with several minor modifications.
The first design iteration used a hand-fabricated fiberglass sheet that acted as the baseboard for the payload servo and pushrod-bracket release mechanism. This system had been created off of a balsa wood model used during bench level testing, seen in Figure 11. The balsa wood model proved to be a successful release mechanism for up to 10 lbs of static loading.
Figure 11. Balsa wood model of payload drop mechanism.
The pushrod-bracket release mechanism consisted of two store bought ½” hose clamp brackets, two laser cut acrylic pieces designed to fit within the hose clamp brackets, and fasteners for the hose clamp brackets. The acrylic pieces were created to reduce the gap between the fiberglass sheet and the hose clamp brackets, ensuring the pushrod followed as near a linear path as possible and increasing the success rate for releasing the payload compartment during flight. 3D printed attachment pieces were fabricated out of ABS plastic.The acrylic and ABS pieces are shown in Figure 12.
Figure 12. Laser cut acrylic pieces (left) and 3D printed ABS attachment piece (right).
The fiberglass sheet had also been modified via Dremel to fabricate a slot cut out large enough to fit the payload servo. Because the hose clamp brackets would be placed at the center of gravity of the UAV, the Pixhawk was also mounted on to this baseboard just above the hose clamp brackets. Everything except for the hose clamp brackets were fastened with the use of hot glue. Figure 13 is a photo of the first design iteration.
Figure 13. First design iteration with components labeled. Note that the acrylic pieces were fitted and glued into the ½” hose clamp brackets.
Unfortunately the first design iteration had a few flaws that reduced both the success rate and the loading capabilities of the payload drop system. The distance between the servo and the hose clamp brackets were not manufactured to the correct length. This large distance coupled with the large sweep angle required for the servo arm exaggerated the non-linear path that the pushrod travelled. The exaggerated non-linear path increased the frictional forces acting on the pushrod, making it harder to release the payload and increasing the risk of deforming the pushrod. The first design also required the pushrod to be bent beforehand in order to be installed, meaning the integrity of the pushrod was compromised before any external loading was applied. Finally, while the acrylic pieces reduced the non-linear path of the pushrod, they increased the pinching during the release of the payload compartment. Calculations for successfully releasing the payload and reducing pinching were made for a system where the thickness of the brackets holding the pushrod were equal to the distance between the two brackets (a 1:1 ratio). However, the manufactured acrylic pieces saw a decrease in the thickness of the brackets and an increase in the distance between the brackets, leading to a ratio that was closer to 1:2. Ultimately, the few design flaws resulted in a less than favorable success rate for dropping the payload due to pinching and friction. Test results showed that the system was only capable of releasing up to 6 lbs of static loading and less than 3 lbs of loading during flights.
The second payload drop system had been designed to tackle all of the issues that arose in the first iteration, and was entirely manufactured out of 3D printed ABS. The distance between the servo and the brackets was reduced to a distance of 4.53 in. The 1:1 ratio between the bracket thickness and distance between the two brackets was restored, and the attachment point between the pushrod and servo arm was moved from the third hole to the second hole. While the movement of the attachment point requires a larger sweep angle from the servo, it allows the pushrod to travel a more linear path than the previous design allowed, thus reducing pinching and making the tradeoff worthwhile. The new bracket was also designed to fit aluminum spacers as guides for the pushrod. This enabled a lower coefficient of friction compared to stainless steel on ABS. The spacers would also allow the pushrod to move in and out of the bracket without the worry of losing material as seen in the acrylic pieces.
The final drop system design proved to be a successful release mechanism for at least 11.5 lbs of static loading with a 100% success rate during bench level testing, and was able to release the 5 lb payload during the final flight test on May 1, 2019.
Figure 14. Final design iteration of the servo-pushrod release system.
2.4.3 Paracord Drop System [AH]
The paracord drop system consists of an Emax ES08maII servo, 40 m of type IV paracord, and a velcro strap to hold the paracord snug to the MTD. One end of the strap is fixed to the MTD frame, while the other end is held up by the servo. The Emax ES08maII servo is chosen because of its previous success of similar releases from the competition UAV. Type IV paracord is selected for its durability and functional application as a retrieval cord. The velcro strap is selected for its light weight and adjustability for different fittings.
When the servo is activated, the unfixed end of the velcro strap is released and the paracord is dropped, with one end of the paracord remaining tethered to the payload compartment. Multiple tests have proven that the figure-eight coil prevents tangling and the servo-strap system successfully releases the paracord with a 100% success rate.
During an initial flight test, the MTD was unable to drag the paracord through grass, so a paracord tension test was performed to see how much tension force is applied to the MTD via the paracord. The 40 m of paracord was attached to a fishing scale and was dragged through the grass at varying speeds, producing an average of 0.23 Ns/m. Thus, the MTD cruising speed of approximately 16 m/s provides a small tension force of 3.7 N, showing that the CG and stability of the UAV are critical. Recent flight tests have proven that the UAV is able to drag majority of the paracord through the grass and have a successful subsequent altitude climb.
2.4.4 Stability with Full Delivery System [AH, SO]
Moment calculations were performed to ensure stable flight with the full weight of the delivery system attached to the UAV using equation 3 (see Fig X for corresponding free body diagram).
| (3) |
where W is the weight of the UAV and delivery system, Fpy and Fpx are the paracord forces, and Dpayload and Dplane are the drag forces. The velocity of the UAV was set to the cruise speed of 16 m/s, and the corresponding forces at the cruise speed are Fpy = 0.8669 N, Fpx = 3.597 N, Dplane = 10.1338 N, and Dpayload = 0.8438 N.
Figure 15. Free body diagram for moment calculations about the AC location.
To avoid needing the maximum thrust, the location of the CG was manipulated while the targeted thrust values required for stable flight were kept near 45 N. Table 8 shows the resulting CG placements at various increments of weight. As a general rule of thumb, the CG location should be moved approximately 3 mm closer to the leading edge of the wing as the weight is increased by 1.25 lbs. Note that these calculations are for stable flight once the paracord is already released. Thus, the starting CG is placed slightly farther back than the desired CG location that is shown in Table 8. For example, the starting CG for the successful 5 lb flight on May 1st was approximately 10.1 cm from the leading edge of the wing, as opposed to the desired 9.9 cm CG location derived from the moment calculations.
Table 8. CG placements and required thrusts for added weights with the payload compartment. *[cm] from the leading edge of the wing.
Weight Added [lbs] | CG Placement* [cm] | FT [N] |
1.25 | 10.8 | 45.0434 |
2.50 | 10.5 | 46.3346 |
3.75 | 10.2 | 46.434 |
5.00 | 9.9 | 45.3408 |
6.25 | 9.6 | 43.0569 |
During the April 17th flight test, stability of the payload compartment had been questioned on whether or not swaying of the payload compartment had been the source of oscillations. Oscillations could occur if there were any gaps between the bracket and payload attachment piece.
In response, two strips of high density packing foam were placed between the payload compartment and the fuselage of the UAV to act as a damper. The foam was secured to the payload compartment via the hose clamp used for the payload attachment piece.
During the April 21st flight test, the payload compartment failed to release while in air. An emergency landing had been performed. It was noted that the foam could have been putting too much force against the fuselage and payload compartment creating additional external forces on the pushrod causing the release mechanism to fail.
New stabilizers were then fabricated out of spare attachment pieces. The reasoning for the modifying the spare attachment pieces came from the idea that it already had a way to be secured to the payload compartment and it did not necessary have to put any additional forces onto the pushrod because it could be adjusted to fit anywhere along the hose clamp. The stabilizers modified out of spare attachment pieces are shown in Figure 16.
Figure 16. Front and side view of stabilizers fabricated from spare payload attachment pieces.
Two of these stabilizers were placed on either end of the payload attachment piece on the hose clamp. The stabilizers would be set into place after the payload attachment piece was secured in by the pushrod.
During the in lab testing, it was seen that the delivery system had been able to drop 7 lbs consistently if and only if the pushrod a correct path through the second end of the bracket.It had been noted that the pushrod sometimes failed to path correctly, and insteads slips under the second end of the bracket causing more “pinching” than allowed. Against the concerns, a flight test was conducted on April 23rd with the notion that the pushrod path would be verifiable.
During the April 23rd flight test, the UAV failed to release the payload compartment and it was noted that the cause could have been from two different sources: the stabilizers or the pushrod itself. Because the stabilizers had been set after the payload attachment piece had been secured, the stabilizers could have been creating additional force on the pushrod just as the foam had done. One of the main discrepancies came from having to adjust the stabilizers and hose clamp after the payload compartment was secured to the pushrod, which meant that no trial could have the exact same fit even with markings along the hose clamp. It was noted that the stabilizers did not have much room for adjustment between the fuselage and payload compartment because of its fabricated dimensions.
New stabilizers were designed to allow a wider range of adjustments between the fuselage and payload compartment. The new stabilizers were fabricated out of ABS via 3D printing and can be seen in Figure 17.
Figure 17. Front and side view of 3D printed stabilizers (left). Stabilizer orientation on hose clamp (right).
To address the pushrod alignment issue, a new servo baseboard had been designed and 3D printed as mentioned in a previous section. Because of the design of the 3D printed baseboard and its removal of errors resulting from hand fabrication, the payload compartment fit snug against the fuselage with no play for oscillations. The successful May 1st flight test had verified that stabilizers were no longer needed to be considered.
The 3D printed servo baseboard had also been designed to include fasteners for the PixHawk, which not only helped the stability of the MTD, but also increased repairability. To ensure that the PixHawk would integrate smoothly, a PixHawk bracket was designed and 3D printed out of ABS as shown in Figure 18.
Figure 18: Isotropic view of PixHawk and bracket (left); bottom view (middle). Integration on base (right).
3.0 Testing and Evaluation Results
3.1 Aircraft
3.1.1 Payload Capacity [MS, CR]
The final flight test on May 1st validated our aircrafts requirements of being able to generate more than a sufficient amount of lift while holding a 2.3 kg payload. The weight of the payload was measured to be 2.31 kg and the wind condition at the time of take off was in the range of 5-7 knots. On this flight test the throttle percent was set to 80 percent and the thrust was at 57 N, with this configuration the MTD was able to takeoff with ease.
3.1.2 Wind Conditions [MS]
Through multiple flight tests at Bellows Air Force Base, the average wind conditions were measured to be between 7 and 10 knots with gusts of up to 15 knots. Although the sudden gusts did cause some spikes in altitude the flights in those wind conditions were stable as long as our CG placement was within our margin of stability. The requirement of operating in 10 knot winds was met and validated on these successful flight tests.
3.2 Electronics
3.2.1 Battery Life [KT]
Looking at 5 different consistent and successful flight tests where the battery drop was noted, the battery life model was validated for accuracy. Using the data from the flight logs and the method for estimating current draw a percentage of the capacity drawn from 80% of the actual capacity was calculated. This was then multiplied to 80% of the actual voltage to estimate the voltage drop. The estimated voltage drop was then compared to the actual voltage drop and the results can be seen in Table 11. The estimated values are relatively accurate. Underestimates have less than a 10% error and overestimates still validate that the model proves there will be sufficient battery life. Errors in this can come from the cell checkers inability to read to the hundredths place.
Table 9. Flight test logs and theoretical voltage drop
3.2.2 LiDAR [DH, GH]
After the LiDAR was successfully installed into the aircraft, multiple test flights were done to confirm its functionality. In general, without the payload, the LiDAR was accurate and useful for its ability to provide the flight controller with highly accurate altitude data. With the payload however, there were multiple issues with it maintaining accurate data due to the sway of the paracord going into the beam of the LiDAR. UHDT did not necessarily need highly accurate altitude data unless UHDT were going out over the open ocean where wave heights can be unpredictable, or using autonomous functionality to align the drop. In the final configuration of the aircraft, the LiDAR was not being used. In future configurations of this system, it would be ideal to determine a way to use the LiDAR to obtain accurate altitude data for use in the open ocean. Additionally, it would be necessary to find solutions to potential LiDAR threats, whether intentional or not. Since LiDAR relies on measuring reflected light pulses, it is possible to easily disturb the LiDAR sensors, resulting in inaccurate measurements, particularly beyond visual line of sight (BVLOS).
3.2.3 GNSS + RTK [DH]
UHDT originally intended to use GNSS + RTK, and the centimeter level accuracy that it provides, to allow for the autonomous alignment and drop functionality to have the accuracy that is required. In the end, UHDT only used GNSS functionality of the HERE+ GNSS be here plus GPSS. Because UHDT does not require centimeter level accuracy, we did not use the RTK although it was tested successfully. The Here+ GNSS was more than accurate for what was required of UHDT.
3.2.4 Radio [DH]
For testing the 900 MHz fpv radios, UHDT only has anecdotal evidence provided by reviews of the module itself which corroborate its projected 15km range. UHDT was not able to get a full range 900 MHz test. Without a boat, it is difficult to test the radio under realistic conditions. However, we were able to test 900 MHz telemetry radios, which should have a similar range, at distances in excess of 10 km over water.
In order to confirm the theoretical 16.8 km range of the 433 MHz telemetry and control radio, UHDT used the “range test mode” available via the Dragon link. This mode cuts the output power of the radio by 30 and roughly produces an estimate of the modules range. In “range test mode” UHDT was able to test the radio at a range of 300 m, this gives an estimated full range of 9 km. At 300 m the radio had 34% RSSI.
3.3 Delivery
3.3.1 Payload compartment [DD]
The payload compartments most mission critical task is to complete MR-3, “The UAS shall deliver the payload without damage to any component of the UAS”. The payload compartment was able to to survive all water drops without damage. Although the compartment was never dropped from the aircraft while in flight loaded with the full 2.3 kg, our mission demonstrations consisted of the unloaded payload dropping from an altitude of roughly 100 ft into water. Through analysis it can be shown that successfully surviving impact from 100 ft without weight corresponds to surviving our full mission of dropping from 10 m into the ocean with a full weight payload. Although the payload is unweighted, dropping from three times the height increases its impact velocity and thus impact force. Using free fall drag Equations 1- 4 with mass of the payload compartment as 1.465 kg, density of air as 1.225 
, Cd of an ogive as 0.295, and frontal area as 0.0331 m2, free fall velocity from 100 ft is 23.005 m/s.
(4)
(5)
(6)
(7)
Taking into account an average ground speed of 16 m/s, resultant impact velocity is 28.018 m/s. Using Equation 5 to calculate impact force, the impact force dropped while flying at 100 ft without the 2.3 kg weighted payload is 1431.57 N. The impact force with the 2.3 kg weighted payload dropped while flying at 10 m is 1151.76 N. The impact force applied to the payload during our demonstration and tests exceed that what we would experience on a flight mission out at sea, validating our impact model and completing MR-3.
(8)
3.3.2 Trajectory [AH]
Videos and flight test logs from the April 17, 2019 flight test were used to validate trajectory predictions, where screenshots of the test drop from the point of release to the point of impact were stitched together (see Fig 19).
Figure 19. Screenshots of the test drop showing the trajectory path of the payload compartment and its corresponding measurements. The experimental path is shown in red and the modeled path is shown in blue.
The drop altitude, wind conditions, and speed of the UAS at the time of the drop were obtained from the flight logs and paired with the corresponding measurements to calculate the horizontal length travelled by the payload compartment (see Table 10).
Table 10. Table showing flight parameters taken from the flight log, experimental horizontal distance travelled, and the predicted horizontal distance travelled from the trajectory model.
VUAS [m/s] | mpayload [g] | Altitude [m] | Scaled Altitude [cm] | Scaled Horizontal [cm] | Experimental Horizontal [m] | Predicted Horizontal [m] | Error [%] |
12 | 1600 | 3 | 4.2 | 10.1 |
| 6.127 | 17.7 |
Although a percent error of 17.7 seems high, there were a lot of areas where approximations had to be made. For example, the wind conditions were modeled as a constant speed of 5 m/s instead of the actual variable winds seen at the time of the drop. Another area of approximation was the scaling used on the screenshots of the video. Since the flight test videos were not stationary, the screenshots taken during the test drop were at differing angles and zooms, making it difficult to accurately measure the experimental horizontal distance travelled by the payload compartment. Thus, all things considered, the trajectory model closely predicts the actual drop of the payload compartment, aiding in accurately delivering the payload to the maritime vessel.
3.3.3 Servo-Pushrod [AH]
The servo-pushrod was designed to fulfill MR-1, where the delivery system needed to be able to both hold and release a payload of 2.3 kg. To account for dynamic loading during flight, added air resistance, tension from the paracord, and a higher factor of safety, the delivery subsystem aimed to create a system capable of holding and releasing at least 5 kg. Bench testing the final design consisted of multiple drops with a static load of 11.5 lbs, with the plane oriented at differing angles to mimic all possible conditions during a flight test. The drop system was able to hold and release the 11.5 lbs at the differing angles with a 100% success rate, exceeding the 5 kg goal set by the delivery subsystem. Finally, during the final flight test on May 1, 2019, the system successfully held and released the 5 lb payload.
4.0 Safety, Risks, & Mitigations
4.1 Developmental Risks & Mitigations [KT]
Developmental risks considered are time, cost, and performance. The risk of not having enough time or funds to complete the project poses a threat to any developmental process. Performance risks occur if the system is not well designed which may be consequent from poor requirement developments.
To mitigate the risk of time, a Gantt chart was used to keep track of top-level tasks for every subsystem. Trello was used in parallel to assign detailed tasks to each member with due dates and completion status. The overall Gantt chart was reviewed periodically and revised to have a better estimate on the status of the team and the remaining buffer time to delegate mission-critical tasks.
To mitigate the risk of cost, a budget estimate was made at every design gate. The Preliminary Design Review (PDR) budget was based on UHDT 2017-2018 team’s cost of parts and equipment. The Critical Design Review (CDR) budget was based on online prices for parts expected to be used in the CDR design. The project would be fully funded by ARL but additional finance from the Mechanical Engineering (ME) funds and VIP funds were also obtained for emergency purposes.
To mitigate the risk of performance, the created MRs and FRs were reviewed at each design gate to ensure that they captured the full intent of the mission at hand. A requirements verification matrix was utilized, and all requirements were reviewed to see if they were specific, measurable, actionable, realistic, testable, and traceable. At each design gate, the proposed design was also reviewed by UHDT advisors and ARL.
4.2 Mission Risks & Mitigations [KT]
To determine risks that are critical to the project development and mission, a risk matrix was utilized. Because this is a new project the levels of likelihood are unknown as prior data is not available. Thus a risk matrix utilizing 4 levels of risk was chosen. The levels being green for low, yellow for medium, orange for high, and red for critical.
The mission risks for each subsystem are denoted by the first letter of the subsystem: D for delivery, A for aircraft, and E for electronics. The mission risks for the delivery subsystem are: D1: Failure to release and deploy payload or retrieval cord, D2: Failure to drop payload within range of maritime platform, and D3: Failure to protect UAV from a tangled cord. The mission risks for the aircraft subsystem are: A1: Failure to takeoff, A2: Loss of control of the aircraft while in flight, and A3: Not enough pitch control from paracord drag. The mission risks for the electronics subsystem are: E1: Electronics failure, E2: Failure to detect the delivery target, and E3: Failure to detect and troubleshoot issues. The risks were placed in Table 11, the risk matrix, depending on its likelihood and consequence.
Table 11. Risk Matrix
Consequences | ||||||
Marginal | Minor | Moderate | Major | Severe | ||
Likelihood | Almost Certain | |||||
Likely | D1 | A3 | ||||
Possible | A1|D2 | E2|D3 | ||||
Unlikely | E3 | A2|E1 | ||||
Rare | ||||||
To mitigate these risks a risk burn down method was utilized. When each of these mitigations methods are
utilized it will reduce the likelihood of the risk, subsequently reducing the overall risk.
The mitigations for the delivery subsystem are: D1: Calculate torque needed for payload weight (payload compartment weight included) and static test of servo drop before integration; D2: Test accuracy of drop and validate trajectory model and practice manual drop using FPV; D3: Ensure cord drops smoothly and calculate/measure the time to unravel and angle of drag and ensure mission area has no tall obstacles or if there is pay close attention to the flight plan.
The mitigations for the aircraft subsystem are: A1: Properly size the propulsion system, do preflight and safety checklists, and do static thrust test with different props and motors to validate thrust; A2: Do preflight and safety checklists, make sure that all components are in good working condition, and do post-flight checks and repair as necessary; A3: Redesign moment and attachment point, and validate pitch control on new MTD, move attachment point behind AC to account for pitch control, and validate maximum allowable rope length to drag before drag moment exceeds pitch control.
The mitigations for the electronics subsystem are: E1: Test individual electronics before integration and test entire electronics systems before integration, and validate sensor data output during pre-flight check tests; E2: Added the use of boat GPS location and LiDAR and FPV and pilot visual will always be available; E3: Have one person during flight tests responsible for announcing necessary flight data to the pilot in command and do post-flight check to make sure no damage to electronic components.
5.0 Technical Suggestions for Improvement
5.1 Aircraft [CR, JC]
There is not much to modify on the MTDs design. In terms of stability, the MTD covers directional stability greatly due to the size of its vertical stabilizers. The MTD’s high wing configuration helps the aircraft in terms of lateral stability. And for longitudinal stability, as long as the CG lies within the static margin the MTD should have good pitch stability.
For missions requiring more speed and more maneuverability, the structural integrity of the wings have to be reinforced. In missions such as this, the wing loading will increase due to the change of the load factor for every maneuver that the aircraft will take. To remedy this, an extra hole could be drilled and a spar could be inserted to prevent wing breakage and allow the plane to perform more intense maneuvers.
If the payload requirement is increased while keeping the same size of the payload compartment, there are two possible options to help accomplish the mission. Due to the mass increase, hand launch takeoffs might no longer become an option as there will be a tendency to inadvertently hit the empennage. Because of this, the aircraft might always start at a high negative pitch angle and therefore making it almost impossible for takeoff. One option to make the mission still possible will be the addition of a landing gear. This will mean that the aircraft will have to start from the ground during takeoff. Possible drawbacks for this option is the integration of the landing gears and a long runway for takeoff, as well as added weight. Another option that can be taken is to make a mechanical launcher. This way the aircraft will always have a positive pitch during takeoff.
A final consideration for improvement or scalability of the system would be to use a bigger plane. The advantage of this would be more thrust, a higher payload capacity, longer flight distance, and ease of taking off. Some disadvantages are higher cost for purchasing a new one and more expensive repairs. Since the mission only called for a 2.3 kg payload, perhaps a bigger plane wouldn’t be needed. To reduce the costs and time of repairs - especially during critical field test time, commonly damaged areas such as the tail and the nose can be reinforced with fiberglass. These reinforcements can be easily transferred from plane to plane to reduce the chances of major damages.
5.2 Electronics
5.2.1 Object Detection [MI]
The next step would be to integrate object detection to autonomously direct the UAS to the maritime platform. This can be done using the field of view of the onboard camera. Using the field of view of the camera, a Python script can be written to determine the current trajectory of the UAS. This information would be used to determine whether or not the course needs to be adjusted. If the course of the UAS needed to be adjusted, it can be done through Mission Planner. Mission Planner has the ability to run Python scripts. So through Mission Planner, a Python script could be injected to allow the UAS to autonomously adjust its course. Another thing that can be improved upon in the future is the speed of the object detection model. Currently the model runs at a real time speed of approximately 1 frame per second. This processing speed is unideal given the UAS will be traveling at a speed of approximately 20 meters per second. Therefore, it would be beneficial to either find a faster model or optimize the current model.
5.2.2 Battery [DH]
Possible integration of lithium ion batteries for higher efficiency can be considered for future teams. Lithium ion batteries are in general more energy dense than lithium polymer batteries. For this discussion, the Panasonic 18650 cells will be used as a baseline. We currently use a 16 Ah lithium polymer battery weighing 1300g. To achieve the same capacity and voltage, we would need 20 lithium ion cells, 4S5P, each with 3.4 Ah weighing a mere 900g. This, at face value sounds incredible. We could either increase our capacity dramatically or make room for other things in our weight budget. The downside to lithium ion batteries are their poor discharge capability. For batteries, a C rating is used to denote its discharge capability. For example, the 16 Ah batteries that UHDT uses for its flights has a C rating of 10 C. With a C rating of 10, and an amp rating of 16, the instantaneous discharge capability can be calculated to be 160 amps, or 10 C * 16 Ah. As a maximum, UHDT only uses about 100 A at any single time, specifically during takeoffs. The downside to lithium ion cells is their abysmal 1 C rating. This means that UHDT would need a total of 140 cells, weighing 6300g to match the discharge rate required for the planes to take off.
The sweet spot would be somewhere in between, possibly even using some of each with lithium ion and lithium polymer. If we took 20 lithium-ion cells required to match the capacity of our lithium polymer, it's discharge capability would be 17 A. While cruising, our system draws anywhere between 10 A to 30 A depending on the conditions. Although lithium ions are not sufficient on their own. If a system was put in place that could charge a lithium polymer battery, possibly as small as 1.8 Ah at 100 C, it could allow the system to be overall both more energy dense and still capable of delivering the amperage required for takeoff.
5.3 Delivery
5.3.1 Payload Compartment [DD]
To improve the payload compartment, it could be 3D printed out of ABS as originally planned because ABS has a higher yield strength and is less dense. A 3D printer with high enough nozzle temperature would have to be used. If size specifications of the payload were given, the compartment could have been reduced in size to reduce drag. Also to reduce drag, a smooth surface finish could be applied. Lastly, fins could have been used on the compartment to insure a nose down water impact and lessen the impact force. Testing would have to be done to ensure the fins would not break off in the water.
5.4 Project Management and Systems Engineering
5.4.1 Flight Test Procedures [KT, KR]
Flight test procedures should have been much more rigorous from the very beginning. The discrepancies may have been due to the fact that the team was working on a new system but was utilizing the previous year’s checklist. Roles should also be assigned for every flight test as it increases productivity and sense of responsibility to all members present. Pre-departure and pre-flight checklists should be modified every year to check if older check sheets are still relevant and if new components are introduced they should be included to the check sheets. More individuals should also be tasked with being able to read the flight logs for post flight analysis and validation of models.
Due to the increased weight, the UAV needed to consistently be launched at a slightly positive pitch angle. Failure to do so at full weight would cause it to lose altitude to the point where the payload was in danger of striking the ground, putting the whole system at risk. In previous years the UAV was light and powerful enough that the initial angle of attack was a less important for a successful takeoff. Future teams should take this into consideration when hand launching the UAV.
5.4.2 Risk Mitigation [KT]
Although the risks and risk mitigation was thought out and executed, UHDT-M faced some of the said risks during testing. Risks: D1, D3, A1, A2, E1 were all encountered during the testing phase. There were many aspects of the mitigation plan which overlooked certain aspects or was not rigorous enough to increase the rate of detection. Although a failure mode & effects analysis (FMEA) was conducted for the upper level mission, it was never done for the individual risks which were mentioned. Utilizing proper use of a risk priority number (RPN) would have been very helpful and may have shown red flags in some risks which would have prompted for a more rigorous mitigation method.
6.0 Final Budget and Schedule
6.1 Budget [DD]
Table 12 shows how UHDT-M budgeted a total project cost of $7,359.44 consisting of components and materials needed for each subsystem. Figure 19 is the expense chart which details what percentage of the budget was allocated to each of the three subsystems. At PDR, our proposed budget including 10% buffer was $7,755. At CDR this was reduced to $5,629 once more information on the items needed was available. This did not include enough spare items which proved crucial during testing. At DDMR, the proposed budget rose back to $7,906, and for the Midterm report was $7,604.67, which was the most accurate budget, including any spares. Funding for the project came from ARL and the VIP program. ARL supplied $6,801.97 of funds, which went toward purchasing the majority of all the aircraft, electronics, delivery, and prototyping supplies, along with multiple spares. The maximum budget given to UHDT-M by ARL was $7,000. From the VIP funds, $487.97 out of the $750 have been used. The team did not use the available $1,000 from the Mechanical Engineering department. The remaining cost of the project is due to team member purchase of the paracord.
Table 12. Project Budget
Figure 20. Project Expense Chart
6.2 Schedule [LP]
The timeline for UHDT-M takes place during the UH 2018-19 AY (August 2018 - May 2019) and included 5 weeks of buffer time of which all were used. The timeline was designed to end in May prior to the completion of the Spring 2019 semester. The UHDT-M team consists of 15 members of which 10 are senior class members and the remaining 5 are underclassmen. Currently, 10 members are from a mechanical engineering discipline, and 5 members from an electrical engineering discipline. With this amount of members from different disciplines, not only the scheduling of key subsystem tasks and integration is of importance, but time management of those tasks also play a key role. The updated gantt chart for UHDT-M academic year is shown in Figure 20. For optimal readability, the gantt chart has been broken into parts, thus allowing sections to be viewed on a larger scale. It should be noted that while the gantt chart was followed in general to ensure all necessary tasks were completed, unforeseen circumstances sometimes required a deviation from the gantt chart. Some subsystems were put on hold for certain tasks as other problems or circumstances from other subsystems were being solved. Also, due to multiple crashes throughout the semester, much time was diverted toward the reassembly of the damaged UAV, or new assembly of brand new airframes and components. Furthermore, UHDT-M experienced many delays in items that were ordered off island. Being located in Hawaii sometimes poses a unique problem with not only finding vendors who ship to this location, but also in receiving orders within a small time frame. Therefore, tolerances were allotted with regard to the gantt chart, and schedules for all subsystems were not held strictly to plan.
Figure 21. Gantt chart for the UHDT-M academic year
7.0 Conclusion [LP]
The 2018-2019 AY serves as the fifth year of UHDT’s venture in advancing UAS technologies and its fourth consecutive entry in the annual AUVSI Seafarer SUAS competition. However, UHDT-M serves as the first year that an extension of this team was formed and a collaborative project with ARL was created. UHDT-M aims to fulfill its mission to produce a UAV capable of transporting a payload to a maritime platform. From this mission statement, a set of MRs, as well as a set of FRs were developed. These requirements guide all subsystems to fulfill UHDT-M’s current mission statement. Currently, UHDT-M has satisfied all mission requirements. Mission requirement 1: The UAS shall be capable of flight with a 2.3 kg payload, mission requirement 3: The UAS shall deliver the payload without damage to any component of the UAS, were both physically met during flight with the UAV, and mission constraint: The UAS shall adhere to laws set by the government. Mission requirement 2: The UAS shall have the ability to reach the maritime platform 8 km offshore, was met analytically. Due to FAA rules and regulations, mission requirement 2 could not be met physically, and therefore the capability of the UAV to meet mission requirement 2 had to be shown through calculations. While using a systems engineering approach it is believed the implementation of semi-autonomous flight, object detection, and air delivery will result in a precise and accurate air delivery system called Moltres.
References
[1] “Wilhelmsen Launches Delivery Drone Service at Nor-Shipping.” The Maritime Executive, maritime-
executive.com/article/wss-ships-agency-launches-delivery-drone-service.
[2] “Special Delivery: Aerial Drones Deliver Shore-to-Ship.” MarineLink, Maritime Activity Reports, Inc., 5 June
2018, www.marinelink.com/news/special-delivery-aerial-drones-deliver-438250.
[3] “Airbus Completes First Flight Demonstration for Its Commercial Parcel Delivery Drone 'Skyways'.” Airbus,
www.airbus.com/newsroom/press-releases/en/2018/02/airbus-Completes-first-
flight-demonstration-for-its-commercial-p.html.
[4] Shankland, S. (2018, April 03). A startup's medical delivery drones now fly farther and faster.
Watch out, Amazon. Retrieved from https://www.cnet.com/news/zipline-new-delivery-
drones-fly-medical-supplies-faster-farther/
[5] Prime Air. (n.d.). Retrieved from https://www.amazon.com/Amazon-Prime-Air/b?ie=UTF8&node=8037720011
[6] Rosen, Jonathan W. “Blood from the Sky: an Ambitious Medical Drone Delivery System Hits Rwanda.” MIT
Technology Review, MIT Technology Review, 15 Mar. 2018,www.technologyreview.com/s/608034/blood
-from-the-sky-ziplines-ambitious-medical-drone-delivery-in-africa/.
[7] Wong, Derek. “NUS Drone Tests Could Signal Beginning of Unmanned Parcel Delivery.” The Straits Times, 8
Feb. 2018,www.straitstimes.com/singapore/manpower/nus-drone-tests-could-signal-
beginning-of-unmanned-parcel-delivery.
[8] Boyle, Alan. “Amazon Prime Air Drone Gets Delivered to Smithsonian for Museum Display in 2021.”
GeekWire, GeekWire, 15 Aug. 2018, www.geekwire.com/2018/amazon-
prime-drone-gets-delivered-smithsonian-museum-exhibition-2021/.
[9] Johnson, Luke. “9 Facts about Amazon Prime Air Drone Delivery System.” Digital Spy, 7
Feb. 2017, www.digitalspy.com/tech/feature/a820748/amazon-prime-air-drone
-delivery-service/.
[10] FPV Model (2015), “MyTwinDream 1800mm FPV Plane.” from
https://www.fpvmodel.com/u/goods_data/2015-06/20150629155009-1515.pdf
[11] BOEING 103 AIRFOIL (boe103-il) Xfoil prediction polar at RE=500,000 Ncrit=9.(n.d.).
Retrieved December 7, 2018, from http://airfoiltools.com/polar/details?polar=xf-boe103-il-500000
[12] HT05 (ht05-il) Xfoil prediction polar at RE=500,000 Ncrit=5
Retrieved April 03, 2019, from http://airfoiltools.com/polar/details?polar=xf-ht05-il-500000-n5
[13] ArduPilot Dev Team (2019). Automatic Tuning with AUTOTUNE — Plane documentation. [online] Ardupilot.org. Available at: http://ardupilot.org/plane/docs/automatic-tuning-with-autotune.html [Accessed 9 Mar. 2019].
Appendix
Appendix A: System Specifications Document [KT]
- Mission Requirements
- The Mission Statement is satisfied when various objectives are accomplished. These objectives are designated as mission requirements (MR). The MRs shown in Table A-1 are the VIP UHDT Maritime’s success criteria for AY 2018-2019. Each Mission Requirement is fulfilled by functional requirements (FR) created by each individual subsystem. A detailed description of the FR that satisfy each MR is found in Table A-2.
Table A-1: Description of Mission Requirements
Mission Requirement | Description |
Mission | |
MR-1 | The UAS shall be capable of flight with a 2.3 kg payload. |
MR-2 | The UAS shall have the ability to reach the maritime platform 8 km offshore. |
MR-3 | The UAS shall deliver the payload without damage to any component of the UAS. |
MC | The UAS shall adhere to laws set by the government. |
Table A-2: Mission Requirement Fulfillment
Mission Requirement | Functional Requirements that Fulfill the Mission Requirement |
Mission | |
MR-1 | FR-AR-1; FR-AR-4; |
MR-2 | FR-AR-2; FR-AR-3; FR-ES-2; FR-ES-3; |
MR-3 | FR-DS-1; FR-DS-2; FR-DS-3; FR-ES-1; FR-ES-4 |
MC | FR-AR-5; FR-AR-6 |
- Subsystem Functional Requirements
- Each subsystem derived FRs which shall be accomplished in order to fulfill each MR. These are specific tasks which are important to the success of the mission.
Table A-3: Description of Delivery System Subsystem Functional Requirements
Functional Requirement | Description |
Delivery System | |
FR-DS-1 | The payload shall be delivered to a 6 DOF maritime platform in sea states ranging from 0 to 3. [Self-imposed] |
FR-DS-2 | The payload shall be delivered to a vessel with an area of 3 m by 8 m. [Self-imposed] |
FR-DS-3 | The payload shall not be exerted to stress greater than 42.5 MPa. [Self-imposed] |
Table A-4: Description of Aircraft Subsystem Functional Requirements
Functional Requirement | Description |
Aircraft | |
FR-AR-1 | The UAV shall hold/carry a 2.3 kg payload. [ARL] |
FR-AR-2 | The UAV shall reach a platform 8 km (5 mile) offshore. [ARL] |
FR-AR-3 | The UAV shall be able to operate in 6 m/s (10 knot) winds. [ARL] |
FR-AR-4 | The UAV shall be able to produce sufficient lift or thrust to achieve flight. [Self-imposed] |
FR-AR-5 | The UAV shall be not more than 25 kg unless otherwise certified by the FAA. [FAA] |
FR-AR-6 | The UAV shall operate in a manner that does not interfere with, and gives way to, any manned aircraft. [FAA] |
Table A-5: Description of Electronics/Communications Subsystem Functional Requirements
Functional Requirement | Description |
Electronics/Communications | |
FR-ES-1 | The UAV shall be able to identify the target for the delivery method. [Self-imposed] |
FR-ES-2 | The UAV shall have sufficient battery power to fly out 8 km (5 miles) and deliver payload. [ARL] |
FR-ES-3 | The UAV shall maintain operational communications with GCS, R/C, FPV, and provide telemetry data to the GCS up to a 8 km (5 mile) range. [ARL] |
FR-ES-4 | The UAV shall have autonomous RTH/RTL capabilities. [Self-imposed] |
Appendix B: Organizational Chart
Figure B-1. Team Organizational Chart
Appendix C: New Aircraft Tuning SOP [DH]
Due to a complete mission failure crash, the SOP for new aircraft tuning needs to be updated. Until now the SOP for aircraft tuning utilized the Ardupilot “auto-tune” function. This function puts the plane into a highly unstable and maneuverable tune and asks the pilot to force the plane into oscillations. The software alters the gain values on all axes until the aircraft is stable.
After the auto-tune is completed, the plane is put through a series of extreme maneuvers in fly-by-wire mode. The maneuvers made are more extreme than those of which the plane will ever experience in autonomous mode. If there are any oscillations on any axes then that axis will be tuned manually. The manual tuning mainly involves increasing the D value on the PID controller and dampening the inputs until there are absolutely no oscillations.
In this specific situation, the aircraft had been put into auto-tune mode for an unsatisfactory amount of time. The aircraft was initially put into an auto-tune state, and all axes were pushed to their extreme. Then, after the drop rope was added to the aircraft, the aircraft was put into the second round of auto-tune mode where the aircraft was unsatisfactorily pushed to its extreme on the pitch axis. Because of this, after the aircraft was landed, the maximum speed of the aircraft and the maximum climb rate of the aircraft were substantially lower than is viable. Due to this, when UHDT attempted to take off post tune flight, the aircraft was unable to climb given that its maximum speed on climb out was lower than the speed necessary to climb.
In the future, the aircraft needs to be held in its auto-tune function until all axes have been calibrated. Each axis needs to be pushed to its limits at least 20 times[13] in the auto-tune mode at both full throttle and zero throttle. Then, and only then can the first step of aircraft tune be completed.
Appendix D: Object Detection Tutorial [MI]
Introduction:
The goal of the object detection is to meet the functional requirement of the Unmanned Aircraft System (UAS) being able to identify a maritime target for the delivery method. Object detection became necessary when unforeseen problems were encountered when testing the Infrared (IR) Lock sensor. When testing the IR Lock sensor, it was discovered that the effective range would be too low for its desired use. The range of the sensor was determined to be approximately 20 meters. Given that the UAS will be flying at approximately 20 meters per second, the sensor would only allow for approximately one second to detect the boat and for the payload to be dropped. This is clearly infeasible, so another approach will be needed. Another problem with the IR Lock sensor discovered during testing was that it was too sensitive to sunlight and would be ineffective for the purpose of the mission. With object detection, we believe we will be able to increase the range and accuracy for detecting the maritime platform.
Two approaches to object detection will be covered in this tutorial. The first will be to take the input of a live stream from a camera onboard the UAS and send it to a computer on the ground which will process the video to detect the boat. The second will be to use a Raspberry Pi Camera onboard the UAS so that the processing of the video can be done onboard the UAS. The benefit of the first approach is that a computer will be able to process the video much faster than a Raspberry Pi. However, the video will first need to be sent from the feed onboard the UAS to the computer on the ground which will cause a delay. Both approaches are similar, but you will need to determine which approach is most ideal for the task.
A brief description of object detection is a computer technology associated with image processing and computer vision used to detect instances of different classes of objects in pictures and videos. The two main categories of object detection are machine-learning and deep-learning. The method we chose to work with was the deep-learning approach, in particular, an approach called You Only Look Once (YOLO). YOLO is a real-time object detection system that is fast and accurate. The way YOLO works is by dividing an image into regions and predicts probabilities in each region. The predicted probabilities are used to weight the predictions of the bounding boxes. An advantage of using YOLO is that it is trained on the Common Objects in Context (COCO) dataset. The COCO dataset includes people, cars, animals, household objects, and much more. But most importantly for our application, COCO is trained on boats.
A disadvantage of using YOLO object detection is that it can struggle to detect smaller objects as well as objects grouped closely together. However, in our application, we don’t have to worry about objects being grouped closely together since the boat will be in the middle of the ocean. Therefore, the many advantages of using YOLO definitely outweigh the drawbacks. In our application, we don’t have to worry about objects being grouped closely together
The implementation of the YOLO object detection will be done using the software OpenCV and Tensorflow. The process for installing OpenCV and Tensorflow will be covered in the section below.
Installation Process on macOS:
This section will go over the installation process for the software that is necessary for object detection on macOS. The tutorial will cover the installation of Python, OpenCV, and Tensorflow. The first installation that will be covered is Python. Python is a programming language commonly used in applications like object detection. To download Python, the first step is to download the Python 3 installer. This can be done using the download page of python.org. Although there are newer versions available, be sure to download Python 3.6 or older. The reason this is necessary will be explained later in the tutorial.
The best way to install Python on macOS is to use a package manager called homebrew. However, homebrew is dependant on a software package called XCode. So, the first command you will need to run in the Terminal is xcode-select --installx. After XCode is installed, you can install homebrew running the command /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" in the Terminal. To verify that homebrew is properly installed, run the command brew doctor. If homebrew is installed properly you should see the output “your system is ready to brew.” Be sure to update your ~/.bash_profile, failure to do so can cause errors later on. You can update your ~/.bash_profile by opening it with a text editor, I prefer Atom. After opening the ~/.bash_profile, add export PATH=/usr/local/bin:$PATH to the bottom of the file. Then run the command source ~/.bash_profile to save the changes.
Finally, you can install Python using the command brew install python3. To verify that Python was installed successfully, run the command python3 --version and the version of Python that is currently installed should be output in the command window.
Next, we will cover the installation process for OpenCV. OpenCV is a computer vision library primarily used for real-time applications.
Before beginning the installation process, verify you have version 3.6 of Python. OpenCV is not supported by Python 3.7, so it is very important that you confirm you have the proper version. If you currently have Python 3.7, you will need to uninstall it and reinstall Python 3.6. To uninstall Python on a Mac there are multiple options. The first is to open the applications folder, select the Python folder, move it to the trash, and empty the trash. However, you will then need to find and remove any other files Python created. The next option is to use the command line and run the command sudo rm -rf /Applications/Python\ 3.7/. The last option is to download an app cleaner/uninstaller from the App store.
To install OpenCV on macOS you will first need to make sure you have Xcode and homebrew installed. If you do not, the installation process for them can be found above in the Python installation process section. After verifying you have Xcode and homebrew installed, you can begin to install the dependencies for OpenCV. These packages will be used to do things like build and compile OpenCV, I/O operations, or for optimization. To install these dependencies, run the commands shown below from the command line.
Another useful tool to install is wget, which allows you to download files from the internet via the command line. You can install wget by running the command brew install wget. You can now take advantage of the wget command to install a Python package manager called pip. To do so, run the command wget https://bootstrap.pypa.io/get-pip.py followed by sudo python3 get-pip.py. Now that you have pip installed, you can install a virtual environment to manage your Python projects. It is recommended, but not necessary. The benefit of using a virtual machine is so that when working on multiple projects, each project's dependencies are independent of each other. The steps to do install the virtual manager are to first run the command sudo pip3 install virtualenv virtualenvwrapper . Then, you will need to again modify your bash profile. You can do so by either using a text editor or directly from the command line. If you chose to edit the bash profile using a text editor, append the following lines shown below to the end of the file and save the changes.
If you choose to edit the bash profile from the command line, execute the commands shown below.
Now that you have installed a virtual environment, you can use it for OpenCV. Run the command mkvirtualenv cv -p python3, which will create a virtual environment named “cv.” To work in the virtual environment, use the command workon cv. Now that you are in the virtual environment, the next step is to install the Python library NumPy, which can be done using the command pip3 install numpy. You are now ready to compile OpenCV. While it is possible to compile OpenCV using package managers such as homebrew or pip, the recommended way to do so is to compile OpenCV by source. Although compiling OpenCV by source is much more tedious, it is the most proper and robust way of doing so. First, you will need to download the opencv and opencv_contrib zip files. This can be done using the commands wget -O opencv.zip https://github.com/opencv/opencv/archive/4.0.0.zip
wget -O opencv_contrib.zip https://github.com/opencv/opencv_contrib/archive/4.0.0.zip. To unzip the files, use the commands unzip opencv.zip
unzip opencv_contrib.zip. Next, you will need to navigate back to the OpenCV directory and inside the OpenCV directory you will need to create a build directory. This can be achieved by running the commands cd ~/opencv and mkdir build. After creating the build directory, enter it by issuing cd build. Once in the build directory, you will want to work in a virtual environment do so by issuing workon cv. Once in the virtual environment, we will use CMake to begin the compilation process. Execute the command shown below.
When the CMake is finished running, you should see output that looks similar to the output shown below.
If the output of the CMake is good, you can proceed to compile OpenCV by running the command make. The compilation of OpenCV will take a while so don’t be alarmed if it does not finish quickly like the previous commands that have been run. After the compilation is complete, you should see an output that looks similar to the output shown below.
Finally, you can install OpenCV by running the command sudo make install. To verify that OpenCV is properly installed, run the commands import cv2 followed by cv2.__version_. If OpenCV is properly installed, the output of these commands should show the version of OpenCV that is currently installed.
Next, we will cover the installation process for TensorFlow. TensorFlow is an open-source library for numerical computation and machine learning. Again, be sure you are working with Python 3.6 before beginning the installation process for TensorFlow as it is not supported by Python 3.7.
The first step in the installation process for TensorFlow can be done by executing the command pip3 install tensorflow. Next, you will need to install some of the dependencies needed by TensorFlow. This can be achieved by running the commands shown below.
As mentioned previously, the COCO dataset will be used for object detection. The following commands will help download the COCO API as well as copy it to the appropriate directory for TensorFlow. The to download the COCO API is git clone https://github.com/cocodataset/cocoapi.git. The command
cd cocoapi/PythonAPI will allow you to change into the appropriate directory. Once in the correct directory you can run the command make. The last command is
cp -r pycocotools <path to tensorflow>/models/research/ which will copy the files to the research directory.
TensorFlow’s object detection API uses protocol buffers also called protobufs to configure various parameters. Protbufs are used to serialize data and were designed to be simple and efficient. Before you can use Protobufs, the libraries must first be compiled. To compile the libraries you must change directories into the research directory inside the TensorFlow directory. To navigate to the proper directory, run the following commands cd tensorflow cd models cd research. Once inside the research directory, run the command protoc object_detection/protos/*.proto --python_out=.
If you receive an error after running the above command, you will need to manually install the protobuf compiler from within the research directory. To do so, first, you will need to download and unzip the protobuf file by executing the commands wget -O protobuf.zip https://github.com/google/protobuf/releases/download/v3.0.0/protoc-3.0.0-linux-x86_64.zip and
unzip protobuf.zip. It is important to note that you download the version for the operating system that you are working with. Then you can recompile by re-running the command protoc object_detection/protos/*.proto --python_out=. If you wish to add the libraries to the Python path, you will need to edit the bash profile. As previously explained, open your bash profile and add export PYTHONPATH=$PYTHONPATH:`<complete path to tensorflow/models/research`:`complete path to tensorflow/models/research`/slim to your ~/.bashrc file. Finally, you can test that you have TensorFlow properly installed by running python3 object_detection/builders/model_builder_test.py. If you get any errors for missing dependencies, you can install them by running the command python3 -m pip install name_of_dependency.
Applications for Object Detection on macOS:
Now that you have all the necessary software packages installed, we can use them to implement object detection. You will need to create a directory to store all the relevant files for object detection. You can name the directory “yolo_object_detection” or something similar. To create this directory simply run the command mkdir yolo_object_detection. Within the directory you just created, create another directory called “yolo_coco” which will contain the dependencies for the COCO dataset. This directory can be created using the command mkdir yolo_coco. The three things that you will need to download in this folder are coco.names, yolov3.cfg, and yolov3.weights. These files can be downloaded from https://github.com/pjreddie/darknet/blob/master/data/coco.names, https://github.com/pjreddie/darknet/blob/master/cfg/yolov3.cfg, and https://pjreddie.com/media/files/yolov3.weights respectively. Next, you can create a Python file called “yolo_image.py” which will contain the code that will be used for object detection. The code used is shown in the figures below.
To run this code execute the command python3 yolo.py --image images/name_of_image.jpg --yolo yolo-coco.
A sample output of this code can be seen below. As you can see a box is output around each object that was detected as well as a confidence.
The YOLO implementation for video is very similar to that of the implementation for images. You will need to create a new Python file called “yolo_video.py”. The code needed is shown below.
To run this code execute the command python3 yolo_video.py --input videos/name_of_video.mp4 \ --output output/output_video.avi --yolo yolo-coco
A sample output of the code can be seen below.
As you can see, the model is able to track the boat well for the most part. At certain angles and further distances, it loses track of the boat for small periods of time. However, it is able to recover and begin tracking the boat again fairly quickly.
Installation Process for Raspberry Pi:
This portion of the tutorial will cover the process for implementing object detection using a Raspberry Pi and Raspberry Pi Camera.
The first step is to download the New Out Of the Box Software (NOOBS) zip file which can be found at https://www.raspberrypi.org/downloads/noobs/. NOOBS is an operating system installer which contains the operating system for the Raspberry Pi called Raspbian. You will also need a MicroSD card and a USB adapter for the MicroSD card. I suggest you use a 32 GB MicroSD card at a minimum. You can then use the software package balenaEtcher to flash NOOBS onto the MicroSD card. Once NOOBS has been flashed onto the MicroSD card, you can insert the MicroSD card into the Raspberry Pi. To power the Raspberry Pi, you will need a Micro USB cable. Initially to setup your Raspberry Pi you will need to either connect the Raspberry Pi to a computer that has a mouse and keyboard. If NOOBS was properly flashed onto the MicroSD card, once the Raspberry Pi is connected to a monitor and powered on, the Raspberry Pi will boot and a Raspberry Pi configuration menu should appear. If you have issues, be sure to verify that NOOBS was flashed onto your MicroSD card properly.
This next step will cover setting up Secure Shell (SSH) so that you can remotely access your Raspberry Pi using any computer. This step is unnecessary but will make it more convenient for yourself later. So if you want you can skip to the next section. First, you will need to use the preferences menu to navigate to the Raspberry Pi configuration window. Next, select the interfaces tab and ensure that SSH is enabled. After enabling SSH, run the command hostname -I to get the IP address for your Raspberry Pi. Now you will be able to remotely access your Raspberry Pi by running the command ssh pi@ip_address_of_your_pi from the command line of a terminal. When you SSH into your Raspberry Pi, you will be prompted to enter the password which should be set as raspberry by default.
Now you can begin the process for setting up object detection on your Raspberry Pi. Before beginning, I recommend that you place a heat sink on the processor of the Raspberry Pi as this will be a long process. The heat sink will help prevent the processor from overheating. The first thing to do is to ensure your Raspberry Pi is updated. To do so run the command sudo apt-get update from your Raspberry Pi terminal followed by sudo apt-get dist-upgrade. Next, we will work on installing TensorFlow. Be sure that you are in your /home/pi directory. Within the pi directory you can create a directory called tf to store all the necessary files. To do so run the command mkdir tf and then you can enter that directory using cd tf. Then, you can download a pre-built file for installing TensorFlow on the Raspberry Pi using the command wget https://github.com/lhelontra/tensorflow-on-arm/releases/download/v1.10.0/tensorflow-1.10.0-cp35-none-linux_armv7l.whl. After downloading the file, you can install it by running the command sudo pip3 install /home/pi/tf/tensorflow-1.8.0-cp35-none-linux_armv7l.whl. Next, some dependencies needed by TensorFlow will need to be installed. You can install the dependencies by running the following commands shown below.
After installing the dependencies, you will have completed everything needed for TensorFlow at this time.
Next, you can move on to the installation for OpenCV. The installation process is very simple. As you did previously for TensorFlow, you will need to install some dependencies that are required by OpenCV. The installation of the dependencies can be completed by executing the following commands which are shown below.
After the dependencies have been installed, simply run the command pip3 install opencv-python. This completes the OpenCV installation.
You will now need to compile and install the protobufs that TensorFlow’s object detection is reliant upon. First, you will need to install the packages that are used to compile Protobuf. This can be achieved by running the command sudo apt-get install autoconf automake libtool curl. Then, you will need to download the protobuf using the command wget https://github.com/google/protobuf/releases/download/v3.7.1/protobuf-all-3.7.1.tar.gz. If there is a newer version available, feel free to download it instead. Next, you will need to unpack the file you downloaded using the command tar -zxvf protobuf-all-3.7.1.tar.gz. Then, change directories into the folder by running the command cd protobuf-3.7.1. Once in the protobuf directory, you can configure the build by issuing the command ./configure.When the configuration is complete, you can build the package by running the command make. The build process will take a while so don’t be alarmed if it runs for about an hour. When the build is finished run the command make check. This process will take even longer than the build. After the make check is completed, you can run the command sudo make install. Next, change directories into the python directory using the command cd python. Once in the python directory, you can export the library path by executing the command export LD_LIBRARY_PATH=../src/.libs. Then, run the commands shown below.
Next, run the following commands shown below to set the proper paths.
Finally, execute the command sudo ldconfig. To verify that protobuf has been properly installed you can run the command protoc and make sure that there are no errors. In order for TensorFlow to work properly, the Raspberry Pi will need to be rebooted after completing the protobuf installation. To reboot the Raspberry Pi run the command sudo reboot now.
After the Raspberry Pi reboots, you can set up the TensorFlow directory. From your home directory, create a new directory called tensorflow_test and then enter that directory. This can be done by running the commands mkdir tensorflow_test and cd tensorflow_test. Once in the new directory, you can download the TensorFlow github repository using the command git clone --recurse-submodules https://github.com/tensorflow/models.git. Next, you will need to modify PYTHONPATH in the .bashrc file. To open the .bashrc file run the command sudo nano ~/.bashrc. Once in the .bashrc file, navigate to the end of the file and add the line shown below.
Then, you can save and exit the bashrc file.
Next, you will need to use protoc to compile the .proto files needed for object detection. You will need to compile the files in the research directory. To navigate to the research directory, use the command cd /home/pi/tensorflow_test/models/research. Once in the research directory, run the command protoc object_detection/protos/*.proto --python_out=. The previous command converts all the .proto files to .py files (python files). The next steps will need to be done in the object_detection directory. To navigate to the object_detection directory execute the command cd /home/pi/tensorflow1/models/research/object_detection. Once in the object_detection directory, you will need to download one of TensorFlow’s pretrained object detection models. Since the Raspberry Pi has a weak processor, you will need to download the fastest model possible. The tradeoff for speed is lower accuracy. However, as stated previously the decrease in accuracy is not a concern. To download the model execute the command wget http://download.tensorflow.org/models/object_detection/ssdlite_mobilenet_v2_coco_2018_05_09.tar.gz. At the time this is currently the fastest model available, but if a faster model is available in the future you should download it instead. Finally, you can unpack the model by running the command tar -xzvf ssdlite_mobilenet_v2_coco_2018_05_09.tar.gz.
Applications on Raspberry Pi:
Now that all the necessary packages are installed on the Raspberry Pi we can begin the process of implementing object detection. Within the object_detection directory, you can create a Python file called “object_detection.py”. The code needed is shown in the figure below. Before running the script, be sure to enable the camera using the Raspberry Pi configuration menu. Also, be sure to connect the Raspberry Pi camera to the Raspberry Pi.
To run this code execute the command python3 object_detection.py.
A sample output can be seen below.
Appendix E: SolidWorks Drawings [SO]
- Zoomed in Servo Baseboard SolidWorks drawing
- Zoomed in PixHawk Bracket SolidWorks drawing
- Zoomed in Payload Bracket SolidWorks drawing
- Zoomed in Payload Attachment Piece SolidWorks draw
- Zoomed in Payload Stabilizer SolidWorks drawing
Appendix F: UHDT Timeline for Program Management
For the successful completion of the mission tasks, it is important to understand the upcoming events for the project and anticipate important events, such as reports, presentations, and integration day. This timeline is helpful in the program management side of things and will be beneficial for future years of UHDT (though edited specifically for UHDT-M). Much of the program management logistics will be accomplished in the beginning of each semester. It is important to maintain team morale with successful team bondings and flight tests throughout the semester. The spring semester timeline has significantly less events and things to do, due to the importance of the final push for flight tests. UHDT-M has had 2-3 flight tests per week for every week possible.
Fall Semester Timeline
Week 1
Establishment of meeting times, welcome meeting, determination of members and introduction to subsystem leaders, project manager and chief engineer.
- Explain the design notebook - list important notes from meetings and all reasoning/rationale for decisions made for mission ops
Roles to be assigned at beginning of semester/year:
- Scheduler (flight tests, team meetings/outings, rehearsals, cleaners; use of when2meet)
- Safety Pilots
- Webmaster
- Will probably need a new team picture for the website
- VIP Presentation Board (for “presentation” fair in November)
- Recorder (to take minutes at meetings, notes during rehearsals and presentations, etc)
- Videographer
First Admin/Leadership Meeting
- Introduction of members, advisors, mentors, etc
- Establish mission and functional requirements, beginning with problem statement
Week 2
First subsystem meetings, establish expectations from members and set initial tasks, explain the purpose of the mission operations lead.
- Create the mission plan
- Checklists
- Flight tests and safety pilot logs
- Explanation of overall system -> give members context
Week 3
Explanation of and delegation of tasks for the project proposal presentation and report
Week 4
Ensure understanding of mission and mission requirements
Week 5
Proposal presentation, final edits for the report
- 9/18: Proposal Presentation
- 9/22: Proposal Report due
- 9/22: SPRG Proposal
Week 6
Review previous years’ t-log files and read through mission planner manual, create first draft of mission plan
- Explain what a t-log file is and how it relates to our mission plan
Week 7
Check changes in the competition rules, determine all necessary items for each task being attempted and required time, meet with subsystem leads and begin research for PDR.
- PDR: what changes need to be made from last year’s UAS, research and rationale for each adjustment
Week 8
PDR research and rationale, slides and drafting MO portion of the PDR
- Should have rationale for our mission requirements (e.g. why we chose to have a PDB as opposed to other options for electronics, why the landing gear is being attempted and how it can help us)
- Include reasoning for direction of flight, order of tasks, altitude, search area task route, changes to air delivery, changes to mission plan
- 10/10: UROP Proposal (if applicable)
Week 9
Work on PDR presentation slides and report
- 10/16: presentation slides due
- 10/20: PDR draft due
- 10/20-25: PDR editing
Week 10
Editing for PDR
- Determine number of flight tests needed
- For Mission Ops: flight logs for each test, safety pilot logs, write short mission plans (how many waypoints are needed, multiple altitudes, what/how we will be testing)
- 10/23: PDR presentation
- 10/27: Final PDR due
Week 11
- Work on mission plans for flight tests
- Checklists for test flights - mostly copied from year before; be sure to edit as needed
- Edit mission plan timelines in accordance with previous year’s t-log file times
Week 12
- Adjust mission plans, checklists, etc.
- Mission plans should be finalized before test flights
- Edit checklists with test flights
- Team Bonding (Veteran’s day)
Week 13
- Ensure electronics and other manufacturing materials are ordered
Week 14
- Draft for CDR
- Checking and editing mission operations binder
- All checklists
- Train members to do pre-departure checks
Week 15
Editing for CDR
- 11/27: CDR presentation draft due
- 12/1: CDR report draft due
Week 16
Final edits for CDR
- 12/4: CDR presentation
- 12/6: CDR due
**Final Exams: 12/11 - 12/15
**Commencement: Dec 16
** Happy Holidays !!! **
Spring Semester Timeline
Week 1
- Spring Registration for all members
- Scheduling for flight tests and weekly meetings
- Introduction of new members and new roles (if applicable)
- Add all new members to Google Drive sharing
Week 2
- Create pairings for flight tests (to ensure enough people are at each flight test)
- Create tentative schedule for flight tests
- Ensure manufacturing and bench-level testing begins
Week 3
- First spring flight test (approximately) - best to use Martin Luther King, Jr. Day (day off from school)
Week 4
- Flight tests and bench level testing
Week 5
- Flight tests and testing
Week 6
- Outline for Midterm Report (TDP)
- Begin assigning DDMR roles for presentation
Week 7
- Draft for Midterm/TDP
- Editing and rehearsal for DDMR
Week 8
- Detailed Design Manufacturing Review Presentation
- Midterm/TDP Editing
Week 9
Week 10
- CoE Banquet List Due - Assign to a member
- 3/16: Integration Day
Week 11
- Midterm Report & Presentation
Week 12 ** Spring Break **
- Additional flight tests
Week 13
- Alpha Prototype Hardware Demonstration
Week 14
- Team bonding
Week 15
- College of Engineering Banquet
Week 16
Week 17
- Final Report Writing
- Peer Evaluations
** Final Exams: 5/6 - 5/10
** Commencement: May 11
University of Hawaii at Manoa // University of Hawaii Drone Technologies Maritime