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
TITLE PAGE
Post Flight Report
Introduction
This report details the performance of Project Icarus during the two major tasks - Long Range Passenger Transport, and On-Demand Passenger Transport. It covers preparation, performance, analysis, and improvements that were made during the course of both tasks.
Task 1 - Long Range Passenger Transport
Requirements
Task 1 entails competitors loading passengers into the UAMS vehicle over a specified route encoded in a QR code. Furthermore, a diversion in the route is also provided in a second 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).
Aircraft Performance
Overall, Task 1 was attempted but not successful at reaching any waypoints. Icarus was initially flown in full quadplane configuration with wings, and at first, was hovered to test motor efficacy. The first hover was performed for about 3 minutes, before the rear-left motor failed, causing the drone to come down in a semi-hard landing from a height of about two meters above the ground. The flight-line team thereafter removed the wings to reduce weight, and tried running a hover-test 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.
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 output for the system when the QR Code was scanned 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 System
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:
// SHOW GRAPHS HERE
Additionally, the motor was seen to be noticeably warmer once it failed, leading to a conclusion that the problem was due to the overheating of the motor.
Task 1 - Action Items
A post-flight debrief was conducted to determine the cause of the motor failure problem, such that Icarus can be fixed and modified for Task 2 the next day. It was determined that Icarus had a very heavy airframe, causing the quad motors to be put under very 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 drone. The following tasks were determined to reduce the weight:
Remove wings
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 they are VTOL drones, they are designed to be used at very high throttle for short periods of time before the aircraft transitions to fixed-wing operation. This was further bolstered by the lack of ventilation on the motors. Hence, it was determined that the motors will have to be changed to other motors with smaller voltage requirements that were brought with the team.
Because the new motors, 7-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 time.
Overall, various modifications were made and the quadplane airframe was essentially redesigned as a quadcopter with a much lighter frame and more effective motors.
Task 2 - On-Demand Passenger Transport
Requirements
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 sec. 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 Task 2 was to manually determine 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 travelling 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 waypoint generation were not used. The chosen routes, in order, are shown in the diagram
