Should I use Line Tracker?

Hello. My team is thinking on using a Line Tracker. What do you guys think are the pros and cons?

Is this for IQ or VRC?

This is for VRC. If we put it on our robot, we plan to compete with it

What do you plan on achieving? I say it’s not a terrible idea for following the line on the home row accurately (easy work around for gained accuracy instead of using just encoders). For a beginner team, I’d say go for it if you have the spare ports.

Line trackers could also be used to detect if there is a ball in any of your subsystems as long as it’s close enough to the object to detect a change in light. It’s not accurate enough to detect the color of the ball (at least not consistently or without some kind of advanced filter).


We plan to use the line tracker in our home row autonomous to track the white tape.

That would be a good implementation of a line tracker, there are basically no downsides to adding it, only downside would be ports. using up ports that could be used for something else like quad encoder odometry system, but that is advanced. if you have ports its a good idea and you could use a line tracker on the left side of the chassis and another one on the right side to make sure you are straight on with the line


You’re gonna need 3 line trackers in that case. A simple bang-bang controller could get this to work, though it needs to be tuned properly or else you’ll have a very jittery robot.



Check this out! Apparently VEXForum is in second place for googling “bang bang controller”!



Weird way of telling everyone that you don’t know what a bang-bang controller is, but alright


I’m not very surprised considering this is a program designed for beginner engineers and bang-bang is primarily used by beginners because it’s simple to code.


It’s also probably because the forums is related to searches you’ve made before

It’s actually used on a number of systems that move slowly and don’t want to turn off / on a lot.

Heating systems usually use bang bang. AC might also be bang bang.


What I am most concerned with using a line tracker is that I might need to change its thresholds and return values every time there is different lighting

To fix thst problem you can have it at the start of the match record what a no ball would be like to help then from there you can just set a standard of how big the difference between a ball there a no ball is. I have something like that but haven’t been able to test it yet

1 Like

Thanks. that might work.

Some code I wrote a few years ago to explain auto calibrating line sensors.

You run a calibration task before match starts, and swipe the robot across a black line, this way the robot can store each sensors maximum and minimum seen value.

With the modern programming environments in C++ I would have done a lot of this with a wrapper class around the line sensor. This simple example however does a good job of doing everything out in the open where everyone can follow.


So what is the purpose of finding the percentage of usable max/min values compared to the theoretical limits? Is that percentage used in a further calculation down the line?

You calibrate them to the light you expect to see in this run. That way brighter fields vs darker fields look the same, because grey is still 50% between white and black regardless of the absolute light coming into the sensor.

Also all sensors are in theory a bit different so the calibration helps make all of your sensors read much more similarly.

If you watch the first 10 seconds of this video

you can see they are all doing a sweep over the line. They turn 90 degrees left and 90 degrees right so the sensors have seen the full range of white to black. That way the robot knows what white and black look like TODAY, given ambient light in the room, sensor height on the robot, hell even heat of the sensor. Then you normalize the units so that to the line following algorithm its just considering how far between white and black it is sensing.