IDP: Line-following
Introduction
Simple line following might be possible with a rather simple program - see Building an easy Line Follower Robot using Arduino Uno for example - but in real life things are rarely simple. In the IDP experiment failure to follow the lines is a common cause of disaster. These notes aim to point out some strategies and difficulties. Some of the strategies might be beyond the scope of the experiment, and some of the questions might be paranoiac - it's up to you to decide.
To successfully follow lines you'll need to worry about sensors, decision-making and control. You'll need
- good information from the sensors - it needs to be detailed and
timely. How many sensors do you need? Where should they be placed? Will they
always stay the same distance from the ground?
Will they be able to tell you not only which side of the line
the sensors are, but how far from the line they are, and the robot's
orientation? How will junctions be detected?
You can make the sensors return a single-bit value or a number in the range 0-255. The advantage of the former is that you can read all the sensor values using a single request command, which will be faster than having to make a request for each sensor value - the more sensor readings performed per second, the more responsive the robot can be. - to decide what to do - given perfect information will you make the right choice? How will you respond to incomplete information or no information? Is it necessary to know about the robot's previous state?
- to react correctly - once you'll decided what to do, will the robot be able to execute the required action precisely and in good time?
Decide where line-following needs to be precise - are there narrow gaps to go through? Does delivery/pick-up require precise alignment? Could you change the general strategy to make line-following easier?
Sensors
Knowing how far from the line the sensor is lets the robot take actions that are proportional to the distance (or angle) between the robot and the line, resulting in a smoother turn. The closer the sensors are to each other, the better the resolution.
In general, It is important to always try to keep the sensor as far ahead as possible from the center of steering because this will also help to amplify the deviation detected by the sensor, resulting in a better response. Suppose your line sensors only told you that you were off the line when you were 3mm off. If the sensors are 20cm in front of the pivot-point of your steering (typically the centre of the drive axle), this is an angular deviation of about 1 degree, which can be smoothly corrected. If the sensors are only 2cm in front of the drive axle, the deviation is more like 10 degrees, resulting in jerky line-following.
Putting the sensors on (or behind) the drive axle, or driving in reverse, is asking for trouble.
In practice, due to the non-linearity of the behavior of DC motors, and many others sources of error that cannot be clearly defined, the robot is still likely to oscillate while trying to track the line, and might sometimes fail because the errors eventually increase instead of decreasing.
Following a straight line
3 sensors
Suppose you had 3 sensors positioned so that when the robot was exactly on the line the situation was like this
Suppose each sensor returned a 0 (off) or a 1 (on) and that the robot's supposed to be going up the page. In the situation above, the state of the sensors would be 010 and you'd like the robot to continue going straight. If the outer sensors are too close to the line, sensors will read 010 only if the alignment is perfect.
What happens if the sensors returned 011? The right-most 2 sensors are over the white line which suggests that the robot needs to go right, but how quickly? In the following situation
the robot is aligned correctly and a gentle correction should soon lead to the sensors returning 010 if the outer sensors aren't too close to each other. A violent lurch would result in the robot oscillating widely along the line, but in the following situation
too gentle a response might lead to a 000 situation. A less gentle response might still produce a worse (001) situation before things improve.
Note that if the sensors are reading 011 the situation might not be as in the 2nd diagram; the actual situation might be
i.e the robot's pointing in the wrong direction (it happens!). If there are junctions on the table there will be even more possibilities. So don't make too many assumptions when interpreting the sensor values without historical information. Your robot might be lost, drifting around the table, or the sun might have come out, upsetting the light levels.
2 sensors straddling the line
With 2 sensors, things are trickier. You could arrange them so that they're both just off the line when aligned
When the sensors read 0 1, the situation could be like this.
You'd like to turn right until the sensors straddle the line again (i.e. both sensors read black). However, if you turn slowly both sensors will end up on the left of the line, both reading black (i.e. the same state they're in when the line's correctly being followed) at which point the robot might continue on its bearing away from the line.
2 sensors just inside the line
Is it any better to have the 2 sensors closer to each other so that they're just on the line rather that just off it? That has problems too. Suppose the robot was veering off the line so that one of its sensors read black, and suppose that as it began to do this it came to a crossroads that it's supposed to go straight through (again, assume the robot's going up the screen).
It would try to correct. Maybe it will straighten up enough to reach the following situation.
What happens next? When the sensor that's on black reaches the transverse white line, both sensors will read white and the robot will think it's back on track. It might then continue on its current bearing until it reaches the following situation.
The right sensor's reading black, which will make the robot think it needs to correct by veering left. Ooops!
However many sensors you use, you need to consider what to do when the sensors return to a state that suggests that the robot's back on the line. Do you want the robot to go straight? The robot may well be at an angle to the line, so going straight will lead off the line again. If your robot arrives at an angle, the sensors will start reading white at different times, so perhaps you could exploit that information.
Junction detection
If you have the junction detectors level with the axis of robot rotation, your robot can stop and turn as soon as it's at a junction. If your detectors are at the front and your drive axis at the back, then the robot will have to move forward after the junction's been detected. How will it know whether it's moved forwards enough?
Turning
When you try to perform a 90 degree turn, how will you know when you've turned enough? You could do it by timing, or reading the sensors, or a combination of both. If you use only the sensors, problems can arise when there are many lines on the table.
Control
How often should you read the sensors? How often should you send commands to the robot? Will errors in the execution accumulate? When you're correcting, should the difference between the two engine speeds always be the same? What could you make it depend on?
Optimising
Once your robot follows lines, you may wish to improve its performance or reliability. Ways to improve include
- Increasing the maximum possible speed (you can slow down as you approach difficult situations).
- Adding more intermediate cases, with intermediate speed settings to make the motion less jerky.
- Giving your robot a memory: have its maximum speed increase after it has been on the line consistently for a few cycles.
- Take short cuts.
Disaster Recovery
It's not unusual for 10% of IDP robots to completely succeed, 10% to completely fail (i.e. not get out of the start box), and 30% to be seriously compromised by their line-following ability (15% wandering off a line at 45 degrees, or going in a circle). Be prepared for disaster. If your robot's lost, will it just stop and feel sorry for itself or will it at least try to recover? Options might include
- Giving your robot a means to recover from disaster - a map of the table; an estimate of global position, a method to search the locality for a line, a way to undo the motor commands until the robot returns to a known state, a means of knowing as soon as possible when an expected milestone has been missed (the earlier you know, the easier it is to recover) etc.
- Adding ways to deal with read errors or very slow response times - fallback strategies