Recently, one of my far-flung friends sent me a magazine article, along with his puzzled comment: "Can Fuzzy Logic REALLY do THIS—and nobody else can do it?" I read the story. It explained that in Europe, there was a requirement for a speed limiter for heavy trucks, at 53.4 mph (86 km/hr). The article claimed that such a speed limiter couldn't be done by any conventional controller.
This was partly because it was very hard to design a model for a truck. There were so many different kinds and versions and manufacturers of trucks. Plus, there were heavy trucks and lightly loaded modes of operation. The truck model would have to work on upgrades and downgrades. Also, the task was claimed to be very nonlinear. So, the author proposed using Fuzzy Logic (FL) to accomplish this. Because his controller would be very versatile and very robust, it wouldn't need to be programmed differently for different types of trucks.
Now, if this article said there were something that I couldn't do with op amps, resistors, and capacitors, then that would present kind of a serious challenge, eh? I always like challenges.
I thought about this. A truck tends to accelerate over a wide range of speeds. It picks up speed, faster or slower, according to its load, proportional to its accelerator-pedal setting, and based on how the engine's torque is geared to the load and influenced by the grade of the road. That sounds like an integrator—an integrator with a larger or smaller feedback capacitor (to represent how the mass of the truck changes), with a positive bias (in case it's "on a downgrade"), or with a negative bias (in case it's "on an upgrade").
A truck's model sounds pretty easy to me—an integrator with some biases, varying gains, and a little lag in the control path. I could then use the model to drive an analog controller like the one shown in Figure 1. Now, I concede that it would be hard to model a truck for every situation, at all speeds. But in this case, a model that's fairly realistic at around 45 to 55 mph is easy to design. See Figure 2—an integrator with a controller input (with a little lag). What's so difficult about that?
So I sat down with a big sheet of paper, added a few control elements to a simple PID loop, proposed some nominal component values, and drew up a couple of wires to connect this to the model of the truck (Fig. 1, again). This is very much like the controller for my "Ball-On-Beam Balancer" (Electronic Design analog supplement, Nov. 20, 1995, p. 50).
Next, I started to draw up some waveforms to show how it would work. In my book,1 I call this a "choreography" to illustrate how each waveform relates to one another. I convinced myself that this loop could be stable and wouldn't oscillate. This is largely related to the way that a control loop can be fairly SIMPLE, NIMBLE, and quick to increase or decrease gas-pedal settings. The truck can accelerate at about 0.01 to 0.05 G's if it's heavily loaded, or perhaps at five or 10 times that rate if it's empty. ANY driver can easily pull his foot off the gas pedal when he wants to avoid exceeding a speed limit—if he wants to, and if he remembers to. Even an FL controller can do that. Even a PID controller can do that. Controlling the speed of a vehicle isn't too difficult. Anybody can do it.
That's because a truck trying to accelerate with a nominal amount of power, driving a wide-range load, is only an integrator, just like an op amp. Everybody likes op amps because it's easy to close a loop around them—whether at high gain, or at low gain—because the phase-shift of an integrator is 90°. Therefore, the loop will be stable. But then I saw the flaw in my first-draft controller circuit: The PID controller has probably been trying to accelerate at full power for a long time, because the vehicle's speed is below the limit. The integrator has, thus, been fed a large dc error signal for a long time—and its output would be near the negative limit! That could easily cause overshoot, and the loop couldn't help it. Overshoot would occur, even though stable operation would eventually take over.
How can I avoid this overshoot? After all, in a speed limiter, overshoot is a really bad kind of performance. The requirement for this limiter is pretty strict, allowing only a small amount of overshoot (about 3 mph max).
Then I remembered some notes by Dave St. Clair2 about "wind-up." Any PID controller can have its integrator term go off to a limit when you don't want it to, such as when the loop isn't in control for a long time. That's called wind-up. How do we avoid this? After all, any PID controller tends to exhibit this wind-up, if it's tasked to pull a large inertial MASS up to a new level. This is NOT a new or unique task. Actually, some PID controllers do very well at this!
I recalled that the remedy is termed "anti-wind-up." I tried looking this up in several books. I found it really hard to find any further mention of wind-up, or of how to perform anti-wind-up. Still, I figured out that it isn't rocket science! This is a special case of analog computation—with a bit of hybrid/digital control.
Reprints
)
