Re: Ways to implement (optimize) an FLC with an 8bit controller

David - Brubaker (brubaker@cup.portal.com)
Sun, 14 Jan 1996 08:17:31 +0100


In the spirit of Earl Cox's plea on another thread that we get more
meaningful discussions going in this group, here is a copy of what
I emailed to Chuck Bass on the topic of designing a FLC using table
look-up.

Regards,

David Brubaker

*******************************************************************
David I. Brubaker, Ph.D.

Huntington Advanced Technology
883 Santa Cruz Avenue - Suite 31, Menlo Park, CA 94025-4608
Voice: 415-325-755 Fax: 415-325-9085 Email: brubaker@cup.portal.com

A technical consulting firm specializing in the design and development
of complex systems.
*******************************************************************

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Chuck Bass
acrocad@ix.netcom.com

Chuck,

In response to your thoughts on implementing an FLC using table
look-up on an 8-bit controller.

First, "is this a reasonable way to go?" It is, and your key here is in
what you mentioned to be "a BIG array". If the array is sufficiently
large to represent your entire input space (with 8-bit inputs and
output this would be 65 Kbytes, for 10-bit inputs and output (and
using 16-bits to handle each 10-bit output), this would be 2 Mbytes,
and for 12-bit inputs and output, this would be 32 Mbytes -- a BIG array!),
and if you fill the array using a fuzzy simulation of your desired
controller to achieve the interpolation between crisp levels that
fuzziness adds to a rulebase, then you have completely represented
the fuzzy rulebase in a single array. Of course, you could use any
algorithm to fill that array -- it doesn't have to be fuzzy.

This approach would not be considered cost effective by most. When
various Japanese companies making consumer products originally
ran into the speed versus memory size problem in fuzzy systems, a
number came up with a hierarchical table approach, where one table
handles coarse control far from the set point, with the table "falling
through" at its center to a level of finer control, with the second table
falling through to a level of still finer control, and so forth, until finest control is achieved at and immediately around the setpoint. Table
management also allows for moving from finer to coarser resolution;
dropping off the edge of a lower table constitutes a "jump up" to a
high table. At the lowest level (which might only be the second table),
the input space immediately around the setpoint is totally (bit-by-bit)
represented. On higher tables in the hierarchy, 2x2-bit, 4x4-bit, and
larger chunks of the input space are represented.

This is a technique that has been around for a long time. A lab partner
and I used it in a senior project in 1970, and if we had bothered to look,
I am sure someone had written it up before.

Those companies that used it and then stamped "Fuzzy" on their
product took some heat because those who had used table lookup
before (your truly included, until I understood how they were
loading their tables) claimed that it was not fuzzy. The key was that
each look- up table was populated by a fuzzy simulation, complete
with inter-level interpolation, so in fact these were actual fuzzy systems;
putting the resolution where it was needed, around the set point,
and letting the far reaches of the input space be more or less a
"bang-bang" controller. In 1991 I used this technique for a client
to show them how a fuzzy rulebased controller could be quite
effectively implemented on a small microcontroller. Again, you
could use any algorithm to fill the tables, not just fuzzy.

I hope this helps. If you have any more questions, feel free to repost,
or to email me direct.

David Brubaker