Josef Link

Making drones fly

The drones in Arc Raiders got me wanting to build my own. My Bachelor's thesis was about drones under sensor attacks, so this felt like a good excuse to bring some of that into my games.

There's something nice about using proper physics in games. While difficult to get it to sit right with gameplay, it often makes the experience feel less scripted. A drone has to lean to accelerate, lean back to brake, and recover when something knocks it sideways. The weight you see is the weight the controller has to deal with. I'll probably cheat where the gameplay needs it, but I wanted to start here.

P, I and D

Let's begin by discussing how a drone is able to fly.

A controller measures the difference between where something should be and where it is. That's the error, $e$. A PID turns that error into a correction:

$$u(t) = K_p e(t) + K_i\int_0^t e(\tau)\,d\tau + K_d\frac{de(t)}{dt}$$

P pushes harder the further away you are. On its own, it can send you sailing past the target.

I adds up the error over time. If a constant force keeps you slightly off target, it builds up the extra push needed to get you there.

D reacts to how quickly the error changes. With a fixed target, it acts like a brake, damping the oscillation.

Four motors

It's not an accident that a drone has four motors. Obviously, increasing thrust on one side tilts the drone in the other direction, allowing for travel. But not as obvious is how it allows for attitude adjustments.

The two diagonal propeller pairs have opposite spin directions. This is what cancels out, or allows for, yaw torque.

$$m\mathbf a = m\mathbf g + R\sum_{i=1}^{4}\mathbf f_i, \qquad \boldsymbol\tau = \sum_{i=1}^{4}\left(\mathbf r_i\times\mathbf f_i + s_i k_y T_i\,\hat{\mathbf y}\right)$$

Each motor produces thrust $\mathbf f_i=T_i\hat{\mathbf y}$ at arm position $\mathbf r_i$. The cross product gives its turning torque; $s_i=\pm1$ gives the rotor's spin direction and $k_y$ its reaction-torque factor. These are body-frame quantities; $R$ rotates thrust into the world, where gravity acts.

Position → tilt

Input: target offset $\mathbf e$ from the position sensor, in heading coordinates ($x$ right, $y$ up, $-z$ forward).

$$\dot{\mathbf e}_k=\frac{\mathbf e_k-\mathbf e_{k-1}}{\Delta t}$$
$$\mathbf h=0.10\,\mathbf e_k+0.08\,\dot{\mathbf e}_k$$
$$\begin{aligned}p&=\operatorname{clip}(-h_z,-0.45,0.45)\\r&=\operatorname{clip}(h_x,-0.45,0.45)\end{aligned}$$

Output: pitch $p$ and roll $r$, in radians. The game supplies the target; the first derivative sample is zero.

Height + heading

Inputs: height error $e_y$ and look-at offset $\boldsymbol\ell$, from the position sensor.

$$c=\operatorname{clip}(c_0+0.12\,e_y+0.10\,\dot e_y,0,1)$$
$$c_0=\frac{mg}{4T_{\max}}\approx0.409$$
$$\begin{aligned}\psi&=\operatorname{atan2}(-\ell_x,-\ell_z)\\\omega_y^*&=\operatorname{clip}(1.0\,\psi,-2,2)\end{aligned}$$

Outputs: collective $c$ (0–1), yaw rate $\omega_y^*$ (rad/s). No yaw request when the look-at point is less than 2 m away horizontally.

Tilt → rotation rate

Inputs: pitch $p$, roll $r$, yaw rate $\omega_y^*$, and IMU up direction $\mathbf u$ in body coordinates.

$$\mathbf u^*=\frac{(-\tan r,\,1,\,\tan p)}{\|(-\tan r,\,1,\,\tan p)\|}$$
$$\mathbf e_{\rm tilt}=\mathbf u^*\times\frac{\mathbf u}{\|\mathbf u\|}$$
$$\boldsymbol\omega^*=(4\,e_{{\rm tilt},x},\,\omega_y^*,\,4\,e_{{\rm tilt},z})$$

Output: requested body rotation rate $\boldsymbol\omega^*$. These runs use P only for tilt: $K_p=4$, $K_i=K_d=0$.

Rotation rate → torque

Inputs: requested rate $\boldsymbol\omega^*$ and gyro reading $\boldsymbol\omega$, both in body coordinates.

$$\mathbf e_{\omega,k}=\boldsymbol\omega^*-\boldsymbol\omega$$
$$\mathbf I_k=\operatorname{clip}(\mathbf I_{k-1}+\mathbf e_{\omega,k}\Delta t,-1,1)$$
$$\boldsymbol\tau=2.0\,\mathbf e_{\omega,k}+0.3\,\mathbf I_k$$

Output: requested torque $\boldsymbol\tau$ (N·m). One PI per axis; the D gain is zero. The integral clamp applies to each component.

Torque → four motors

Inputs: collective $c$, torque $\boldsymbol\tau$, motor arms $\mathbf r_i$ and reaction signs $s_i$.

$$\begin{aligned}\Delta T_i={}&\frac{-r_{i,z}}{\sum_j r_{j,z}^2}\,\tau_x\\&+\frac{r_{i,x}}{\sum_j r_{j,x}^2}\,\tau_z\\&+\frac{s_i}{k_y\sum_j s_j^2}\,\tau_y\end{aligned}$$
$$m_i=\operatorname{clip}\left(c+\frac{\Delta T_i}{T_{\max}},0,1\right)$$

Output: $m_{\rm FL},m_{\rm FR},m_{\rm BL},m_{\rm BR}$. $T_{\max}=12$ N per motor; $k_y$ is the reaction-torque factor. FL/BR have $s=+1$, FR/BL have $s=-1$.

Manipulating sensors

Another thing, besides the physics, which isn't faked in my game are sensors. A real drones relies on sensors which tell its attitude, velocity (angular and translational) etc.

This allows for a pretty fun damage model.

We can add bias and noise to our sensors, and the drones steering gets worse. Apply more noise and more bias and it'll crash.

$y_k=\omega_k+b+\sigma\xi_k,\quad\xi_k\sim\mathcal N(0,1)$

Recorded at 60 Hz · playback
Drag to orbit · scroll to zoom
0.0 s

Loading recorded flight…

Coupling to Godot

The flight code lives in a shared C++ library, plugged into Godot through a GDExtension. I can run it in a standalone simulator too, which makes it easy to test lots of flights. It's a simplified rigid-body model: four rotor forces and their torques, without a full aerodynamic simulation.

Recorded at 60 Hz · playback
Drag to orbit · scroll to zoom
0.0 s

Loading recorded flight…

PID result
Median waypoint pass speed 3.21 m/s
Crash rate 1.46%
Median maximum overshoot at the end 1.85 m

These are the simulation results over thousands of randomly generated tracks.

In the next part of the series, we'll try to beat it with a trained drone using reinforcement learning.