Interrupts per second

[RyanCahoon]

Hello everyone,

I've been looking around the forums and have seen several posts but I haven't seen a definite answer. My team is designing a robot and we want to put encoders on it. Questions arose concerning the fact that encoders we have are 100 clicks/revolution, and we are planning on having the wheels turning at .7 - 1 rev/second, meaning 700 to 1000 clicks per second of the encoders * 2 sides. We were wondering, can the RC handle 2000 interrupts a second, in addition to whatever it takes to run the camera and essentially the default code?

Thanks,
--Ryan

[Mike Betts]

Ryan,

It all depends on how many (and which kind of) instructions are being executed in the interrupt.

Here is a good discussion on the time required to service the interrupt before your code even gets to run.

In general, keep the code short and 2000 interrupts per second should not be an issue.

Mike

[tseres]

it should be fine, but if it isn't, banebots (just google it) has an encoder click reducer

[Kevin Sevcik]

Just remember that 2000 interrupts per second is going to start running the risk of stretching PWM pulses on PWM13-16 if you're using the standard IFI Generate_PWMs() code. If you have any interest in using these PWMs, you'll probably want to transition to the CCP-based PWM generation code on Kevin Watson's site.

[RyanCahoon]

We're not using PWM13-16 and it's just going to be a counter on the encoder interrupts so it sounds like it will work. Thanks for the help!

--Ryan

[artdutra04]

If you are worried about processor overload from using too many interrupts in your program, you can also gear the encoders slower so you'll have less pulses per second. You'll start losing accuracy, but if you gear them slower by a 3:1 reduction you'll still have 33.3 pulses per revolution.

On a six inch wheel, that's an accuracy of about 0.56 inches per pulse. This should be more than sufficient for drive train applications, since that's within the tolerances of a FIRST playing field.