How fast should a control loop run?

Run a control loop as fast as you practically can: a common rule is ten to twenty times faster than the quickest motion it has to control. A controller that runs only now and then holds its last output in between, and that hold acts as extra lag. If it must run slowly, its D term has to divide by the real time between runs, or every correction kicks too hard.

A slow loop is a lag

Suppose the drone's controller runs once every 20 steps of 10 ms, every 200 ms, and holds its thrust in between. The thrust becomes a staircase. Between decisions the drone keeps flying on a command up to 200 ms old, the same way it flies on a sensor reading that's 200 ms late. A slow loop and a slow sensor hurt in the same way, and they add.

The time step must match

The derivative is a change divided by the time it took. Run the controller every 5 steps and the error's change happened over 0.05 s, so divide by 0.05:

if (steps % EVERY == 0) {            // EVERY = 5
  float d = (error - prev) / 0.05;   // the real time between runs
  prev = error;
  thrust = 9.8 + 2.0 * error + 2.0 * d;
}

Divide by 0.01 instead and the computed rate is five times too big: Kd 2 behaves like Kd 10, and the drone swings. Run every 20 steps with the same mistake and every kick is twenty times too strong. The integral needs the same care in reverse: it multiplies each error by the real Δt.

How fast is fast enough?

This drone, behind a 200 ms sensor lag, swings with a period of about three seconds. Five decisions a second is still about fifteen per swing, and with the right divisor it settles in about 3.3 s, as fast as running every step. Two decisions a second, one every 500 ms, is too few: even the right divisor swings.

The sampling theorem says you need more than two samples per cycle just to see a wobble. Control needs far more, because each hold is a delay inside the loop. Hobby flight controllers run their loops a thousand times a second or faster; a room thermostat can get away with once a minute.

On a microcontroller

Never time a control loop with delay(): it stalls everything else and the interval drifts as the code grows. Check millis() or micros() each time round loop(), run the controller when its interval is up, and use the measured gap as Δt. That keeps the maths right even when a pass runs a little late.