Building a Custom Octocopter From Scratch With No Hardware Experience

Karolina Dubiel, a software engineer who had never taken on a substantial hardware project, designed, milled, soldered and flew a custom octocopter — then trained a reinforcement-learning policy that keeps it airborne after motors fail. By her account the project went from an idea to a flying drone in two and a half weeks and to RL-controlled flight in under eight.

From Fusion 360 to a hand-built airframe

The airframe was designed in Fusion 360 and CNC-milled from G10 fibreglass for the arms and 5 mm carbon fibre for the body plates, with the arms intertwined in the centre for stiffness. Four phases followed: CAD and assembly; wiring the electronics and flying as a conventional flight-controller octocopter; training a policy for normal flight and dual-motor failures; and the sim-to-real transition, with motors shut off in field tests.

A 43,000-parameter network at 50 Hz

The final controller is a two-hidden-layer MLP with 128 units per layer — about 43,000 parameters — running at 50 Hz on the drone's own flight controller, compiled into ArduPilot's C++ at the motor-mixing level, with no companion computer and no fine-tuning after simulation. It reads the last ten state frames (0.2 s of history): attitude, angular rates, position, velocity and an eight-value channel giving each motor's thrust level, with failed motors forced to zero.

Training happened entirely in simulation — MuJoCo with PPO via PufferLib — on a fixed mixture of episodes with zero, one or two dead motors (weighted 0.1, 0.2 and 0.7) under a curriculum that ramps domain randomisation from nominal to full. One trick is a symmetry-averaging head: the network runs its weights twice, once on the true state and once on the same state relabelled by a 180° rotation of the airframe, and averages the two — exactly equivariant to that rotation at zero extra parameters.

What it survived, and a lesson in reward hacking

Trained only on up to two dead motors, the policy held station on the real airframe through triple and even quad failures. The earlier version was also textbook reward hacking: with a pose-only reward, hovering on four motors scored the same as on eight, so the agent parked healthy motors and often flew as a quad. Adding a term that rewards using every available motor produced a retrain that held all eight motors in hover in 20 of 20 episodes for 3.6% less hover precision and survived out-of-distribution failures better: 99% versus 90% with three dead motors, 85% versus 64% with four.

Bugs worth reading about

The build log also documents three system-identification bugs that had invalidated every earlier fault-tolerance number: the arm length from centre of mass to motor was hardcoded at 35.20 mm instead of 181.938 mm, the inertia formula used 8π² instead of 4π², and the motor layout was modelled as a “+” when the airframe is an “X”. Together they left the simulated drone with roughly 2.6 times less control authority; after the fixes, dual-failure survival under full domain randomisation rose from 71.7% to 95.8%, and the hardest yaw cases from 41.2% to 94.6%.

An octocopter was chosen deliberately: a quadcopter that loses a motor must give up yaw authority entirely to stay airborne.