Quote:
Originally Posted by Kevin Sevcik
I'll note that 57 had a fast update loop on our shooter wheel a few years back. We ran it at about 75 Hz, if I recall correctly. Our update rate was actually primarily limited by how quickly it was reasonable to sample our encoder. If you're going the standard route of counting encoder ticks per unit of time to get velocity, getting a 100 step resolution at 100 Hz means you're servicing 10000 interrupts per second. We had a fun trick to get around this without any extra hardware, but it's only good for 1 encoder and it's non-directional to boot.
|
It's been on the back burner for a while and someday I'll get around to finish coding it, but a really neat trick is to not measure the number of encoder ticks per unit time, but to measure the amount of time
between ticks instead. Using your example, you could use the internal 10MHz timer to give you a
one part in a thousand resolution in velocity at a control rate of 10KHz!. If you don't need to control at 10KHz, you can forward predict the number of ticks to accumulate for a, say, 100Hz control rate, which will give you an incredible velocity resolution of about one part in 100,000. I've used this technique in a few applications for my day gig, with pretty stellar results. Pretty cool, eh?
-Kevin