Line Tracking Trouble

VEX V5 Technical Support UNOFFICIAL Tech Support
1

Hey. I found out how to program the line tracking sensors. Now, what happens if the robot gets off the line? I am trying to figure out different ways for the robot to fix itself but I can’t seem to find the answer:confused:. Can someone please take a look at the code so far and add in whatever might work so I could get an idea of what to program? Thanks!!!

#pragma config(Sensor, in1, lineFollowerLEFT, sensorLineFollower)
#pragma config(Sensor, in2, lineFollowerCENTER, sensorLineFollower)
#pragma config(Sensor, in3, lineFollowerRIGHT, sensorLineFollower)
#pragma config(Motor, port2, leftMotor, tmotorServoContinuousRotation, openLoop)
#pragma config(Motor, port3, rightMotor, tmotorServoContinuousRotation, openLoop, reversed)
//!!Code automatically generated by ‘ROBOTC’ configuration wizard !!//

task main()
{
wait1Msec(2000);

int threshold = 1500;

while (1 == 1)
{
displayLCDCenteredString(0, “LEFT CNTR RGHT”);
displayLCDNumber(1, 0, SensorValue(lineFollowerLEFT), 4);
displayLCDNumber(1, 6, SensorValue(lineFollowerCENTER), 4);
displayLCDNumber(1, 12, SensorValue(lineFollowerRIGHT), 4);

if(SensorValue(lineFollowerLEFT) > threshold)
{
  motor[leftMotor] = 63;
  motor[rightMotor] = 0;
}

if(SensorValue(lineFollowerCENTER) > threshold)
{
  motor[leftMotor] = 63;
  motor[rightMotor] = 63;
}

if(SensorValue(lineFollowerRIGHT) > threshold)
{
  motor[leftMotor] = 0;
  motor[rightMotor] = 63;
}

}
}

2

Keep in mind that this code is only the very basic intro into line following. If you need better accuracy, you will have to use a better control loop, like a P or PID loop. You can find good examples of both if you search around on the VEX and ROBOTC forums. Now what do you mean “the robot gets off the line”? If it’s pushed off, it’s going to be difficult to find the line with just line sensors since you don’t know how the robot’s been pushed, if it turned…ect. The best you can do with line sensors is see which side and direction the line left your “vision” at (which sensors last saw the line, how fast was it moving…ect). If you mean that the robot loses the line on it’s own, then my answer is that a good line tracking algorithm should not result in that happening. A bit of a non-answer, I know, but I’ve seen robots with algorithms good enough to drift around 90 degree angles.

3

Well, under what ciscumstances would the robot go off the line? If you’re using three sensors, the only reason that I can think of why your robot would be taken off the line is because you crash with another robot OR your purposefully take yourself off the line.

When you crash, IMO, it’s autonomous over. It’s near impossible to autonomously recover from a crash.

If you take the robot of the line purposefully, then you’re going to need more sensors that let you know where the robot is. (Sonar, light, etc.)

  • Sunny G.
4

What you could do is have the robot spin in place if it loses the line (until it finds the line again), it may or may not work depending on the specifics of how the line was lost in the first place. Worse, you may end up going back the way you came if the 'bot completes more than half a turn before finding the line.

5

I see you have LCD module code in your mainline while loop.
This may cause poor performance. Search the forum for posts by jpearman about the lcd module to see some reasons why.

You could try putting the LCD output in a lower priority task running at a 200ms interval, while the main while(1) loop runs as fast as possible.

If you are using a Cortex (and not a PIC), you may also get better performance by using motor ports 1 and 10 (direct 2 wires ports), as jpearman reports that these have much faster reaction times (1-2ms) than the 3 wire motor ports (5-40ms in theory).

A fast control loop is like driving a car with your eyes open.
Between the LCD and the motor ports2,3, the
slow control loop is like driving a car by sitting in the passenger seat and looking out the window once every 5 seconds, then telling the blind driver to go straight, right, or left;

I’m looking at some NatCar youtube videos, with a ~300 foot line following course with winning speeds > 8 fps, for college student built robots, mostly based on 1/10th scale RC touring cars, with ackerman servo steering rather than differential drive.

6

Did I say that? We had a thread going about the LCD in EasyC but I don’t remember anything about ROBOTC.

My understanding is that sending text to the LCD in ROBOTC does not use many cpu cycles. I have not specifically tested displayLCDNumber that the OP is using (I normally use sprintf followed by displayLCDString) but my understanding is that all these functions do is put the text into an internal buffer that is constantly being sent to the display at about 60Hz.

EasyC on the other hand has a significant delay in the code that sends the message to the LCD, it was somewhere around 20mS before they fixed the last bug, it may be more now.

However I do agree with this, it’s good idea to put LCD display code in a low priority task if that fits well with the overall design of the software.

This is also true but may not make much difference in practice, do your own tests and decide.