From Simulation to Takeoff: A Campus Science and Technology Competition on Autonomous Flight Drones

The evolution of educational drone programs has reached a pivotal moment: the transition from manual piloting to fully autonomous systems. To cultivate the next generation of aerospace engineers and computer scientists, universities and high schools are increasingly adopting high-stakes, project-based competitions. This paper details the architecture of a comprehensive campus competition centered on the MSOEN framework (Mission, Sensor fusion, Obstacle avoidance, Environmental mapping, and Network). By enforcing a strict pipeline from Software-In-The-Loop (SITL) simulation to real-world flight, this competition model bridges the gap between theoretical coding and physical aerodynamics. We explore the technical requirements, the tiered challenge structure, safety protocols, and the pedagogical impact of forcing students to validate their algorithms in a “Sim to Sky” progression.

---

1. Introduction: The New Arena of STEM Competition

For years, student drone competitions focused primarily on FPV (First Person View) racing or manual agility. While these events honed hand-eye coordination, they did little to advance the cause of computer science or systems engineering. Today, the industry demands professionals who can write the “brain” of the machine. Consequently, the “Autonomous Flight Drone Competition” has emerged as the pinnacle of campus STEM events.

Unlike a race where the fastest pilot wins, an autonomous competition is won by the most robust algorithm. The challenge is not just to fly, but to fly without a human in the loop. This requires a deep understanding of the MSOEN stack. This paper outlines how to design and execute a campus competition that takes students on a rigorous journey from the safety of a digital simulator to the complexity of a real-world takeoff.

2. The “Sim to Sky” Philosophy

The core philosophy of this competition is “Sim to Sky.” In the professional aerospace industry, no code is loaded onto a flight controller without extensive simulation. We apply the same standard to students.

• Risk Mitigation: Drones are dangerous. Propellers are essentially flying blades. By requiring students to prove their logic in a simulator first, we eliminate 90% of potential hardware crashes and safety incidents.

• Iterative Development: In simulation (using tools like Gazebo or AirSim), students can “crash” a thousand times without incurring financial loss. This encourages experimentation with complex logic, such as SLAM (Simultaneous Localization and Mapping) or Computer Vision, without the fear of breaking a $2,000 drone.

• Digital Twinning: Students learn to create a “Digital Twin” of their physical drone. They must ensure that the physics model in the simulator matches the weight, thrust, and inertia of their real hardware.

3. Competition Architecture: The Three Tiers

To ensure a fair and educational experience, the competition is divided into three distinct tiers, each representing a stage in the autonomous development lifecycle.

Tier 1: The Simulation Gauntlet (The “Paper” Trial)

Before touching a physical drone, teams must submit their code for a simulated mission.

• The Platform: PX4 or ArduPilot running on Gazebo.

• The Task: Navigate a virtual “Obstacle Course” using only Python scripts and the MAVSDK.

• The Rules: GPS is artificially “jammed” in the simulation. Teams must rely on Visual Odometry or Optical Flow to maintain position. This tests their understanding of Sensor Fusion (S) and Obstacle Avoidance (O). Only teams whose drones complete the simulation without “crashing” (divergence in the EKF) are allowed to proceed to Tier 2.

Tier 2: The Hardware Integration Lab (The “Bench” Test)

Once the code is validated in simulation, teams move to the workbench. This tier focuses on the Network (N) and Hardware integration.

• The Setup: A “Caged” lab environment. Teams must connect their Companion Computer (e.g., NVIDIA Jetson Nano) to a Pixhawk flight controller.

• The Challenge: The “Data Throughput” test. Teams must stream telemetry data (MAVLink) and a live video feed (RTSP) to a ground station while executing a pre-programmed “Mission (M).”

• The Evaluation: Judges inspect the “Cleanliness” of the code and the physical robustness of the wiring. A “spaghetti” wiring job results in point deductions due to the risk of vibration-induced disconnections.

Tier 3: The Takeoff (The “Live” Flight)

The final tier is the public exhibition. This is where the “Sim to Sky” transition is truly tested.

• The Arena: A netted outdoor or indoor pavilion.

• The Mission: A complex “Search and Retrieve” operation. The drone must autonomously take off, navigate to a series of GPS waypoints, identify a specific colored object using OpenCV, descend, and drop a payload (a small ball) onto the target.

• The Catch: Midway through the mission, a “Wind Disturbance” (created by large fans) is activated. The drone’s PID controllers and EKF must compensate for the sudden environmental change.

4. Technical Deep Dive: The MSOEN Implementation

To succeed in this competition, students must master the five pillars of MSOEN:

• Mission (M): Students use QGroundControl to plan the initial waypoints, but they must write custom Python scripts to handle “Off-Nominal” conditions. For example, if the target is not found at Waypoint 3, the drone must enter a “Loiter and Scan” pattern rather than proceeding to Waypoint 4.

• Sensor Fusion (S): Teams are encouraged to fuse data from multiple sources. A team using only GPS will lose to a team using RTK (Real-Time Kinematic) GPS fused with an IMU and a LiDAR for altitude. The competition judges the “smoothness” of the flight log; jerky movements indicate poor filtering.

• Obstacle Avoidance (O): This is the most critical safety feature. Teams must implement a “Bubble” of at least 2 meters. If a foam obstacle is placed in the drone’s path just before takeoff, the drone must detect it via Stereo Vision and re-route.

• Environmental Mapping (E): As a bonus round, the drone must generate a 2D occupancy grid of the arena floor during its flight. This tests the SLAM capabilities and the processing power of the Companion Computer.

• Network (N): Teams must demonstrate a “Heartbeat” monitor. If the Network connection is lost for more than 5 seconds, the drone must execute a “Fail-safe” (either hover or return to home).

5. The Judging Criteria: A Professional Rubric

Unlike a race, this competition is scored on a weighted rubric:

1. Simulation Score (20%): Did the code pass the SITL stress tests?

2. Autonomy Level (30%): How much human intervention was required? (Zero intervention = full points).

3. Precision (20%): How close did the payload land to the target? (Measured in cm).

4. Code Quality (15%): Is the code modular? Is there proper error handling? (Judges perform a “Code Review”).

5. Presentation (15%): Can the team explain why their algorithm made a specific decision during the flight? (Root Cause Analysis).

6. Case Study: The “Autonomous Delivery” Scenario

In a recent iteration of this competition at a leading technical university, the challenge was to deliver “vaccines” (ping pong balls) to “remote clinics” (small landing pads) scattered across a model terrain.

• The Challenge: The terrain included a “tunnel” (GPS denied) and a “forest” (obstacle dense).

• The Winner: The winning team did not have the fastest drone. Instead, they had the most robust Sensor Fusion logic. They used an Intel RealSense camera to build a local point cloud, allowing their drone to “feel” its way through the tunnel where GPS was unavailable. Their code included a “sanity check” that compared GPS coordinates with visual landmarks; if they didn’t match, the drone defaulted to visual navigation.

7. Overcoming Challenges: The “Crash” as a Lesson

A key feature of this competition is the “Crash Log Analysis.” If a drone crashes, the team is not disqualified. Instead, they are given 30 minutes to analyze the .bin or .ulg flight log.

• The Lesson: In the real world, drones crash. The value lies in the Post-Mortem. Students use tools like FlightPlot or PyMAVLink to graph the sensor data. They must present a “Failure Report” identifying whether the crash was due to a Software Bug (e.g., division by zero in the PID loop) or a Hardware Failure (e.g., motor desync due to voltage drop). This transforms a failure into a high-value learning moment.

8. Safety and Regulation

Safety is paramount. The competition operates under strict “Code of Conduct”:

• Geofencing: Every drone must have a software-enforced geofence. If the drone strays outside the netted area, the motors must cut.

• Kill Switches: Every team must have a physical “Kill Switch” (a separate radio link) that overrides the autonomous code and disarms the motors instantly.

• Propeller Guards: Mandatory for all indoor flights.

9. Conclusion: The Future of Educational Competitions

The “From Simulation to Takeoff” model represents the future of STEM education. It moves away from the “Black Box” of consumer drones and into the “Glass Box” of autonomous systems. By forcing students to validate their ideas in simulation before risking hardware, we teach them the discipline of professional engineering. This competition format not only produces better programmers and engineers but also instills a deep respect for the laws of physics and the complexity of the algorithms that govern our modern world. The sky is no longer the limit; it is the classroom.

---