logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·03.11.26
← Back to news

Building a custom octocopter from scratch with no prior hardware experience

Original article
karolina.mgdubiel.com|252 points|54 comments|by noleary|Jun 28, 2026

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:

  1. Design: Modeled using Fusion 360.
  2. Fabrication: CNC-milled utilizing a combination of carbon fiber and G10 fiberglass.
  3. 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: Sustain flight after random shutdown of 2 motors during field tests.\text{Sustain flight after random shutdown of 2 motors during field tests.}Sustain flight after random shutdown of 2 motors during field tests.


📓 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.

AttemptStrategyOutcome
1Baseline PPO, high exploration, constant 2-motor faults.Entropy rose (11→2211 \to 2211→22); crashed at 20M steps during save.
2Lowered exploration, no curriculum (direct to dual-faults).Variance collapsed (negative Gaussian differential entropy); killed the run to add a curriculum.
3Added 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 ±3\pm 3±3; 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 [0,1][0, 1][0,1]. 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 tanh squash 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 rrr was 0.000.000.00. The survival bonus was perfectly offset by the altitude penalty: Reward=(+0.1survival)+(−0.1altitude)=0\text{Reward} = (+0.1_{\text{survival}}) + (-0.1_{\text{altitude}}) = 0Reward=(+0.1survival​)+(−0.1altitude​)=0 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 rsurviver_{survive}rsurvive​ from 0.1→1.00.1 \to 1.00.1→1.0. New Reward=(+1.0survival)+(−0.1altitude)=+0.9/step\text{New Reward} = (+1.0_{\text{survival}}) + (-0.1_{\text{altitude}}) = +0.9/\text{step}New Reward=(+1.0survival​)+(−0.1altitude​)=+0.9/step

🚀 Final Results

By the 9.5M step mark, the policy achieved total survival across hover, single, and dual motor failure classes.