The next step or iteration in our evolution of Controller involves sweeping for the path. This is motivated by an analysis of the objectives for the Line-follower robot outlined in Chapter 8, The Line-follower Robot. Imagine the robot starting off on a straight-line segment of the path. In the previous iteration, when the program was executed, the robot would move along the segment and come to a stop at its end.
In a realistic path, the end of one segment is connected to the start of the next one, the two making an angle with each other. The robot is tasked with discovering this new segment and then moving along it. To do so, it will have to turn in place searching (sweeping) for the path.
We start with a simplistic and partial implementation of this functionality. To test it, we keep only a single segment in the path and we want the robot to come to the end of the segment, sweep around and reacquire it (now facing in the exact opposite direction), and follow the segment back to its start before coming to rest.
The functionality described previously is achieved by making the following changes to the Controller class. We add a sweepClockwise() method:
private boolean sweepClockwise()
{
log("Sweeping clockwise");
int count = 0;
drive.rotateClockwise();
while (! sensor.onPath())
{
count++;
delay();
}
log("Delay Count: " + count);
drive.stop();
return true;
}The purpose of the
sweepClockwise() method is to rotate the robot (in place) in the clockwise direction until it acquires (detects) the path. Since this is the first implementation of such a mechanism, we add some additional logic to it for diagnostic purposes. The second statement (after the initial log) is one such which declares the count integer variable int count = 0; and sets its value to 0.
The next statement is drive.rotateClockwise(); instructs differential drive to start rotating the robot in the clockwise direction. This is followed by a while loop, which analogous to the move() method loops until the path is detected.
Inside the body of the while loop, we have the usual call to delay() to pause execution for 50 milliseconds. Along with it, we have the postincrement statement count++;, which basically increases the value stored in the count variable by one on each iteration of the loop. When the while loop finally terminates, the value of count is equal to the number of times the loop iterated. This is a very standard technique to determine how many times an indefinite loop iterates.
After the while loop terminates (because color sensor has detected the path), we log the value of the count variable, stop the motor, and return a value of true. This method has been defined to return a Boolean value in anticipation of future use where the path may not be found, and this eventuality will need to be communicated to the calling method. A returned value of true indicates that the path was indeed found while sweeping in the clockwise direction.
The sweepClockwise() method is in turn called by the new seek() method:
private boolean seek()
{
log("Seeking Path.");
return sweepClockwise();
}The seek() method is, for now, simply a wrapper around the sweepClockwise() method. Eventually, it will perform a limited seek in both directions but for now it simply calls sweepClockwise() and returns what it returns, which is always true.
Finally, we place a call to the seek() method inside the run() method:
public void run()
{
log("Starting controller");
move();
seek();
move();
end();
}In this iteration of Controller, two additional statements are added to the run() method after the first call to move().
To test this iteration, simply compile and transfer this code to EV3 and then execute it. If the Line-follower robot is set up at the start of the segment, the first move() call (inside the run() method) will make it move along the segment until it ends.
At this point, the move() method will return execution and it will move on to the next statement, which is seek(). This will in turn call sweepClockwise(), which will cause the robot to pivot (turn in place) in the clockwise direction. This turn will stop when the robot comes across the segment again but is pointed in the directly opposite direction (back where it came from).
The sweepClockwise() and seek() methods will both return true and execution will reach the last move() method, which will cause the robot to start moving back along the segment until it ends (right where the robot started).
Note
Note that while testing this iteration on my EV3, a close monitoring of the log revealed that for the 180 degree about turn, the value of count was 100. So, 100 delays are equivalent to 180 degrees of rotation. You will have to determine this number for your own robot. This piece of information will be useful later on.
Testing this iteration of Controller may raise a number of issues in this approach; I know that it did for me. This is a normal part of software development. You analyze a problem, come up with a first attempt at a solution, implement it, test it, and immediately discover a number of issues. This, in turn, directs you towards your next attempt at the solution.
The issues that I came across included the robot getting off the path before the segment ends because of some imperfection in the path, surface, or alignment of the robot. As it is currently programmed, this immediately triggers a seek (a clockwise sweep) for the path and the robot never makes it to the end of the segment.
Another issue is that at the end of the segment, the robot stops the instant color sensor clears the path. Since the sensor is at the head of the robot, this means that the robot stops with most of its body still on (and aligned with) the current segment. The subsequent seek rotates the robot in place, which swings the sensor from just near the end of the segment to a point significantly away from that end. This means that when the new segment is acquired via rotation, the robot will not be aligned along it since the head of the robot and not its center is at the intersection of the segments. The robot will end up aligned along neither the current nor the new segment.
The final issue is actually because of the way the seek is programmed. In its final version, the robot should never rotate by 180 degrees because we do not want it to detect the segment it is currently on but in the opposite direction. If that were the case, the robot will constantly keep moving back and forth along the path, swinging around at either end. We want to implement some mechanism to limit the rotation of the robot.
The following sections of this chapter will fix these issues and with each iteration of the Controller, we will come closer to the final form of the Line-follower robot.