SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

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.



About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.