Quadcopter PID output and duty cycle conversion

Question

I'm trying to design two PD controllers to control the roll and pitch angle of my quadcopter and a P controller to control the yaw rate. I give to the system the reference roll, pitch and yaw rate from a smartphone controller (with WiFi).In the case of roll and pitch the feedback for the outer 'P' loop is given by my attitude estimation algorithm, while in the inner 'D' loop there is no reference angle rate, and the feedback is provived by a filtered version of the gyroscope data. As far the yaw rate is concerned, is only a P controller, the reference yaw rate is given by the smartphone, and the feedback of the only loop is provived by the smartphone. This is to illustrate the situation. My sampling frequency is 100hz (imposed by the attitude estimation algorithm, that is a Kalman Filter, that I'm using). I have tuned my controller gains with matlab, imposing a rise time of 0.1 seconds and a maximum percent overshoot of 2% with root locus. Matlab is able to found me a solution, but with very large gains (like 8000 for P and 100 for D). I was doing the tuning, using a quadcopter model (for each euler angle) based on the linearized model for quadcopter or instance : $$\ddot \tau_\Phi = I_x\ddot \Phi -> G_\Phi(s) = \frac{I_x }{ s^2} $$ only in order to have a 'reasoned' starting point for my gains, and then re-tune it in the reality. (The transfer function above is continous, in my model I have obliviously used the discrete version at 100hz of sampling rate). This is to do a premise of my following questions. Now, I have to map my controller outputs to duty cycle. Since I'm using a PWM at 25Khz frequency, my period (in the TIM channel configuration) is of 2879. I have checked the activation threshold (after which the motor starts move) and the threshold after which it stops increasing its speeds, and the first is 202 and the second is 2389. I was following the very good answer of Quadcopter PID output but I still have some questions.

1) As far the throttle mapping is concerned, I have to map it in such a way that the values coming from my smartphone controller (in the interval [0, 100]) are not mapped in the whole [202, 2389] interval, but I have to 'reserve' some speed in order to allow the quadcopter to have an angular movement exploiting differences in the 4 motor speeds even with 100% throttle?

2) Coming back to the fact that matlab propose me huge gains for my controllers, this leads to the fact that I cannot directly sum the controller output to the duty cycle as stated in the metioned answer (because I will certainly go out of the [202, 2389] bound of my TIM pulse). Doing a proportion will result in altering the gains of the systems, so placing somewhere else the poles of my systems and the procedure done with matlab will became useless, right? So, what I'm doing wrong? I have tried to enforce matlab to bound the gainsm for instance in the [0,100] interval, but in this case it cannot find gains such that my constraints are verified. Thank you

Answer 1

I'm posting this as an answer because it is a bit lengthy for the comments section, and I hope it will point you in the right direction.

First, you mention an "outer P loop" and an "inner D loop", which, to me, would imply that you are performing those two tasks at different rates. This is incorrect for any form of a PID controller (P, PI, PD, etc.)

All of your gains, proportional, integral, derivative, should act on the respective error measurement. If you are commanding a speed, proportional error is the difference between command and actual speed. Integral error is the difference between desired and actual position, and derivative error is the difference between reference and actual acceleration.

You have the option of either calculation the integral/derivative of your reference speed, the actual speed, and subtracting to get the error, OR you can calculate the integral/derivative of the speed error and use that directly.

Once you have all the error terms, you multiply each by its respective gain and add all the terms to get the control signal. I emphasize add the terms to reinforce that you need all the terms to get the control signal - you shouldn't be calculating one at a faster rate than the other.

What I believe you are missing is what you had asked about in your other question - it seems like your Matlab model is missing the transfer function that converts from PWM to speed, and maybe from speed to torque or lift.

I would imagine the relationship between PWM and speed is linear - lowest PWM signal gives some minimum speed (y-intercept), up to full speed at 100%. Then, as the paper you linked in your other question suggests, try a constant k1/k2 to get from speed to lift/torque.

This paper (PDF) seems to give the answer you're looking for (on page 8), and this page gives a really good derivation of equations of motion.

So, back to your specific questions, regarding point 1, you can either operate up to "full throttle" with no modifications, or you can leave a "reserve" (overhead) for maneuvering, or you can have sliding gains to account for a lack of headroom. If you want to rotate, you speed two props up and slow two down. At full throttle, two will slow, but the other two can't go any faster. Maneuvering is cut (for all intents and purposes) in half. You can leave headroom to allow two to speed up, but this restricts your top speed. You could modify gains to (hand waving) slow the two props twice as fast. This makes up for the other two not speeding up at all because you have the same differential.

The choice here is up to you, but because the controller is "watching" craft performance as compared to your commands it shouldn't matter too much. The controller isn't going to slow a pair and speed a pair by a fixed amount, it's going to slow/speed until the desired command inputs have been met. It won't respond quite as quickly as you would expect, though, because...

Point 2 - actuator saturation. This refers to passing a reference that is of such a magnitude that the actuator cannot comply. The output of your controller is the output of your controller. If you have modeled the system well, then the output should be what you supply as an input to your system. If the actuator saturates, it saturates. This would be something like requesting a speed of 1800rpm from a 1200rpm motor, or a force of 150lb from a 100lb hydraulic cylinder - you are asking the actuator to do something it physically cannot do.

In your case the gains may cause the system to saturate - your PWM signal "should be" (per the controller), at 150%, but you can only command 100%. So you truncate to whatever the max is (100%), and send that. When the controller "sees" that the system is responding and approaches the reference command, it will back off on its own. This is the great thing about a controller. The output signal doesn't matter too much because it's looking for a response as compared to your command, not any kind of absolute.

That is, if you command a yaw rate of 30 deg/second, but you can only accelerate 1 deg/s^2, your controller may saturate your input asking "full throttle". Once you finally accelerate to the desired yaw rate, the controller will back off on its own to hold the desired command. Note that the controller will always try to meet the performance goals you specified when choosing the gains; it is up to you to spec the actuators to meet those performance specs.

Mostly this is to say that, if your gains look like they're too high, you may have either asked for more performance than your craft is capable of delivering or you have not modeled your system correctly. If you're close it will generally work, but if your gains are too far off (your model is too incorrect), then you will wind up with either no response or you will wind up railing the controller, where the controller says, "I'm too slow - Full throttle!" and then a moment later, "I'm too fast, turn it off!". This is caused by gains that are too high.

You can always tune the gains manually to achieve desired performance (section 4 of this PDF - Zeigler Nichols tuning), but I think you'll find that PID control of a MIMO system is nigh impossible due to coupling between input/output channels. I think you would be happiest with a state feedback controller, but that's not what you asked about so I'll just post the link and leave it at that.

Good luck!