This is the story of how I am building a line following robot. Use the links below if you want to jump around this page.
There are a number of ways to set up the course for a line following robot. It can be a black line on a white background or the reverse. Either way, the robot is "trained" to use sensor readings to detect the line and follow it by adjusting the course and/or speed of the robot.
Here is a typical easy line following course:
And if there is a competition, the winner is usually the robot that can complete a lap or a set number of laps in the shortest time.
As soon as sharp turns or crossing intersections are introduced, the problem becomes more difficult. The robot now has to have more sensors and be "smarter" to detect these different situations. Here are two examples of more complex courses:
Since I want to be able to navigate more complex race courses, I have chosen to use multiple sensors to detect the lines.
Here is part 1 of a multi-part article I'm writing about "How I Built a Line Following Robot":
Part 1: Selecting the sensors, building the eight element in-line sensor array, constructing the motors and caster.
I've used the QRD1114 sensor before and I like it. I would recommend it to those who like building their own circuits from scratch. It looks like this:
It is cheap, accurate and fairly easy to set up. It is just the IR transmitter and a phototransistor receiver with no electronics, so the user must set up the circuitry on a printed circuit board or proto-board. Here is a typical set-up schematic:
Also, the output is analog, so you must either have a built in A/D converter in your microcontroller or add an A/D chip to your design.
Since I wanted to keep this simple and easy for students, I decided to try a new sensor, a SingleLine Detector from LynxMotion.com shown here:
Notice the blue potentiometer with the yellow receptacle for a phillips screwdriver. This pot is used to adjust the sensor sensitivity. Just above the pot, you will see a red LED. This shows what the sensor is seeing, so is useful when setting up and testing the unit.
The advantage to this sensor is that the electronics is built in and the output is a one (5 vdc) or a zero (0 vdc) at the input pin of the microcontroller. This sensor costs about $14.00, or three or four times the cost of the QRD1114, but the ability to "plug and play" is worth the additional cost.
Once you decide on the sensor, the next decision is to decide on how many sensors are required to do the job. With no consideration for speed, one or two sensors are sufficient. The problems with this approach become apparent when the robot speeds up. As speed increases, turns come faster and the robot reaction time must improve. But then comes the question - - How many sensors are enough???
I'm working on another project with a different microcontroller where I built an eight-in-line sensor array, so I wanted to experiment with fewer sensors. So I needed a number between three and eight. I picked five, an odd number, so that when the robot is on track, it is only over one sensor. The argument could be made that six sensors spaced close together can also be effective. Anyway, for no particular reason, I picked five over six sensors.
This robot is built using the concepts and ideas of a college electronics course called "Embedded Systems". The hardware and software for that course are predetermined, therefore, the following will be the heart of the systems discussed for this robot:
I decided to start with a simple line following course and then build a more complex course. Here is my first course laid out on a white-board:
A line following robot with five sensors only has a limited number of possible combinations (assuming no read error). If the sensors are spaced such that only one sensor is normally over the line at one time, then the combinations are limited to these:
00000
10000
01000
00100
00010
00001
11111
The possible reading of 11111 is for the situation in some courses when the robot hits the end of the course, which is usually a black circle or square.
In the real world, these combinations will not be enough to allow for all situations. A lost robot, stumbling on to a line, might have any number of unplanned combinations, like:
00111
11110
10001
. . . or a number of other combinations. The approach will be to assume the algorithm to be workable in the simplest form, and then add any common combinations that occur.
Let's write some pseudocode to set up an arbitrary behavior.
Read sensors
00000 = Robot is lost! Continue line search procedure.
10000 = Robot off to the right. Left motor ahead slow, right motor stop
00001 = Robot off to the left. Right motor ahead slow, left motor stop
01000 = Robot drifting left. Slow down right motor.
00010 = Robot drifting right. Slow down left motor motor.
00100 = PERFECT!! Full speed ahead.
11111 = End of course. Shut down.
XXXXX = any other reading = Proceed with last command.
I said arbitrary behavior because the proper speed control for the motors under these conditions is unknown. An extremely cautious procedure would stop one of the motors whenever the robot begins to drift off center. This is cautious, but very bad in a contest where a fast line follower is needed. For fast line following, the motors need to be kept at the top speed that the robot can handle without loosing control.
So, I will initially set up the motor speeds as shown below. Then adjust to the conditions that allow the fastest speed.
| READING | LEFT MOTOR | RIGHT MOTOR |
| 00000 | slow ahead | medium ahead (Slow left circle, searching) |
| 10000 | stop | slow ahead |
| 00001 | slow ahead | stop |
| 01000 | slow ahead | fast ahead |
| 00010 | fast ahead | slow ahead |
| 00100 | Fast ahead | fast ahead |
| 11111 | stop | stop |
| XXXXX | last command | last command |
The exact speeds for "slow", "medium" and "fast" will have to be determined by experimentation and trials. The initial plan would be to be conservative and on the slow side until the algorithm is proven to work correctly and then by adding speed until control is lost, then back off slightly.