why my discretized PID controller behaves differently than my continuous (unfiltered) PID?

I am simulating a continuous pure PID (unfiltered) controller with parameters kp= 11.4 , kd = 3.16 and ki = 1.2, these parameters give me a desired overshoot, rise time and settling time, the idea is to discretize the PID to control a continuous system, I discretized the PID, but when I run the simulation, it's like I had two different controllers, the transient response of the system is very different, why would that be? , thanks

I discretized using c2d command, with 'tustin' method (as it's the only method that will discretize an improper TF), I also tried trapezoidal approach and got the exact same results (not good)

I've tried sample times = 0.01, 0.001, 0.000001, the controller behaves pretty much the same

I am only implementing an unfiltered PID controller because teacher asked me to.

(if I discretize a filtered PID, discretized and continuous behave the same, so I wonder why isn't it so for unfiltered PID)

connections

blue line: system controlled with continuous PID, yellow: controlled with discretized PID

[Sayan]

Hi @Israel Almaraz Vasquez, How did you put the discretized transfer function in the discretized tf block as it can only be used for transfer functions of which the order of denominator is greater that the nominator and the discretized version of the PID transfer function is improper? Did you add any more options to c2d?

Answer 1

[Anurag]

Hi Israel,

I understand that you are seeking reasons to as why is the output of the discretized control system different than that of the continuous time system.

The effects of discretization on the behaviour of a control system stem from the inherent differences between continuous-time and discrete-time domains, and here are how the differences may arrive:

• Continuous systems are represented by differential equations, and discretization involves numerical integration techniques with varying accuracies and properties.
• The sampling rate is crucial in discretization. A low sampling rate can cause aliasing, inaccurately representing high-frequency components in the discrete-time system and impacting accuracy.
• Discretization methods can change the transient response of a system, adding dynamics or adjusting the settling time during state transitions.
• Mapping poles and zeros from continuous-time to discrete-time can alter the system's dynamic behaviour, influencing the overall system response.

Recommended ways to investigate solve this discrepancy are:

• Consider using higher-order numerical integration methods (e.g., Runge-Kutta methods) instead of simple methods like Euler's method.
• When discretizing continuous signals, such as input signals, using ZOH or FOH can be more accurate than direct discretization.
• Understand how poles and zeros in the continuous-time system map to the discrete-time system. Some discretization methods may cause the poles to shift.

For additional information please refer to the following documentation:

• https://www.mathworks.com/help/ident/ug/continuous-discrete-conversion-methods.html
• https://matlabhelper.com/blog/matlab/runge-kutta-method-in-matlab/
• https://www.mathworks.com/help/dsp/ug/discrete-time-signals.html

Answer 2

[Paul]

Hi Israel,

Let's take a look at the problem analytically.

Define the plant and controller

s = tf('s');
P = tf(1/(s^2 + s));
K = 11.4 + 3.16*s + 1.2/s;

The closed loop transfer function from input to output is

C = feedback(P*K,1);

Plot the step response

figure
step(C),grid

This plot compares favorably with the yellow curve in the scope, which is the output using the discretized compensator. So the problem is with the model of the continuous-time system. The problem lies entirely with using the Derivative block in combination with a step command that is discontinuous

The transfer function from the input to the error signal is

E = 1 - C

E =
 
            s^3 + s^2
  -----------------------------
  s^3 + 4.16 s^2 + 11.4 s + 1.2
 
Continuous-time transfer function.

and the error in repsonse to a step input is

figure
step(E)

We see the error jumps immediately to one when the step is applied, which means that the derivative of the error (as would have to be computed by the Derivative block) is a Dirac impulse at t = 0. Of course the Derivative block cannot output a Dirac impulse. In fact according to the doc "The initial output for the block is zero." The bottom line is that output of the Derivative block is way too small at t = 0 and shortly thereafter, which causes the simulated transient response to be much slower than it should be.

For simulation purposes, you can consider:

(a) Replace the Derivative block with a transfer function of the form: D(s) = s/(tau*s + 1) where tau is a smallish number. i used tau = 0.01 and got a pretty good result for this problem. Note that doing so will probably require a smaller simulation step size that will then have implications on simulating the discrete-time control path.

(b) Don't inject a pure step input. Instead, run that step command through a high-bandwidth, low-pass filter of the form F(s) = 1/(tau*s + 1). Here, the tau should be small relative to your desired closed-loop time constant, which is about 0.2 sec.

(c) Or you can construct a rectangular impulse with smal width (like 0.001 seconds) with unit area starting at t = 0 and add that to the output of the Derivative block before the Kp gain. This approach should get you very close to the expected output resopnse, though won't recover the error response shown above. I wouldn't do this other than to gain a better understanding of what's going on.

It sounds like you already have a solution with your "filtered PID," which I suspect means that the compensation does not have a pure derivative.