08.31.09

Follow a Line – Line Following Basics

Posted in My Robots, PathBot tagged , , , , , , , at 10:14 pm by Thom

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.

clip_image001

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.

clip_image001[4]

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. clip_image001[6]

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.

clip_image001[8]

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.

clip_image001[10] clip_image001[12]

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 imagemotors.

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.

07.26.09

Puckbot – Collector Robot Post-Mortem

Posted in CollectorBot, My Robots tagged , , , , , at 9:31 pm by Thom

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. 

Read the rest of this entry »

07.18.09

Puckbot I – Collector Robot Success!

Posted in CollectorBot, My Robots, RobotC Code, Video tagged , , , , , , , at 10:38 pm by Thom

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.

collectorbot-behdia

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

Read the rest of this entry »

07.14.09

Escape Sequence – A generic approach to getting away

Posted in AreaBot, CollectorBot, My Robots, RobotC Code tagged , , , , , , , , , , at 10:28 pm by Thom

BumpEscapeStateDiaThe 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?

Read the rest of this entry »

Bumpers and Light – Combining Sensors into One Port

Posted in CollectorBot, My Robots, RobotC Code tagged , , , , , , , , , , , at 8:53 am by Thom

TFR_20090713_0694_thumb.jpgSome 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

Read the rest of this entry »

07.13.09

AreaRover III – Video

Posted in AreaBot, My Robots, Video tagged , , , , , , , , , , , , at 12:21 pm by Thom

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.

Read the rest of this entry »

Differential Light Sensor – Two NXT Light Sensors as One

Posted in CollectorBot, My Robots, RobotC Code tagged , , , , , , , at 11:52 am by Thom

 Collector Robot 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

Read the rest of this entry »

07.09.09

New Pages – My Bookshelf & My Code Library

Posted in Information tagged , , , at 9:55 pm by Thom

glossy_3d_blue_i 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

Homing Behavior – Home in on a Light Source

Posted in Behavior-based Theory, CollectorBot, My Robots tagged , , , , , , at 8:25 pm by Thom

CollectorLight 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

Read the rest of this entry »

07.05.09

Finding Objects – A new robot idea for an autonomous robot

Posted in CollectorBot, My Robots tagged , , , , , , , , , , , , , , , , , , , , , at 11:33 pm by Thom

glossy_3d_blue_orbs2_108 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.

Read the rest of this entry »

Next page