How do u get your robot to follow the white line??????????????????

[HuskieRobotics]

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??????

[jacob_dilles]

http://www.chiefdelphi.com/forums/search.php?searchid=72414

search before you post

[HuskieRobotics]

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???????

[KenWittlief]

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.

[HuskieRobotics]

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???????

[KenWittlief]

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.

[Phil_Lutz]

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.


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

[Elgin Clock]

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!! :D

[KenWittlief]

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.

[Phil_Lutz]

get to the ball in ~4.16 seconds
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. :)

[KenWittlief]

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

[Phil_Lutz]

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

[Elgin Clock]

And what does your bot do for the next 10 secs...
Dead rec back to harvest balls?
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. :D

[jeremy562]

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).

[Astronouth7303]

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.

[Steve Horton]

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...................... :)

[KenWittlief]

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.

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.

[Anthony Kesich]

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

[Phil_Lutz]

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...................... :)
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.

[Ryan M.]

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
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.)

[Phil_Lutz]

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.)

During the scrimmage we attended one student aligned the robot at about a 45~ angle to the line. He was asked to align it he replied "It will be fine". The robot's first command turned out to be drive forward. it went off the line, spun to reaquire, crossed the line again at 90~ to the line spun hard again and crossed the line at about 45~. Total distance travelled in auto. 2 ft from the wall. :ahh:

:)
Ah youth.

[deltacoder1020]

During the scrimmage we attended one student aligned the robot at about a 45~ angle to the line. He was asked to align it he replied "It will be fine". The robot's first command turned out to be drive forward. it went off the line, spun to reaquire, crossed the line again at 90~ to the line spun hard again and crossed the line at about 45~. Total distance travelled in auto. 2 ft from the wall. :ahh:

:)
Ah youth.

this is why you always want to utilize the factors you can precisely control, such as the alignment. Human error just adds onto any error in a program, so try to get the best possible scenario for your program to run in.

[JBabbie]

ok , you need 2 banner cells, one of the left or your bot (l_banner) . and one on the right (r_banner)

if ( l_banner == 1)
turn robot left 45 degrees ( run trial and error tets to find out how long it takes to turn your bot 45 degrees left)
if (r_banner == 1)
turn your robot right 45 degrees

so... if you had 4 wheel tank drive , and your left drive motors were pwm01 & pwm02 , and your right were pwm03 & pwm04. and run a counter ((int)count_me)

if (l_banner == 1)
{
count_me ++ ;
if (count_me <=2)
{
pwm01 = pwm02 = 200; /* runs your left motors at a medium
speed forward */
pwm03 = pwm04 = 75; /*runs your right motors at a medium speed
reverse */
}
if(count_me >=3)
{
count_me = 0; /*resets the counter */
}
}
else
if (r_banenr == 1)
{
count_me ++ ;
if (count_me <= 2)
{
pwm01 = pwm 02 = 75; /*left motors run reverse */
pwm03 = pwm04 = 200; /*left motors run forward */
}
if (count_me >= 3)
{
count_me = 0; /* resets the counter */
}
}
else
pwm01 = pwm02 = pwm03 = pwm04 = 255 ; /*runs robot full forward */

keep in mind that the values I gave the motors and the counter are guesses , you might want to play with those on your own =), and also ... thats for a tank drive robot.. so if you use that.. keep your wheels pointed straight if you have swivel drive :)

fixed the indentation =)

[deltacoder1020]

it will, you just need to use the CODE vB tag.

[Phil_Lutz]

Use CODE in square brackets to start a code segment and /CODE in square brackets to stop the code segment.

:)

Phil

[Salik Syed]

How do you get a heading using the Yaw rate sensors? is it really easy ? i would think u just keep a timer then multiply the reading from Gyro * TIME * TIME... also how do you turn the 0-254 value to something that is a actual value like m/s etc...or not?
but i heard that integrating causes a LOT of errors etc...

[KenWittlief]

took me a minute to find this in another thread - this is the crash course in turning a yaw rate sensor into a compass heading - only difference this year is the analog in gives you a 10 bit number - I just did a ' >>2' to divide it by 4 (shift right twice) - 8 bits is plenty...

__________________________
last year we used the supplied yaw rate sensor to figure out our compass heading - you can do it with ONE line of code!

when the bot is not turning the output of the yaw rate sensor was 127 - when you turn in one direction the number goes up, the other, the number goes down (yaw rate sensor wired directly to analog input - no external circuits/filters or anything else)

start off with a 16 bit variable initialized to 32000. then somewhere in your code add the value of the sensor to that heading variable, and subtract 127 (to correct for zero being 127)

THATS IT! thats all it takes - as your bot turns in one direction, the heading variable will increase - as it turns the other way, it decreases. If you turn 180° right, then turn 180° left, it will go back to 32000

it works EXTREEMLY well - the errors tend to cancle themselves out - the only refinement you might want to add is to let the bot sit for minute while its not moving, and see if zero is 126, 127, 128... and use that as your zero offset.

with a little testing you can find out how many counts in the heading register is equal to 1 degree - turn the bot 90° right and read the register. but dont bother dividing the heading register by a constant to work in degrees - just use whatever units the register comes out to be - for example, if 32,000 is zero heading, maybe 45,153 will be +90° and so on.

thats all there is too it - since the SW loop runs at a consistant rate, simply adding the sensor signal to the variable is all you need to do to intergrate degrees/second into degrees!