Anyone using sensors???

[f22flyboy]

its faster to cut off the curve into 90 degree sections than to make a wide arc around to the ramp. If you use dead reckoning to make the same curve that you would if you followed the tape, what's the point?

I agree that your code is simpler, but not faster, at least not for our bot.

We also were planning on putting the gyro in so it accelerates when it hits the ramp, but never got around to it. Yet another thing to be done at regionals.

[Katie Reynolds]

Originally posted by Stephen Kowski
dead reckoning - too inconsistent put a few bins in the way and while your robot thinks it is going straight up the ramp it is now going off at an angle. You get a battery that has a higher or lower charge the motors will act differently. just too inconsistent

Yep. This is why we opted for a robot that follows the line. We're using 5 sensors this year ... they're all lined up on the front of TOBOR VI. It's pretty nifty! I believe we have a dead reckoning program written just in case we need to use it, but I'm not sure.

- Katie

[rust710]

Alex you are tired or really not with it. Where did you get 393? Actually I am not doing it like that at all. This is how I am doing it.

POT = (POT*127)/254 'Gives me a perportional number between 0 and 127

if POT<63 then
Left_drive = 127 + POT
Right_drive = 125 'Locks wheel
else
Left_drive = 125 'Locks wheel
Right_drive = 127 + (254 + POT)
endif

I think this is right but it is late and I can't find the source I wrote earilier.

[f22flyboy]

1
      _______________
     |               |
     |               |
     A              B

2
              ____
           _|       |_
       _|               |_                    
      |                     |
      A                    B

maybe this will help explain what I'm trying to say. The distance from point A to point B is shorter in 1 than in 2

Edit- trying to get the lines right
Edit-close enough

[srawls]

First of all, we are not travelling in a straight line, we must travel forward, turn 90 degrees right, go forward, then travel 90 degrees right again.

Second, the distance may or may not be greater, that's not the point. When you don't do an arc, you have to stop, turn, then move, and then you have to accelerate back up to your top speed. When you do an arc, you apply power to the motors continously, and thus you aren't jerky and you save some speed.

Now, it may be different depending on drive train issues, and robots, but it's not as simple as "the shortest distance between two points is a straight line" (unless you are 179 and you can just climb over the rail, thus going in a straight line! )

Stephen

[f22flyboy]

I'm not advocating an 0 radius turn. There is some arc to the turns, but they would still be considered a sharp 90. Hitting the front lip of the ramp at top speed in our current configuration would be catistrophic, so I say once again: It is a decision that needs to be made in each team, and is dependant on your individual robot and strategy.

I still maintain that cutting of the curve in dead reckoning is faster for most bots that I have seen, but only time will tell.

[Willum]

We have both a curve and a 90-90 dead reck going. I believe the 90-90 program is faster, but sometimes there's a good reason behind using an arc. but i've said too much.

[Duke 13370]

Alex you are tired or really not with it. Where did you get 393? Actually I am not doing it like that at all. This is how I am doing it.



code:--------------------------------------------------------------------------------
POT = (POT*127)/254 'Gives me a perportional number between 0 and 127

if POT<63 then
Left_drive = 127 + POT
Right_drive = 125 'Locks wheel
else
Left_drive = 125 'Locks wheel
Right_drive = 127 + (254 + POT)
endif
--------------------------------------------------------------------------------


I think this is right but it is late and I can't find the source I wrote earilier.

Remember ours didn't work earlier, this fixes it, and 127+256=393 (i forgot that 254 thing) this inverses it correctly, the one we had was backwards (close to 127 was sharper turn than 254).

[Duke 13370]

the big advantage to an arc is that is would be variable, and not limited by the line. (you could make it variable with the 90-90 thing, but this uses less variables)

[Cory]

the fastest way isnt a 90/90 turn. The fastest is to back up at an angle and then go straight up the ramp with a very minor correction. We have multiple modes of autonomy, using Gyros, Line followers, and dead reckoning. We are using 5 sensors in a line to detect the line.

This is our config:

| | | | |

this works rather nicely
[edit] ummm it didnt like the way i spaced my little lines, lemme figure out a way to fix em.

Basically, there are two sensors on the far ends and then a group of 3 in the middle.


Cory

[Jeff_Rice]

We are. I wish we had five sensors to play with, though. We're only using three. We also have some d. r. programs.

Sensors are cool!

Look for our bot doing some cool antics at the Seattle regional!

[Cory]

Oh yeah, we have a pretty cool odometer too. Ill post some pictures in a few days when i upload a whole bunch of our bot.

Cory

[Pierson]

We were going to do line-following until our programmer found a better way to use the sensors to count wheel revolutions. Look for some very cool autonomous action from 360 at the Seattle Regional.

[Josh Hambright]

we aren't line following...
but then again we aren't exactly dead reckoning either....

sensors galore on our robot... 16 digital inputs and 3 analog! (gee that was fun to wire )

[Andrew]

Is anyone else out there using encoders? I heard one person talk about odometry.

We got some gray scale mechanical encoders (Grayhill) and are using them on our back wheels.

We do the back up then forward at an angle strategy.