...
Generic structure - title page, task 1: requirements, details, results - task 2: requirements, details, results --- conclusion
TITLE PAGE
Post Flight Report
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 major tasks - tasks at the AEAC Student Competition: Long Range Passenger Transport , and On-Demand Passenger Transport. It covers preparation, performance, analysis, improvements, and improvements key takeaways that were made during the course of both tasks.
...
Requirements
Task 1 entails competitors bidders loading passengers into the UAMS vehicle their UAMS and then flying it over a route specified route encoded in a QR code. FurthermoreDuring the flight, a diversion in the route is also is required to avoid an exclusion zone and rejoin the original route at a specified waypoint, provided in a second different QR code with information about restricted zones and the new waypoint in the route.
The planned approach was to use the autonomous mode of the aircraft to take-off and reach each of the waypoints. Using a QR code scanning system, the encoded waypoints would be uploaded to Mission Planner directly, and the aircraft would take off to a fixed height of 60 meters (to clear any trees)received route information once the QR code is scanned to create a waypoint plan, 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 attempted but not successful at not attempted and unsuccessful in reaching any waypoints. Icarus was initially flown in its full quadplane VTOL configuration with wings. 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, and at first, was hovered to test ensure motor efficacy since unpredictable motor behaviours were observed in previous tests. The first hover was performed for about 3 minutes, before the rear-left right motor (4) failed, causing the drone to come down in a semi-hard landing from a height of about two meters above the ground.
The motor failure was due to overheating and running the motor 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 as before occurred and the rear-right motor gave way. By this time, the flight window was over and the team realized that significant changes to the drone have to be made.Through more investigation and research into motor specifications, it was concluded that the desired flight profile was not achievable using the current motors, as these motors were intended to run at maximum current for three minutes at a time - not for sustained quad flight. 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.
...
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, with the fences being treated as edges in the graph.
The QR code being scanned, and the output for the system when the QR Code was scanned process, is shown in the image below:
...
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 that occurred.
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 ArduPilot were at 100%, but however the drone was still losing altitude. This was concurred by seen in a visible dip in the rear left motor, implying that the motor stopped workingslowed down drastically. The ESC was not the cause - replacing the ESC did not fix this problem. It was deemed to not be because of the motor controller, as the system is 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 overheating of the motormotor 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 problem, such that Icarus can to decided how Icarus could be fixed and modified for Task 2 the next day. It was determined that Icarus had a very heavy airframeOne of the major problems was the high weight of Icarus, causing the quad motors to be put placed under very a high load. Various solutions were proposed, including replacing the motors, cutting weight, and adding extra motors to allow for more thrust. Ultimately, to mitigate these issues, it was decided that a lot of weight would be cut back on the dronethe 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 cross-bars and other required sections for fixed-wing flight
Furthermore, the datasheets for the quad motors were examined and it was seen that the motors were not optimized for continuous operation. Because 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. This issues was further bolstered exacerbated by the lack of ventilation on the motors. Hence, it was determined that the motors will have would need to be changed to other motors with smaller voltage requirements that were brought with the team.Because the new motors, T-Motor's MN5008 KV:340, run most effectively off a 6S architecture, the harnessing was also changed from 12S to 6S and thus, two 6S batteries were used in parallel to maximize flight timelower power draw, increased efficiency and more appropriate duty cycle requirements. New motors, Titan T6015, were borrowed from another team and mounted on the aircraft. They were optimized for quadcopters, had sufficient ventilation, and the thrust that was required.
Overall, various modifications were made and the quadplane airframe was essentially redesigned as a quadcopter with a much lighter frame superstructure, and more effective motors.
...
Task 2 models a scenario where various routes are given, and need to be optimized while picking up and dropping off passengers at numerous given waypoints. 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 secseconds. A QR code was given that detailed the available routes, and specific routes were to be chosen to fly.
The approach taken by WARG on for Task 2 was to manually determine determining routes that were not only close to the starting location , but also had an overall short distance to travel. Although an algorithm modelled around the traveling salesman problem was designed and tested, it was made to maximize revenue, and not minimize distance. Ultimately, the former was deemed too risky, and thus, the autonomy points for way-point generation were not used. The chosen routes, in order, are shown in the diagram
...
...
and had a short travel distance.
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 were chosen manually, and are shown in the diagram 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 and to test often, in various weather conditions. The original design of the aircraft was a VTOL fixed-wing hybrid which was optimized for controlled landing on landing pads, as well as long-distance flying between waypoints. However, the weight of the drone was too high, causing the motors to have to work harder and overheat, preventing the drone from flying longer than three minutes. All of the testing for 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, weighed 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
Ultimately, 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.