[TubaMorg]

Just another point of view. We tried driving our robot in autonomous w/o sensor data and it is fairly impossible. Sending a signal to your victors for a particular speed doesn't mean your robot will go the same speed every time. As mentioned before, battery voltage and drive train variances will effect the outcome every time making prediction and accuracy hit or miss. Turning only makes the error worse.

As you are a competent programmer I would recommend acquiring Kevin Watsons code (if you aren't using EasyC) which can be used quickly to get your kit sensors working. Explore these forums some more for various descriptions on what encoders are. Very simply though, encoders is a generic term for a sensor that can count (people feel free to correct me if I'm wrong!). There are few different ways to do this. Optical encoders use a beam of light, usually infrared, that when broken generates a signal (think garage door opener safty device). You can imagine that if reflective strips are placed at periodic intervals on a wheel and an optical encoder is focused at the wheel while it is spinning, an on/off signal will be generated that is proportional to the speed of the wheel. Depending on the application, this can be used as a way determine distance travelled. I believe the KOP this year has such encoders.

A simple mechanical encoder would be a momentary switch device that would signal when activated (think pegs on a wheel depressing a switch).

Now we have the KOP gear tooth counter which is an electromagnetic encoder that works on the Hall Effect which is why it also known as the Hall Effect sensor. It simply generates a signal when its surrounding magnetic field is disrupted which is why it works as a gear tooth counter. The caveat is that since it is based on magnetics, whatever it is counting needs to be ferrous. It just needs to be mounted in close proximity to the meshing face of the gears (1-2mm). As mentioned before, if you are using the KOP transmissions, they already have pre-drilled holes to mount the sensor on the face plate where the motors are mounted. The Tips sheet shows the picture. Just make sure the TAPERED part of the holes are facing OUT not IN, or it wont align properly. Also make sure that nylon washers are used to mount the gear tooth sensors or you'll short it out.

Encoders are a simple way of getting distance travelled. Not perfect, but ok. You loose accuracy due to slippage and missed counts, but this is the way to implement dead reckoning. Timing in this scenario isn't really dead reckoning because you don't know what speed your going or what direction.

Now for a quick yaw rate gyro explanation. Again, Kevin Watson has code for gyros (how he does all this I'll never know). As the name implies, yaw rate gyros send a signal proportional to how fast it is turning. In our case, since 5 volts is the base line, 2.5 volts means no turning, >2.5 means one way, <2.5 means the other way. Kevin's code handles all the initialization and timing and integration and junk that makes it useful. Or you can use easyC which has the code built into the WPlib library. Either way the work has already been done.

Soooo if you get the gear tooth counter installed you can get distance. If you get the gyro installed you can get direction. I think I've rambled on long enough. I hope I was some help and didn't confuse anyone.