Home > Behavior-based Theory > Brooks’ Subsumption to the behavior-based framework

Brooks’ Subsumption to the behavior-based framework

Last week I posted an article that attempted to (in short order) explain my behavior-based implementation for the Lego Mindstorms robotics products. I published a set of RobotC code that can be used as a foundation for programming autonomous robots (NXT or RCX). My plan is to post articles, ideas, discussion, robot designs, etc… in order to create a collaborative pool of information on this topic.

A comment was started about implementing Suppression and Inhibitor nodes into my framework. I love feedback. I went back to my notes and previous research on subsumption architecture.

Back in the early 80’s Rodney Brooks developed a radically different approach to robot programming robots called subsumption architecture.  The concept was (I hope I am not butchering this) based on the study of animals and insects and how they function in their environment.  As it turns out, that behavior can be modeled by decomposing larger tasks into discrete behaviors.  Each behavior has a goal in mind, but does not have global knowledge of the big picture.  By building new behavior logic (learning) on top of basic behaviors at the lowest levels, more complex behaviors override these “primal” ones at times to approximate intelligence.  In Brooks’ model, behaviors were hierarchical in nature, and wired to each other to form a complex network of “thought” based in instantaneous reaction, not planning or mapping.

Want to be inspired!

Read this: http://en.wikipedia.org/wiki/Subsumption_architecture

Watch this: http://video.google.com/videoplay?docid=-5563890805802735704

and this: http://video.google.com/videoplay?docid=-3001796420465120286&hl=en

Brooks created a structure, or language for developing behaviors. They may have many inputs (triggers) and many outputs (control requests).  They can also be grouped into functional macro-behavior structures to create more complex behaviors by interfacing with other behaviors.

subBeh1

Behaviors interface with each other by means of conceptual “wires – signal connections between items” and “nodes – mini-arbitrators”.  Each behavior monitors the wires and obeys suppression (S) and inhibition (I) nodes while creating its output.  A simple task to cover the area of a room may be modeled like this.

sub1

Suppression Nodes (If B then B else A) act as mini-arbitrators to allow one behavior to subsume another.  The output of this collective depends on behavior B’s wish to control the robot.

supNode

Inhibition Nodes (IF B then No Output, else A) act as shutoff valves. If behavior B is active, behavior A’s output is inhibited and the result is no control commands from either behavior at the output

InhNode

Simplification

Behavior-based programming (w/fixed-arbitration) can be considered a sub-set of subsumption.  Subsumption is super powerful, but there is a price to pay for that flexibility.  In my experience working with autonomous Lego robots, even the simple way can be challenge your patience.

The world is greatly simplified in my framework by eliminating behavior nodes and implementing ONE MASTER ARBITRATOR that chooses a winner to control the drive motors based on behavior hierarchy.

Suppression is implemented on a larger scale.  A arbitrator examines all active behaviors to determine a winner.  Behaviors are not linked to each other, but to the arbitrator.  This eliminates mini-arbitrators in favor of a global winner.  Simplistic? Yes, but also effective in most cases.

behDiagram3

The complexity of implementing behavior level wiring and suppression nodes is eliminated.

Inhibition nodes are also missing from my implementation.  Inhibition on the Lego scale can be built into the behaviors themselves based on external (or internal) inputs such as:

  • Not triggering if a sensor or combination of sensors is not in the correct range
  • Checking internal flags like timing and not triggering if it is not time.
  • Randomness
  • Checking to see who the last winner was and acting accordingly
  • Creating a set of rules to trigger the behavior

Individual behaviors may become more complex due adding more logic, but again, the framework is less complicated, easier to use in most cases, and much easier to debug.  In most cases, the simple framework can still accomplish complicated tasks.

My behavior-based framework provides for a behavior to be enabled or not.  The arbitrator checks this functionality as skips enabled=false behaviors.  This mechanism could be used (if careful) as an inhibitor, but caution must be taken.  There are many pitfalls to this implementation.

  • Which behaviors have permission (wired) to control other behaviors?  Can they be wired somehow?
  • The order of behavior code execution may determine if a behavior is enabled or not.  What about contention?
  • How is a behavior reset to enabled=true?  Brooks implemented suppression and inhibition nodes using a timing parameter..  (Ex. Inhibit behavior Z for 20ms)

Let me know what you guys think…

Advertisements
  1. June 23, 2009 at 3:35 pm

    Inhibition is a need to have for the model robot I want to build. I need a way to turn off the object avoidance when a red can has been detected by the camera, because the same sensor is also used for determining how far the bot still needs to go before it can close its claw on the can. However, once the can has been grabbed and lifted, I want object avoidance to resume as normal but switch off the can detection behaviours.

  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: