In many quadrocopter projects, three separate PID controllers are used to control rotations around the three axis: yaw, pitch and roll. This is no easy task, because the directly controlled variable is the motor force / acceleration, which is the second derivative of the rotation angle. As many successful projects show, this gap is nothing to worry about – the PID constants just need to be tuned nicely – but for me it always seemed an unnatural, unnecessary and imprecise setup. In my last blog post, I introduced the idea of axis rotation planning. Axis rotation planning eases the task of a PID controller so that it now only controls the rotation speed – which it has a more direct influence on.
For a comparison on problem complexity, consider yourself confronted with the task of driving at 50 km/h compared to parking your car at a given position – both should be no real problem for a human, but parking often involves additional thoughts.
In order to get a target speed for the PID for a given axis, we use axis rotation planning: an analytic approach for polynome fitting that constructs a nice-to-follow path with minimal oscillations between a current state and some desired future state.
Axis rotation planning gives us a function/path (a target angle for every point in time) to follow. In a continuous world, we could just hand the first derivative at the current time to the PID as the target speed. Unfortunately, we only have discrete time steps (I hope to get around 100 updates per second). With discrete time steps, just using the path’s first derivative is not optimal, since the acceleration will be applied not only at this moment, but in a whole time span. My solution is to use the average derivative over the estimated time span that it will be the active target speed.
Example: If we update the motor speeds 100 times per second, we first calculate the rotation plan – let’s call it – and then derive the quadrocopter’s target rotation speed (for one of the three axes) for the time interval that starts now:
Important notice: if axis rotation planning uses a different time unit (like halfsecond, tenthsecond, whatever), the update rate in the upper definition must be given with respect to that time unit.
Of course this discretisation still introduces an error with this approach, but it should not be dominant at high update rates (like >100 Hz). Probably, it will not even be noticable at all with the consecutive axis rotation plannings.
The Mathematica Notebook is now extended with the calculation of this average target speed.
A nice alternative to my attitude control approach is to use a linear quadratic gaussian controller. These controllers rely heavily on a Kalman Filter, which makes the system very robust to noise in measurements and output. However, the modelling and computation is more complicated, as we also see in this paper, where a LQG controller is set up to control the altitude of a quadcopter. A comparison on the performance of PID controllers versus LQG/LQR controllers in steering a quadcopter is performed in this paper: the LQG robustness results are clearly inferior, but because of the sensor fusion delay, a PID is able to respond much faster. The authors try to combine both worlds by tuning the PID with LQR, but the results are questionable. My own approach with axis rotation planning could be a good compromise: it removes the PIDs oscillation while beeing equally fast in updates as a PID.
Here is a very nice blog post using a neural network as a PID replacement – I would love to also use one, but I am unsure how to train the network on a real quadrocopter.