# PID tuning, how “I did it my way”

The tuning is focussed on the gyro sensor output – and the angular speed in degrees per second that the 3 axes of the drone are moving in (pitch, roll and yaw).  In a stable hover, all three axes need to be sensing angular speed of zero degrees per second, but that alone doesn’t guarantee horizontal hover – they could all be leaning at a fixed angle and still read 0 off the sensors.  The gyro PID solves both the angular stability and position.  First a recap on what the various PID components do…

P = proportional – for a given error between the current angular speed read from the gyro and the desired angular speed (0 for a hover for example), the P gain multiplies the difference to provide power to the blades.  Simple enough to get roughly right, but exactly right is like sitting on a fence – slightly too much gain and it overshoots, either falling off or wobbling manicly, too little and it can’t get onto the fence in the first place.  Tuning to sit balanced on a fence is hard, so there’s I and D to help…

I = integral – the difference between the current error and the previous error are added to a total error which via the I gain provides power to the blades – While the P gain can be tuned to stop the angular speed, the I gain ensures that the net error is 0, meaning that as the error returns to 0, the drone returns to horizontal. I provides stability for fence sitting if you’re carrying a load on one side, or in the drone case, the motors / blades / chassis are not perfectly matched (which they won’t be!).

D = differential – although this is not strictly necessary for the drone, it provides faster, finer tuned reaction to changes in error; essentially, if the error has grown since last time, the PID D output increases the power for self righting, assisting the P gain to decrease the error.  On the other hand, if the error has shrunk since last time, the PID D output reduces the output, preventing just the P from overshoot. D takes the oscillations out of fence sitting which P can’t cope with fast enough.

Various internet sites say tune for P gain first for short term stability, then I gain for long term stability and finally (and optionally), up the P gain to a slight oscillation level and tune D gain to flatten it out again.

First step was to put a test rig that didn’t involve any take-offs / crashes.

The drone is very delicately balanced here to the extent that with unplugged power leads, they stick out the back, and the drone absolutely will not balance to start the test.  That’s due to the black blobs on the stools which are slightly domed (normally used by the kids to reach the sink for when brushing their teeth!);  hence the balance shown in the testing video was genuine due to the PIDs – to the extent it could also recover from some taps by me.  The tilt at the end happens because the test was over and the motors powered down.

Throughout the tuning I used graphs like below to track gyro results against PID outputs against blade spin rate so I could be sure which PID gain to tweak and by how much – time consuming but accurate.  Since this was a live run, I can also compare against reality – in the graph show, although there were oscillation both in reality and obvious as the two top lines in the graph, these did not escalate (like the crashes) but maintained a wobbly stability.  My interpretation of this was P looked good graphically, but underpowered in reality, I is OTT causing the oscillations and D gain was clearly needed to assist P:

PID tuning nearly done

From there, the tuning itself was iterative.  Having tuned P (with I and D set to zero) to get no oscillations (and not enough power either!), I tried upping the P gain, and include the D gain to boost / suppress P as necessary, and after a few cycles of tinkering, that did the job – I had plenty of power to correct errors quickly, but with the D suppressing overshoots.

But the drone still wasn’t returning to horizontal, but that’s OK, that’s what I gain’s for.  It needed to be last for tuning as otherwise it masks P and D gain tuning as show above.

Here’s the graph output shown with the near completed tuning corresponding to the video.

Nearly complete PID tuning

Perhaps some very fine tuning to go, but it’s good enough for now.

On a slight tangent, these stats also reveal another problem shown in the next graph: although the drone was reasonably stable, the vertical speed was not – it was integrating from 0 downwards despite the fact the drone was going nowhere vertically; this has been bothering me for while, as it would make an untethered flight dangerous.  The every reducing vertical speed would cause ever increase power to all rotors meaning the drone would climb rather than hover at a fixed height.

The graph shows that very clearly that even with the drone stabilized, the z accelerometer would never actually read 1g – the slight angles of pitch and roll means the accelerometer will be reading < 1g, and so integrating that leads to a vertical speed that keeps reducing.

So the accelerometer output needed compensation for the pitch and roll angles.  A day of research and some very helpful advice from the Raspberry Pi forum solved that – spot the difference between between the compensated and uncompensated vertical speed for the drone on the test rig – the scale is meters per seconds  – I’m much happier with 2mm/s drift rather than 20cm/s!

Vertical Speed Compensation

That’s made me very happy; only by tuning the gyro PIDs could I then see the woods for the trees – I’d just assume it was a code bug, or noise spoiling the integration.  So that’s one more worry from my pre-take-off check list.

## 3 thoughts on “PID tuning, how “I did it my way””

1. Hi

So I have built the Quad Copter to the original design and have fired it up for the first time and to date have carried out test cases 1 & 2. The copter works and the propellers run up fine but I have one minor problem.

From the moment the Pi fires up without qc.py running the beeper starts beeping. When qc.py is run it stops and does not provide any count down beeps. At the end of the test case it starts beeping again and the propellor blades twitch. It is as if there is a background program running, any ideas?

Regards

Colin Warwick

• Hi Colin,

The beeps you’re hearing are from the ESCs – when they don’t get a signal from the code, they beep – annoying isn’t it! While qc.py is running, the ESC beeps stop but you should get much quieter beeps from the sounder on your circuit board.

Not sure why you don’t get these count down beeps – double check the beeper is connected the right way round (there is a positive and negative side), and that it’s plugged into the right pins – I’ve got that wrong a few times because the pins are hidden underneath.

Hope that helps,

Andy