First Question: How accurate is the quad encoder in terms of DEGREES? +/- 1,2,5,x degrees?

Second Question: How accurate is the going forward and backwards many times in terms of the numbers given directly from the quad encoder in Easy C? Like if you ‘print’ the value of the quad encoder to a monitor, it reads 0, then you turn clockwise and it’s 200, then counter clockwise to -200, and repeat, how much off is it each time?

Third Question: My robot has been having problems with the accuracy of the quad encoders… I turn it clockwise 180 degrees from the start, then turn it back to start, and turn it counter-clockwise 180 degrees, and back, repeat 2 times, AND IT’S 1 NUMBER OFF!!! from the start position (0). DOES ANYONE ELSE HAVE THIS PROBLEM???

Fourth Question (last): How fast/slow can the encoder react up to? In terms of RPS (revolutions per second, no I don’t want minutes, I want seconds please)

Some of your questions can be answered by reading the Inventors Guide page online, or the printed one that came with your quad encoders. As I recall, they have 90 slots, so quad 90 is 360, so about +/-1 degree accuracy.

A google search, or a forum search also shows many other posts about quad encoders, so your warm welcome should go out to the people whose answers are already available to you, in addition to the future replies you have to wait for.

Since you didn’t describe how your encoders are attached, I’ll assume direct drive on 4" wheels. 1 degree rotation of a 4" diameter wheel is 4"*pi()/360=0.035" or about +/-1/32" of an inch. ~+/-1/50" of an inch if using small wheels.

It seems more likely that your manual dexterity in doing 6 half-rotations is off by 1/32" of an inch.

As for Max speed, a drivebase with 3:1 speedup gears, on 393HS motors internally geared for 160rpm (crazy fast), with 4 encoders (holo drive) running 180 interrupts per revolution, could theoretically generate 4(encoders) * 180(interrupts per rev) * 160 RPM * 1/60 RPS/RPM < ~2k interrupts per second.
The PIC cpu is rated at 10M Instructions/sec and the Cortex cpu at 9x that. I wouldn’t expect an interrupt driver routine to take anywhere near ~ 10k instructions, so it seems unlikely that your problem is related to running the encoders too fast.
Experimental results on these kinds of things look really good in white-papers and in Robotics Engineering notebooks.

The encoders are very accurate as far as actually measuring just how many rotations have occurred; however, they are limited in their capability because if you tell your robot to drive until the encoder reaches a certain value, there will be an error. This error develops because even after the motors stops the robot continues to move due to momentum.

The same error that occurs with straight driving applies here. One side of the drive may have less resistance (friction) than the other so it will turn more than the other side. The effect of this error over several turns will create a high degree of inaccuracy.

Sensors these sensors will update in a matter of a few milliseconds

The encoders are very sensitive but the key is to write code which actively check the difference between the two encoders to keeps them close so turns are become more accurate.