Home > Behavior-based Theory > Framework Extension – Behavior Suppression I

Framework Extension – Behavior Suppression I

I have been thinking about adding suppression nodes to my behavior framework for some time, but mostly have been able to avoid it by creating new behaviors for special cases.  Anyway, I decided to take a crack at it.  This functionality adds a level of complexity, but also allows for some freedom to handle special cases where the straight hierarchical model does not produce the results intended.  I will be releasing an updated Framework soon.


In theory, a behavior has a node on its output that if triggered inhibits its control message from being selected for control of the robot.  The behavior’s functionality is unaffected; it output is just discarded in the arbitration process.

In the following case, behaviors A has priority over B, and neither of the behaviors are wired for suppression.  If A requests control, it gets it.  If B requests control, it can only get it is A declines control.


Any behavior may inhibit (suppress) any other behavior.  The behaviors are virtually wired together.

In the following diagram behavior A has priority over behavior B, but B is wired to inhibit A.  If A requests control, B can still control whether or not A gets that control by triggering inhibition on A.  If B requests control, it can get it if A declines control or A is suppressed (inhibited).


As with any other behavior-based functionality, inhibition is valid for the current cycle of the arbitrator.  What this means is B can inhibit A’s output for ONE cycle of the arbitrator.  At the end of arbitration, the A’s inhibition is “reset”.  In order for B to inhibit output longer, it must inhibit with each cycle to suppress B’s output.

Another option is to allow suppression to span arbitration cycles by adding a time parameter.


  • Is there a need to implement suppression for nTimeslices?  Behaviors actions are stateless by default, and would request control with each cycle to maintain control. 
  • If a behavior is inhibited, should it reset its internal state?  If not certain behaviors may be released mid-action.  As a programmer, you need to address this.
  • What is multiple behaviors want to suppress or release a behavior?  Who owns the wired connection?
  • Can a behavior reset another’s inhibit attribute?  If so, how is it determined which behavior overrides others? 
  • Do I need to implicitly release the suppression or should it be released automatically?
  • Is there a difference between suppressing a behavior and disabling it?
    • Inhibition is a temporary output block based on another behavior’s connection.
    • Disabling may be a more permanent state where a behavior does not execute until re-enabled

More to come as I hash out a viable implementation.  Let me know your thoughts.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: