Hello Waijung (Part III : Feedback Control)

Hello Waijung

Part III : Feedback Control

Previously in the Hello Waijung series.

At the end of part II, we have a working platform to continue our experiment. From the open-loop response, as the capacitor is charging/discharging, the output voltage gradually changes towards the input, though we can see it could not reach Vin level in 5 seconds. If we need to steer the output to the desired command level within some shorter interval, a controller is needed. Output voltage feedback is also required for precise regulation. In this part we investigate two schemes of real-time feedback control simulation using MATLAB/SIMULINK, Waijung, and STM32F4DISCOVERY board that could help reducing development time and effort. In the first structure, a controller is constructed as a SIMULINK block and interacts with the real plant via USB-to-serial communication*. The second structure is a standalone embedded application where a controller is implemented on the target processor connected to the real plant. In both cases, a theoretical output response is simulated for comparison.

*In the workshop they called this “hardware-in-the-loop” and included HIL abbreviation here and there. I choose to honor the developer by retaining such name, though I make a caution that it might not quite be consistent with HIL definition in a general sense.

For this part, we need to design a controller and put it in a feedback loop.. It is quite customary to do the design in continuous-time domain and discretize the controller later. MATLAB as a powerful control design tool for single-input-single-output system called sisotool. Figure 1 shows the feedback configuration used by sisotool. In this case we need to design and implement only the feedback controller C (the red block). The feedforward controller F and sensor H are set to 1.


Figure 1 general feedback configuration

From part II, our plant transfer function in the s-domain is

(1)   \begin{equation*}  G(s) = \frac{1}{1+1.551s} \end{equation*}

Figure 2 shows the sisotool graphical display during control design process. If you’re good at root locus method, use the upper-left subplot. I’m more comfortable with loopshaping method at right.


Figure 2 control design process with sisotool in MATLAB

So basically what I do is first adding an integrator to eliminate steady state error. Then I add a zero close to the pole of the plant so that the loop transfer function has gain slope of -20 dB per decade around my chosen crossover frequency. To achieve better measurement noise attenuation, I add another pole to cause 2-pole roll-off in the high-frequency region. Last, I adjust the gain to achieve a desired bandwidth. While doing this, I check the step response y(t) and controller output u(t) as shown in Figure 3, which is a convenient feature in sisotool. Higher bandwidth may result in too high controller output exceeding the DAC voltage.


Figure 3 step response and controller output plots from sisotool

For demonstration purpose, I perform this adhoc design without a solid specification. You may try formal control design procedure with specified rise-time, percent overshoot, etc.

So, after playing around with sisotool for some time, I eventually settle with this controller

(2)   \begin{equation*}  C(s) = \frac{9.4619(s+0.642)}{s(s+2.998)} \end{equation*}

It is left as an exercise to the reader that, using ZOH method and sampling time 0.01 sec, we can derive a discrete-time transfer function of this controller as

(3)   \begin{equation*}  C(z) = \frac{0.09352(z - 0.9936)}{(z-1)(z-0.9705)} \end{equation*}

Instead of doing the conversion by hand, we export the controller from sisotool to MATLAB workspace, and discretize it with c2d function, with sampling time 0.01 sec as its argument

>> Cd = c2d(C,0.01)
 
Cd =
 
   0.09352 z - 0.09292
  ---------------------
  z^2 - 1.97 z + 0.9705
 
Sample time: 0.01 seconds
Discrete-time transfer function.

You can hard-code this into SIMULINK diagram or make data available in workspace. Since SIMULINK discrete transfer function block accepts data in the form of numerator and denominator, which you can use tfdata function to extract

>> [numz,denz] = tfdata(Cd,'v')
numz =
 
         0    0.0935   -0.0929
denz =
 
    1.0000   -1.9705    0.9705

then put the variable names into the block. I choose to hard-code the controller into the models so that I could run it without doing this computation each time.

Once again, the SIMULINK models used for this experiment come in pair HIL_AinH_Target.mdl, and HIL_AinH_Host.mdl, shown in Figure 4 and 5.


Figure 4 SIMULINK model for target HIL_AinH_Target.mdl


Figure 5 SIMULINK model for host HIL_AinH_Host.mdl

Notice that the controller blocks exist only in the host model file. There are two blocks, one for theoretical model simulation, and another is put in the loop with the real RC circuit plant. When real-time simulation starts, the controller, implemented in the host, communicates with the real plant via the ADC and DAC modules of STM32F4DISCOVERY.

The build and run process is essentially the same as in part II. The only difference is the two controller blocks in host model, where the numerator and denominator data of the controller must be put into.

Update, build, and load the target. Then run the host simulation. Clicking on any scope icon on signal route yields the plot shown in Figure 6. It turns out that the discrepancy between the theoretical and actual response is significant. Can you explain what happens?


Figure 6 real-time simulation result from HIL_AinH_Host.mdl

For those who have some experience with PID control, you’d see similar effect in a situation known as “integrator windup.” The undesirable large overshoot happens when an integrator is present and there is some saturation at the plant input. This is also the case for our feedback system. Notice from the controller output u(t) in Figure 3 that it has maximum variation of nearly 2.5 volts, while the DAC output is limited to 0 – 3 volts, and we generate input command signal that switches between 1 and 2 volts. So during transition, the computed controller output could exceed the DAC range, causing worse response than it should behave in a pure linear system.

To verify whether our explanation above is correct, we lower the control bandwidth a bit by reducing the controller gain to 55% of its original value. This can be done easily by multiplying the data in numerator field of the two blocks by 0.55. Figure 7 shows the step and controller output response after the gain reduction. The controller output variation now decreases to 1.6.


Figure 7 step and controller output responses after gain reduction of 0.55

Running the new simulation results in the closed-loop response in Figure 8. Now we see that the comparison matches much better.


Figure 8 simulation result from HIL_AinH_Host.mdl after gain reduction

Standalone Implementation

Suppose that, after a series of simulation and redesign, we are satisfied with a controller and decide to implement it on the target processor. This can be done easily with Waijung by moving the discrete controller transfer function block from the host to the target model file as shown in Figure 9 – 10. Now the host model contains only theoretical simulation for response comparison.


Figure 9 target standalone model Standalone_Target.mdl


Figure 10 host standalone model Standalone_Host.mdl

First we experiment with the original controller without gain reduction to see the effect from saturation. The responses are shown in Figure 11. The detrimental effect from DAC output limit is less than the case when the controller is in SIMULINK, but is still noticeable.


Figure 11 standalone response from high-gain controller

Now we reduce the controller gain by a factor of 0.55, resulting in the responses in Figure 12. The standalone response now matches that of the theoretical feedback model quite well.


Figure 12 standalone response after controller gain reduction

Conclusion

In these 3 parts of the Hello Waijung series, we examine the power and usefulness of MATLAB/SIMULINK and Waijung tool in embedded control system development. The original workshop requires a set of hardware accessories, which is convenient for those who have no time to solder and wire electronics by their own. Here, for a budget limited guy like me, I show how the hardware can be kept minimal and concentrate on using the software tool. Once you understand the basics, it is straightforward to extend your knowledge to a more advanced plant than the RC network. Therefore, your first endeavour is perhaps to replace the RC plant by a more complicated system and use the same procedure to design, build, simulate, and implement feedback control for such plant.

Supplement

Zipped file containing all model files hello_waijung.zip

Comments

comments

Comments are closed.