# Fuzzy Inference module for behaviour-based control

In previous blog I talked about the subsumption architecture of Hurby toy, now it is time to talk about the fuzzy inference module which controls its happiness state.

Hurby's happiness depends on two main variables.

• Elapsed time since last play (in hours).
• Playing time trend (mean measured playing time), in minutes.

According with these inputs, Hurby will get happier if elapsed time since last play is reduced and playing time trend is incremented. On the other hand, it will get unhappier if that elapsed time increases and/or playing time trend decreases.

As both inputs are relative and vague concepts, it is a good situation to think about the use of a fuzzy inference reasoning module. Within this fuzzy module I can control Hurby's behaviour according with vague input specifications, for example: "If last playing time was a long time ago and playing time is decreasing then Hurby will be very unhappy".

These kind of rules are very easy to understand by humans, and what fuzzy systems permits is to program this kind of reasoning.

Furthermore, I am an enthusiast of KISS principle. If you don't know what means KISS, you can googled it. But basically is an acronym for Keep It Simple, Stupid. And it states that most systems works best if they are simple rather than complicated.

In this case, applying KISS principle to the design of the Fuzzy Inference System, I've got these key points:

• Inpust only will can be catalogued into 3 fuzzy sets (LOW, MIN, HIGH) or similar and these sets are triangles.
• Output will be the percentage of happiness. 0% means completely unhappy and 100% means extremely happy.
• Defuzzification method for the percentage of happiness is done according with the "center of mass". And hence, output fuzzy sets are singleton points in stead of triangles.

All of these premises, give me this situation:

• Elapsed time since last play will be expressed in hours and is fuzzified according with this figure:

• Playing time trend will be expressed in minutes and fuzzified as shown below:

• Percent of happiness (output of the fuzzy inference module) is defuzzified to get a crisp happiness % as shown below:

As inputs are catalogued into 3 fuzzy sets, and there are only 2 inputs, this raises the number of fuzzy rules to 9 (3*3).  So graphically, the knowledge base of this fuzzy module will be this (see below). Now I have to fill it:

Filling this knowledge base implies that I have to decide how Hurby will react depending on the inputs. In the case of the first cell which corresponds to rule: "If time since last play is short AND playing time trend is also short, then Hurby will keep NEUTRAL. And filling the rest of rules the result is this:

As you could se above, during the explanation of the first rule, there is a logical operator (AND). Also, can be other operator (OR). In these cases, and based on fuzzy logic algebra, I will translate AND operation into MINimum values, while OR operations will be MAXimum values. I will explain with an example:

Suppose that in a certain moment inputs are: TSLP=12hours and PTT=3min, in that case the fuzzification of both inputs will activate 3 rules (MED-SHORT, MED-MED, MED-LARGE):

As shown, those 3 activated rules have the minimum value of each input membership (due to the AND operator). In this case all of them has a value of 0.5.

Looking at the knowledge base, the first and second activated rules have the same effect, that is, Hurby will be NEUTRAL. This can be translated into a single rule with OR operator:

If (TSLP is medium AND PTT is short) OR (TSLP is medium AND PTT is medium) then happiness will be neutral.

And as told before, OR operator is translated into MAX value, in this case MAX(0.5, 0.5) = 0.5. In conclussion the fuzzy inference has a result of 2 rules:

• Hurby will be NEUTRAL with a membership of 0.5 (1st and 2nd rules)
• Hurby will be HAPPY with a membership of 0.5 (3rd rule)

Applying the Center Of Mass equation as defuzzification method, we have that Hurby's happiness will be 75%.

Attached to the blog, you can find a C++ class named FuzzyIO8 (both files cpp an h in a zip compressed one). This is the fuzzy inference module explained. I've given that name because I format both inputs and output as <uint8_t> data types. This simplifies fuzzy calculations and improves its execution time in real time applications like this one. Even, simplifying this module as I've done, it only requires a dozes of RAM bytes, which is very important in resource-constrained MCUs, where RAM is very appreciated for other purposes.

In next blog entries I will talk about how Hurby will move its eyes, ears, feet and mouth depending on its happiness state and which is the function of the module I've named as Motor Cortex.

See you!

AttachmentSize
FuzzyIO8.zip4.95 KB

## Comment viewing options

This is a very interesting approach to the problem.  My approach would have been very very different and probably not half as cool!

This approach could easily be modified into a generic business rule engine so definitely has use outside of modifying the behavior of your Furby. I can think of several projects in my role as a PC developer where this approach would have been more elegant than what I did!  Thank you for sharing.  This is really good stuff.

Regards,

Bill

Thanks. Yes you can modify the code according with your needs, and use it in any other kind of applications.
Yes, i hope i can finish it before summer holidays, before august.... Else they must wait a bit more... ;)

You could try a little MIBE architecture for the emotional and behavioral functions.  I ran across MIBE on wikipedia as a further development of subsumption arch.  It

I'm using it on SuperDroidBot for its emotions and its motivations.  Emotions control how the robot feels, motivations determine what it decides to do.

My implementation (which may not be pure MIBE, as I built mine before reading about MIBE and seeing parallels) goes like this...Basically, there is a set of emotions (10) all running concurrently, and a set of motivations running concurrently.  Each emotion/motivation has a range from 0 to 100%, a goal value that the given item naturally gravitates towards, and a speed (positive or negative) that the item gravitates towards the goal at (very slow, slow, medium, fast, etc)  At any point in time, a single emotion and a single motivation is dominant...has the highest value.

Events happening to the bot can raise or lower one or more emotions/motivations.  In your bot, tickling can boost happiness by 20%.  Happiness could naturally diminish 1% per second.  On my bot, talking to a person reduces boredom by 20%, increases happiness 25%, increases motivation to talk, increases motivation to look at large heat sources in front of the bot, and reduces motivation to move around.  The programming ends up being nicely separated as the emotions know nothing about the events.  The events simply ask for an increase/decrease/min/max when they occur.

Basically, the bot iterates through each emotion/motivation several times a second and moves its current value towards its goal value (up or down) by the speed for that item.  The dominant emotion is reflected by the face, the dominant motivation is given a chance to execute.  It is important to have a given motivation decrease dramatically once it executes so it doesn't execute too often.

Pretty easy to implement a maslow's hierarchy of needs in this.

There are probably a million ways to do behavioral stuff.  Looking forward to seeing where you go with yours.

Regards,

Martin

Hi Martin, thank you very much for the suggestion. I've been reading about your SuperDroidBot and it is an awesome work. Congratulations!!!!

I read time ago something about MIBE (perhaps on wikipedia too), but now your comment has refreshed my mind again, and I'm going to study once more (deeper), maybe I could do something along that way.

In a couple of clicks I've found a pair of readings I will read this afternoon, they seem interesting and I suppose both will give me links to other ones.

They are these:

Thank you very much for your comment!!!!

First of all, thanks for stimulating the discussion on this topic, and thanks very much for the feedback on my bot.  Lastly, a HUGE thanks for the two links to the papers.  That first paper is very much how I approached the issue, I want to re-read it several times to flush out where I can improve.  Really good paper in my opinion.  I'm sure there is gold to be found in those words.

The second one is interesting too.  I haven't read it all yet, but some of the ideas raised like attachment theory are intriguing.  I left out "moods" on mine for simplicity but intend to add it in later...as another set of agents like emotions but slower acting and less intense.  I definitely see a need for "traits" now as discussed in the second paper.  My AI is set up to be used by multiple robots concurrently, so "traits" would be key to differentiate the behavior/capabilities of each robot.  Traits are probably just another term for "Robot Settings".

This is really key stuff that I wish more hobbyists were studying.  Once you get a platform that can move around, not bump into things, and interact with humans in some way, behavioral "affective" programming becomes center stage.  That is where I took the ramp towards verbal interaction, which is another huge discussion entirely.

Happy coding,

Martin

Hi Martin, you've opened my eyes... ;)

I've refocused what I'd done, now I'm completely sure I have to go on with motives for this robot. I'm planning a new architecture, a talk about in this blog.

Thanks again.

Thanks to both Martin and Lord Bot. I will be reading those papers shortly.

And Lord Bot isn't the only person inspired by your work, Martin. I am also.

I was planning to use a fairly haphazard framework that I had developed for basic subsumption and then modified to be more MIBE-like, even though I didn't know what it was called. Things have moved on while I was away from this hobby.

I'll be starting to create a new framework, probably in Java. That is, when I'm not working on Groucho's chassis. I have to test some motors shortly and then then modify a metal wheelchair framework when at the moment all I have is a hacksaw and a dremel tool so I can fit my new battery in. I'm putting my other bots away for now to give me more time.

Just to give you an idea of where I'm heading, all my code and the plans for Groucho will be Open Source. I will also see if I can make the leaning and emotional framework part of ROS if I can. To be honest, I won't turn down help at this time, and I'm sure a Ill be talking to both of you later for information, at least.