Tuning a controller is not always the hardest part. Its implementation in a real-world control loop requires additional efforts: One might have to be able to (gracefully) turn the controller on or off, modify its parameters while in operation, and deal with unwanted behaviors such as measurement noise, actuator limitations, or time delays in the control loop. This is usually easier said than done. In this chapter, we examine some of these issues and try to offer solutions that maintain the simplicity we consider a vital part of the “ADRC spirit.”
9.1 Controller Output Limitation
9.1.1 Magnitude Limitation and Windup Protection
In every practical control loop, the manipulated variable—fed by the controller output—is subject to certain limitations. This leads to problems if the controller wants to drive the actuator beyond its limits while trying to reach or maintain a set point: As long as a control error persists, the controller tries to cure the issue by applying more of the same medicine, leading to an ever-increasing controller output magnitude. This phenomenon is often called integrator windup, 1 since the controller accumulates nonzero control errors due to its integral behavior.
There is a multitude of model-free and model-based approaches to prevent windup [2]. In practical (often, PID) controllers, simple (“ad hoc”) solutions are usually employed, such as conditional integration or back-calculation [3]. However, each variant comes with a different set of properties and some with additional parameters to tune. This puts an extra burden on the designer of a control loop.
Anzeige
ADRC can be affected by windup, as well, since estimating the total disturbance creates an integral term, which we have seen in the transfer function representations. And now for the good news, since ADRC is built around an observer, there is one simple yet effective solution that does not require additional tuning, making use of the so-called observer technique [1]. As we have already hinted at several times, especially in Chap. 8, feeding the limited control signal back to the observer prevents windup [4]. Figure 9.1 shows the resulting control loop structure.
Fig. 9.1
Discrete-time ADRC, state-space implementation, enhanced by a control signal limitation block. Feeding back the limited controller output ulim instead of u (as in Fig. 8.4) is the only measure required to prevent windup in ADRC
×
To achieve magnitude limitation of the control signal—which, in our opinion, should be part of every practical controller—the additional “Limiter” block consists of a hard upper/lower limit for u:
$$\displaystyle \begin{aligned} u_{\mathrm{lim}} = \operatorname{sat}_{u_{\mathrm{min}}}^{u_{\mathrm{max}}}(u) = \begin{cases} u_{\mathrm{min}} & ,\ u < u_{\mathrm{min}} \\ u & ,\ u_{\mathrm{min}} \le u \le u_{\mathrm{max}} \\ u_{\mathrm{max}} & ,\ u > u_{\mathrm{max}}. \\ \end{cases} {} \end{aligned} $$
(9.1)
To prevent windup, the observer is now being fed by the limited signal ulim instead of the unlimited controller output u—it is as simple as that. Do you believe that? We can find out using the dual-feedback transfer function representation (8.37) from Sect. 8.4.3, where we derived two discrete-time transfer functions from the measured plant output y and the limited controller output ulim back to the updated (unlimited) controller output u. If we put in the α, β, γ coefficients provided in Appendix A.7 for bandwidth parameterization, we can obtain the DC gain of these transfer functions by evaluating at zero frequency (i.e., z = 1), yielding
Evidently both CFBu and CFBy are of proportional type. The controller output u will therefore not wind up if both ulim and y are stuck at certain values but converge to a finite value regardless of the control error.
Anzeige
In Fig. 9.2, ADRC-based control loops building on our go-to example from Sect. 5.2 are being compared, with and without this simple anti-windup technique. It can be seen that, with anti-windup, overshoot of y and build-up of u are prevented, and u recovers nicely from being in saturation.
Fig. 9.2
ADRC with magnitude limitation: closed-loop simulation of the example in Fig. 5.4, this time with a discrete-time state-space implementation of ADRC with Ts = 0.1 s. Tuning and plant parameters are as described in Sect. 5.2; only the bandwidth was increased to ωCL = 2π ⋅ 0.3 rad∕s. Three variants are compared: unlimited controller output (blue), an externally applied limitation (without feedback to ADRC, i.e., without anti-windup—the control signal is shown both before and after the limitation block here, red colors), and the scheme of Fig. 9.1 (with anti-windup via feedback of ulim to the observer, green color). Using reference and disturbance steps, the controllers are deliberately driven into saturation. The simple anti-windup scheme of Fig. 9.1 prevents overshoot and windup of the integrator state within ADRC
×
9.1.2 Rate Limitation
On top of magnitude limitation, more advanced restrictions to the control signal are, within certain limits, possible—which is the reason we put such a generic “Limiter” block in Fig. 9.1. One notable and practically relevant example is the inclusion of an additional rate limitation. During transients or after sudden load changes in a control loop, this enforces a maximum possible velocity for control signal changes, which can also help to be easier on the actuator. A discrete-time implementation for both magnitude and rate limitation is shown in Fig. 9.3 and governed by
Discrete-time limitation block adapted from [4]: Using two (symmetric or asymmetric) saturation elements, the output signal ulim can be limited in both magnitude and rate, cf. (9.2)
×
The simulation example in Fig. 9.4 compares controllers with two different rate limits to an unlimited controller. Again, u(k) recovers nicely from being rate-limited, which underlines the effectiveness of the observer-based anti-windup technique. The price to pay for a slowed-down control signal might be a reduced ability to quickly compensate disturbances or to achieve the desired closed-loop response.
Fig. 9.4
ADRC with rate-limited controller output: closed-loop simulation of the example in Fig. 5.4, with a discrete-time state-space implementation of ADRC with Ts = 0.1 s. Tuning and plant parameters are as described in Sect. 5.2. In this example, there are no magnitude limits set for the controller output u, but a rate limitation is in place for two variants (green colors). If chosen to be strict (slow), a rate limitation will reduce the controller’s ability to reject disturbances and follow the reference signal with the initially designed bandwidth
×
One must always keep in mind that the anti-windup extension of ADRC discussed here belongs to the category of simple, “ad hoc” techniques. As such, it cannot do wonders and compete with advanced model-based approaches such as MPC. It is very possible to provoke oscillations by choosing the rate limit too strict—which, on the other hand, is not advisable due to the decreased responsiveness of the controller anyway. A rate limit should be carefully selected and, if possible, evaluated using a closed-loop simulation. Having a rate limit as an easy-to-implement option for ADRC in the first place, however, is a very welcome addition and a selling point compared to traditional PID-type controllers.
9.2 Bumpless Transfer
One of the aspects that practical controllers and their “textbook” siblings differ in might appear trivial, despite being of great importance: the ability of smoothly enabling a controller, i.e., without inducing unnecessary control actions. This has never appeared to be a problem in any of the simulation examples presented so far, since all of them were being simulated in closed-loop mode starting from zero initial conditions for both plant and controller. Nonzero initial conditions can, for example, be caused in practice by the plant’s ambient conditions—think of the room temperature in a temperature control task. The desired way of transitioning to closed-loop control from manual control mode, or switching between different controllers, is often called bumpless transfer, as no “bumps” shall occur in either the controller output or the controlled variable. Similar issues can occur when retuning a controller while in operation, where a sudden parameter change may lead to unwanted drastic changes in the controller output. In this section, we want to address this class of problems.
9.2.1 Transfer from Manual to Automatic Control
To demonstrate what can go wrong without proper initialization, let us pick up the example from Sect. 5.2 once more. In the first set of results shown in Fig. 9.5, it is controlled by discrete-time ADRC that is enabled after being in a settled, nonzero state due to manual control. Enabling ADRC with zero internal state in this scenario leads to terrible results—no signs of a “bumpless” transfer, we must do better!
Fig. 9.5
Bumpy and bumpless transfer to automatic control: enabling discrete-time state-space ADRC in a nonzero initial state of the plant \(P(s) = \frac {1}{s^2 + 2s + 1}\) from Sect. 5.2. The transition between manual control with umanual = 1 and closed-loop control with r = y = 1 occurs at time t = 1 s. Three variants are compared: (left, blue colors) no initialization, i.e., all internal state variables are zero when switching on, (center, green colors) tracking of y and umanual by the observer before switching on the controller output—here purposefully a little too early, and (right, red colors) direct initialization of the observer state prior to enabling the controller output. Obviously, enabling ADRC without initialization—i.e., with zero-valued internal state—can be a bad idea, leading to enormous control action spikes. Enabling the observer well before the controller to let the ESO track the manual control action and current plant output can resolve this issue if the controller does not need to be enabled instantly. Direct initialization allows to bumplessly switch on both observer and controller at the same time
×
We consider two discrete-time ADRC forms especially relevant for practical use: the state-space and the dual-feedback transfer function implementation, as they are functionally equivalent also regarding their anti-windup possibilities. Initialization procedures to achieve bumpless transfer for these two are therefore being discussed in the following. If the reference signal value is chosen to match r = y and the plant being in a settled state before, the transition to closed-loop control should then be bumpless, i.e., not be noticeable in both the control signal and the plant output.
State-space implementation: As outlined in [4], one option involves enabling the observer earlier than the controller and feeding the externally provided control signal u and plant output y to the observer. This approach can be called tracking, and if this is done in time to allow the observer to reach a settled state before the controller output is being activated, bumpless transfer can be achieved. If the observer state is not yet fully settled, the transfer will still be (slightly) bumpy, as specifically demonstrated in Fig. 9.5 (second example).
Another option allows to simultaneously enable controller and observer at time step k by means of direct initialization of the observer state to a meaningful previous value \(\hat {\boldsymbol {x}}(k-1)\). Given a measurement value of the plant output y(k − 1) and the initial control action u(k − 1) (e.g., from manual control), a simple initialization strategy consists of setting the estimated output to the measured value, i.e., \(\hat {x}_1(k-1) = \hat {y}(k-1) = y(k-1)\), and adjusting the total disturbance such that the controller output will match the given value u(k − 1) if r = y is being chosen:
Attention! It is important to note that the z−1 element in the observer implementation of Fig. 9.1 does not hold the state \(\hat {\boldsymbol {x}}\), since \(\hat {\boldsymbol {x}}(k)\) is being formed by the output of said z−1 element plus l ⋅ y(k). To initialize the observer output to the desired value given in (9.3), one must therefore set the (N + 1) storage variables of the z−1 element to the value \(\hat {\boldsymbol {x}}(k-1) - \boldsymbol {l} \cdot y(k)\). The third example shown in Fig. 9.5 uses this approach to achieve bumpless transfer.
Dual-feedback transfer function implementation: For the minimum-footprint variants shown in Fig. 8.9, we can adapt the initialization steps presented in [5] to the form introduced in this book.
1.
Denote the sum of the two feedback transfer function outputs as the intermediate variable f, and compute its value from the recent measurement y(k − 1) and the externally provided previous control action u(k − 1): \(\displaystyle f(k-1) = u(k-1) - \frac {k_1}{b_0} \cdot y(k-1)\).
2.
Initialize the storage variable xN+1 belonging to the lowermost unit delay: xN+1(k − 1) = −αN+1 ⋅ f(k − 1) + γN ⋅ u(k − 1).
3.
Recursively initialize the upper N storage variables xi in reverse order, i.e., ∀i = N, N − 1, …, 1: xi(k − 1) = xi+1(k − 1) − αi ⋅ f(k − 1) − βi ⋅ y(k − 1) + γi−1 ⋅ u(k − 1).
For error-based ADRC, things are a bit easier since the estimated variables are derived from the control error—which is zero when transitioning from a settled state to closed-loop control with r = y. Nonetheless, initialization is necessary to provide the desired output value upon enabling the controller.
Error-based ADRC, state-space implementation: For direct initialization of the observer state, (9.3) gets simplified under these conditions and now reads
In a settled state r = y, which implies e = r − y = 0, this value can directly be written into the (N + 1) storage variables of the z−1 element of the observer in Fig. 8.10. Alternatively, the tracking approach can, of course, also be adapted to the initialization of error-based ADRC.
Error-based ADRC, dual-feedback transfer function implementation: Similar to the steps described above for output-based ADRC, initializing the minimum-footprint variants shown in Fig. 8.13 can be done for the state variables (unit delays) in a recursive manner. Given an externally provided previous control action u(k − 1) and assuming zero control error for the time instant of enabling the controller, one obtains the following procedure.
1.
Initialize the storage variable xN+1 belonging to the lowermost unit delay: \(\displaystyle x_{N+1}(k-1) = \left ( \gamma _{N} - \alpha _{N+1} \right ) \cdot u(k-1)\).
2.
Recursively initialize the upper N storage variables xi in reverse order, i.e., ∀i = N, N − 1, …, 1: \(\displaystyle x_i(k-1) = x_{i+1}(k-1) + \left ( \gamma _{i-1} - \alpha _i \right ) \cdot u(k-1)\).
For x1, this initialization necessarily leads to the value x1(k − 1) = u(k − 1).
Exactly the same procedures can also be used when switching from a different controller to ADRC. Finally, if present, an output limitation block must be initialized in all variants before enabling the controller output such that its initial output matches the given previous control action u(k − 1).
9.2.2 Bumpless Parameter Changes
Another desirable feature of a real-world controller is the ability to modify its parameters while being in operation. Remembering the ingredients of ADRC first summarized in Sect. 3.1.5, we can group parameter modifications in three categories: changes to the critical gain parameterb0, changes to the state-feedback controller, and changes to the observer. Note that, when using bandwidth parameterization with ωCL and kESO, a modification of ωCL would affect controller and observer at the same time. From the factor \(\frac {1}{b_0}\) in the control law (3.15), it becomes obvious that a sudden change of b0 would immediately result in an abrupt change of the controller output—an undesirable behavior.
Avoiding jumps of the controller output when modifying its parameters is a problem very much related to that of bumpless transfer: One can think of it as switching from one controller to another, with a different parameter set. At least in a settled state r = y, the control signal u should remain constant when doing so. It, therefore, suggests itself to reuse the solutions discussed before for the bumpless transfer problem. The procedure for a parameter modification would then be:
1.
Compute the controller output with the previous parameter set.
2.
Apply the parameter changes, i.e., if one of the input parameters to ADRC tuning (such as b0, ωCL, or kESO) is modified, update all dependent matrix or transfer function coefficients for the implementation chosen.
3.
Reinitialize the internal controller/observer state variables such that the controller will maintain the previously computed output value, e.g., using (9.3).
A simulation example of implementing bumpless parameter changes using this approach is presented in Fig. 9.6. As a final note, it might be argued if bumps in u should be “allowed” when switching controllers or modifying parameters in the midst of a transient. In the eyes of the controller taking over, starting from an initial condition r ≠ y could be interpreted as the beginning of a step response, which usually involves a jump in u. Steering clear of this discussion, we limited ourselves in this book to providing solutions for bumpless transfer and parameter changes when the plant is in a settled state r = y.
Fig. 9.6
Bumpless transfer and bumpless parameter changes for discrete-time ADRC with N = 2 and Ts = 20 ms. Initial tuning parameters are ωCL = 2π ⋅ 0.2 rad∕s, kESO = 10, and b0 = 1. Normalized plant \(P(s) = \frac {1}{s^2 + 2s + 1}\) from Sect. 5.2. Measurement noise is added with σ = 0.002. As desired, the bandwidth changes do not lead to bumps in either y or u but can be recognized from the varying impact of measurement noise on u, as well as the settling time
×
9.3 Dealing with Measurement Noise
Measurement noise is almost inevitable in any practical control loop, although the severity of the problem will, of course, depend on the considered application. One result of the gang of six analysis performed in Sect. 5.3.3 was that high-frequency measurement noise will impact the controller output depending on the amount of damping provided in the transfer function Gun in that frequency range—which, in turn, depends on damping provided by the feedback controller transfer function CFB.
In Fig. 5.8 of Sect. 5.3.3, we have already seen that the choice of observer bandwidth affects Gun and will require a compromise. Larger values of kESO would—in theory—be “nice to have” regarding disturbance rejection and maintaining closed-loop dynamics even under plant uncertainties. On the other hand, some upper limit to kESO (or, more general, to the observer speed) will be imposed by the maximum amount of noise admissible in the controller output.
What we have not seen yet, however, is the fact that all of this becomes even more of a problem for increased plant orders N. In Fig. 9.7 we demonstrate this fact with two examples controlling normalized first- and second-order plants with ADRC implemented in discrete-time form. The same levels of measurement noise are inducing vastly different levels of noise in the control signal, and this will worsen fast if the order is increased beyond N = 2.
Fig. 9.7
Influence of the system order N on the sensitivity of the controller output to Gaussian measurement noise with σ = 0.005. The normalized first-order plant is \(P_1(s) = \frac {1}{s + 1}\) and the second-order plant \(P_2(s) = \frac {1}{s^2 + 2s + 1}\). Both control loops are being tuned for the same bandwidth ωCL = 2π ⋅ 0.2 rad∕s, kESO = 5, and with b0 = 1. Sampling interval of the discrete-time controller implementation is Ts = 10 ms. With increasing system (= controller) order N, the impact of measurement noise on the controller output becomes drastically larger
×
So what can be done to mitigate the impact of measurement noise? First, we want to briefly discuss two options to reduce the noise sensitivity without requiring structural modifications or additions to the controller or control loop.
Bandwidth selection: An obvious approach to this problem is to reduce the bandwidth when tuning ADRC, particularly regarding the observer dynamics. It was evident from Fig. 5.8 in Sect. 5.3.3 that the choice of kESO quite drastically affects the sensitivity of the controller output to high-frequency measurement noise. To demonstrate this fact with a time-domain example, Fig. 9.8 builds on the second-order example from Fig. 9.7 and compares observer designs with kESO = 5 and kESO = 10. Solving the noise sensitivity problem with reduced kESO values, on the other hand, must be traded in for reduced disturbance rejection abilities and the fact that closed-loop dynamics will increasingly fall short of the design goals, as visible from closed-loop step responses in Fig. 9.7, as well.
Fig. 9.8
Influence of tuning parameters on the sensitivity of the controller output to Gaussian measurement noise with σ = 0.005 in a control loop with a normalized second-order plant \(P(s) = \frac {1}{s^2 + 2s + 1}\). Other ADRC parameters remain fixed at N = 2, b0 = 1, and ωCL = 2π ⋅ 0.2 rad∕s. Sampling interval of the discrete-time controller implementation is Ts = 10 ms. For each of the observer bandwidth choices (kESO = 5, green colors; kESO = 10, blue colors), a half-gain tuning variant was added (thinner, darker lines), demonstrating the ability to reduce the noise sensitivity while maintaining the dynamics of the controlled variable
×
Half-gain tuning: A more subtle solution to tuning ADRC with reduced noise sensitivity in mind was proposed in [7], called half-gain tuning. It can be applied to tuning both controller and observer within ADRC, and the application of this method is very simple in continuous-time domain: Firstly, compute controller and/or observer gains using bandwidth parameterization; then reduce these gains to 50 % afterward. This results in closed-loop dynamics that—when applied only to the observer—are almost indistinguishable from regular bandwidth parameterization but lead to reduced high-frequency gains and hence improved noise suppression. In Fig. 9.8 two additional test cases demonstrate the effect of using half-gain tuning for the observer.
Applying half-gain tuning to discrete-time ADRC involves a few more steps: Compute the continuous-time eigenvalues of the closed outer loop for the virtual plant (3.17) using halved controller gains kT or the eigenvalues of the closed-loop observer (3.16) using halved observer gains l. Map these poles to the discrete-time domain, and then perform pole placement for the discrete-time virtual plant (8.12) or the discrete-time observer (8.5), yielding the desired results for kT or l.
To quantify the noise levels indicated only visually in the examples of Fig. 9.8, Table 9.1 gives RMS and MAD values for the controller output for these two options (kESO variation and half-gain tuning). If freedom to modify the controller or control loop structure is available, there are additional options to mitigate noise problems.
Additional low-pass filter: As demonstrated in Sect. 5.4.2, an additional pole added to the plant might—if fast enough, of course—be barely noticeable in the closed-loop dynamics. Adding a simple low-pass filter in the feedback path with a time constant being only a fraction of the plant time constant is therefore one possible option to reduce the impact of measurement noise.
Table 9.1
Mean absolute deviation (MAD) and root mean square (RMS) values of the noise levels in the examples of Fig. 9.8, computed for kESO = 5 and kESO = 10, both without and with half-gain tuning for the observer (cases labeled “HGO”). These values were obtained from steady-state simulations, averaging 100000 samples. Caused by Gaussian noise, the MAD and RMS levels are related by a factor of \( \sqrt {2/\pi }\) [6]. Using half-gain tuning for the observer reduces the noise levels by approximately more than 25 %, without noticeable impact on the closed-loop dynamics
Criterion
kESO = 5
kESO = 5, HGO
kESO = 10
kESO = 10, HGO
MAD
0.03840
0.02761
0.15555
0.11585
RMS
0.04815
0.03462
0.19501
0.14534
Enhanced ADRC structures: ADRC can be equipped with additional countermeasures against measurement noise. As one example, cascading multiple extended state observers is proposed in [8]. This, however, comes with some drawbacks on its own, such as additional tuning parameters or the burden of selecting the correct structure [9]. It should therefore be considered an ongoing research topic to keep an eye on.
9.4 Control of Plants with Dead Time
Many practical processes exhibit time delays—for example, due to actual transport mechanisms or as part of a simplified plant modeling, where a “low-pass plus time delay” is a sufficiently accurate description of higher-order dynamics. In either scenario, models of a plant such as those given in Table 3.1 must be extended to take the time delay (dead time Td, in seconds) into account. For a first-order plant, P(s) then reads
So far, we did not consider plants with time delays in this book. But if information about the plant dead time is available during control design, it appears reasonable that one can make beneficial use of that information.
For ADRC, one simple and practical solution is to synchronize the observer (which has a plant model inside) with the time-delayed plant [10]. In that case, the implementation of discrete-time ADRC in state space could be realized based on the control law (8.1), but with the following modification to the input signal u of the discrete-time ESO:
In (9.6), terms AESO, bESO, and l are identical to the original observer in (8.5). From (9.6), it is evident that synchronization of ESO is being realized solely through an additional delay of the fed-back control signal by nd samples. In Fig. 9.9, we show the control loop with an accordingly modified discrete-time ADRC implementation. The value of nd must be chosen to let the discrete-time delay approximately correspond to Td:
Block diagram of a control loop with discrete-time ADRC, as in Fig. 8.4, but for a plant with dead time. The control signal entering the observer is delayed by nd samples to synchronize the observer with the time-delayed plant
×
To provide some intuition if and when time delays can be a problem in a control loop when not considering them, Fig. 9.10 presents closed-loop step responses of unmodified ADRC implementations controlling a first-order plant with increasing dead time values Td. As visible, larger time delays induce oscillations, and the control loop can quickly become unstable beyond that.
Fig. 9.10
Effect of adding dead time Td to a normalized first-order plant \(P(s) = \frac {1}{s + 1}\) (nominal case: thick black line) in a control loop with first-order discrete-time ADRC (Ts = 20 ms). Values of Td are ranging from 20 ms to 80 ms (increasingly dark colors). A further increase of Td would render the control loop unstable
×
While the simple solution of (9.6) as part of Fig. 9.9 cannot achieve wonders, a mitigation of delay-induced problems is possible. This is being demonstrated in the examples shown in Fig. 9.11, which build on the worst-case simulation of Fig. 9.10 but now synchronize the observer with the plant. Even if one does not exactly know the actual dead time, the closed-loop response is considerably improved.
Fig. 9.11
Compensating the effect of the worst-case dead time (Td = 80 ms) from Fig. 9.10 by delaying the u-input of the observer by nd samples (with sampling interval Ts = 20 ms), as shown in Fig. 9.9. To demonstrate the effect of missing the actual dead time value, i.e., \(n_{\mathrm {d}} \ne \frac {T_{\mathrm {d}}}{T_{\mathrm {s}}} = 4\) (nominal case, thick black line), values of the applied delay are varying between nd = 2 (underestimation, blue colors) and nd = 6 (overestimation, red colors)
×
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Due to its practical relevance, we are only covering windup occurring within the controller in this book—so-called controller windup, as opposed to plant windup [1].
