Quote:
Originally Posted by AdamHeard
how many interrupts per second can the processor handle?
|
As I recall, it can handle somewhere in the 5000-7000 range. Keep in mind though, that your encoders will probably not be your only interrupt events. Serial communication (i.e. to the camera) & ADC conversions both also count as interrupts. You may also just have a clock running for other timing.
Quote:
Originally Posted by AdamHeard
Our highest gear puts the encoder shaft at about 1500 rpm. We're using the grayhill 128's that Kevin reccomends (because we already have them) and that puts out a lot of counts per second , 1486.6 [rpm] / 60 [seconds/min] * 128 [counts/rev] = 3172 counts per second!!!, and that's only one side. That seems like way too much to me.
|
Something else to consider: where are you putting your encoder, relative to the motor, gearbox & wheel? I would suggest putting it close to the wheel.
Let's suppose you have 10" diameter wheels (fairly large by FIRST standards). That means you have a 31.4" circumference. If that's in a 1:1 ratio with your encoder at 128 ticks per revolution, that means you get an encoder tick every 1/4" of linear movement. That should be sufficient. (I usually aim for 1/4"-1/2" per tick, which has always been more than enough.)
Suppose instead, you have very small wheel - 12" circumference (about 4" dia), and a very fast robot - 20 ft/sec. That means you get 128 ticks per linear foot, and 2560 ticks per second (and 0.1" per tick) at full speed. Double that to count both sides, and you're only at 5k interrupts per second, assuming you're traveling at full speed with both wheels.
If your robot is at a more reasonable speed in the 10-14 ft/sec range, and your wheels are typical FIRST wheels in the 4"-8" dia range, and you have a 1:1 ratio between the encoder and the wheels, at 128 ticks/rev you'll have a good balance among ticks/second, ticks/inch and total interrupts.