There are many ways to control the weighting in a fuzzy logic inference engine. It is important to think of fuzzy logic as a mathematical process that can be embedded in- to larger structures, rather than a stand-alone discipline.
This humble mathematical process can provide very impressive decision making when it is properly employed in conjunction with other techniques. In the chapters to come, we will see how merging fuzzy logic with modeling and other concepts can produce spookily powerful results.
Closed Loop Controls, Rabbits and Hounds
5
C H A P T E R
Any good athlete will tell you that the key to an exceptional performance is to ima- gine the task ahead and then to practice until the body can bring this imagined sequence into reality. Similarly, generals create “battle plans,” and business people create “business plans” against which they can measure their performance. In each case there is a master plan, and then separate plans for each component. An athlete has a script for each limb, the general for each command, and so forth. All of these plans must be kept in synchronization.
Controlling a robot or other complex intelligent machine requires that it have a plan or model of what it expects to accomplish. Like all such plans, it is quite likely to require modification within moments of the beginning of its execution, but it is still essential.
Like the commander or executive who must modify a plan to allow for changing si- tuations, a robot must also be able to modify its plan smoothly, continuously, and on the fly. If circumstances cause one part of the plan to be modified, then the plans for all other parts must be capable of adjusting to this.
For the plan to have any meaning, physical hardware will need to track to the plan to the best of its ability. Thus we trespass into the fiefdom of Controls. This subject is deep and broad, and engineers spend their entire careers mastering it. In short, it is a great subject to trample on. The fact is that it is quite possible to create decent con- trols for most applications using little more than common sense algorithms.
The purpose of a control system is to compare the plan to reality, and to issue com- mands to the servos or other output devices to make reality follow the plan. The desired position of the robot or one of its servos is often referred to as the rabbit and
the position of the actual robot or servo is referred to as the hound. This terminology comes from the dog racing business, where a mechanical rabbit is driven down the track ahead of the pack of racing canines. A closed loop system is one that measures the error between the rabbit and hound, and attempts to minimize the gap without becoming erratic.
Classical control theory has been in existence for a very long time. Engineering courses have traditionally taught mathematical techniques involving poles and zeros and very abstract mathematics that beautifully describe the conditions under which a control can be designed with optimal performance. Normally, this involves produc- ing a control system that maintains the fastest possible response to changing input functions without becoming underdamped (getting the jitters). It is perhaps fortu- nate that the professor who taught me this discipline has long ago passed from this plane of existence, else he would most probably be induced to cause me to do so were he to read what I am about to say.
Control theory, as it was taught to me, obsessed over the response of a system to a step input. Creating a control that can respond to such an input quickly and without overshooting is indeed difficult. Looking back, I am reminded of the old joke where the patient lifts his arm over his head and complains to the doctor “It hurts when I do this, Doc,” to which the doctor replies, “Then don’t do that.”
With software controls, the first rule is never to command a control to move in a way it clearly cannot track.
If you studied calculus, you know that position is the integral of velocity, velocity is the integral of acceleration, and acceleration is the integral of jerk. Calculus in- volves determining the effect of these parameters upon each other at some future time.
In real-time controls this type of prediction is not generally needed. Instead, we simply divide time into small chunks, accumulating the jerk to provide the acceleration, and accumulating the acceleration to provide the velocity, etc. This set of calcula- tions moves the rabbit, and if all of these parameters are kept within the capability of the hardware, a control can be produced that will track the rabbit.
Furthermore, the operator who controls the “rabbit” at a dog race makes sure that the hounds cannot pass the rabbit, and that it never gets too far ahead of them.
Similarly, our software rabbit should adjust its acceleration if the servo lags too far behind.
A common problem with applying standard control theory is that the required para- meters are often either unknown at design time, or are subject to change during operation. For example, the inertia of a robot as seen at the drive motor has many components. These might include the rotational inertia of the motor’s rotor, the inertia of gears and shafts, rotational inertia of its tires, the robot’s empty weight, and its payload. Worse yet, there are elements between these components such as bearings, shafts and belts that may have spring constants and friction loads.
Not withstanding the wondrous advances in CAD (computer aided design) systems, dynamically modeling such highly complex systems reliably is often impractical be- cause of the many variables and unknowns. For this reason, when most engineers are confronted with such a task, they seek to find simpler techniques.
Flashback…
As a newly minted engineer, my first design assignment was a small box that mounted above the instrument panel of a carrier borne fighter plane. The box had one needle and three indicator lights that informed the pilot to pull the nose up or push it down as the multi-million dollar aircraft hurtled toward the steel mass of the ship. As I stood with all of the composure of a deer caught in the landing lights of an onrushing fighter, I was told that it should be a good project to “cut my teeth on!”
The design specification consisted of about ten pages of Laplace transforms that de- scribed the way the control should respond to its inputs, which included angle-of-attack, air speed, vertical speed, throttle, etc. Since microprocessors did not yet exist, such com- puters were implemented using analog amplifiers, capacitors, and resistors, all configured to perform functions such as integration, differentiation, and filtering. Field effect switches were used to modify the signal processing in accordance to binary inputs such as “gear- down.”
My task was simply to produce a circuit that could generate the desired mathematical function. The problem was that the number of stages of amplifiers required to produce the huge function was so great that it would have been impossible to package the correct mathematical model into the tiny space available. Worse yet, the accumulation of toler- ances and temperature coefficients through so many stages meant the design had no chance of being reproducible. With my tail between my legs, I sought the help of some of the older engineers.
To my distress, I came to realize that I had been given the task because, as a new gradu- ate, I could still remember how to manipulate such equations. I quickly came to the realization that none of the senior engineers had used such formalities in many years.
They designed more by something I can best describe as enlightened instinct. As such, they had somehow reprogrammed parts of their brains to envision the control process in a way that they could not describe on paper!
Having failed miserably to find a way out, I took a breadboarding system to the simula- tor room where I could excite my design with the inputs from a huge analog simulator of the aircraft. I threw out all the stages that appeared to be relatively less significant, and eventually discovered a configuration with a mere three operational amplifiers that could produce output traces nearly identical to those desired. It passed initial testing, but my relief was short lived. My next assignment was to produce a mathematical report for the Navy showing how the configuration accomplished the desired function!
At this point I reverted to the techniques I had honed in engineering school during labo- ratory exercises. I fudged. I manipulated the equations of the specification and those of the desired results to attempt to show that the difference (caused by my removal of 80%
of the circuitry) was mathematically insignificant. In this I completely failed, so when I had the two ends stretched as close to each other as possible, I added the phrase “and thus we see that” for the missing step.
A few months later my report was returned as “rejected.” Knowing I had been exposed, I began planning for a new carrier in telemarketing. I opened the document with great apprehension. I found that the objections had to do with insufficient margins and im- proper paragraph structures. I was, however, commended for my clear and excellent mathematical explanation!