Post-Flight Report Notes

Deliverables

• Title Page

• Overview of each task requirements (task 1 and 2)

• Detailed results of each task (technology, route planning, overall results, what went wrong, etc.)

• Overall comments - how well things went, lessons learnt, etc.

• Conclusion

Generic structure - title page, task 1: requirements, details, results - task 2: requirements, details, results --- conclusion

Introduction

This report details the performance of WARG’s solution to Big City’s urban mobility needs - Project Icarus. This primarily concerns the performance during the two tasks at the AEAC Student Competition: Long Range Passenger Transport and On-Demand Passenger Transport. It covers preparation, performance, analysis, improvements, and key takeaways that were made during the course of both tasks.

Task 1 - Long Range Passenger Transport

Requirements

Task 1 entails bidders loading passengers into their UAMS and then flying it over a route specified in a QR code. During the flight, a diversion is required to avoid an exclusion zone and rejoin the original route at a specified waypoint, provided in a different QR code.

The planned approach was to use the received route information once the QR code is scanned to create a waypoint plan automatically, load it into Mission Planner, and flash it into the flight controller. Once flashed, the aircraft would be armed, take off, and begin the waypoint mission flight. As the drone flew and sent the diversion information, the chosen approach was to create a modified waypoint mission to avoid the exclusion zone and rejoin.

Aircraft Performance

Overall, Task 1 was not attempted and unsuccessful in reaching any waypoints. Icarus was initially flown in its full quadplane VTOL configuration with wings. In previous flights, unpredictable motor behaviour was observed where one motor would fail after an arbitrary amount of time. Hence, the team elected to do a motor and hover test from a safe height above the ground to see if the aircraft would be able to sustain flight for long enough, safely. The first hover was performed for about 3 minutes, before the rear-right motor (4) failed, causing the drone to come down in a hard landing from a height of about two meters above the ground.

Analysis of the motor failure indicates that the failure was caused was due to overheating of the motor from running at high power for a prolonged period of time. The flight-line team thereafter removed the wings to reduce weight and tried running a hover-test again to test the motor again. Unfortunately, the same problem occurred and the rear-right motor gave way. Through more investigation and research into motor specifications, it was concluded that the desired flight profile, as a fixed wing aircraft with vertical takeoff capability, was not achievable using the current motors in the given weather conditions, as these motors were intended to run at maximum current for three minutes at a time but we experienced failures far faster than the rated operating time. The team concluded it would be unsafe to transition without further validation of the aircraft performance.

Data from past flights show direct correlation between ambient temperature and flight time before motor failure.

Open

Outside temperature vs flight Time before motor failure

Autonomy

Software was written to read the QR code scanning technology, take the waypoint information, and convert it into a list of mission planner destinations that can be written to a file and uploaded to the Mission Planner. This code was written such that the shortest paths were selected and that the aircraft didn’t travel into restricted areas. This was determined using Dijkstra’s shortest-path algorithm.

The QR code being scanned, and the output for the process, is shown in the images below:

Open

QR Code being scanned by the in house scanning system

The QR-Code scanning technology for the initial waypoint sequence generator was tested and functional. Unfortunately, the system could not be used during Icarus’s attempt at Task 1 due to the persistent motor failure.

Control Systems

The rear-right motor failed in both flights that were performed. The logs from the flight controller were analyzed, and various qualitative and quantitative data was used to determine potential problems and action items to fix those issues. Firstly, a graph showing the throttle commands from the flight controller to each of the motors is shown below:

The graphic below shows where the motor numbers are with respect to their position on the drone.

As can be seen, the throttles commanded from ArduPilot were at 100%, however the drone was still losing altitude. This was seen in a visible dip in the rear left motor, implying the motor slowed down drastically. The ESC was not the cause - replacing the ESC did not fix this problem. It was not a signal wire issue either, as the motors continued to spin after they gave way. For a signal issue, the locking motors should have stopped turning as no direction would be provided to the motor. Additionally, the motor was seen to be noticeably warmer once it failed, leading to a conclusion that the issue was due to the motor overheating. The overheating failure was never observed beforehand, as the ambient temperature was sufficient to cool the motors when the airframe was being tested during winter.

Task 1 - Action Items

A post-flight debrief was conducted to determine the cause of the motor failure to decided how Icarus could be fixed and modified for Task 2 the next day. One of the major problems was the high weight of Icarus, causing the motors to be placed under a high load. Various solutions were proposed, including replacing the motors, cutting weight, and adding extra motors to allow for more thrust. Ultimately, it was decided that the drone weight needed to be cut down to a sub 7kg flight weight. It was critical, however, to keep structural components of the aircraft for safety and optimal performance. The following tasks were determined to reduce the weight:

• Remove wings and mid-wing sections

• Remove tail-section

• Remove pusher motor and prop

• Remove all mounting hardware and sensors that were not required for quadcopter flight

The datasheets for the quad motors were examined and it was seen that the motors were not optimized for continuous operation. Since they are VTOL motors, they are designed to be used at very high throttle for short periods of time before the aircraft transitions to fixed-wing operation, and not for continuous quad flight. This issues was further exacerbated by the lack of ventilation on the motors. Hence, it was determined that the motors would need to be changed to motors with lower power draw, increased efficiency and more appropriate duty cycle requirements. New motors, Titan T6015, were borrowed from another team and mounted on the aircraft. These motors are optimized for quadcopters, have sufficient ventilation, and are rated for the required thrust of our aircraft.

Overall, various modifications were made and the quadplane airframe was essentially redesigned as a quadcopter with a much lighter superstructure, and more effective motors.

Task 2 - On-Demand Passenger Transport

Requirements

Task 2 models a scenario where various transit routes are provided, and paths between these waypoints are followed, all while picking up and dropping off passengers at their desired destinations. With the same cabin and landing pad used in Task 1, the competitor must carry the passengers and land on the pad with rotors stopped for 15 seconds. A QR code was given that detailed the available routes, and specific routes were to be chosen to fly.

The approach taken for Task 2 was manually determining routes that were close to the starting location and had a short travel distance. These routes were then to be uploaded to Mission Planner and flown with an established geofence.

Aircraft Performance

The aircraft was able to successfully arm without errors on the first attempt. It was taken off in stabilize mode and flew well without excessive vibration. The aircraft was then tested in Loiter, where it demonstrated excellent stability for 3D position hold. After a short hover, the aircraft landed, waypoints were uploaded, and it armed in preparation for takeoff. Following takeoff, the altitude was manually increased to 50 m before the aircraft was switched into auto mode. The aircraft began to fly the mission shown below. Before reaching the first waypoint, the aircraft threw a geofence failsafe and began to return to home. The pilot in command switched the flight mode back to Loiter and attempted to fly down the runway manually. Again, the aircraft hit the fence and entered Return To Land. Return To Land was followed until the aircraft was close to the takeoff location, where the pilot then switched to Loiter and landed via down-facing FPV camera.

In reality, the aircraft was on route and did not hit the geofence. There may have been an issue with the uploading or configuration of the boundary. The pilot returned to Loiter mode, brought the aircraft back, and landed it in the location where it had taken off. New parameters were uploaded to the aircraft to change the geofence behaviour, but connection issues and failsafe prevented the aircraft from arming again. The error given was an internal ArduPilot error that had not been experienced before by any members of the flight line. The flight line team attempted to resolve the issue but were unable to within the flight window.

Autonomy

The software reuses the QR scanner from task 1 to convert the QR code into routes. The distance and revenue of each route were used to calculate a cost, which was then used as input to a vehicle routing algorithm that generated the optimal path for the aircraft. Battery swaps i.e. returning to waypoint Alpha were also taken into account. An email containing the path would be sent to the competition organizers.

The team instead chose to manually chart a path to optimize chances of safe success rather than for cost.

Routes are shown in the diagrams below:

Conclusion

Overall Performance and Lessons Learned

Over the course of Task 1 and Task 2, various faults were identified and noted for subsequent years' competitions. The most significant lesson learned from the competition tasks was to keep the drone design simple, test frequently, and test during different weather conditions. The original design of the aircraft was a VTOL fixed-wing hybrid which was optimized for controlled vertical landing on landing pads as well as long-distance flying between waypoints. However, the drone’s weight was greater than anticipated, and the motors were not able to generate enough thrust for sufficent landing and takeoff times. All testing of the aircraft was performed in the winter with very cold temperatures, so the overheating issues were never encountered by the team. Therefore a valuable lesson learned was to take into account the ambient temperature of the drone when conducting flight tests.

The mass of the aircraft increased much higher than anticipated after integrating systems such as landing gear, control surfaces, video, lights, and GPS. The mass of long cables and solder, as well as tape and hot glue were underestimated causing the overall mass of the drone to be over the 15 kilogram limit when conducting the Flight Readiness Review. Ultimately, designing the competition airframe as a quadcopter would have been significantly simpler, weighted less, and would allow for a larger number of flight tests to tune to drone and practice flying to waypoints and landing on landing pads.

During the Task 2 flight window, radios were used as a method of communication between the flight line and the ground control tent. The radios were unclear and the team resorted to using cellphones to communicate. More testing should have been done on the radios beforehand. The organizational flaw during the Task 2 is that the flight line communications could have been made more clear by using predefined roles and tasks.

Final Comments

Project Icarus attempted both Task 1 and Task 2 of the UAS 2023 competition as detailed in the CONOPS. Icarus went through multiple rapid prototype and development phases throughout the competition, but ultimately all configurations were not able to complete the tasks as expected. Various reasons were detailed and analyzed as to why the goals were not achieved, and takeaways were noted for subsequent competitions. WARG has a lot of points to take back and work on for the drone during next year’s competition season.