The future of high precision is fuzzy
Scott Rosenthal
July, 1993
Fuzzy logic has intrigued me ever since I came across an article on it three years ago
when I was trying to use an obstinate mass-flow controller with a standard PID loop. In
the midst of my modeling, tweaking and cursing, that article in its most abbreviated form
said what I was doing wasn't necessary. However by this point, I had almost solved the
problem, and my client vetoed any change in approach. Although fuzzy logic took a back
seat to conventional techniques that time, dogged perseverance with the client allowed me
to recently try my first real-world fuzzy application and, just as pundits have preached,
it worked. Therefore I plan to devote my next couple of columns to discussing that design
process for a fuzzy control function, the implementation problems encountered and why I
feel fuzzy logic should be part of every embedded designer's bag of tricks.
The evolution
Before getting into application details, some history on how I became a believer in
fuzzy logic might help you relate the technique to your work and see it as a viable
alternative to conventional methods. My company designed a thermistor-based temperature
monitor whose 0.002°C accuracy compared to NIST standards makes it one of the most
accurate in the world. Unfortunately, these very sensitive instruments are even more
sensitive to noise pickup. The initial technique we used to remove this noise was to apply
an N-point boxcar moving average to the data. However, with that method, if one bad point
gets into the boxcar, the algorithm needs N time periods to remove its effect from the
result. To eliminate this problem we placed all types of constraints on data going into
the boxcar. For example, if the incoming point wasn't like data already within the boxcar,
the program replaced the new data point with the boxcar average. Likewise, if this
replacement occurred too many times in a row, the program dumped the boxcar data and
started filling it again.
The theory behind this technique was that if the data wasn't the same as the previously
collected values for several samples, the data must've really changed. In all, we had
three different rules-not to be confused with fuzzy rules I'll discuss later-for allowing
data into the boxcar and when the boxcar should dump its data. In the end, the boxcar
concept worked, but each time the averaging buffer dumped, the instrument generated noisy
readings until the boxcar filled again. Obviously, on a precision instrument such
occasional noisy readings are unacceptable, so we dumped the boxcar technique in favor of
an IIR (infinite impulse response) filter.
In case you're not familiar with this technique, the IIR filter keeps as part of its
history all previous input readings that it's filtered. Therefore each point, no matter
how old, theoretically has some bearing on the IIR filter's output. In hardware, a good
analogy is an RC filter. By contrast, if the boxcar is ten points long, only samples that
occurred during that brief period of time have any effect on the output.
You can easily create an IIR filter in code with the following equation:
NewIIRValue = ((100 - alpha) * OldIIRValue) + (alpha * Reading)) / 100
where the alpha term has a value between 0 and 100. Although I prefer this form, you
can also express this equation without percentages, and alpha then takes on a value
between 0 and 1:
NewIIRValue = ((1 - alpha) * OldIIRValue) + (alpha * Reading))
The IIR function is easy to understand. As alpha approaches zero, the less effect a new
reading has and the more previous readings determine the output value. Obviously, if alpha
equals 0 then the IIR uses only old readings; if alpha equals 100, it uses only new
readings. By changing a, you can easily tailor the amount of filtering. The problem we
encountered with our instrument was that if we cranked alpha down low enough to get stable
readings, the instrument's response time became too long.
To solve this problem, we implemented a 5-step alpha term. It begins when the user
first switches the instrument on and alpha starts very large. After a certain number of
readings, the instrument's firmware decreased the value of alpha and continued decreasing
it on the basis of data in a table until alpha reached a value low enough to provide the
required stability. If a step change occurred in the readings-like sticking the thermistor
into a temperature bath-the alpha term moved back to step one and starts the sequence
again. This technique allowed us to keep instrument noise down while minimizing the unit's
response time. It worked, but looking back with 20/20 hindsight, I believe there's a
better way to control the filtering.
The fuzzy alternative
As I said previously, I've had a growing interest in fuzzy logic. Everyone who's
followed that technology knows about "miracle" products from Japan such as smart
washing machines, vacuum cleaners and 35-mm cameras. However, most tutorials in this
country seem to focus on only a couple standard examples: balancing an inverted pendulum
or regulating a room's temperature. However, at least in my business, I rarely see an RFQ
for an instrument capable of balancing an inverted pendulum. I know that these
demonstrations are just examples, but for development engineers hard real-life examples
are our teachers. Hence I've looked for engineering examples of fuzzy logic and found few
in the popular engineering press. Therefore, with an inverted pendulum and room
temperature controller as my guideposts, I launched into making an IIR filter that uses
fuzzy logic to tailor its response.
As with all new technologies, there's always that looming question about where to
begin. I collected literature from fuzzy-logic software and hardware manufacturers. I
reread all the articles I'd clipped from the past few years including Ken Anderson's
column from last December (reference). The one thing that came through crystal clear was
that implementing fuzzy logic isn't difficult. The trick is knowing where to apply it.
After careful consideration, I decided to try to design my fuzzy IIR filter from
scratch. I could've started with one of the many fuzzy-logic simulation and modeling
packages on the market, but being on a tight budget and sick of learning another software
package, I elected not to go this route. In addition, I'm a firm believer in that if you
haven't done something yourself, you probably don't fully understand it. Also, how can you
decide which package to get if you've never worked with fuzzy logic? Maybe I took the
chicken's way out, but I designed my own fuzzy-logic engine. Truthfully, the design was
the easy part-the hard part was obtaining the correct information for feeding data into
it. Next time I'll describe the results of my first foray into this new technology. PE&IN
Reference
Anderson, K, "Low-cost code generator clears the way to fuzzy logic," PE&IN,
Dec 1992, pgs 59-64.
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
