How do you program your robot to follow the white line that leads to the ball release. My team wants it as a backup in case the tracker doesn’t work, but i don’t have a clue how to program it… Can someone help me???please???
i did do that none had any examples of code for the line follower, I really did not want to look through all of them but i have and still nothing can you please help me???
following the line would be difficult, because of the two 45° turns that it takes
your bot will end up being pretty slow if thats the way you find the release ball.
I realize that but we want it only as a back up in case something screws up in the ir tracker. So can you please help me???
I dont have any code that you can cut and paste
but the algorythm is pretty simple if you have two sensors on your bot
you would put them on either side of the line, tell your bot to normally go straight ahead at a relatively slow speed.
then if the left sensor sees the line, turn towards the left
if the right sensor sees the line, turn towards the right
if neither sensor sees the line, go straight ahead.
you will have to test the code on your bot with the sensors and adjust how fast the bot moves forwards, and how hard it turns when it sees the line. You might also need to tell it to stop moving forward when its turning.
thats the simple version of it.
If you mount 3 sensors it’s easier.
if left only sees, moved left “harder”
if left and center sees, move left “slightly”
if center only drive straight
same on the right.
too fast…(overran the line) what was the last sensor to see the line?
If left pivot left (right forward/left backward)
and versa visa.
We are counting the times we run off the line to determine where we are.
3 hard turns to re-aquire and we are there.
Phil
Iww… precious time waster in that type of auto-mode… lol
Just do like we do and dead reckon, and get to the ball in ~4.16 seconds!! 
for auton mode, we are using a yaw rate sensor to generate a compass heading, pointing the bot between the beacon and the moble goal, and using the gyro to go straight ahead
until our IR sensor sees the beacon (it has a very narrow window of view - like a pinhole camera)
then we turn hard towards the release ball, using the gyro again to measure a precise turn (ie 80° or 81 or 83…)
then moving straight ahead with our arm at release ball height, until contact swithces on the front hit the bottom railing
this should allow us to run at full speed most of the way there - we will see how it works on the real field.
And what does your bot do for the next 10 secs…
Dead rec back to harvest balls?
Phil
ps. We get there in 7secs with line follow and a 4fps drive train. Not much wasted time. and fully deployed to react once there 
24ft / 7sec = 3.42 ft per sec not bad for a 4fps system.
last year we used line following and had seven sensors on the bot on a bar - same idea as above, depending on which sensor sees the line you turn harder and harder
it worked ok, but we abandoned that approach and used the gyro as a compass, and started out backwards, doing a V turn
we hit the wall in 3 seconds consistantly last year.
This year our drivetrain is slower, but our navigation with the gyro should allow us to run at full speed most of the way there.
thats the trick - not outrunning your sensors
But that is exactly what we ARE counting on
We want to overrun the line exactly 3 times (each corner) then we stop.
We (at last test) overrun the line by 6 inches before the program reacts to the change. All good.
Phil
Maybe, but we haven’t quite figured that out yet… lol We are just glad that we got autonomous to work before we shipped this year… The first year we did that… Yay to us!! Now that’s progress!!
One more meeting should be enough to figure out what to do in those next 10 seconds, maybe a 180 spin just for for kicks… Then again maybe not, I don’t want to drive into a ball and tip over because of it getting lodged under us!
Probably more than likely nothing though, just a waiting game for the next strategical move, and time to charge up that compressor.
The problem with overrunning the line is that you have to get back to the line, preferably going as straight as possible. At least until you get to the next corner… If you overrun the line too much, it might take a while to get back on track. That said, counting each time you “lose” the line is a clever way of figuring out that you’re at the end of the road.
Last year’s was a little different because the line was an arc. You could compensate for the arc in software (depending on which side of the field you were on).
Since the RC this year is about a jillion times faster, start going full speed and ratchet down the code if it doesn’t work. All’a yous are still in the mindset of Slow, Tiny, and can’t do squat.
For turning, us either 0:254 or 191:254. That way, you still go forward while turning.
I don’t believe you or Ken or Phil above. I’d like to see you guys post some code to prove what you’re doing…
its not a question of how fast the SW is running - last year the loop ran at 38Hz, same as this year and it was plenty fast
the problem with line following with only 2 or 3 sensors is you only have a gross idea of where the line is, its either this way or that way - you cant be sure how far
and the bot is relatively big and heavy, making it slow to turn and respond to commands - if you try to go too fast you end up overshooting the line and your bot will zigzag back and forth trying to track it
using a gyro sensor, by comparison, give you much greater information on how far off course you are, and you can implement a Proportional, Integral, Differential (PID) control loop to track your course and optimize it to stay tighly on the desired heading, no matter what your bot encounters along the way.
with the gyro, if you are a tiny bit off, you can apply a tiny bit of correction - if you are way off, you can apply a lot of correction - and everything inbetween is covered with very fine resolution.
We decided to run with 6 sensors, 3 in front and 3 in back. That way we know whether to shift left or spin left or adjust left to different degrees. But thats just incase the IR dies completely. Otherwise, the two work in tandem. Nice to see but a real pain in the @$$ to program.
-Kesich
I don’t like posting code, as it gives you the answer, instead, I would like you to have an understanding of the logic/process that is involved.
btw. I have emailed you.
That is basically the same as what we are doing. It works almost every time. (if you line it up horribly unstraight with the line at the start it just sits there and jerks back and forth.)