- Shopping Bag ( 0 items )
Many embedded engineers and programmers who need to implement basic process or motion control as part of a product design do not have formal training or experience in control system theory. Although some projects require advanced and very sophisticated control systems expertise, the majority of embedded control problems can be solved without resorting to heavy math and complicated control theory. However, existing texts on the subject are highly mathematical and theoretical and do not offer practical examples for...
Many embedded engineers and programmers who need to implement basic process or motion control as part of a product design do not have formal training or experience in control system theory. Although some projects require advanced and very sophisticated control systems expertise, the majority of embedded control problems can be solved without resorting to heavy math and complicated control theory. However, existing texts on the subject are highly mathematical and theoretical and do not offer practical examples for embedded designers. This book is different;it presents mathematical background with sufficient rigor for an engineering text, but it concentrates on providing practical application examples that can be used to design working systems, without needing to fully understand the math and high-level theory operating behind the scenes. The author, an engineer with many years of experience in the application of control system theory to embedded designs, offers a concise presentation of the basics of control theory as it pertains to an embedded environment.
• Practical, down-to-earth guide teaches engineers to apply practical control theorems without needing to employ rigorous math
• Covers the latest concepts in control systems with embedded digital controllers
• The accompanying companion website contains source code and real-world application examples to help users create fully working systems
1.1 Control Systems
Control systems are all around us. Any system that does our will with a minimum amount of effort on our part is a control system. Room lighting is a control system—you flip the switch, and the lights go on or off. The steering of a car is a control system—you turn the steering wheel, and the car turns. Home thermostats, traffic lights, microwave oven timers—all of these are control systems.
Automatic control systems are control systems that do some of the thinking for us. If we can set a system to perform some task at a high level of abstraction and have it be responsible for correctly performing the detailed sub-tasks to reach that goal, then that system is an automatic control system. Automatic control systems range from the highly intelligent and complex to the absurdly simple. Everyday examples of automatic control systems include flush toilets, room thermostats, washing machines and the electric power grid. Each one of these systems automatically performs its task without direct operator intervention: the flush toilet runs a measured amount of water into the bowl, then fills its tank to the correct level and stops, a room thermostat turns heat or cooling on and off to keep the room temperature constant, a washing machine performs a specific sequence of filling, agitating, spinning and draining, and the power grid delivers power at a constant voltage and frequency in spite of varying loads.
Closed loop control systems will receive most of our attention in this book. A closed loop control system is one that measures its own output to determine what drive to apply to itself. Closed loop control has some powerful advantages, but it also presents some profound difficulties to the control system designer. With careful design, the advantages can be made to outweigh the difficulties, which is why closed loop control is a popular method of solving engineering problems.
1.2 Anatomy of a Control System
A control system is composed of a number of parts. Throughout the rest of this book I will use a consistent terminology for these parts of control systems that follows the normal terms used by control engineers in English-speaking countries.
Figure 1.1 shows the parts of a closed-loop embedded control system. The software generates commands that are translated into an analog signal by the digital-to-analog converter (DAC). This low-power signal is amplified and applied to the plant. The plant contains an actuator to convert the electrical drive from the amplifier into some useful action in the plant. The plant output is connected to a sensor whose output is applied to an analog-to-digital converter (ADC). The ADC value is read by the control software, which uses this information and the command signal to determine the next drive command to the DAC.
In control-system language, the "plant" is the thing that is being controlled. This name probably originated from the term "steam plant" or "manufacturing plant" as one of the earliest uses of formal control theory was in the regulation of steam plants driving factories. Later on, formal control theory was applied to a variety of other fields, but the term "plant" has stuck.
There is no hard and fast rule for saying exactly which part of your system is the "plant." Depending on the point that you are trying to get across, the word "plant" could be so inclusive to encompass everything in the system except for the core piece of software that implements the controller.
At the very least, however, your control system will contain some item whose behavior you wish to control. This could be as ephemeral as the level of data in a buffer, or as concrete as a thousand-ton passenger train hurtling along at a hundred miles per hour. No matter what it is, this item is, in the end, your "plant." Any more inclusive definition of your plant should include this real plant, and you should not lose sight of what it was that you were trying to get your plant to do in the first place.
It is a good idea, then, when you are describing a control system to state clearly what you mean when you say "plant." Similarly, when you are analyzing a control system, it is a good idea to be flexible about what the term "plant" can mean, and when you are reading a description of a control system you should understand what the writer means when he says "plant."
Simply enough, a controller is the thing that controls the plant. As with the term "plant," this term can vary in its exclusiveness from the actual core piece of software that implements the controller to everything but the physical hardware that's being affected. As with the plant, it is necessary to be clear in one's definitions, and careful in one's reading of the term.
Through the history of control systems, controllers have been implemented in a number of technologies. The earliest controllers were purely mechanical devices. Even before people thought to apply mathematics to the study of automatic control systems, simple mechanical regulators were being built. In industrial settings, pneumatic controllers were popular for quite a while, because the pneumatic signal from the controller could easily drive a pneumatic actuator. With time, analog electronics came to be used as controllers. Today most new controller designs—even those that masquerade as analog—are digital controllers whose implementation is not much different from Figure 1.1.
In spite of the prevalence of the digital controller, one should not discount other forms. Some systems can benefit immensely from having a mechanical or purely electronic controller to act as a backup to a digital one, or to provide a tight inner loop around which a control loop with a digital controller is placed. It is good to be aware of the places where feedback control already exists, and to know when this can be exploited, or when it must be worked around.
At its most exclusive, a controller is just an algorithm running on a microprocessor, reading numbers from a few input ports and writing other numbers to some output ports. At this level a controller does nothing, and can do nothing, to affect the outside world. To perform this task a control system needs an actuator.
An actuator is a transducer that takes a command from the controller and converts it to a useful form of energy to drive the plant. In Figure 1.1 the DAC is what the controller sees as its "actuator." More usually, one thinks of actuators as being some form of motor or other device that takes an already-amplified electrical signal and turns it into useful work.
Actuators can take many forms. Some of the most imaginative and creative work that is done in real-world control system design is often found in actuator selection Also, alas, some of the most mundane and boring is found here as well. Actuators can range from the simple, such as a resistive element in a heating system, to the sublime, such as a Pockels cell in a laser system, which requires several hundred volts to change the polarization of incoming light so that a laser's intensity (or some other characteristic) can be affected.
The complement to an actuator is a sensor. Without an actuator, a controller is crippled. Without a sensor it is blind.
A sensor is the transducer that measures some output of the plant and converts it into a form that can be read, directly or indirectly, by the controller. Sensors will usually be analog, where some physical quantity will be translated into a voltage to be read by a DAC. Sometimes, however, a sensor may be able to more or less directly convert a physical quantity into a digital signal; for example, a shaft encoder or a can-counter on a production line.
1.3 Closed Loop Control
Closed loop control systems are a mixed blessing, particularly for the engineer who has to design or maintain one. Closed-loop control has many advantages, but for every advantage there is a drawback, and threaded through any control system problem are the limitations imposed by the basic physics of the plant, sensors, actuators and controller.
If you can accurately measure a plant's output with a sensor, and if you can reliably induce changes in the plant's output to any degree necessary, then you can build a controller that will position the plant with a degree of accuracy that approaches that of the sensor—even if the plant, by itself, cannot be positioned reliably at all.
With your accurate sensor and well-behaving plant, your controller can respond to plant errors that arise from external disturbances that perturb your plant's output. Even if the plant is so sensitive to disturbances that it is useless without closed-loop control, if it is responsive to control you can build a system that, as a whole, can operate correctly even with continuous disturbances.
If your plant can respond strongly to drive, but is, by itself, sluggish, a good feedback control system will speed up the plant's response. This fast plant response can be used to follow a command signal better, or simply to reject outside disturbances better.
In addition to being able to make an accurate plant out of an inaccurate one, given a good sensor you can turn this around: with a plant that responds predictably both to drive and to external stimuli, but with a sensor of limited range, you can build a wide-ranging, accurate sensor for physical phenomena. Specifically, force-balancing accelerometers and rate integrating gyros perform this task by keeping a proof weight (or spinning wheel) centered within the frame of the device with an accurate force (or torque) driven by closed-loop control.
Every silver lining has a cloud, however, and for all its advantages closed-loop control systems have some disadvantages and some limitations.
The most dramatic disadvantage to closed loop control is instability. You want to have a system that goes where it is supposed to and then stays put. With closed-loop control, however, you can take a perfectly stable plant and a perfectly stable controller and put them together into a shaking, snarling beast of a closed-loop system that will loop its own errors back on itself and oscillate around its desired setpoint in ways severe enough to harm actuators, mechanisms, or even the surrounding scenery.
If you take care with your control system design you can avoid instability—but such care takes development time and money. In addition, when you add a controller to a system you add direct recurring costs to purchase the controller's parts, assemble them, and make sure that their design stays current.
A final 'problem' in this list is that control systems are not magic. Real systems have real limitations, and nothing—not even an automatic control system—can overcome the laws of physics. Limitations in the strength of your actuators, in the response speed of every part of the system, in your plant's tendency to allow itself to be driven nicely, and in your sensor's ability to deliver noise-free measurements will all limit the ultimate performance of your system.
For all these problems and limitations, closed-loop control systems are an everyday part of life. Why? Because for many situations the advantages of closed-loop control systems far outweigh their disadvantages. Where a closed loop system may go unstable an uncontrolled plant may not work at all. Where a closed-loop control system is sensitive to sensor problems, its open-loop counterpart would be buried under plant variations. The biggest reason to use a closed-loop control system is because even with the expense and complexity of a controller, you can often do the overall job with much less expense, and much higher quality, by using closed-loop control.
Executive controllers are the kind of controllers that most of us are familiar with designing. In fact, the usual meaning of the 'controller' in 'microcontroller' is an executive controller.
An executive controller functions much as an executive in a company. An executive controller is concerned with making the right thing happen at the right time, and is content with issuing certain orders at certain times. If an executive controller does get feedback on the things that it is controlling, it is feedback that is at an abstract level; "motor two is broken" or "process four is complete." An executive controller issues commands at a similarly abstract level; the deepest it may go is to command something to go to a certain value, while expecting that its command will be followed.
Excerpted from Applied Control Theory for Embedded Systems by Tim Wescott Copyright © 2006 by Elsevier Inc.. Excerpted by permission of Newnes. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.