Behavior-based Framework Code–Download

I am in the process of updating the framework to 3.0, but in the mean-time, here is the latest production version.

RobotC Behavior-Based Framework for Autonomous Robots 2.2

Other links on the site have not been corrected yet.  Sorry for the inconvenience.

Some of the features for 3.0 include:

• Robot behaviors collection in one place with a core set of methods to operation on them.
  • Adding behaviors is easier now.  Just update the Behaviors list and it will be automatically initialized in the collection.
• The arbitrator is now a class which means you can deploy more than one.  This might be useful for a robot that moves and has an arm that needs arbitration.
  • Behaviors can be assigned to an arbitrator (or not) from the robot’s behavior pool.
  • The drive module was extracted from the original arbitrator so arbitrators can be used for anything. – The 2 drive parameters were made generic in the behavior class to support this as well.

— More to come.

Behavior-Based Programming vs. Precision Moves

Here is an interesting dilemma.  In the behavior-based world, we strive to make our robots responsive to the real world.  They act and react to changing stimulus, solve complex problems, and sometimes surprise us in their ability to succeed.  Here are a couple of tasks I have not been able to accomplish very easily.

• Move forward two feet
• Turn 90 degrees

What if you wanted to build a robot that could drive in a square pattern by driving forward two feet, turning 90 degrees and repeating…  Can a behavior be created to do this?

Here is the problem.

Normally, a program has complete control over the motors throughout a maneuver.  With behavior-based systems, each behavior is may or may not have control of the robot for any given timeslice.  Each cycle of the arbitrator is a new look on the world.  As factors change, so too does the robots control.

Anyone out there have any ideas for implementing a way to turn x-degrees or measuring n-ticks of distance accurately?  While we are here; Anyone have any fancy math for calculating a 90-degree turn when not spinning (motors at different speeds)?

I have a couple of ideas I am going to try, so let me know your thoughts.

Behavior-Based Robot Framework 3.0

I released a new version of my behavior-based robot framework today.  It includes inhibit and enable functionality.  Let me know what you think.

Download it here: Behavior-Based Robot Framework 3.0

I included a sample robot that extends the basic CRUISE robot by adding a new behavior SPIN that periodically inhibits CRUISE and takes control. 

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.

Basics

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.

Puckbot – Collector Robot Post-Mortem

Building and programming the Puckbot was a fascinating project.  I have attempted to build similar robots a few times over the past couple of years,  but I never really devoted the time toward creating a stable, reliable behavior-based framework first.  Earlier frameworks utilized different techniques that were weak in execution, difficult to debug, and unpredictable.  With my latest venture using RobotC, I spent some real time working on the framework.  The framework was the least of my worries on this robot.  It functioned as designed and is easy to add behaviors to, easy (easier) to debug, and certainly robust enough to create viable autonomous robots.

Implementing the collector robot with Lego Mindstorms NXT and my RobotC behavior-based framework was completely rewarding.  I still have to laugh a little when I watching the robot move around the arena, collecting pucks and delivering the successfully to the light.  Of course, I thought out the sensors and behaviors, of course there is a ton of information and study on the collector in my books, but to see it actually do the job for real was special.  I have to admit, I was a little unsure if I could pull it off.  There are a lot of behaviors working in concert, all with their own set of parameters to fiddle with, and so many things that could have gone wrong; They had in the past…

Wow!  Watching the robot in figure out what to do, and doing it by its self, is what it is all about. 

Puckbot I – Collector Robot Success!

The collector is a more complex robot building on concepts learns from AreaBot.  The robot covers are much area of a closed arena as possible collecting Mindstorms NXT foam pucks, and delivering them to a central home base (light source).  The following represents the sensors, drivers, and behavior hierarchy to accomplish the task.

See all of the collector robot articles here.
Download the Code: Download: bbPuckBot.zip
See the video here.

Escape Sequence – A generic approach to getting away

The escape behavior is one of the more important behaviors implemented in my robots.  Any time the robot bumps into a wall, there is an opportunity to escape.  In response to a trigger (collision), the robot backs up, spins away, and nudges forward to execute the “escape sequence”.  I have detailed this sequence in articles about creating the AreaBot robot.

The reason I am blogging about it again, is that I believe the escape sequence is a generic action.

Download Sample Code: EscapeSequence.zip

What do I mean?

AreaRover III – Video

Sorry this video took so long to post.  Some time in the past two weeks, my microphone/Windows 7 combination started acting up.  The voice was recorded choppy and awful.  I sounds like two drivers are competing for control of the microphone processing, but I can’t tell for sure.  I guess those are the breaks with release candidate software…

Any way, here is the missing video.

Collecting my behavior-based RobotC code in one place

 Currently, All code attached to the robot articles and is self-contained (the framework, behaviors, sensor drivers, etc… in one zip file) .  I think this makes the most sense for each robot so people can download all they need in one shot, but I wonder if I should create a pool of code that accumulates the latest versions of the framework and each behavior I created so people can download one or more files as samples to build upon or create their own arrangement.  What do you think?

The tricky part of putting each file online is the framework is being changed as I go, so keeping everything in sync may be a chore.

For instance, this week I made a change to the timer macros that allow a programmer to create and name multiple timers within a behavior.  That means previous code will not function (if you over-wrote the framework file) until you update behaviors to name the timer in the following functions.

CreateTimer(); ---> CreateTimer(timerName);
StartTimer(); ---> StartTimer(timerName);
TimesUp(time); ---> TimesUp (timerName, expirationTime);

AreaRover III – Another wall following behavior

Background

While I was experimenting with the Lego Ultrasonic (US) sensor for following a wall, I thought I would create a behavior for following a wall using only the front bumper.  This serves two purposes.

1. As a backup or augmentation to the US wall following.
2. As an alternative to the US wall following where only the front bumper is needed to accomplish similar goals.

Download the code: bbAreaRover3.zip