Building a custom octocopter from scratch with no prior hardware experience
Constructing a Custom Octocopter: From Zero Hardware Experience to Flight
Project Overview: An ambitious journey by Karolina Dubiel to build a fault-tolerant RL-powered octocopter. The timeline from initial concept to a flying prototype was a rapid 2.5 weeks, starting with absolutely no prior experience in hardware.
🛠️ The Build Process
The drone was conceptualized and realized through the following workflow:
- Design: Modeled using
Fusion 360. - Fabrication: CNC-milled utilizing a combination of carbon fiber and G10 fiberglass.
- Assembly: All components were put together by hand.
The Ultimate Objective: To develop a controller trained via Reinforcement Learning (RL) that can maintain stable flight even when experiencing single, dual, or quad motor failures. The goal is a zero-shot deployment from simulation to physical hardware.
🗺️ Project Roadmap
- Phase I: Design the custom frame in CAD, CNC the parts, and assemble the motors and propellers.
- Phase II: Integrate electronics and achieve flight using a standard Flight Controller (FC).
- Phase III: Train an RL policy to handle standard flight and dual-motor failure scenarios.
- Phase IV: Execute the sim-to-real transition for RL-driven flight.
Current Milestone:
📓 Build Log
Day 17: Navigating the Research Landscape
June 15, 2026
I currently find myself in a unique position: I have no formal undergraduate research experience. Having spent only two years at Georgia Tech before starting my current gap year, I never felt the timing was right to integrate into a campus lab. Because I didn't envision transitioning immediately from a bachelor's to a graduate degree, research wasn't a priority—until this project.
The Vision: I aspire for this project to culminate in a published academic paper. However, several hurdles remain:
- The drone must successfully fly using RL (simulated data alone isn't enough).
- I need to define a specific research question and establish non-RL benchmarks for comparison.
While publishing independently is the most direct path, collaborating with a PhD student or an established lab would be ideal. Admittedly, the academic world is intimidating, and the idea of "cold emailing" professors is daunting. But I reason that if I can build a complex drone from scratch without prior experience, I can certainly send a few professional emails.
Call for Input: If you are embedded in academia, how realistic is this trajectory? Leads are welcome!
Day 30: The Steep Learning Curve
June 28, 2026
Status Update: The drone now survives single, dual, and some triple motor failures!
Wait, it's only in simulation. While the results are promising, the path to this success was riddled with technical obstacles.
📉 The Trial-and-Error Process
Before committing to a massive policy with domain randomization, I ran a "sim-only" test (approx. 1.5 hours on CPU). It failed miserably at first.
| Attempt | Strategy | Outcome |
|---|---|---|
| 1 | Baseline PPO, high exploration, constant 2-motor faults. | Entropy rose (); crashed at 20M steps during save. |
| 2 | Lowered exploration, no curriculum (direct to dual-faults). | Variance collapsed (negative Gaussian differential entropy); killed the run to add a curriculum. |
| 3 | Added 4M steps of pure hover curriculum. | Revealed two systemic bugs that were previously masked by the "brute force" signal of immediate failures. |
| 4 | (Operator Error) Zombie process running in background. | Checkpoints corrupted; commands saturated at ; tip-over in 7 steps. |
🛠️ Debugging the System
The "entropy panic" and crashes were symptoms of two core issues:
Bug A: The Saturation Problem The Gaussian policy produced unbounded means, but the environment clipped these commands to . Since PPO calculated gradients on the unclipped values, once a motor value drifted past the edge, there was no gradient to pull it back.
- The Fix: Implement a
tanhsquash function as a residual around the hover throttle.# Conceptual Fix command = hover_throttle + tanh(network_output) * scale
Bug B: The Reward Paradox During open-loop tests, the reward was . The survival bonus was perfectly offset by the altitude penalty: Because the drone is marginally stable, it always eventually crashed. PPO saw no difference between "hovering for 200 steps then crashing" and "crashing instantly."
- The Fix: Increase from .
🚀 Final Results
By the 9.5M step mark, the policy achieved total survival across hover, single, and dual motor failure classes.