Here we deal with the future, both nearest and that a bit further. First, supported by the body of knowledge we have put forward with this book, we make a case for using ADRC in the future. Then, we provide key takeaways on how to use ADRC moving forward and how this book can facilitate that. And even though we are heading toward the end of Part II, this is not the end of the book yet. We explain what substantial information is still coming and why it can be especially useful to returning readers. Here we also gather and list all the “cooking recipes” which are ready-to-use procedures to tune and implement all ADRC variants covered in the book. Finally, we take a look at ADRC in a broader sense and discuss possible avenues for its further development.
Why to Use ADRC in the Future?
Entering now the back end of the book, it is time to summarize its efforts. From the start, we wanted to encourage readers to try ADRC, and here we recap and reflect on the arguments that speak for its use in the future. Looking at the state of the art of ADRC and the hyper-growth of topics associated with it, we see that ADRC, as a technology, has reached its maturity phase. It has been in use for long enough that most of its initial faults and inherent problems have been removed or reduced by further development. It is relatively well established that we know what it can and cannot do, how it is related to classical control, and therefore we can at last realistically assess its strengths and limitations. Finally, it seems that the control community has accepted ADRC, and although it has not seen widespread practical use, its scientific background is rather clear. And this maturity of ADRC technology is one of the motivations behind our decision to write this book right now. So with everything we have shown so far in the book, what are the core arguments behind using ADRC in the future? First of all, it is not a magical, one-size-fits-all solution. It is, however, a solid practical linear control. Even though we now know that the linear ADRC is not much different than a PID and that you could tune a modified PID loop in the same way you tune ADRC (as we have shown in the book), it does come with built-in qualities that make it a good default choice when looking for a practical solution to tackle a real control problem. Based on the detailed analyses and visual comparisons we have conducted throughout the book, ADRC can be characterized by the following feature set:
Generally good out-of-the-box control behavior: As we have shown, linear ADRC offers a relatively large level of robustness and adaptability while providing a practically acceptable ratio between necessary design effort and resultant performance. If one chooses an output-based variant of ADRC, then one gets a nicely critically damped tuning, which fits most solutions.
Easier tuning: The use of bandwidth parameterization greatly simplifies the controller tuning process by minimizing the number of tuning gains and, by introducing the notion of bandwidth, also makes the tuning process more intuitive with its two practically appealing time- and frequency-domain interpretations. This makes ADRC more transparent than classical controllers. Compared to, for example, the time-tested PID, you still have some parameters to tune in the case of ADRC. But for ADRC it is conceptually a different task than finding PID parameters, which are more intertwined than the above parameters, and for ADRC we know more about which compromises one can expect when having certain parameter choices.
Easy to build in windup protection: The structure of ADRC facilitates a simple, pragmatic, yet effective modification that results in gained windup protection, which is especially crucial in real systems. Although this feature is not magical and is rather a standard operation procedure in practice, it is convenient that in ADRC it is there and one does not have to think about it.
Low-footprint implementation: The above core features do not cost extra computational resources. The implementation of linear ADRC is not much more demanding than that of a classical controller. If needed, there are specialized variants of ADRC (some of which we have covered in the book) that are explicitly dedicated to practical control systems that require high computational efficiency and low parameter footprint.
Customizability: As we have shown in many instances throughout the book, ADRC is not a single set of equations. It can be straightforwardly tailored to a given application depending on many factors, like design requirements, characteristics of the controlled plant, or limitations of the actuators or the sensors. This flexibility in design is similar to what we see in, for example, PID with all of its iterations and customizations introduced over the years.
Anzeige
How to Use ADRC in the Future?
The use of ADRC always boils down to a certain amount of steps. From our experience, these mostly are the following four, which you could already recognize from the previously introduced “cooking recipes”:
1.
Plant modeling
Plant relative order (N): In many instances, it is generally known or relatively straightforward to be somewhat accurately approximated by a low number, usually N = 1 or N = 2. Note: That is also the reason why our simulation and experiments in the book are first or second order as they are most common in practice.
Critical gain parameter (b0): There are different options for choosing this parameter. One is using a time-domain model, the concept we introduced in Sect. 5.1.1 and then applied to the first hardware example in Sect. 11.1. One can also use the frequency domain model, as we have shown in Sect. 5.1.2 and then use this concept for the second hardware example in Sect. 11.2. If you deal with a plant with simple first- or second-order low-pass behavior and have its transfer function model, then you could calculate b0 as done in Table 3.1.
2.
Controller and observer tuning
Controller bandwidth (ωCL): It is much easier in the case of ADRC methodology to have an idea from the application itself about its value (in other words how fast the settling time could be). This has been made very clear in the hardware examples we have provided where we dealt with two systems with significantly different time constants: one in hundreds of seconds and the other in milliseconds. Those values directly tell us about how big the searching space is for ωCL and what is realistically possible in terms of system performance. Tuning has to also take into consideration factors limiting the bandwidth and related to the intrinsic characteristics of the system and the environment it operates in (e.g., input delay). Note: Such a system dynamics-related approach is much easier than trying to figure out, for example, PI parameters.
Observer bandwidth (tuned indirectly via kESO): Recalling (3.22), the observer bandwidth results from selecting the scaling factor kESO. Interestingly, even if one keeps its value within a default range kESO = 3, …, 10, there is a good chance you will obtain satisfactory performance. This results from an intuitive relation within ADRC that the inner, disturbance estimation loop (driven by the observer bandwidth) has to work faster than the feedback control loop (driven by the controller bandwidth). In practice, the bandwidth selection will always be affected by an upper bound resulting from the limitation of the controlled system (e.g., sensor noise), something we have shown in detail in Chap. 5. Note: For systems with N more-less known and for which the default value of kESO is expected to provide satisfying results, this could potentially mean a necessity of finding only b0 and ωCL.
3.
Implementation
In the book, we have presented several different ways (variants) of implementing ADRC, each having its own characteristics, but the above tuning applies to all variants we covered. To aid the readers with choosing a suitable variant, we provide an overview in Fig. 12.1, where three major questions need to be answered: continuous or discrete time? state-space or transfer function form? “classical” (output-based) or error-based ADRC? Note: Here we show just a selection of variants that, in our opinion, are most useful. In general, other variants can be used as well, and it is up to the user to decide what is the most fitting type of ADRC implementation depending on the given scenario. The next step is the implementation of the actual code. Depending on the earlier selection of the most suitable variant, one can go with a continuous-time implementation or, what is more likely in practice, with a discrete-time one. In Chap. 10, we show in great detail how discrete-time variants can be deployed in software form using a model-based environment or with manual coding using C language.
Fig. 12.1
Overview of ADRC variants discussed in this book and where to find their summary in the Appendix. To aid with the decision, three major questions to be answered have been visualized: continuous or discrete time? state-space or transfer function form? “classical” (output-based) or error-based ADRC?
×
4.
Customization
Finally, if there is a clear need to further improve the control design, the “standard” ADRC (as introduced in Chap. 3) could be tweaked. Due to the flexibility of ADRC in terms of its structure and parameters, it can take into consideration different practical aspects, for example, by using the extensions and modifications we have shown in the book. Augmenting ADRC with such add-ons can create tailor-made solutions to directly address certain important characteristics and limitations of the system, like plant dead time and measurement noise.
How to Use This Book in the Future?
Anzeige
The graphical guide we started with all the way back in Fig. 1.1 can serve as a useful gateway for returning readers, allowing them to quickly jump back into whatever aspect is interesting to them or needs repeating:
Wanting to consolidate foundations: If you want to solidify your understanding of the fundamental methodology of ADRC, its operating principle, basic tools, and methods, then you are invited back to the elemental Chaps. 2 and 3.
Wanting to deeper understand: If you are looking to go beyond the fundamentals, then you can check Chaps. 4 and 5. There you will find how to design the most important variants of ADRC and how to parameterize and tune ADRC while understanding the practical role of tuning parameters on system performance. These parts also detail the derivation of ADRC core concepts and help to understand the characteristics of its components (in both time and frequency domains) and the connection between the ADRC methodology and classic controllers, which also helps to understand the strengths and limitations of ADRC, both theoretical and practical. We refer the readers seeking historical perspective and relevant bibliographical support for ADRC to Chap. 7.
Wanting to deploy in practice: If you already understand ADRC and want to use it writing control software, then you can go to Chap. 10, where selected discrete-time ADRC variants (derived in Chap. 8) in software form are implemented using both a model-based environment and manually with C code. One can also go for a quick and easy Simulink-based implementation of ADRC with one of the software libraries shown in Appendix B.
Wanting a reference manual: If you are an experienced control engineer and you know how to deploy things in practice, then just start applying ADRC using the prepared “cooking recipes” (Table 12.1) as we have done for examples in Chap. 11. For that, you will need “ingredients,” and we provide those in a condensed way in the reference-style Appendix A. This cheat sheet could potentially be the only source material needed for your future ADRC implementations.
Table 12.1
List of “cooking recipes” that are ready-to-use procedures to tune and implement linear ADRC. For each variant, the required set of equations is, along with a block diagram, provided in condensed form in Appendix A
Linear ADRC Variant
Location
Details
Continuous-Time State-Space Form
Page 42
Appendix
Continuous-Time Transfer Function Form
Page 54
Appendix
Continuous-Time Error-Based State-Space Form
Page 97
Appendix
Continuous-Time Error-Based Transfer Function Form
Page 100
Appendix
Discrete-Time State-Space Form
Page 130
Appendix
Discrete-Time Transfer Function Form
Page 134
Appendix
Discrete-Time Dual-Feedback Transfer Function Form
Page 138
Appendix
Discrete-Time Error-Based ADRC (all forms)
Page 143
Appendix
Wanting to tailor-make: Knowing how to design and implement customized versions of ADRC, including some of its extensions and modifications and taking into account various practical aspects of the controlled systems may turn out to be very beneficial moving forward, especially when faced with nontrivial control problems and stringent control goals. Chapters 6 and 9 show a variety of ways that can aid designers with that.
The first four points happen to align exactly with the book’s subtitle “from principles to practice,” where, in this context, principles mean understanding and practice means deployment. With the last point, related to tailoring, we invite the reader to continue the journey by roaming freely and exploring ADRC beyond the rudimentary ideas and tools we have covered in the book.
Moving forward, the book can be easily revisited for consultation as a textbook, handbook, or reference, all to help different audiences achieve their desired goals.
Is This the End?
We are now in the last numbered chapter of the book, but there are still essential things coming. Appendix A repeats in a compact form all of the relevant equations required to implement and tune all the ADRC variants we have considered. Appendix B is a handy overview of various ADRC implementations in MATLAB/Simulink. It also details our proposed “Linear ADRC Blockset,” which is an add-on helping to quickly deploy ADRC in the variants covered in the book. Therefore, we hope you will frequently return to this book, either to its main covered material (Parts I and II), to consult for the sought information regarding various aspects of ADRC, or to the Appendices, to use it as a reference.
From the perspective of ADRC, it is not the end either. Quite the contrary, from the scientific development side, many interesting topics are being investigated—some of which we briefly covered in the “look beyond” part of Chap. 7. From the practical side, we now expect its larger adoption in the real world for all the reasons associated with the ADRC area reaching its technological maturity phase.
As for the future of ADRC in a broader sense, it is expected that over the next decade, the biggest generators of real-time data will be devices that sense and control the physical world. Such an amount of data requires a rapprochement of the control area. Control theory has been traditionally and firmly rooted in model-based design. However, the availability and scale of emerging data (both temporal and spatial) will require us to rethink the foundations of our discipline. With its inherent large independence from a precise description of the controlled dynamical system, a data-driven methodology like ADRC could play a meaningful role in that endeavor.
Coming back to the question: Is this the end? For the regular part of the book, yes, it is. But we hope this will also be a start: for you putting ADRC into practice.
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.
