Home > Behavior-based Theory, RobotC Code > Behavior-based Framework for Mindstorms NXT Robots

Behavior-based Framework for Mindstorms NXT Robots

Behavior-based Framework for RobotC

Download my RobotC code: : behRobotFramework.zip

I have created a basic framework in RobotC to implement behavior-based programming.  There are two files to start with when creating a behavior robot.

  • behRobotFramework.c – The main robot file (template).
  • behavior_robot.h – the heart of the behavior implemention.
  • behRobotFramework.c

    The framework template allows you to initialize the robot, define and implement behaviors, and loop through behaviors to determine a winner for control of the drive motors.

    behavior_robot.h

    This file provides the main behavior-based “brains” functionality for the robot.  Macros, variables, and functions are provided to implement the robot.

    behClass

    Behavior Robot (Drive Motors)

    My robot implementation is a differential drive robot.  That means a robot that uses a left and right motor directly connected to wheels used to drive the robot.  By controlling the left and right motors, the robot can drive forward, backward, and turn or spin either clockwise or counter-clockwise.
    // ROBOT.DRIVE METHODS
    void DriveRobot(int power, int steering);//SUBMIT DRIVE PARMS TO MOVE ROBOT
    void DriveRobot(typBehavior &winner);    //SUBMIT BEHAVIOR TO LOOKUP AND EXECUTE DRIVE PARMS TO MOVE ROBOT

    Behavior robots do not need to implement differential drive.  To implement another drive mechanism would include changing these methods.  The behavior structure would also need modification to contain left and right power settings instead of power and steering values.

    Behavior

    Behaviors are the building blocks in this framework.  In the main code we define a set of possible behaviors to implement for the robot.  This structure defines an ID for each behavior.  When we AddBehavior(), this ID is placed into a priority index (hierarchy) and base attributes for the behavior are set.

    // BEHAVIOR MACROS SUPPORTING CLEANER BEHAVIOR CODING
    #define Behavior(beh) typBehavior _beh = beh
    #define RequestControl() Control(_beh, true)
    #define DeclineControl() Control(_beh, false)
    #define SetCommand(_p, _s) DriveCommand(_p, _s, _beh)

    // BEHAVIOR METHODS
    void DriveCommand(int p, int s, typBehavior beh); //SET THE DRIVE COMMAND FOR A BEHAVIOR
    void Control(typBehavior beh, bool wantControl);  //BEH REQUESTS TO CONTROL THE ROBOT

    //BEHAVIOR ATTRIBUTES
    tBehavior aBehavior[MAX_BEH];   //Each behavior has a set of attributes used by the robot

    string name;          // PRINT NAME OF BEHAVIOR - ADDED FOR DISPLAY
    bool requestControl;  // REQUEST DRIVE CONTROL OF THE ROBOT
    int motorSpeed;       // REQUESTED DRIVE SPEED (0 - 100)
    int motorSteering;    // REQUESTED DRIVE TURNING (-100 TO 100)
    bool enabled;         // BEHAVIOR IS ENABLED OR DISABLED – SUPPRESSION

    As each behavior runs, it may request or decline control of the robot drive motors.  To do so, the behavior calls SetCommand() to write the drive commands into the behavior’s attributes for power and steering.  Control() is called to write the boolean attribute requestControl which is used by the arbitrator for determining control of the robot.

    Arbitrator

    The arbitrator is the heart of the behavior implementation.  Its job is to determine the highest priority behavior that has requested control.

    // ARBITRATOR METHODS
    void AddBehavior(typBehavior beh, string n);      //ADD A BEHAVIOR TO THE PRIORITY INDEX AND INITIALIZE IT
    typBehavior Arbitrate();                          //DETERMINE WINNING BEHAVIOR TO CONTROL ROBOT

    // ARBITRATOR ATTRIBUTES
    typBehavior behPriority[MAX_BEH];   //array of behaviors in priority order
    int priority;                      //next priority to set when adding behaviors
    typBehavior winner;                //ARBITRATION WINNER

    Given this simple behavior diagram

    Basic behavior-based room explorer

    Basic behavior-based room explorer

    The following represents how the behavior robot consumes and organizes the information.  The total number of behaviors implemented is 2.  This is defined as MAX_BEH.  The implementation allows this constant to be set in the code rather than predefined because RobotC must define array size, and there is no reason to keep unused array elements in memory.  The BUMP ESCAPE behavior has the highest priority and CRUISE has the lowest.  The Behavior ID is stored in the priority array for use with the arbiter.

    arbitor

    The behavior array’s index is the behavior type as well, providing a direct link between the priority array and the behavior.  The arbitor checks for requestControl=True, then returns the winner’s behavior ID.

    Advertisements
    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 )

    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: