How to check for a sharp angle with a line follower?

Question

I have the mBot robot and I want to program it to follow the line. So far it can pass any kind of line that is >90°.

I want it to be able to pass 90°-ish angles as well. Like this one:

The problem is that my mBot robot has only 2 line following sensors (they are 5 mm apart and the line is 2 cm wide) so I can't use just the sensors.

Most of the times it just goes to the line and when it's supposed to turn it just misses the line (goes on the white) and goes back to get back on track. Once it's back on the black line it once again tries to go forward but goes on the white instead of taking a turn. This happens endlessly.

Sometimes it passes the angle by going back and forth and accidentally turning, but that's not even a workaround, let alone a solution.

Here's a test course of the first round of the competition.

My robot can pass this without a problem, but it gets stuck on this (poorly edited, sorry) course:

It can't pass the 20 block if the robot enters it from a 15 or 20 block (so basically it gets stuck if it's coming from an angle and hits a 90 degree turn).

The sensor value could be read as either 0, 1, 2 or 3 depending on what the robot currently sees:

0 - on the line
1 - on the right of the line
2 - on the left of the line
3 - not on the line

Pseudo code of my current program:

loop forever:
    if (on the right of the line):
        turn_left()
    if (on the left of the line):
        turn_right()
    if (on the line):
        go_forward()
    if (not on the line):
        go_backwards()

So how would I go about taking such sharp turns?

Answer 1

It can't pass the 20 block if the robot enters it from a 15 or 20 block (so basically it gets stuck if it's coming from an angle and hits a 90 degree turn).

Somehow coming from an angled line makes it more likely that your robot moves orthogonal to the 90°-ish turn, so that it gets stuck in the back-and-forth loop. Maybe if it moved very slowly backwards it could detect the moment when only one sensor goes on, which would lead to a turn. But it's a competition after all, so let's not move backwards, especially not very slowly.

I'm not sure if the image of the different sensor values is accurate in terms of scale. It looks like the line is not much thicker than the two sensors are apart. Now imagine the edge case that both distances were the same: the sensors are as far apart as the line is thick. In this case, the robot can only really move in the exact direction of the line. This is very bad for a 90°-ish turn for the reason mentioned above. The ratio between sensor distance and line thickness seems to play a role in how the robot behaves. You cannot change anything about the thickness of the line or the distance of the sensors, but I think it's important to think about what impact those values have or at least could have.

What you can change though is what you consider to be the line. You can follow a line by following its edge, too. The code could look like this:

loop forever:
    if (on the right of the line):
        turn_left()
    if (on the left of the line):
        go_forward()
    if (on the line):
        turn_left()
    if (not on the line):
        turn_right()

As the edge is only a line, the behaviour depends more or less only on the distance of the sensors, not the ratio between the distance of the sensors and the thickness of the line. I'd give it a go and see how the behaviour changes.

A ratio that you can change more continuously is that of the velocities. How many degrees is turn_left() and how many millimetres is go_forward()? Playing around with those values will lead to different, possibly more preferable behaviour of the robot.

---

theory interlude

In a nutshell, you want to control a system with two inputs: angular and radial velocity. Setting either one will influence the other. In your case, the radial velocity control loop freaked out and became unstable: back-and-forth motion forever. The important thing is that the system should have reacted with a large increase in angular velocity (to do the hard 90°-ish turn), but instead the radial velocity went mad.

This is a sign that the interaction between the two is not well controlled and requires further investigation.

Changing the ratio between both velocities essentially modifies the gains of the controllers. Lowering both velocities means more sensor readings per travelled distance and thus a higher sampling rate, which in general leads to more stable systems.

---

tl,dr;

Things to try

1. Change both angular and radial velocities, but keep their ratio the same and see if that changes anything
2. Change the ratio between the two and see if that changes the behaviour of the robot. Especially on different types of tiles. What ratio works best on straight tiles, what works better on curvy tiles. Is there some setting that works for both?
3. Try both 1. and 2. for the on-the-line approach and the on-the-edge-of-the-line approach and see if you get to different results.

Answer 2

Sorry I have no experience of line following robots, I use ultrasonic sensors, so this answer may be a bit naïve and there allsorts of reasons why you can't do this.

Your bot travels forwards and realises it has lost the line. Assuming that the distance travelled is not "very far", less than 1/2 the length of the bot, you should be able to do a complete 360 and find two lines. One of those lines will be at about 180 degrees from where you started turning (this should be measurable by the number of turns of the motor, if its a stepper), this is not the line you are looking for, you need to follow the other one.

Does that help?

Answer 3

I have a similar idea like @Bending Unit 22, which is not to follow the line but its edge instead. So you detect the line only with one sensor (let's say only with the left one (blue dot)).

• If the you both sensor indicates line then your robot should turn right until the right sensor (green dot) indicates white surface. This is the event circled with green in the image below.

• If both sensor are lost sight of the line, then the robot should turn left until the left sensor is back on the track. This is the event circled with blue in the image below.

Basically, there could be two states of line-following:

1. Default state when the robot has one sensor on the line while the other is off the line.
2. Turning state if one of the events occur. The robot could stop and turn until the the left sensor gets back on line or till the right leaves the line. Since we can assume that the direction is known and the robot is not moving, we could turn on maximum speed (or at least you can try and see how it works). You can test it while the robot is in motion of course.

Previously, when your robot lost the line there was no information about the direction, so it could only go backwards hoping to find the line.

It is only a theory but I think it's worth a try or just to move forward your project.

You have mentioned that your cannot use more sensors but are you allowed to modify on the current hardware?

I have checked that the sensors have digital output which means [line] - [no line], not much information. But if you could connect the IR-sensors output voltage to some analog pins, this way you could obtain higher resolution.

To explain further this part:

A basic line detecting sensor is a IR photo-diode and photo-transistor pair. Like the one on your robot only it has a little bit more on the module, a newer version from Makeblock's page:

(Module on left, actual sensor on the right) Your robot has a previous version, which probably uses an other sensor. This one in the image is a TCRT500 from Vishay.

If we have a look at the schematic level:

The output is at the red circle. Now, if there is sufficient reflected IR light the transistor will conduct and the output will be pulled down to GND. If there is not enough reflected IR light, the transistor won't conduct and the output is pulled up through the resistor to supply voltage. But it is not working like a switch, so the out can be anything between 0 - V_Supply. For a given spectral distribution (IR in our case), the photo-current is linearly proportional to the illuminance . So as I said the output voltage can vary between 0 V and VCC (5 V in common).

Your sensor module works the same way, only it has a comparator on it which makes digital output of the analog signal.

When the IR LED illuminates the edge of the line, maybe half of the light is reflected or more, so the transistor can conduct slightly. This means that the output won't be pulled down near 0 V, it will be, let's say around 2 V. But not 0 V (which is the complete white surface), and this is the important because this means that it partly detects something (the line).

Now back to the comparator, it compares the output voltage of the photo-transistor to a reference voltage. It checks if the signal is above or below the reference and sets its output to LOW or HIGH accordingly.

If this the reference is 2.5 V then your module will say that it detects line when the output voltage is above 2.5V, so that information with the 2 V signal will be considered as a white surface where as we saw the edge, thus we lose resolution.

Now, if you could read this whole analog range with an ADC your resolution would be higher and maybe a more delicate controlling algorithm could be achieved.

Answer 4

The problem seems to be that your robot functions by moving its sensors perpendicular to the line; when the line becomes perpendicular to itself, the robot loses the assumption that lateral movement will bring the line back into the center of the sensors.

The only way to fix is this is to change the sensor configuration (adding more if necessary) to break this ambiguity.

Answer 5

In my configuration I have a PID algorithm for the main following mechanism. Then I have a separate routine to move into if The car ever goes off the line and all 6 sensors are sensing white. This tells the car to turn the direction that it saw the line last. This seems to work up to 45 degree turns for me.

Answer 6

It seems that you can have 4 possible readings (w,w), (w,b), (b,w) and (b,b). So, the program what to decide what to do in each situation. To help figure out the next action, the past history can also be used. So, it is up to you to decide how much history is useful, or practical. I suggest some kind of state diagram, but use whatever you are already familiar with.

Now, in your pseudocode, how much do you turn left and right? How far are you moving between each reading? Can you measure how far each wheel has gone?Is it possible to go backwards until line is found? How straight are your moves forward and backward? These questions are just some of the considerations for you to think about as you refine your strategy.

The bottom line is that the dual sensor does not provide enough data from a single reading, to, for example, identify whether you've just run over the edge of a straight line, the line has bent, or (if it has bent) by how much!

The whole point of a line robot competition is to get each builder to design (and test) their strategy.