# How to tune PID for a Y(t) = k*X(t) system?

Could I have your opinions on PID type selection? System description

1. Here comes a very simple system: $\mbox{Output}(t) = k * (\mbox{Input}(t) + \mbox{systemVariable}(t))$. $k$ is constant and $\mbox{systemVariable}(t)$ is a system variable which may change according to time.
2. The goal of the whole system is to maintain system output at $0$. It has to be as close to zero as possible. The controller has to compensate the $\mbox{systemVariable}$.
3. The change ($\mbox{systemVariable}$ ) is modeled by a very slow ramp.

Controller description

1. The controller's input is the output of the system. However, the measurements are always noisy, and I modeled Band-Limited White Noise into the measurements.

2. After PID controller, the output goes into an integrator, since the PID controller always calculates the "change" of the plant input.

Questions

1. My original thoughts: Add a PID controller with P=1/k is enough. Since every time the controller gets an error $e$, it can be calculated back that the compensation on controller output shall be $e/k$. However, Matlab auto-tuning always give me a PID. Why is that?

2. What is the relation between P of PID and measurement noises? If P is large, the system will tend to be rambling largely, due to the noises. If P is small, the system will tend not to converge to the correct value or very slow. How to make the trade-offs? Or how to prevent system from rambling largely and get quick system responses?

Thanks a lot!

• Why do you have the "integrator" block in the last step of your controller? Why do you have the band-limited white noise in your controller? I understand that, because it's white noise (presumably zero-mean), that it doesn't truly make a difference where you put it, but for clarity it should be a summation block on your feedback line, as the noise is injected in your feedback, and as a note, you are adding the noise instead of subtracting it, which you should do if it is, in fact, feedback noise (if it were not zero-mean this would make a big difference!). – Chuck Aug 12 '15 at 13:10
• As an edit to the above, I just re-read your question. As noted in my answer below, you should not be using the integrator after your PID controller. – Chuck Aug 12 '15 at 13:28
• Can you explain what the underlying system is and why there is a ramp? – Chuck Aug 13 '15 at 0:26
• The system is drifting slowly, and the controller shall compensate the drift. The drift is modeled, if correct, by a drift.. – richieqianle Aug 13 '15 at 2:43
• What is the system? What is the drift? Is the drift bounded? Is it linear? The more information you can give the more helpful we can be. – Chuck Aug 13 '15 at 11:43

I had problems understanding the diagram and the question. It might be because you didn't explain every step to keep the question short or just because I use some terminology differently so I'd like to go through this slowly. This is not to say that this is the right way to do it, but so that everybody is on the same page. The comments imply that others are also confused. Essentially, I would identify things differently and in control theory giving something a different name can be a major part of the solution.

I was pretty much in WTF? mode until I saw this in the comments: r+PID_output, which gave me a hint on how this came to be. Well, at least I think.

## The ramp is not part of the plant

No, not even if it is part of the plant. The reason is that adding the ramp makes the plant nonlinear. An LTI system is a Linear Time Invariant system. That means (among other things) shifting the input by some amount of time, should only result in a time shifted output, without changing the input value. The ramp breaks that rule.

For the sake of some more confusion, $y = mx + n$ is also nonlinear1.

I could come up with some gruesome simile about how you'd want to rather choke on your own innards than doing nonlinear control theory, but instead I'd say let's try to do this with linear control theory. It is able to handle the situation.

The plant is just $k$, it's transfer function (which can be calculated now, just another benefit of kicking the ramp out) is simply:

$$output (t) = input(t) \cdot k \\ Output(s) = Input(s)\cdot k \\ \frac{Output(s)}{Input(s)} = k$$

## Neither noise nor integrator are part of the controller

As you say, the noise isn't created in the controller, so why model it there? And the mysterious integrator is removed in a coincidently similar way to the ramp. * cough *

We are left with the bog standard control loop without a sensor. (a sensor will never be present in this answer, the sensor in the image simply has a transfer function of 1) ## Finding a suitable controller for the system

$P=\frac{1}{k}$ is enough. Since every time the controller gets an error e, it can be calculated back that the compensation on controller output shall be $\frac{e}{k}$. However, Matlab auto-tuning always give me a PID. Why is that?

It's tempting to use the inverse of the transfer function of the system as a controller.

That would compensate the system exactly, if you are a glas-half-full kind of person. On the other hand, if you are a glas-already-empty-again-damnit-gotta-order-another-one kind of person, it only compensates the system exactly. The subtle difference is that a model is never exact. With slight inaccuracies in the model due to real world stuff, compensating the system transfer function exactly is not a good idea.

Adding an integral part for good measure is usually a good idea, one reason is stated here:

The integral term accelerates the movement of the process towards setpoint and eliminates the residual steady-state error that occurs with a pure proportional controller.

## For those about to ramp, we compensate you2

The existence of the ramp cannot be denied. Instead of modelling it as part of the system, let's model it as the disturbance variable as can be seen in the following image named $W$ hint: a click on the image leads you to the source of the image which is an article on how to simulate disturbance transfer functions with matlab

Two important properties of a system are:

1. how quickly it follows a change of the input, which is kinda moot, because that's constant $0$ in your case
2. how quickly it can compensate a disturbance

It's usually a trade-off between both. You can compare them by looking at their transfer functions.

There's a great image showing that on a non English Wikipedia article. This is optional, so feel free to just skip this.

Trouble is that the variables used there have different names. The block diagram with controller $G_R(s)$, system $G_S(s)$ and disturbance $D(s)$ looks like this: The disturbance transfer function is thus given as:

$$\frac{Y(s)}{D(s)}=\frac{G_S(s)}{1+G_R(s)G_S(s)}$$

Ok, ready? Here it comes: Don't worry if you don't have the Sauerkraut to read it, because I do.

There are 4 plots displaying unit jumps of disturbance and input and the output responses to these using two different controllers (both PID controllers but different parameters):

1. the $\color{blue}{\text{thin blue}}$ line is the plot of the input $w(t)$ jumping to $1$ at $t = 0$, it's basically just a horizontal line at 1
2. the $\color{green}{\text{thin green}}$ line is the plot of the disturbance $d(t)$ jumping to $1$ at $t = 10$
3. the $\color{blue}{\text{thick blue}}$ line is the response of the output controlled by a controller tuned for quickly adopting changes in the input. As you can see it takes the jump of the input rather well without overshooting much. The disturbance however is not compensated quickly. It causes a huge bump in the plot(up to 1.3) which never fully recovers back to 1 (where it should be) within the visible area of the diagram. You certainly don't want that.
4. the $\color{red}{\text{thick red}}$ line shows the response of the output controlled by a controller tuned to quickly compensate disturbances. The response to the input jump is a disaster, but the response to the disturbance jump at $t = 10$ is barely visible. The disturbance jumps from 0 to 1, but the output only climbs to roughly 1.05 because of that. This is what you want

The only difference between the two is what PID parameters were used:

$$\color{blue}{G_R(s) = \frac{0.8(2s+1)(s+1)}{s}}$$ $$\color{red}{G_R(s) = \frac{10(2s+1)(s+1)}{s}}$$

There's some factor that should be rather big (10 vs. 0.8) in order to compensate disturbance well, let's call this factor $a$:

$$G_R(s) = \frac{a(2s+1)(s+1)}{s}$$

The generic PID controller has the transfer function

$$G_{PID}(s) = K_p + K_i\frac{1}{s} + K_ds$$

I conclude that multiplying all 3 PID parameters by some factor improves how well the system can handle disturbance.

The disturbance is also what I'd add the noise to.

## The mysterious integrator

Now that's all nice, but what the heck is this integrator thingy supposed to be? And how is r+PID_output a hint?

It's a feed forward compensation of the disturbance. r+PID_output is a hint because it contains the +, which indicates that this is supposed to be a feed forward. The problem is that in the block diagram, it is a separate block after the PID controller, which means in the block diagram, it is actually $r \cdot PID_{output}$, which is not how feed forward should be.

The following image shows how a feed forward compensates disturbance: (with yet again differently named variables) The compensation of the disturbance is indeed added after the controller. As can be seen in the image, it is added via a negative summation node.

As seen above, the controller itself should be able to handle disturbance, because it is tuned to do only that in your use case.

A feed forward can take some workload off the controller. If you really think this is neccessary, go ahead and add the feed forward. I would keep it separate from the controller, for better readability, although adding the feed forward will basically just change some parameters of the PID controller.

2 with apologies to AC/DC

• Wonderful explanation! I have been studying in German speeking area of Switzerland and your style reminds me friends in that area. 1. What does Z' stand for? Do you mean ramp disturbance? If so, Im afraid that it cannot be observed by the controller. So I doubt if it can be substract from the output of the controller directly. 2. Why do you think output of the integrator is r*PIDoutput? Shall not it be r+PIDoutput for an integrator? Thanks again! – richieqianle Aug 13 '15 at 3:04
• @richieqianle 1) it is indeed the disturbance. While it's true that you cannot measure it, you can still estimate it very well (at least you claim that you can). Think of a $Z'_1$ that is the real disturbance going into your plant (which you can neither prevent nor measure) and a $Z'_2$, being your estimate of the disturbance subtracted from your controller output, directly compensating the disturbance. Again, the feed forward is just an optional helper, the controller alone should be able to handle the disturbance, but given that you know the disturbance, FF gives you an advantage. – Bending Unit 22 Aug 13 '15 at 16:45
• @richieqianle 2) Sorry if I'm not being clear here. Compare the block diagram that you posted with the last one in my answer. Your integrator is directly connected to the output of the controller. For block diagrams, which consist of transfer functions, that means multiplication. In the block diagram that I posted, the feed forward is going into a summation node. The difference is that your integrator will integrate everything, whereas the idea of the FF is to compensate the known disturbance directly. – Bending Unit 22 Aug 13 '15 at 16:59
• @ BendingUnit Great explanation again... I think I know what you mean, PID without an integrator is sufficient. Do you think adding an integrator is wrong? – richieqianle Aug 14 '15 at 1:31
• @richieqianle the purpose of the FF is to take advantage of knowledge of the disturbance. You state in another comment that "The drift has a direction, but move in a random way". If it's random, you don't really know it or you'd only have some probabilistic model, which is not easily directly compensated. I suggest to try it out. After all, this is the purpose of tools like Matlab and simulink. Throw everything at it that you can think of and compare the results. How much better is the controller with the FF? How much effort is it to implement the FF? Then you can make a decision. – Bending Unit 22 Aug 14 '15 at 19:39

I just re-read your question again, and I realized that you are mistaken about the output of the PID controller. The PID controller, like most controllers, provide exactly the signal that should be sent to the plant. You should NOT be integrating the output of the controller. The PID controller does look at the output error (input - output), but it acts on that output error to provide the appropriate plant input to drive that output error to zero (to get the output to equal the input). Again, DO NOT integrate the output.

If your only issue with this system is the noise coming off of your feedback, then why not just use a filter and be done with it? You haven't stated what your plant is, so I don't know why your system variable would be a (unbounded?) ramp. Even if you are going to decide you need a PID controller, you should still use a filter if you are expecting noisy feedback.

Regarding measurement noise and PID, typically in industry the controllers are only PI, not PID, because a noise spike causes a big derivative term to be erroneously added. That is, all other things in equilibrium, $D = (noise/dT)$, where $P = noise$ and $I = noise*dT$. So, assuming you have a small sample time, noise causes usually no problems on the $I$ term, some on the $P$ term, and a lot on the $D$ term. The best way to mitigate noise is to not introduce it. Use a filter!

Matlab auto-tuning is always going to give you PID because it is stupid in that it does not understand how to exploit specific information about your plant. It provides a system capable of controlling any (SISO) plant.

• Hi Chuck，thanks for your reply. 1. In my case, the controller contains a PID controller and an integrator. The reason is as following: An error measured by the controller is based on previous controller output. 2. Yes we are using filters and there are still noises. As for the ramp, it is system property. The system keeps drifting as time goes by. 3. Yeah, it seems that auto-tuning does not work perfectly. Shall I consider using a relatively small P and a relatively larger I? – richieqianle Aug 12 '15 at 13:42
• @richieqianle I do not understand your reasoning for having an additional integrator at all. The input of the controller is always based on previous controller output in a closed loop control, so according to your logic, every controller of any kind has to have an additional integrator. Which is not true. – Bending Unit 22 Aug 12 '15 at 13:55
• @BendingUnit22 Sorry I did not reason it clearly. As can be seen that there is a ramp in the plant. The purpose of the controller is to compensate the ramp. At t1, ramp = r and keeps going up. At this point, the output of the controller cannot be zero. Is has to be r+PID_output. And r comes from the integrator. – richieqianle Aug 12 '15 at 14:05
• The PID controller does not care what the plant is doing. At all. The PID controller looks at the output, looks at the input, and provides a signal to your plant to drive the error to zero. You SHOULD NOT put an integrator after your PID controller. If you really want to exploit some knowledge of your plant to create a controller, you should look at implementing a state space controller. – Chuck Aug 12 '15 at 14:38
• @Chuck I agree with you, the PID controller does not have an integrator. Could I have a controller, which composes of a PID controller and an integrator? Or could I just regard the integrator as a part of the plant? – richieqianle Aug 12 '15 at 14:55