Source: https://oliviercouthaud.com/drone · Status: Prototype · 2026 · Tags: MuJoCo MJX, JAX, PPO

# Fault-Tolerant Quadrotor

A simulated drone that learned to fly a figure-eight, and to keep flying when one of its four propellers gets weak.

[Image: Top-down plot of a figure-eight flight path coloured by tracking error, mostly green, with a short red stroke from the origin at the start]

Figure: One 10 second figure-eight flown by my first policy: no faults, normal speed. Colour is how far the drone is from the dashed reference line, from green (close) to red (0.2 m). The red stroke is the opening second, catching up with a path that starts 1 m away from where the drone does.

I reimplemented a published controller recipe, SimpleFlight, on MuJoCo MJX with Crazyflie parameters, then trained it to cope with one rotor losing thrust. All of it is simulation. The method comes from papers: SimpleFlight, RMA and MAVEN, whose rotor-fault ranges I borrowed.

## What I wanted

I think an autonomous system has to be able to adapt to whatever happens to it, and the most extreme case for a drone is losing power to one of its motors, which can make it fall out of the sky. The long game is a small drone you can talk to, that maps where it is and survives losing a motor. I cut that into five milestones: reproduce SimpleFlight, fault tolerance, visual obstacle avoidance, 3D mapping with return to a landmark, and language commands. Here I cover the first three.

Healthy, my first policy tracks a figure-eight with an average error of 2 to 9 cm depending on speed, on a simulated 32 g Crazyflie-class quadrotor. For the second milestone I wanted to know how far a controller trained on one laptop GPU would still hold the path if one propeller delivered only part of its thrust, and whether it could adapt without being told which rotor was weak.

## How it works

The policy never commands motors directly. It outputs a collective thrust and three body rates, and a rate controller with a mixer and a 25 ms motor lag turns that into four rotor speeds.

**What are body rates?**

How fast the drone is rotating around each of its three axes (roll, pitch and yaw). Asking for rotation speeds instead of motor speeds keeps the network's job simple: it says how it wants to turn and how hard to push up, and a small conventional controller works out what each motor has to do.

It sees the next ten reference points (50 ms apart, relative to the drone), its velocity and its rotation matrix. SimpleFlight reports roughly a 63% performance drop when a quaternion is used there, so I used a rotation matrix. I have not tested the quaternion myself. I took the PPO hyperparameters unchanged from the SimpleFlight paper. Training runs 2048 environments in JAX at roughly 70,000 steps per second on an RTX 4070, and the 15,000-epoch fault run took about 3.75 hours.

**What is PPO?**

Proximal Policy Optimization, a standard way to train a policy by trial and error. It collects a batch of flights, works out which actions led to better scores than expected, and nudges the network towards them. The "proximal" part is a clip that stops any single update from changing the policy too much, so one unlucky batch can't wreck what it has already learned.

Figure: Diagram. The simulator runs at 100 Hz, with a first-order motor lag of 25 ms. CTBR stands for collective thrust and body rates.

Fault tolerance comes from RMA's two phases, which I step through below. During training, 70% of episodes get one rotor at 50 to 100% of its thrust, plus mass varied by ±20% and thrust coefficient by ±30%. In phase 1 the actor is handed the true fault state. In phase 2 I freeze it, collect 20,480 rollouts, and train a small network to guess that state from the last half second of observations and actions.

**What is domain randomisation?**

Every training episode gets slightly different physics: a different mass, a different thrust coefficient, and here, a different weak rotor. The policy can't memorise one drone, so it has to learn something that works across all of them, including the faulty ones.

**What does "privileged" mean here?**

It means information the simulator knows but a real drone couldn't measure directly, like the true strength of each rotor. A policy that can read it learns fast. The trick from RMA is to then train a second network to estimate that information from things the drone can sense, so the privileged input isn't needed when it is deployed.

Step 1. I train the policy with a cheat sheet: it is handed the true strength of every rotor and the mass of the drone. This is the privileged policy, trained for 15,000 PPO epochs.

Figure: Diagram. Click or tap a step for a short explanation. Wind is in the state vector but I did not randomise it in phase 1, so it is always zero.

## Results

**Figure-eight tracking error, metres, no faults. Mine is the first policy (no fault training), simulation, 3 seeds, reference starting at T/4 as in the paper's code.**

| Policy | Slow 15 s | Normal 5.5 s | Fast 3.5 s |
|---|---|---|---|
| Mine | 0.020 | 0.040 | 0.094 |
| Paper | 0.016 | 0.028 | 0.051 |

My error is 1.3 to 1.8 times the paper's at each speed. All three are under the pass thresholds I used (0.050, 0.056 and 0.150 m, roughly 2 to 3 times the paper's errors), and none of the 21 rollouts across all seven benchmark trajectories crashed. An earlier CPU evaluation gave numbers 0.003 to 0.004 m lower. I use the GPU numbers so every comparison shares one backend.

**After fault training, simulation, 3 seeds. Fault means rotor 0 at 70% thrust, nothing else changed. "Privileged" reads the true fault state; "encoder" is the deployed version.**

| Policy | Slow 15 s | Normal 5.5 s | Fast 3.5 s |
|---|---|---|---|
| Privileged, healthy | 0.024 | 0.057 | 0.138 |
| Privileged, fault | 0.032 | 0.079 | 0.534* |
| Encoder, healthy | 0.024 | 0.057 | 0.133 |
| Encoder, fault | 0.034 | 0.081 | 0.605* |

* Crashed, so these are not clean tracking errors. The encoder policy crashed on two of the three seeds there.

Fault training costs accuracy when nothing is wrong: 0.057 m at normal speed instead of 0.040. A run of the same network without randomisation reached 0.044 m at epoch 7,000 on the older CPU evaluation, so most of that gap looks like the randomisation rather than the architecture, though that run was not trained to the end. With a rotor at 70%, error at normal speed is 1.4 times the healthy value. The encoder adds almost nothing over the privileged policy, which was my main question: the signature of a weak rotor is readable from the drone's own history. It reads the rotor strengths well (normalised error about 0.011 on average) and the mass scale less well (0.076). I have no paper numbers to compare these to, since the fault setup comes from RMA and MAVEN rather than SimpleFlight.

### Try the other paths

Healthy: privileged 0.057 m, encoder 0.057 m

Simulation, mean over 3 seeds, GPU backend. Figure-eights start at T/4, the other paths at t = 0. * means at least one seed crashed, so the number is not a clean tracking error. Polynomial path with a fault: the privileged policy crashed and the encoder policy did not, and the reason is still open. The first policy was not tested with a fault. The scale stays the same when you switch between healthy and fault.

## What I ran into

**Targets re-set after measuring.** For the fault milestone I had set 0.037 m healthy and 0.060 m with a 70% rotor, with zero crashes. The first results were 0.057 and 0.081, and fast-with-fault crashes. I re-set the targets to 0.060 and 0.100 m after measuring, and the results pass those. The original, tighter targets are not met.

**The start-up effect.** The encoder sees an empty, zero-padded history for the first 50 steps. My guess is that it then predicts "healthy" and the actor flies as if nothing is wrong. A 200-step analysis did not reproduce the crashes, so I can't call that the cause. The privileged policy, which sees the true fault from step 0, also crashes at fast-with-fault (0.534 m), so much of this may simply be a rotor at 70% leaving too little thrust margin at that speed. The start-up story is only my explanation for the extra encoder error. Separately, the polynomial test with a fault crashed on 2 of 3 seeds with the privileged policy but not with the encoder, and the reason is still open.

**Training issues.** I paused and resumed a run with the Adam state reset. Error jumped from 0.085 to 0.215 m and then to about 1 m (inline evaluation from t = 0, so each figure includes about 0.03 m of start-up error and isn't comparable to the tables above), and 11,000 more epochs did not recover it. Training reward looked healthy throughout, because easy random trajectories carry the average, so I now judge on held-out figure-eights. My random-trajectory generator also made straight segments with zero curvature, while the figure-eight apex needs about 4.8 per metre. The policy plateaued at 0.105 m (same t = 0 evaluation) until I replaced it with smooth quintic polynomials.

**A false alarm.** The fault-trained policy looked 2.5 times worse than the first one until I found that the paper's code starts the figure-eight at T/4, not t = 0. That one choice changes the mean by about 0.031 m, and the paper doesn't state it. Later I raised a threshold that was failing before asking why, declared the gate passed, and found the cause the next day: a wrong checkpoint and a trajectory that ended too early. Both times, re-checking the numbers is what caught it.

### Where the reference starts

The reference starts 1 m from the drone, so the first second is spent catching up. Averaged over a 10 s run that adds about 0.031 m. This is the red stroke in the first plot.

Figure: Path: x = cos(2πt/T), y = sin(4πt/T)/2, in metres. Drawn from the formula, not from a flight.

Ringed marker: the reference at t = 0, at (1, 0). Black dot: the drone, at (0, 0).

## Obstacles

The next step added depth rendering (MJWarp) to the MJX environment, with physics unchanged. The fault policies above don't use it. The obstacle policy is a separate one, trained from scratch with faults and pillars together. Its actor reads a 64 by 64 depth image reduced to 16 minimum-depth bins, plus a fault latent trained jointly. The scenes are generated procedurally, with plain box pillars.

It ran 500 million steps and ended above its tracking target. On 128 random scenes, 92% of fair episodes (path at least 0.15 m from every obstacle) finished collision-free, but tracking error on those was 0.17 m against a 0.10 m target. Even on the unfair scenes, where the commanded path itself runs into a pillar, about one run in six got clear by leaving the path. With a 70% rotor, 52% finished collision-free and 38% went out of bounds. It stopped improving by about 190 million steps. My read is that the tracking reward is almost flat below about 0.15 m, so there is little pushing it tighter. A later short cloud reward sweep (early checkpoints) cut the figure-eight error from 0.287 to 0.215 m by easing the crash penalty, and I then dropped the 0.10 m target rather than chase it.

[Image: Top-down render of a drone path among five red pillars; a blue dotted commanded path runs into a pillar while the yellow flown path loops elsewhere]

Figure: A render from mid-training. Blue dots: the commanded path, which runs into the lower-right pillar. Yellow: the path flown. Magenta: the drone. This is an "unfair" scene, because the commanded path itself passes 0.07 m from a pillar, so it is left out of the 92% figure.

[Image: Low view of a flat green field with six red pillars visible and a tiny drone in the middle distance]

Figure: Another render from the same set: eight pillars in the scene, six in view, 0.20 m clearance on the commanded path.

## Where it stands

None of this has flown on hardware. The Crazyflie is the model the simulation is built on; the drone I actually own is a tiny Meteor 65 Pro II, and none of this has run on it. I tested a 70% fault on rotor 0, on the three policies above (privileged, encoder, obstacle). A dead rotor, 50% thrust, wind and a mass change at the same time are untested, and total rotor loss, the case that started all this, is outside the trained range of 50 to 100%. The code on GitHub covers the first policy and the fault-training setup. The encoder and the obstacle policy are not on GitHub yet. After the obstacle work I moved the project towards perception and safety layers in simulation, and the fault-tolerance part is where I pick up again.

I'm going back to it. The next step is a larger 5-inch drone with a computer on board, so some of these experiments can run in real life. From there I want to expand the project to autonomous flying, navigation and real onboard intelligence, and I'm thinking of using a small, fast decision model to help it make certain smart decisions. The clip below comes from the simulation work I did after the obstacle policy and is not the controller above.

Figure: A separate demo, not the controller above: a trajectory-tracking policy with a heading command, on a modelled 0.23 kg sub-250 g quad (not a built drone), flies a hand-tuned scenario in MuJoCo. A scripted takeoff, a planned route, a rule-based safety shield that steers around a person crossing, and a scripted descent to land. Positions and pose come from the simulator, and the drone, person and pillar are stand-in shapes.

- **Stack**: MuJoCo MJX, JAX, Flax, PPO. Depth rendering with MJWarp is used only by the obstacle policy.
- **Fault tolerance**: Two-phase training with a learned encoder (RMA)
- **Status**: Prototype
- **Scope**: Simulation only so far. Nothing has flown on a real drone. A 5-inch build with onboard compute is next.
- **Credit**: Method from SimpleFlight, RMA and MAVEN
- **Code**: [github.com/Forkei/fault-tolerant-quadrotor](https://github.com/Forkei/fault-tolerant-quadrotor)

[← All projects](https://oliviercouthaud.com/projects)