Summary

There are many ways (and sensors) available that can allow a robot to follow a line. I have experimented a few that are of interest.

• Single Light Sensor
• Two Light Sensors
• Mindsensors LineLeader Sensor (Intelligent array of 8 light sensors in one I2C package)

In this article I review a couple of standard ways of staying on track, and then review the new Mindsensors – Line Leader sensor.  I was part of a beta-testing group for this great sensor.

Single Light Sensor

Using on NXT light sensor, there

are a couple of possibilities for following a line that can be effective. The programmer can either code to follow the line itself, or the edge of the line.

Following inside the line offers the advantage of knowing the robot is on the line, but what direct do we turn of we fall off? If the robot falls off of the line, which direction should it turn to return to it? As the robot drifts back and forth on the line, the programmer must try to correct its course to stay on the line. This method is mostly impractical.

Edge following offers the advantage of knowing the direction to turn in order to stay on the line. It is generally a faster, more accurate method for following a line. You select the right or left side of the line to follow, and code the robot to turn left if the light sensor reports BLACK and right if WHITE. This method allows a robot to follow the edge of the line through straight sections and curves. Is there a better method to follow a line?

Two Light Sensors

Using two NXT light sensors, there are also a couple of useful configurations to review. Sensors are generally set side by side on the front of the robot with either both inside, or both outside the line. With two sensors (left and right), more accurate line following can be achieved because as a line is lost on one side or the other, recovery is possible because we know which side lost the line.

Placement of the light sensors is very important so that only one sensor at a time could be on the line. As can be seen in the illustration, as the robot drifts from one side to the other, one sensor contacts the line and the robot can react accordingly.

Coding is similar to using one light sensor following the edge of a line, but you can let the robot run straight if both report WHITE or both report BLACK (depending on the configuration). This allows the robot to gain speed instead of oscillating back and forth (as much) as it must with one light sensor.

Mindsensors Line Leader Sensor

A more advanced method for following a line is to utilize three or more light sensors to follow a line. Many people have custom built line following sensor arrays, but Mindsensors has just released the Line Leader sensor for the rest of us. Not only does it contain eight (8) sensors in its array, the intelligent sensor also implements some very nice internal coding and a robust I2C interface to communicate with the robot.

Because there are 8 light detectors under the sensor, it is very easy to determine how to follow a line. The goal is to keep the line centered under the sensor. As the line moves left or right under the robot, it can compensate to center the line under the sensor. How is this done? Mindsensors has a good explanation in the Line Leader user guide.

Mindsensors took all of the hard work and math out of determining how to follow the line. There is a register for retrieving the STEERING value from the sensor. I have used the STEERING value successfully by supplying speed values to two motors. The following example code shows how to read the STEERING value from the sensor, and apply it to two drive motors.

int clip(int x, int min, int max) {
  if (x<min)
    return min;
  else if (x>max)
    return max;
  else
    return x;
}

While(true) {
//TWO MOTORS – DIFFERENTIAL DRIVE STEERING FROM LINE LEADER 
//GET STEERING FEEDBACK FROM THE SENSOR TO KEEP ROBOT ON THE LINE

  steering = (int) LL_Read(SensorPort, LineLeaderAddr, LL_READ_STEERING);
  motor[RIGHTMOTOR] = clip(70 + steering, -100, 100); //RIGHT MOTOR
  motor[LEFTMOTOR] = clip(70 - steering, -100, 100); //LEFT MOTOR
}

The clip function is a simple utility function that should be in everyone’s toolbox. It takes value returns it if it is between min and max. If outside the range, it returns min or max.

Mindsensors supplies a simple driver file that makes reading the STEERING value easier. We call LL_Read() with the LL_READ_STEERING constant to return the STEERING value suggested by the sensor based on where the line is. The last step is to determine speed value for the left and right motors. We ideally (in this case) want to travel straight at speed = 70. We add the steering value to the right motor, and subtract it from the left motor (within the range motors accept – [-100 to 100]). That’s it.

As the line drifts to the right (or robot to the left), steering becomes a negative number. The further it moves to the right, the bigger the number becomes to allow for correction of the robot.

If the STEERING value returned is -20, we set the motors to use the value to correct the robot’s steering.

RIGHTMOTOR power = 70 + (-20) = 50

LEFTMOTOR power = 70 – (-20) = 90

This causes the right motor to spin faster than the left turning the robot left to re-center the sensor over the line.

Your program would continue to loop, finding the next steering value and correcting the motors accordingly. The robot uses this feedback control to follow a line.

What if the robot takes advantage of the NXTs motor implementation and links the RIGHTMOTOR and LEFTMOTOR together? NXT firmware allows the motors to take advantage of the internal encoding for each motor to keep them running at the same speed (It can move in a straight line!). I often implement my drive motors with this configuration so the robot can easily move straight. Here is a quick code sample of implementing sync’d motors.

void _DriveRobot(int power, int steering) {
  if (steering >= 0) { //RIGHT TURN or STRAIGHT
    if (lastPower!=power || lastSteering != steering){
      nSyncedMotors = synchBA;
      nSyncedTurnRatio = (100 - (2*abs(steering)));
      motor[LEFTMOTOR]=power;
      lastPower=power;
      lastSteering=steering;
    }
  }
  else { //LEFT TURN
    if (lastPower!=power || lastSteering != steering){
      nSyncedMotors = synchAB;
      nSyncedTurnRatio = (100 - (2*abs(steering)));
      motor[RIGHTMOTOR]=power;
      lastPower=power;
      lastSteering=steering;
    }
  }
}

In this case, I have directly passed the STEERING value returned from the Line Leader to this routine with excellent success. Robot speed is determined by the POWER parameter (-100 to 100) to implement reverse, stop, or forward. The STEERING parameter (-100 to 100) determines left, straight, or right turns.

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. 

What Went Right

As you can see, I am proud of this accomplishment as a whole.  When I break down the components, there are many things I learned, that really worked well.  Here are a few.

• Learning that one front bumper is enough in many cases.  Like most of you, I almost always create my front bumpers with two bumpers (left & right).  I starting thinking about it, and wanted to try to use only one input for the bumpers and found I was not giving up too much advantage by implementing one bumper.
• Going a step further and adding a light sensor to the same port as the bumpers. In my case, I was able to work around the limitation of having light sensor and bumper readings on the same port and I saved inputs for other sensors.
• By implementing sensor drivers, I also created a standard set of functions to communicate with the sensors.  The idea was to create a function like FrontBumper.isBumped() so that in the future, a behavior that implements this function does care about the implementation or configuration of the sensors, only is the front bumper was bumped or not.  The driver performs the calculations and returns whether or not the bumper is engaged. (note-I did not say pressed).  The bumper be physically implemented to be “isBumped” when pushed or not pushed depending on the design.
• Creating a sensor driver for the differential light sensor also shined for me.  By creating a driver that supplied standard methods and values, multiple behaviors could use the “triggers” for their own purposes without complicated, customized logic in each behavior.  Look at the code to see what I mean; Especially with the differential light sensor.  Seeing or not Seeing a light is critical to the operation of the robot.  The driver return true or false.  Calculations are done internally to the driver to determine thresholds, etc…  Several behaviors use the common functions.
• The Differential Light Sensor auto calibrates.  When I first created the robot and coded some behaviors, varying light sources in my office caused many confusing problems for the robot (and me!).  The differential light sensor driver attempts to do the hard work no matter the environment lighting by storing hi, lo, and current values and doing calculations to automatically configure thresholds and return meaningful information.

What Were Some Challenges

• The Puckbot manages several behaviors at once.  Trying to understand programmatic failures is not always easy to determine.  I found that by disabling all behaviors but one or two really helps to find issues.  By implementing only LIGHT HOME, I was able to move the robot manually into position, and watch trigger points and see the homing action.
• Speaking of homing, There were times when the robot would home in on the light source only to get too close and “loose” track of it because the light sensors saw a similar value, but did not directly see the light.  Kind of like going cross-eyed trying to see the tip or your nose.  The robot would crash into the wall behind the source and escape most of the time, but it looked clumsy.  At least there is some inherent graceful degradation, even in my simple NXT robot.
• Wall following utilized the front bumper, which was on the same input port as the down pointing light sensor.  While touching a wall, the robot is unable to determine if it has captured a puck.  It is effectively blind at times.
• On this topic, one weakness of the hierarchical behavior model is the paradox it can create at times where it seems one behavior should be higher priority than another in some cases, and lower in others.  BUMP FOLLOW and DARK PUCK were victims of this.  Generally, bump follow must be high on the list above BUMP ESCAPE since it only triggers sometimes, but what if the robot encounters a puck along the wall while following?  DARK PUCK is pretty low in the list and should not be above the escape behaviors or the robot might crash into a wall carrying a puck and not be able to escape.  I need to think more on this, but I think the answer may be to create a new, special case, behavior above BUMP FOLLOW for when a puck is encountered while following a wall.
• Physical design caused interesting challenges.  For example, I changed the puck catching mechanism several times to maximize capture.  I even changed the design after I posted nice pictures on the design in this blog.  I was not capturing pucks when they were near the front wheels.  Compare the video with the pictures in the blog and you will see differences (if you look close).
• I noticed the robot seemed to get stuck in a loop in a few cases where it was away from the light source, and carrying a puck.  I think the robot starts to turn toward the light source with a puck, but the puck slips from the catch.  The light sensor looses it momentarily, and the light source is not strong enough to attract the robot, so it starts to CRUISE.  At that point, the puck slips back into the catch and starts the loop over.  It is a complex case of canyoning and surprised me when I first saw it.  The robot appears to orbit the light source for a time before giving up.  I would like to revisit that scenario, but it is difficult to trigger when you are trying.

Last Thoughts

All in all, the Puckbot collector robot was a complete success.  It can collect four pucks and deliver them to the light source successfully most of the time in less than 5 minutes.  There are some cases when a puck gets trapped along a wall or in a corner and the robot fails, but most of the time it succeeded.  I will certainly revisit this robot and tackle these weaknesses.

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.

Behaviors in Detail

I have reviewed the sensors and drivers in previous posts, so here I will focus on new behaviors, and discuss the big picture.  I have described CRUISE, BUMP ESCAPE, and BUMP FOLLOW in posts for the AreaBot.

LIGHT ESCAPE – If a light source is too bright, get away

Light escape is the highest priority and key to collecting pucks in a central home base location.  Although it has nothing to do with collecting anything, this behavior is the mechanism for dropping off the pucks at home base.  When the robot approaches the light source (with or without a puck in its grasp), and gets close, this behavior is triggered.  The robot backs up (leaving the puck it was pushing behind) and spins away to find more pucks.

Light escape is a relatively small behavior that relies on the differential light sensor as a trigger and the generic escape sequence to escape.

HOME LIGHT – if a light source is in view, move toward it

Home Light is a behavior that is triggered when the robot see enough light to determine it sees the home beacon, and attempts to move the robot toward it.  The differential light sensor is employed to determine the difference between left and right light intensity, and uses that value to steer the robot toward the light.

In an ideal situation, the robot will home in on the light while also pushing a puck.  In this way, pucks are delivered to the light source.

DARK PUCK – If a puck is captured and home is not in sight, turn toward it

Dark Puck is a departure from the collector robot from my reference book.  The original behavior was called DARK PUSH.  When the robot encountered a puck it could push it.  In the book, pucks were detected by turning toward them, and only pushing them if there was a light.  If no light beacon was seen, the robot would execute an escape sequence.

It was not practical to detect pucks with my robot using the IR proximity sensors, so I needed another way to increase the odds of moving pucks to the home base.  Dark Push applies similar principals to Dark Push by triggering when the robot is pushing a puck, and facing away from the home base beacon.  Dark Puck detects a captured puck using a legacy light sensor pointed down into the puck catch.  When detected, and the differential light sensors report no beacon, the robot attempts to turn (without loosing the puck) toward the light source.  If successful, HOME LIGHT may take over and move the puck to home base.

WordPress Tags: Collector,Robot,Behavior,Diagram,AreaBot,Mindstorms,task,Behaviors,CRUISE,BUMP,ESCAPE,HOME,DARK,PUCK,PUSH,concepts

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?

In my experiments so far, any time the robot needs to escape from a trigger (collision, too much light, etc…) the same sequence of events occurs in order to free the robot from the trigger.

We examined BUMP ESCAPE where a bumper collision occurs.  Once triggered, the robot backs up for a time, spins right or left for a number of degrees, and finishes by moving forward a short time to make sure it starts the next behavior in a different location as when escape was triggered.

For the collector robot, a behavior was written that needs to escape when a light source is too bright (LIGHT ESCAPE).  Why not use the same code to escape from a “too bright” light source.  I have a Boolean trigger, and I understand the movements the robot can perform to move away from the light.  At first, I copied the escape code from bump escape, and changed it to work with the bright light.  Then I got an idea…

Maybe I should create a generic escape sequence function and allow other behaviors to utilize the common code.  I spent an evening coping key parts of the code to a new include, and called it escape sequence.  Now a new escape behavior is easy to implement.  I just need to know the current state and trigger condition.

// *** NEEDS EscapeSequence.h
// *** ASSUMES A FRONT BUMPER IS IMPLEMENTED IN THE MAIN ROBOT CODE

// BEHAVIOR CODE TO ESCAPE FROM A FRONTAL COLLISION
void BEH_BumpEscape() {
  Behavior(BEHAVIOR_BUMP_ESCAPE);  // SET THE BEHAVIOR ID
  static typEscapeState bumpState; // ESCAPE STATE VALUE
  bool isCollision;                // COLLISION VALUE

  isCollision = bumper_isBumped();    // DID A COLLISION OCCUR?
  if (bumpState != STATE_START) {   // ALREADY ACTIVE, FOLLOW ESCAPE ROUTINE
    EscapeSequence(bumpState, isCollision);
  }
  else {
    if (isCollision)
      EscapeSequence(bumpState, isCollision);
      else
        DeclineControl();  // NO COLLISION OCCURED-DO NOTHING
    }
}

Here is the new BUMP ESCAPE behavior.  The behavior checks if the robot is in a collision (trigger condition), and calls EscapeSequence(currentState, currentTriggerCondition).  The Escape Sequence does the rest.  How is that for a few POWERFUL lines of code!

The code is very similar to implement LIGHT ESCAPE.  Notice the trigger condition isTooLight.  The only difference is under the statement that checks “not state = start” where I send “false” as the condition.  If I sent the isTooLight condition here, the robot backs up until there is not too much light.  I just wanted the robot to recognize it was too close to the light source and turn away.

// *** NEEDS EscapeSequence.h
// *** ASSUMES TWO LIGHT SENSORS ARE IMPLEMENTED IN THE MAIN ROBOT CODE

// BEHAVIOR CODE TO ESCAPE FROM A FRONTAL COLLISION
void BEH_LightEscape() {
  Behavior(BEHAVIOR_LIGHT_ESCAPE);  // SET THE BEHAVIOR ID
  static typEscapeState leState; // ESCAPE STATE VALUE
  bool isTooLight;                  // COLLISION VALUE

  isTooLight = DiffLight_IsHome();

  if (leState != STATE_START) { // ACTIVE, EXECUTE ESCAPE ROUTINE
    EscapeSequence(leState, false);
  }
  else {
    if (isTooLight)  // TRIGGER THE ESCAPE ROUTINE TO START
      EscapeSequence(leState, isTooLight);
      else
        DeclineControl();  // NO COLLISION OCCURED-DO NOTHING
    }
}

I will make all code for the collector robot available very soon as one download package.

Some of you may have noticed that my Collector Robot has more than two light sensors hanging off the sides…  There is an archaic bumper (design from the original Mindstorms 1.0 kit) and a legacy light sensor buried in the bumper.  There is also a couple of white arched technic pieces under the bumper.

I thought I would go into more detail on this design because the implementation was interesting.  This robot is designed to find and move Lego NXT pucks around.  It does not specifically search for pucks, but happens upon them because it is able to cover all areas of the arena.

Download the driver here: BumpLightCombo.h

Technical Background

The bumpers give the robot protection from walls and objects and trigger several behaviors within the robot to perform tasks like escaping a collision and following a wall (just like Areabot).

There is a “puck catch” under the bumper that is designed to either direct pucks into the middle where a light sensor can detect the black color, or deflect pucks to far to the right or left away from the wheels.  If a puck is detected in the catch, various behaviors are triggered to increase the chance the robot will deliver them to home base.

Sensor Implementation

Sometimes there is an opportunity to combine sensors together into one port that requires no additional hardware.  It requires a little bit of ingenuity and programming creativity, but the results can give you more sensory power without using additional input ports.

For my Collector Robot, I wanted to implement a front bumper to detect collisions, and a light sensor to detect captured pucks. As knowledge and experience luck would have it, I was able to combine the bumper and down pointing light sensor into one port because the sensors are not needed at the same time.

There are a few compromises that need to be understood to configure the sensors using only one NXT input port.

• The left and right bumpers are connected together to provide ONE bumper on the front of the robot.
  • A compromise with this configuration is the loss of ability to detect left or right collisions.  I used to think this was bad, but I found out it is not that big of a deal.  In my case, bumping is used to escape from a collision or for following a wall.  In both cases, I control the turning directions anyway, so there is no reason to implement left and right bumpers.  Escape randomly turns away from the wall.  Wall following always follows walls on the right side, so a spin gets it into position easily.
• The legacy light sensor is also connected to the same port as the bumpers and is used to detect pucks in the “puck catch” area.
  • What happens, is the light sensor value is read as long as there is not a collision.  If there is a collision, the value goes to 100.  No problem for collector robot because I am continually monitoring for the presence of a puck when not hitting a wall.
    • You must implement bumpers that are normally open (not pressed) in order to use the light sensor.  These are not the best for bumpers because it takes more force to press the buttons than to release them.  Collector Robot gets beat up a little, but it is good for its sole   I can live with that.
    • When the bumper is pressed, the light sensor is useless.  This can be an issue if you need the bumpers and the light sensor at the same time.  In my case, a collision was more critical than whether or not I could detect a puck in the collector.

I wrote a driver that allows me to abstract all of this logic into a few functions I can call to check the sensor(s) status.  It is not complicated, but lets me concentrate on the rest of the code without remembering the implementation.

Code Listing

#define FRONT_BUMPER S2  //DEFAULT INPUT PORT FOR BUMPER SWITCH SENSOR
#define LIGHT_DOWN S2  //DEFAULT INPUT PORT FOR BUMPER SWITCH SENSOR 

const int kLightSensorDark = 24; //LIGHT SENSOR BLACK THRESHOLD 

//INITIALIZE FRONT BUMPER TYPE AND MODE
void BumpLightCombo_Initialize() {
  SensorType[LIGHT_DOWN] = sensorReflection;
  SensorMode[LIGHT_DOWN] = modePercentage;
} 

// CHECK THE SENSOR FOR BUMPED.  MUST BE NORMALLY OPEN AND CLOSED ON TRIGGER!
bool bumper_isBumped() {
  return (bool) (SensorValue[FRONT_BUMPER] >= 99);
} 

// CHECK THE SENSOR FOR BUMPED OR NOT BASED ON VALUE AND CONFIGURATION
bool lightDown_isDark() {
  return (bool) (SensorValue[LIGHT_DOWN] <= kLightSensorDark);
} 

// CHECK THE SENSOR FOR BUMPED OR NOT BASED ON VALUE AND CONFIGURATION
bool lightDown_isLight() {
byte _value = SensorValue[LIGHT_DOWN];
  return (bool) (_value > kLightSensorDark + 5 && _value <99);
}

cccc

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.

It shows the robot trying to move about in my arena.  The first part shows AreaRover bouncing off the walls and failing to enter the second chamber because the door is not very large.  Eventually, the robot would make it into the room, but we like efficiency.

By adding wall following to the behaviors, the robot is able to follow a wall around the corner and into the 2nd chamber very easily.  I experimented with using the Ultrasonic sensor to follow a wall on one side, and bumper collisions to follow the wall on the other side to add variety.  It just goes to show you that behaviors can be layered in a robust manner fairly easily.

WordPress Tags: AreaRover,Video,robot,chamber,Ultrasonic,sensor,collisions,behaviors

  One of the goals of the Collector Robot is to push pucks to a light source “Home Base” and leave them there.  In order to accomplish this, the robot must be able to home in on a light source.  In order to home, the robot needs to have some method for finding the light, and adjusting its course to drive toward it.

I created a virtual differential light sensor using two NXT light sensors mounted on the robot facing forward, angled to the left and right.  This gives me a good starting point to read values from each sensor to determine the difference in intensity and therefore determining the STEERING value to drive the robot toward the light.

Download the driver: DiffLight-driver.h
Download this too: mathext.h

Purpose

One of the challenges I ran into was the many things a robot can do with two light sensors combined in this configuration.

• check the intensity of each light sensor separately.
• calculate the difference between the sensors for applying a steering value.
• determine which sensor sees the most light at a given time.
• determine which sensor sees the least amount of light at a given time.
• auto calibrate a dark/light threshold value for each sensor.
• what is the maximum intensity each sensor has recorded?
• what is the minimum intensity each sensor has recorded?
• determine an overall average light from the sensors.
• determine if the robot is close to a light source.
• determine if the robot is facing a light or not.

So you can see, this list screams – Create a driver!  So I did.

The Driver Implementation

The differential light sensor driver consolidates the logic and data necessary to accomplish the above tasks.  The following represents the current functionality within the differential light sensor driver class I created.

//FUNCTION PROTOTYPES ---------------------------------------------------
void DiffLight_init();          //INITIALIZE THE SENSORS
int DiffLight_LeftThreshold();  //CALC'D RIGHT THRESHOLD VALUE
int DiffLight_RightThreshold(); //CALC'D RIGHT THRESHOLD VALUE
int DiffLight_Threshold();      //CALC'D THRESHOLD BETWEEN LIGHT & DARK
int DiffLight_Average();        //AVERAGE CURRENT LIGHT VALUE
int DiffLight_Maximum();        //LOWEST OF LOW READING FROM SENSORS
int DiffLight_MaximumAvg();     //AVERAGE OF LEFT & RIGHT MIN VALUES
int DiffLight_Minimum();        //HIGHEST READING FROM EITHER SENSOR
int DiffLight_MinimumAvg();     //AVERAGE OF LEFT & RIGHT MAX VALUES
int DiffLight_Difference();     //DIFFERENCE BETWEEN LEFT & RIGHT VALUES
typLightSensorBool DiffLight_State(); //FACING LIGHT SOURCE OR NOT
bool DiffLight_IsHome();              //IS AT THE LIGHT SOURCE OR NOT
//-----------------------------------------------------------------------

One of the interesting aspects of this driver, is its auto-calibration feature.  I was getting tired of setting and setting constants for light and dark values.  I wanted to robot to build a knowledge  base of its environment and calculate decisions on that data.  All of the functions above take into account data the sensors collect and return values relative to the environment, no matter how light or dark home base and the ambient light are.  This is accomplished by storing min and max values for each sensor giving the robot a basis for understanding light and dark thresholds.

The work horses driver functions for the collector robot code are DiffLight_Difference, DiffLight_State() and DiffLight_IsHome().

DiffLight_Difference() is a simple function that returns the difference between the current values of the two light sensors.  This value shows if a light source is on the left or right side of the robot.

DiffLight_State() uses an algorithm to determine if the virtual sensor is facing toward or away from a light source (home).  You might think this is an easy task, but experimentation showed me it can be more difficult to implement.  I wound up implementing hysteresis into the function to prevent the sensor from oscillating back and forth near border zones.  Once locked into IS_LIGHT or IS_DARK, the sensor needs to overcome a hysteresis factor to switch states.

DiffLight_IsHome() is another useful function I implemented to determine if the robot is very close to the light source.  I wanted a generic method for determining this, but again it turned out to be a little more complicated than expected.  I wanted to know when I was ~90% to the maximum light value to determine “HOME” success.  With auto-calibration, the sensor is unable to make a good decision until it gathers enough information about its environment.  I implemented a minimum difference factor that makes sure the min and max values are at least 30 before allowing home to be calculated.

In addition, I added a structure to capture several values of interest about the sensors that can be used in internal calculations.

typedef struct {
  ubyte rtMax;  //RIGHT LIGHT SENSOR MAX RECORDED VALUE SINCE START
  ubyte rtMin;  //RIGHT LIGHT SENSOR MIN RECORDED VALUE SINCE START
  ubyte rtVal;  //RIGHT LIGHT SENSOR CURRENT VALUE
  ubyte ltMax;  //LEFT LIGHT SENSOR MAX RECORDED VALUE SINCE START
  ubyte ltMin;  //LEFT LIGHT SENSOR MIN RECORDED VALUE SINCE START
  ubyte ltVal;  //LEFT LIGHT SENSOR CURRENT RECORDED
} sDiffLight;
sDiffLight _dlSensor;

A task that continually runs to read the values and populate the structure.  The functions utilize the structure values and return appropriate values.  The base code is encapsulated to keep the results consistent for all behaviors that require values.  I am a fan of hiding complexity and doing things once.

To use the driver, include the file in your robot code and start the task.

#include "driver\DiffLight-driver.h"

StartTask(DifferentialLightSensor);

That’s it.

I added a couple of new pages to the blog where I posted a list of my robot books, and my Mindstorms behavior-based framework code (RobotC).  I found that as I posted more articles, the code was getting lost.

I plan to add a change log for the framework, so you can all get the latest versions and know what changes were made (and why…).

I also created sections for behavior code to be posted, but I am not exactly sure if that makes sense because each robot requires certain sensors and structure in order for a given behavior to make any sense. 

I think I will summarize each robot project and post zipped code for each experiment for you to download in this one place.  This way you can see the robot, and view the sample associated code.

WordPress Tags: Code,Library,robot,Mindstorms,behavior,framework,RobotC

My next robot is taking some time to build, code and  debug, so I thought I would create some quick posts about some of the behaviors I am implementing along the way.  Homing in on a target is a very useful behavior that can be broadly applied to many types of situations.

• Finding a beacon
• Finding a light source
• Following a line

Homing in on a light source

By placing two light sensors on the front of the robot facing ~45 degrees to left and right, we can search for a light source and home in on the signal by checking the difference in light levels between the two sensors.  For example, if the light is brighter on the left, the robot will turn left attempting to equalize the signals between the two sensors (thus point directly at the light source).  Moving the robot forward at the same time allows the robot to home in on the source.

The concept is to utilize two (or more) sensors arranged to allow the robot to consume data and make steering decisions based on signal strength or quality between the two.

Implementation

If (Light > Threshold) {
  DriveCommand( speed, g(right-left));
}

The pseudo-code above illustrates how easy homing can be implemented.  If the robot sees a light to follow, it sets the drive command to move toward it using the difference between left and right light values (multiplied by a gain constant) to control the steering toward the light.

This code can also be implemented as a bang-bang controller by implementing a constant steering value based on the sign of (right – left).  If the light is on the left, sgn() returns –1, if on the right sgn() returns +1.  The gain becomes the steering value.

Other Homing Actions

Homing on a digital beacon can be implemented with the same logic.  The difference is the left and right signals may be counted pulses.  If the left sensor is aligned more to the source than the right, it should theoretically receive more pulses from the homing beacon.  The above implementation can be applied to the counts.

Simple line following also follows this concept.  Two light sensors pointing to the ground can be implemented this way by comparing the two signals and adjusting steering to keep the robot on the line.

WordPress Tags: Behavior,robot,beacon,example,concept,logic,light sensor

I started this blog about a month ago to share ideas and robot programs using behavior-based techniques.  I went back to one of my favorite books, “Robot Programming – A Practical Guide to Behavior-Based Robotics” by Joseph L. Jones to renew my ideas.

I have decided to create a Lego NXT robot that is similar to the one featured in the online simulator that used to run for this book.  Unfortunately, the site was disbanded a while back so you can’t see it in action, but you can still find the user documentation here.  The java code for BSim is here.  Anyone want to host this applet?  It is pretty cool.

The task I am interested in is “Collection Task”.  This task uses several behaviors to have the robot move around an area collecting pucks and moving them to a light source in the middle.  It is fun to watch in Bsim because none of the behaviors collects anything?!  Each behavior they implement performs its goals that collectively solve this challenge.  The Collection Task uses behaviors Escape, Dark-push, Anti-moth, Avoid, Home, and Cruise in order of decreasing priority.

Of course, I have some hurdles to overcome implementing this on my Lego NXT robot.  Challenges are fun, right!

Here are some of my initial challenges.

• Robot shape – Their robot is like Roomba.  Round and smooth.  Sensors are cool and well thought out.  Robot actions are very cool.
• Limited sensors on the Mindstorms robots.  There are several sensors engaged on Bsim.  Some creativity with the NXT is necessary to come close.
• The simulator has a perfect world where everything works as designed.
• Lights are a problem because in the simulator they do not reflect light off the walls or objects.  They are easy to home in on.  The real world is not so easy.
• BSim is able to understand PUSHING a puck vs. COLLIDING with a wall.  That is tougher with the NXT.  To implement this, you may need to be able to implement a stall sensor or something like it.  I have not been able to consistently make a stall sensor reliable.  I have some ideas around this.

I am up for the challenge.  I built and programmed a prototype this week, but still have some more work to do.  I will post more progress this week.

Stay tuned…

WordPress Tags: robot,ideas,behavior,Practical,Guide,Robotics,Joseph,Jones,Lego,documentation,code,BSim,task,Collection,Roomba,Round,Sensors,actions,Mindstorms,world,Lights,walls,sensor,prototype,techniques,goals,robots,simulator,behaviors