A smart robot can detect its surroundings and make decisions based on its findings; a smart robot is a winning robot. One of the ways to make your robot smart is by giving it the ability to receive input from the game field. Using a Color Sensor on your LEGO MINDSTORMS robot is a great place to start when adding some intelligence. I have found that many new teams are intimidated by using sensors other than the rotation sensors built into the EV3 servos, but this doesn’t need to be the case.
One of the great things about the EV3 Color Sensor is that it’s pretty much a passive sensor from a hardware perspective: you simply put it on your robot facing the direction you wish to use for detection and wire it up, and it is ready for action. With that said, you will need to have a good understanding of how the sensor works and what you’ll use it for in order to get the most out of it. Also, being able to develop smart programming code to interrupt the input received from the EV3 Color Sensor will be important.
First, you need a better understanding of what the EV3 Color Sensor is and how it works. Then, I’ll discuss how you can make use of it.
EV3 Color Sensor
The EV3 Color Sensor allows your robot to visually analyze its environment, basically giving your robot the gift of sight. It will be able to detect the differences between light and dark, either by detecting the ambient light of its surroundings or by analyzing the color of something in front of the sensor.
Both the LEGO MINDSTORMS Education EV3 Base Set and Retail Set include one EV3 Color Sensor, but you can buy extras through LEGO Education or other retail sources.
The EV3 Color Sensor contains an LED and a phototransistor; the phototransistor actually reads the reflected light from the LED or ambient light in the room. The Color Sensor ideally is reading from a very narrow field of vision; this field is based on the distance of the sensor from the source. For example, if you were to point the Color Sensor at the light in your ceiling, you would get a very high-level reading. Now, if you hold a black LEGO brick in between your robot and the ceiling light, the sensor would not recognize the brick simply because the field of vision is too great. However, if you placed the brick on a table and pointed and held the Color Sensor just a few inches over the brick, it would be able to detect the dark-colored brick. Keep this in mind when placing your Color Sensor on your robot’s chassis. Don’t position your sensor so far away that it cannot distinguish what you want it to.
The EV3 Color Sensor can read light in three modes: color, ambient light, and reflective light. Ambient light readings are the actual light values in the current room, coming from a light source other than the LED on the EV3 Color Sensor. Reflective light is measuring the light values returned from the lit LED on the EV3 Color Sensor. Color is detecting the actual color of light being reflected back to the sensor.
Ambient Light
The Color Sensor can be used to measure the ambient light in an area by using the Ambient Light Intensity option. This will allow the sensor to use the light in the room as the main source for the Color Sensor. For example, you may have a program that wants to know what the actual light levels are in the robot’s current location. If the robot is sitting in a room with little or no light, the ambient light level would be very low. If the location is well lit, the ambient light level would be high. Using these kinds of reading is rare in an FLL-type event. During most robotic competitions, the robot is trying to detect markings on the game field and not really concerned about the actual room lighting.
Reflective Light
The examples here will be using the Color Sensor to read the reflected light levels, which is the intensity that is returned from the surface that the LED light reflects. On the Color Sensor block, you will want the “Generate light” option enabled. When properly calibrated, the intensity levels will range from 100 to 0, but when you look at the actual uncalibrated values of the Color Sensor, you will see that the range is much smaller, more like 70 to 30. The range is smaller because the Color Sensor can read a much wider spectrum of colors than the human eye can see. So the calibration process puts the values into a range that can be useful. Later, in the “Calibrating the Color Sensor” section, I will describe the process for calibrating the Color Sensor.
Color Mode
As the name implies, the EV3 Color Sensor can not only detect light but the actual color as well. The Color Sensor can read seven different colors: white, brown, black, blue, red, yellow, green, and No Color. This mode is useful when the game field has multiple lines of various colors or scoring elements that are different colors and require sorting.
Positioning the Color Sensor
The location of the Color Sensor on your robot is very important to how well the robot will respond when doing line following, and a great deal of the location choice depends on what type of lines you plan your robot to be following. If the Color Sensor is located close to the pivot point on your robot, as shown in Figure 5-1, the corrections the robot makes will be very drastic on a sharp curve. When using a differential steering robot, recall that the pivot point is the midway point of the track, and the track is the distance between the two drive wheels. Put the sensor close to this point, and the robot will overshoot a curve more quickly and will be forced to make drastic corrections to get back on track, thus making the robot seem very jerky when traveling a curved path. On the other hand, if the robot will be commonly following straight lines, having the Color Sensor close to the pivot point will give a very smooth response.
Figure 5-1. DemoBot with a single Color Sensor mounted close to the pivot point
Of course, the opposite is true for sensors mounted far ahead of the pivot point, as shown in Figure 5-2. This forward location is ideal when following an arc, because the robot can make corrections quickly and will not need to make drastic turns. But when traveling on a straight line, more zigzag motion will be seen because the line detection is more sensitive with the Color Sensor ahead of the pivot point.
Figure 5-2. DemoBot with a single Color Sensor mounted far in front of the pivot point
Keep the Color Sensor position and the consequences of its location in mind when analyzing the game field and putting together your strategy for completing the missions. Test frequently and feel free to move the sensor around on your chassis to find what location works best for your design. Do remember that your sensor may need to be recalibrated after each change since its location can have an effect on the light readings.
Calibrating the Color Sensor
One of the things you learn quickly with using light as an input source is that it varies from place to place. The light in your classroom or basement can be very different from the light where the robotics event is being held. The idea behind calibration is to adjust your sensor to the conditions expected in the room.
Depending on the room, you may only need to calibrate one time in the room in which you will be running your robot, even if you are running it multiple times within the same day. But if the room has light conditions that may change, such as large windows that allow in natural sunlight, you need to think about how that light will be changing throughout the day. You may want to calibrate your EV3 Color Sensors before every run. Proper shielding of your Color Sensors is important for getting consistent Color Sensor readings as well; I will discuss that in later sections.
Don’t start calibrating your sensor until you have them located where you want them on your robot’s chassis, because changing its location on the chassis can affect the values read by the sensor.
Ideally, you’re going to want to keep your EV3 Color Sensor close to the game field; 2 to 3 centimeters is a safe distance, but make sure your robot can clear any obstacles that it may have to climb. You don’t want your robot getting caught on the sensor because of low ground clearance. I’ve even seen robots that raise Color Sensors when more clearance was needed and then lower the sensors when a light reading is needed. Such design is maybe a bit of overengineering for a FIRST LEGO League robot, but they are fun to watch.
Making the Calibration
Now you need to calibrate the sensor so that you can set the real-world values for light and dark. In an ideal environment, the EV3 believes white to be maximum light value returned and black to be the minimum value return. These values are represented in the EV3 code as values between 0 and 100, but rarely will an uncalibrated sensor return either of these two endpoint values. Most of the time, the real values will come back within a range of 30 to 70.
By calibrating the EV3 sensor, you are resetting the limits of the light-reading range based on light readings in the current environment. Also, calibrating the Color Sensor allows the robot to run in different environments without having to actually change the program code to recognize the new room light values.
Note
One year a FIRST LEGO League qualifier was held in an airplane hangar. The location was great, but the lighting was horrible for robots, because every game table in the room had different lighting contrast. This was an excellent opportunity to have a robot that would calibrate its light on each run, and it was too bad our team didn’t have such a calibration plan at the time. We did get lucky with a very good run on a table with some consistent lighting; our other runs of the day were not as impressive.
You can perform the calibration in two ways: using EV3’s own Calibration block that stores the calibrated values in the EV3’s memory or by creating your own calibration program that will store the values locally in a file on the EV3 brick.
Using the EV3 Calibration Block
On the EV3 Color Sensor block there is a Calibrate mode, which is used to calibrate the maximum and minimum levels for the EV3 Color Sensor. The values read by the Calibration block are stored on the EV3 brick and remain there until they are deleted or the sensors are recalibrated, even if the EV3 brick has been turned off.
Note
If you are using two EV3 Color Sensors on your robot, the calibration values stored by the Calibration block will be applied to both sensors; the EV3 brick does not store separate values for each sensor.
To use the Calibration mode, you simply add the Color Sensor block to your EV3 program. Most likely, you would add it in either a separate calibration program or at the beginning of the program you are about to run. If you wish to include calibration in all of your programs and calibrate before each run, creating a My Block with your calibration code would be a good idea.
For example, you could create a My Calibration block; within this block, you would include two Color Sensor blocks, one to read the minimum light value and one to read the maximum light value. Between the two Calibration blocks, you would write a trigger event such as a Wait block. In the example presented in Figure 5-3, the first Calibration block will read the maximum light value and then wait for the EV3 orange button to be pressed before it reads the minimum light value.
Figure 5-3. A simple EV3 calibration program
The logic for the program shown in Figure 5-3 is as follows:
Hold the robot’s Color Sensor over a light area of the field (on a white or very light color), as shown in the left-hand side of Figure 5-4.
Figure 5-4. Calibrating the DemoBot Color Sensor over a light area (left) then over a black line (right)
Press the gray button on the top of the EV3 brick.
Hear the confirmation tone.
Move the robot’s Color Sensor to a dark area of the field (the darker the better), as shown in the right-hand side of Figure 5-4.
Press the gray button on the top of the EV3 brick.
Hear a confirmation tone.
Now you might want to elaborate on the program. For example, you could add some display prompts to let the user know where to place the robot’s Color Sensor and what to do next.
Using a Local File
For various reasons, you might prefer to not use the Calibration block that comes with EV3. For example, perhaps your robot has two Color Sensors, and you wish to store a separate calibration value for each sensor. The solution is to calibrate from values that you store in a file. You can apply separate calibration values to each sensor by creating your own calibration program and then storing the resulting values in a text file on the EV3 brick. You will be able to read that file each time your other programs are run and retrieve the stored light calibration values.
The process of storing and retrieving from a local file is really not as complicated as it sounds and can be made into a really nice program with not too much effort or code. Figure 5-5 shows that instead of using the Color Sensor’s Calibrate mode, the code invokes a Color Sensor block that copies a value from the Intensity value of the Color Sensor block into a text file. If you are using multiple Color Sensors, you could use this same process for each sensor, thus allowing you to have a unique light range for each sensor (again, when using the EV3 Color Sensor block in Calibration mode, the value calibrated is applied to all Color Sensors connected to the EV3 brick).
Figure 5-5. An EV3 calibration program that writes the minimum (top) and maximum (bottom) values to a text file
To use the saved value, you would simply use the File Access block and set the mode to Read, thus allowing you to bring the saved value back into your code for comparison. Figure 5-6 shows a very simple example of this where the Min value is being read back into the program and compared with the Color Sensor on Port 3.
Figure 5-6. An EV3 calibration program that reads the maximum and minimum values from a text file
If you wanted to save values for multiple Color Sensors, you would simply name the files accordingly. For example, it might be a file called MinPort1 and MinPort2 to save values for Color Sensors on ports 1 and 2, respectively. To use the values that you saved, your line-following program first reads the saved values from the files and then calculates the desired light value range. That calculation requires a bit more math for a conditional line-following program but fits right into the proportional line follower that I will discuss in the section on “Line Following.”
Viewing the Calibration
One thing that has confused people about calibration is the process of seeing the newly calibrated values. The EV3 brick has a built-in utility to allow you to view the values of its various sensors, but it always displays the uncalibrated values from the Color Sensor. So if you use the Calibration block and store new calibration values for the EV3 Color Sensor in the EV3 brick’s memory and then use the built-in Color Sensor viewer, you’ll find that it will not show you the newly calibrated values, because it continues to display the original uncalibrated values.
To see the real values, you can write your own Color Sensor value viewer that will show the calibrated values being returned from the Color Sensor. It’s important to know these values so that when you start writing your line-following routines, you will know the proper range values the robot will be attempting to detect.
The program is simple, as shown in Figure 5-7. You create a loop that contains a Color Sensor block and is wired to a Number to Text block. The loop will convert the numeric value returned from the Color Sensor to text so that it can display it on the EV3 screen. The converted value is now passed to the Display block. You would then wait a second and take another reading of the Color Sensor.
Figure 5-7. A calibrated light value viewer to display calibrated Color Sensor values on the EV3 screen
A program like the one shown in Figure 5-7 will be very helpful in figuring out the initial range for your line-following program, when you’re debugging your program, and when you’re simply experimenting with different Color Sensor positions on your robot chassis. For example, you can move the Color Sensor around and get a feel for the difference in light readings based on things such as distance from the game field or even various light sources in your room.
I find it helpful to have such a viewing program running and then shine various light sources at my robot as it sits still on the game field to see what kind of lights have an effect on the reading. Try the lights at various angles too, because many times shadows cause more issues than the light itself.
Deleting Calibration Data
The EV3 Calibration block also has a delete function that will clear out any calibrations currently stored in the EV3 brick’s memory. It could be helpful to clear out such values at the beginning of your calibration process just so you know you’re working with clean values in your EV3 brick, especially if you’re in a classroom where different people are sharing an EV3 brick.
Figure 5-8 shows a basic Calibration deletion program. First, the program waits for the user to press the orange EV3 button and then it deletes the current calibration via the Calibration block. Finally, it plays a confirmation tone.
Figure 5-8. A program to delete the current Color Sensor calibration
Shielding the Color Sensor
Although calibration of your Color Sensors is important, shielding the Color Sensors is just as important, if not more so. The EV3 Color Sensor produces its own source of light via the LED, so outside light is really just a nuisance. Many robots that depend on Color Sensors for navigation work best in a dark room, where the only reflected light they are reading is from the LED on the sensor.
I had one coach tell me that his team’s robot had perfect Color Sensor programming, because it worked just as well with the lights turned off. I hated to tell him that the true test is not removing light sources but adding them. And it’s not so much the extra light that will get you as the shadows cast by the lights.
One year, I held a scrimmage match at my home for a few teams, and we quickly realized that my basement wasn’t going to be big enough to hold the game tables and the teams, so we moved everything outdoors onto the driveway—in the direct sunlight! The shadows cast by the sun as it went behind the trees caused the robots to completely lose control. They were constantly reading shadows as black lines and missing their marks, causing them to make some spectacular crashes on the game field. That scrimmage turned out to be more helpful than we expected, since it showed everyone how sensitive their robots were to the extra lighting. After that day, the teams learned to better shield their Color Sensors from outside light sources.
The main thing to do is keep the Color Sensor low and perpendicular to the game field; having the sensor at an angle will not give you the results you desire. Around 3 centimeters off the game field is a good distance. Don’t get so close that the sensor can’t detect the light, but at the same time, don’t get so far away that outside sources have an effect on your readings.
Build some type of cover for your Color Sensors; this is a great way of preventing interference from outside light. Many teams will mount the sensors under the bulk of the robot chassis to use the actual robot frame itself to block out the room light.
Line Following
Chapter 3 discussed going straight and having a well-tuned robot. I mentioned using the field environment for help in traveling a straight line, such as running along the wall of the field with wall followers. Well, another great way to navigate along the field is to follow any lines that may be present on the field map. For example, the FLL 2009 Smart Move field was a line follower’s dream. There were nice thick black lines that could guide a robot to most of the important places on the field. In fact, those lines were placed specifically to encourage teams to incorporate line following, or at least line detection , in their robot’s logic.
I believe a lot of teams recognize that line following is useful but struggle with how to build and develop a good line-following robot. The code doesn’t have to be scary. Yes, you can have some very complicated line-following logic and use lots of fancy algorithms to keep your robot traveling smoothly, but there are simple solutions as well. I will try to explain some of the different techniques available.
Remember, though, that these are just examples. I encourage your team to use these as a starting point and build on them; see how much better you can make them.
A Dual-State Example
The simplest of line-following programs will be a dual-state program , where the Color Sensor either sees black or white and adjusts accordingly. The robot is not actually trying to follow the line but is trying to find the edge of it. You just need to decide if you wish to follow the left or the right edge of the line. The robot will oscillate back and forth over the line constantly checking for either black or white values; even if the line is straight, the robot will continue to move back and forth searching for the line. The robot is basically looking for two conditions: a light value that is dark or bright. Based on these values, the robot will either go to the right or the left. In other words, the robot is really working in a mode where it has only two conditions (dark or bright) and two actions (turn left or turn right).
This kind of program is a good start for teams just learning about line following and trying to get a grasp on what is going on with the robot and the code. Most advanced teams will use something a bit more complex or at least smoother running. The more the robot oscillates, the slower it will perform. The goal is to follow the line as straight and as fast as possible.
The code for such logic is fairly simple, as shown in Figure 5-9. Let’s assume that our robot is only using one EV3 Color Sensor at this point. This example will have a master loop that runs continuously. In a real-world situation, you would need to include some kind of condition that would break the robot out of this loop, but for this example, having the robot stay in constant line-following mode is fine.
Figure 5-9. A simple line-following program that zigzags back and forth over the line
Let’s assume we have a Switch block that uses a Control type of sensor, and the Sensor will be our Color Sensor. You would need to also configure what port the Color Sensor is connected to on the robot; on DemoBot, the Color Sensor is connected to port 3.
We are going to assume that the robot’s Color Sensor has been calibrated using the calibration block at this point, so our Compare value for the Switch block is going to use 50 as the middle point. If the light value returned is less than 50 (dark), we will turn the robot to the left looking for a value that is greater than 50 (light). You can see that the power settings on the various Motor blocks differ depending on what direction we wish to turn, as discussed in Chapter 4.
Next, we’ll loop back and check the Color Sensor value again. Again, there is no condition in this loop that will allow the robot to go straight; it will always be going to the left or the right.
You will notice that this program is not following the line itself so much as the left edge of the line. If your line has lots of arcs to the right, you might want to switch up the program and follow the right edge of the line instead, since any sudden changes in the direction of the line could cause this simple program to miss the line and send your robot out to Neverland. This type of program works best with lines that stay relatively straight or only curve slightly.
Defining More Than Two States
In the dual-state example, the program only had two conditions to deal with: a light value either greater or less than 50. The problem with that approach is that the robot will tend to overcompensate for changes in the light value. Think of a car traveling down the road and one tire starts to go off the roadway. Turning the car’s steering wheel drastically to the left will bring the car back onto the road but could very well cause the car to lose control and run off the other side of the road. Instead, the driver will gradually turn the car back toward the road and remain in control of the car, since the compensative reaction is in relation to the amount of error that needed to be corrected. We can do the same thing with the LEGO robots by adding more conditions to the switch logic.
Think about the value returned from a calibrated Color Sensor; it will be between 0 and 100. If the value is close to 0, you are going to want to make a more drastic change in the direction compared to a value around 35, where you would need only a slight correction in direction. What you would need to do is divide the possible light range (0–100) into smaller sections.
Let’s create a series of five smaller ranges (numbered 0–4) by dividing 100 by 20; this will give you the new condition values that you will use in the Switch block. I refer to this method as the complex condition method . Table 5-1 shows the code you will use for each state condition.
Table 5-1. Complex State Conditions
Range Value | Action |
|---|---|
0 | Turn sharply to the left; slow down motor B. |
1 | Turn slightly to the left; slow down motor B slightly. |
2 | Stay straight; keep both motors equal. |
3 | Turn slightly to the right; slow down motor C slightly. |
4 | Turn sharply to the right; slow down motor C. |
The example code, as shown in Figure 5-10, will again contain a master loop that runs continuously with a Color Sensor block. The Intensity value from the Color Sensor block will be wired to a Math block, where you will divide the intensity value by 20 and round it off to the closest value. This value will be what you pass to the Switch block. Since it is possible to get a return value of 5 when the light value is higher than 90, you simply just set condition 4 as the default condition on the Switch block, thus forcing condition 5 to implement the same actions as condition 4.
Figure 5-10. A complex condition line-following program with five conditions in the Switch block
Within each condition of the Switch block, the Move blocks are set at various power levels to force the robot to turn in one direction or the other, but when the condition value is 2, both Motor blocks are set to the same power level to allow the robot to travel straight.
Implementing a Proportional Algorithm
If you want to make line following, especially of curved lines, even smoother, you could take the complex state method and break down the Color Sensor Intensity value even more. For example, you could go from five conditional states to ten. Eventually though, you’ll have more conditions than you’ll want to manage in EV3; large Switch blocks can become very clumsy to deal with in the EV3 interface. One solution is to implement a proportional algorithm .
Whenever you start talking to anyone about robotics and line following, the term PID will come up, which stands for proportional, integral, and derivative. But most LEGO EV3 programs that people claim are PID are really just proportional. For EV3, a proportional type of program is very doable, while a full PID program is a bit much for such a simple programming language (but I’m sure someone, somewhere, has implemented the PID approach in EV3).
A proportional system uses a bit of math to calculate the amount of correction that is needed to get the robot back on the line that it is following. Instead of using a set value to correct the direction of the robot, you actually calculate the direction change based on the value read by the Color Sensor. If the error value is small, the robot corrects very slightly, whereas a larger value results in a stronger correction.
Let’s begin with an example of a proportional EV3 by creating the Variable blocks as described in Table 5-2.
Table 5-2. Variable Definitions Used in the Proportional Line-Following Program
Variable | Description |
|---|---|
MidRange | This value will be the middle value between the minimum and maximum light readings. If the Color Sensor is calibrated with a minimum value of 0 and maximum of 100, the MidRange will be 50. |
Gain | The Gain variable will be used to fine tune the error correction. If the robot is zigzagging too much, you set Gain to a value less than 1. If the robot is not responding fast enough, you set Gain a bit higher to adjust the correction. |
Power | The Power variable determines the power level that the robot will travel at when going straight, and this value should be adjusted between 30 and 70, depending on your robot’s design. Be careful not to set the value too high, or the robot might miss the line. |
Error | The Error variable is calculated by subtracting the MidRange variable from the Intensity light value, and it will be used when you set the correction to the robot’s motors. |
Correction | The Correction variable will be the Gain applied to the Error amount. This will give you the difference you need to apply to the Power variable, which is then applied to the motors. |
Now the logic in this code is fairly simple, as shown in Figure 5-10. First, you calculate the Error value by subtracting the MidRange value from the Intensity value returned from the Color Sensor. Next, you calculate the Correction value by multiplying the calculated Error by Gain. The Correction value will be applied to the Power value and then passed to the Motor block. The trick is to invert the value between the two motors, so for Motor block B, you would add the Correction to the Power, and for Motor block C, you would subtract the Correction from the Power. Figure 5-11 shows this logic put into an EV3 program. Remember that different robot designs will require some adjustments to the Power, Gain, and MidRange depending on your robot’s response.
Figure 5-11. The proportional line-following program does not use a Switch block and instead calculates the nessary power to drive the motors and keep the robot on the line
Using Dual Color Sensors
The examples so far have all dealt with robots using a single Color Sensor to detect the edge of the line your robot is following. But what if you added a second Color Sensor and straddled the line? The FIRST LEGO League rules do allow for two Color Sensors, even though none of the LEGO MINDSTORMS kits include a second sensor (you can purchase a second sensor separately if desired).
When you have two Color Sensors, you are going to want them to be spaced on your robot just a bit wider than the line you will be trying to follow. Set them too close together and you’ll never get a valid state for going straight; too far apart and you will find your robot overcompensating for direction changes when it hits the line. Ideally, neither sensor will see the line when the robot is centered over the line; they should only see the area next to the line. Figure 5-12 shows the DemoBot with two Color Sensors installed.
Figure 5-12. A complex condition line-following program for dual Color Sensors, with a Switch block for each Color Sensor and only three conditions
If you wanted to use the complex state method I mentioned earlier, you would simply add a second Switch block, so there’s one for each Color Sensor, and each Switch block would now only have five conditions, as shown in Table 5-3.
Table 5-3. Complex State Conditions for Robots with Dual Color Sensors
Color Sensor | Range Value | Action |
|---|---|---|
Left | 0 | Turn sharply to the left; slow down motor B. |
Left | 1 | Turn slightly to the left; slow down motor B slightly. |
Right and Left | 2 | Stay straight; keep both motors equal. |
Right | 1 | Turn slightly to the right; slow down motor C slightly. |
Right | 0 | Turn sharply to the right, slow down motor C. |
Both Color Sensors need to start off straddling the line. If the robot gets into a position in which both Color Sensors see black, the robot will simply slow down. That’s because the conditional switches would slow down both motors and thus try to force the robot to turn in both directions at once. This can happen when a robot leaves base expecting a line to follow just outside of base and it detects the border around the base. To remedy this, either a delay needs to be added to the program when leaving base to prevent line detection, or you just allow the robot to slow down when it first detects the border then speed up again after it is past the border. Figure 5-13 shows an example of how you could write dual Color Sensor logic in EV3.
Figure 5-13. DemoBot with dual Color Sensors installed
Line Detection
The lines on a game field can serve other uses for navigation besides line following. Various areas on a game field often are outlined by a line of some sort. The outline might not even be a true line, just a shape or an image of some sort. These graphics are still important and can be very helpful when trying to determine if a robot is in the right location. Also, be aware that these lines might not be simple black lines; many times, they will be colored lines and require a bit more effort to detect properly with an EV3 Color Sensor.
In the game field for FLL’s 2008 Climate Connections (see Figure 5-14), parts of the field were outlined with various colored lines. These were very useful when trying to navigate to a given area to perform a task. What made them tricky to use was the fact that they were colored lines. Also, you had to cross over a large rainbow printed on the mat. The solution wasn’t as simple as driving forward until encountering, say, a red line. You had to time when your robot would begin looking at the correct red line and move past the rainbow, or you had to count how many red lines you encountered.
Figure 5-14. The 2008 FLL Climate Connections field mat
First, I’ll discuss some general ideas on finding lines. Then I’ll explain how color lines appear to an EV3 Color Sensor.
Finding a Line
If you take a look at the 2008 FIRST LEGO League Climate Connections field mat, as shown in Figure 5-14, you will see that it doesn’t have a lot of lines that would be helpful for line following. However, there are lots of thick lines that either outline or could guide a robot to a particular location on the field. These lines aren’t there just to look pretty. They are there for you to use to help your robot navigate to particular locations. In the middle of the field, you will see a lot of open space, and it would be very easy for your robot to get lost in this space. Having the borders enables you to better program your robot to detect when it has reached a location that you are targeting.
Say, for example, your robot leaves base and is heading to the location I’ve marked as Zone A in Figure 5-14. After the robot leaves base, it will be very dependent on odometry to find its way across the field. During this time, it should start looking for the thick black border around Zone A using its Color Sensor. You will have to be careful that the other colors on the field don’t confuse your robot. In real life, that rainbow at the bottom of Figure 5-14 tripped up many robots. You need to think, when planning the task for your missions, about what things can be in your way. What other markings on the mat can confuse your robot?
Now let’s look at the FIRST LEGO League 2015 Trash Trek field mat, as shown in Figure 5-15. It was very different from the 2008 Climate Connections mat in that it had much better-defined zones with easy-to-track borders. There were a few black lines that you could use for line following plus they were great for breaking up the different areas of the mat, giving your robot quick feedback for where it was located currently on the field. Notice the two obvious black lines crossing the robot’s path as it leaves base heading east. Counting these lines is a great way to help the robot learn where it is located.
Figure 5-15. The 2015 FIRST LEGO League Trash Trek field mat
When you count lines, remember that you cannot just count how many times your Color Sensor sees a black line, because as a Color Sensor travels over a line, it will read it multiple times. You will have to include edge-detection logic in your code, along the following lines:
Look for a black line, or rather a black reading.
Increment a counter when black is encountered.
Begin looking for a transition to white (i.e., for a white reading).
Go back to step 1 when white is encountered.
Once you find white, start looking for black again; this process would continue for however many lines you’re expecting to encounter. Figure 5-16 presents an example of what such code would look like in EV3.
Figure 5-16. An EV3 line-counter program
In this EV3 line-counter code, the robot runs forward and waits for the Color Sensor block to detect a black line. Then, the next Color Sensor block will wait to find the next non-black area, letting you know that it has completely crossed the black line. When the loop counter reaches three, this Loop block exits and the Move block at the end will stop the robot.
Detecting Color in Lines
You will notice that, on the field mats in Figures 5-14 and 5-15, many of the lines or areas are not simple black-and-white lines; actually, many of them are colored lines or edges. When you are thinking through your strategies for navigating a game field, look for colors that contrast more drastically with other colors to help avoid confusion and make finding the navigation points easier. Thick lines are, of course, going to make better markers than thin or fuzzy lines and edges. You are really looking for anything unique that can produce consistent readings back to your program. Consistent markings are going to produce consistent results.
Summary
Color Sensors are one of the most helpful sensors when trying to navigate most robotics game fields. In FLL the game field maps are full of clues that can be utilized by Color Sensors. Many teams will shy away from using them just because there is a bit of a learning curve when first using them. But almost all winning teams have taken advantage of Color Sensors when navigating the game fields.