Much of modern control theory is equivalent to machine learning. "Adaptive feedforward control" is a form of machine learning. So is "automatic system identification". Back in the 1990s, before machine learning had really got going, I thought that adaptive feedforward control was a path to AI. In a sense it was, but it took a lot of mathematical development in other fields to get it there.
Feedforward control is unusual. In feedback control, you look at the error and try to zero it out. Usually, there's some lag in the system, which leads to undershoot, overshoot, oscillation, and all the usual problems of feedback systems. Maxwell (yes, that Maxwell) figured all this out in 1868, and his little paper "On Governors" defined linear control theory for a century.[1]
Feedforward control, though, is about measuring disturbance inputs, predicting what's going to happen, and adjusting controllable inputs so that the error remains near zero. An example is a heating system with an input for outside temperature as well as inside temperature. When the outside gets cold, the heating plant will be cranked up in advance of the inside getting cold. This is essential if the system being controlled has a lot of lag, like a big building's heating system.
Adaptive feedforward control is automatically identifying how the inputs affect the outputs by watching everything for a while. It's thus a form of machine learning. For the heating system example, a good controller might learn that a 10 degree drop outside means a 5 degree drop inside 1 hour later. It might also learn that the heating hot water temperature rises at 30 degrees an hour when the boiler is at full power. Such info can be used to decide to crank up the boiler half an hour after the outside temperature drops, so heating water will be available just when it's needed. This is a basic form of machine learning.
One big difference from the machine learning community is that controls people demand error bounds on their control algorithms. So the machine learning techniques used tend to be the ones ameninable to error analysis. Support vector machines, yes; deep neural nets, not so much.
Kalman filtering is very interesting. You are able to combine a bunch of inputs, of varying levels of uncertainty, along with a model of the system to arrive at an optimal estimation of the state.
I find that this is interesting to compare with Pulse-Width Modulation[0], in which a system must alternate between OFF and ON at some proportion to "simulate" a non-binary signal (i.e. 60% of the time if the signal is on ON and 40% it's on OFF, then it looks like, on average, 0.6 rather than the discrete 1.0 and 0.0).
Re PWM, I coincidentally recently was reading "Magic Sine Waves"[0] by the irrepressible Don Lancaster. He's done a lot of development since that article[1]
Two examples where I use bang-bang control for inflate/deflate valves on inflatable weirs[0] and open/close solenoids on hydraulic pressure units controlling hydraulic rams attached to pelton turbine deflectors[1].
But I calculate a pulse width - how long the valve should be opened for in order to correct the error.
For a turbine deflector loop it might execute every 1s with a minimum pulse time of 50ms and a maximum pulse time of 1s.
For the weir control it might execute every 60s with a minimum pulse time of 300ms and a maximum pulse time of 20s, because the weir continues to move after the output is de-energized and the response of the water level over the weir depends on the area of the body of water behind the weir.
I set a gain that determines how long the output is energized (the pulse width) for a given magnitude error.
In my case the actuators are still discrete so the signal stays as a pulse train, it is not filtered up to be a continuous time signal.
I see some typically Wikipedian problems with over-technical description in the first paragraph: it uses the word "plant" to mean (I think) "device" or perhaps "system," and includes the somewhat baffling sentence "These controllers may be realized in terms of any element that provides hysteresis"--and "hysteresis" itself is quite poorly defined in its own article. (The best I can figure is that hysteresis refers to a system whose output lags behind changes in input, but I'm still not clear how a typical reader is supposed to get that from "Hysteresis is the time-based dependence of a system's output on present and past inputs. The dependence arises because the history affects the value of an internal state.")
Economist/applied maths grad student here: econ is full of control theory jargon ("overshooting", "hysteresis" and so on); often well applied too. And if economics is aware of this, systems sociologists in the Parsons/Luhmann tradition are probably also aware of it.
So who's the "typical reader"? Web designers? Startup founders?
> So who's the "typical reader"? Web designers? Startup founders?
You mean for Hacker News, or Wikipedia? There's actually a Wikipedia article about that (https://en.wikipedia.org/wiki/Wikipedia:Readers_first), but a good rule of thumb is that articles should be written for the layperson except where that would impact accuracy. I think Styrophone's explanations above demonstrate that this particular article could be a lot clearer without sacrificing accuracy.
Recognizing that the spirit of your comment is about the utility of Wikipedian descriptions in general (I agree!), I thought I'd build out some of these concepts in case someone similarly frustrated also happens to be curious about them.
"Plant" is a legacy term referring to the device or system acting on the state you're trying to control. Sticking with thermostats, the plant is the heating element.
A straightforward way to think of hysteresis is that the output depends on the history of the input. A simple example of hysteresis in a temperature controller would be to turn off heat if the temperature rises above threshold A, but only turn on heat if the temperature falls below threshold B.
"These controllers may be realized in terms of any element that provides hysteresis" -- This is indeed awkward phrasing, since it could be read as though the property of hysteresis is fundamental to create a bang-bang controller. In fact, using hysteresis is "just" a best practice. Strictly speaking, you could make a hot water heater that turns heat on and off based on a single hard temperature threshold as measured by a thermometer, and it would work. However, any noise in the system will make the output jittery and cause unnecessary cycles. Having a "heat off" threshold higher than the "heat on" threshold makes for smoother transitions.
That's just an excuse for poor communication. It is quite possible to speak clearly to laymen on technical subjects; any good science writer does it on a daily basis. It's true that you wouldn't want professionals to use layman-speak when talking shop, but Wikipedia is an encyclopedia, not a technical reference.
Auto racing is an example of this being the optimal strategy, not just a simple or cheap implementation. Disregarding cases where you have to feather the throttle or brakes to maintain traction, the best racing line is always (I think) where you mash the throttle on a straightaway until the absolute last possible instant, then immediately mash the brakes to slow down just enough to squeak through the turn. It takes some getting used to.
Braking is also used to control weight distribution before cornering, shifting weight to the front wheels to allow for a sharper turn. Optimization occurs when the centrifugal force's direction is counter balanced by the friction of the tires, which varies with acceleration and braking. Optimal lines depend on the shape of the turn, but max braking always occurring right before the apex and shifts to high acc after. Really though, its max brake/acc without slipping not just 1/0. Traction control/abs simplify the situation at the racer input level, allowing optimal strategy to approach 1/0 by functioning as a micro instance of the bang bang strategy. The abs/tcs is 1/0 due to optimization, not simplicity, since a variable input would not allow the wheels to return to a rolling state anymore quickly.
Great point about shifting weight to the front wheels. Real life racing theory is definitely much more complicated than my amateur understanding, especially when you're talking about high-performance cars and trained drivers.
This isn't really correct. There's four things you have to be aware of when going through a corner--throttle, brake, orientation, and traction. Oftentimes the fastest route through a corner doesn't match the bang-bang approach you describe. A good example is a series of chicanes where the bang-bang approach would actually make you slower.
To put it another way, traction factors a lot more heavily into the best route around a corner and therefore demands fewer instances of full-on/full-off throttle and braking that you describe.
Kinda. But you have an input with (presumably) finer control than is usually available with an actual bang bang. Throttle control in racing is what I'd consider a "pun" on bang bang. While it's shaped the same, the rationale doesn't quite line up with a real life bang bang.
In racing, it is "cheap" in the sense of a sort of cost function based on response time.
It's also used on some rockets and guided bombs, which is where I first heard about it. It leads to rougher trajectories but it's a more reliable control surface since you only need to handle zero or full deflection on a given fin.
26 comments
[ 2.8 ms ] story [ 33.0 ms ] threadFeedforward control is unusual. In feedback control, you look at the error and try to zero it out. Usually, there's some lag in the system, which leads to undershoot, overshoot, oscillation, and all the usual problems of feedback systems. Maxwell (yes, that Maxwell) figured all this out in 1868, and his little paper "On Governors" defined linear control theory for a century.[1]
Feedforward control, though, is about measuring disturbance inputs, predicting what's going to happen, and adjusting controllable inputs so that the error remains near zero. An example is a heating system with an input for outside temperature as well as inside temperature. When the outside gets cold, the heating plant will be cranked up in advance of the inside getting cold. This is essential if the system being controlled has a lot of lag, like a big building's heating system.
Adaptive feedforward control is automatically identifying how the inputs affect the outputs by watching everything for a while. It's thus a form of machine learning. For the heating system example, a good controller might learn that a 10 degree drop outside means a 5 degree drop inside 1 hour later. It might also learn that the heating hot water temperature rises at 30 degrees an hour when the boiler is at full power. Such info can be used to decide to crank up the boiler half an hour after the outside temperature drops, so heating water will be available just when it's needed. This is a basic form of machine learning.
One big difference from the machine learning community is that controls people demand error bounds on their control algorithms. So the machine learning techniques used tend to be the ones ameninable to error analysis. Support vector machines, yes; deep neural nets, not so much.
[1] https://commons.wikimedia.org/wiki/File%3AOn_Governors.pdf
Convolution integral, Laplace transform, Z transform, frequency domain, impulse response, step response, digital filters... it's all amazing.
[0] https://en.wikipedia.org/wiki/Pulse-width_modulation
[0] http://www.tinaja.com/glib/sinquest.pdf
[1] http://www.tinaja.com/magsn01.shtml
They're everywhere - A/D are PWM, class D amps are PWM, power supplies...
But I calculate a pulse width - how long the valve should be opened for in order to correct the error.
For a turbine deflector loop it might execute every 1s with a minimum pulse time of 50ms and a maximum pulse time of 1s.
For the weir control it might execute every 60s with a minimum pulse time of 300ms and a maximum pulse time of 20s, because the weir continues to move after the output is de-energized and the response of the water level over the weir depends on the area of the body of water behind the weir.
I set a gain that determines how long the output is energized (the pulse width) for a given magnitude error.
In my case the actuators are still discrete so the signal stays as a pulse train, it is not filtered up to be a continuous time signal.
[0]: https://www.google.ca/#tbm=isch&q=obermeyer+weir [1]: https://www.google.ca/#q=pelton+turbine+deflector&tbm=isch
Lutz.
So who's the "typical reader"? Web designers? Startup founders?
Bonus ironic jab/useful information combo: https://simple.wikipedia.org/wiki/Hysteresis
You mean for Hacker News, or Wikipedia? There's actually a Wikipedia article about that (https://en.wikipedia.org/wiki/Wikipedia:Readers_first), but a good rule of thumb is that articles should be written for the layperson except where that would impact accuracy. I think Styrophone's explanations above demonstrate that this particular article could be a lot clearer without sacrificing accuracy.
"Plant" is a legacy term referring to the device or system acting on the state you're trying to control. Sticking with thermostats, the plant is the heating element.
A straightforward way to think of hysteresis is that the output depends on the history of the input. A simple example of hysteresis in a temperature controller would be to turn off heat if the temperature rises above threshold A, but only turn on heat if the temperature falls below threshold B.
"These controllers may be realized in terms of any element that provides hysteresis" -- This is indeed awkward phrasing, since it could be read as though the property of hysteresis is fundamental to create a bang-bang controller. In fact, using hysteresis is "just" a best practice. Strictly speaking, you could make a hot water heater that turns heat on and off based on a single hard temperature threshold as measured by a thermometer, and it would work. However, any noise in the system will make the output jittery and cause unnecessary cycles. Having a "heat off" threshold higher than the "heat on" threshold makes for smoother transitions.
Specialities mangle language. It's just the way the world is.
To put it another way, traction factors a lot more heavily into the best route around a corner and therefore demands fewer instances of full-on/full-off throttle and braking that you describe.
In racing, it is "cheap" in the sense of a sort of cost function based on response time.