Configure Timers

[Ether]

Originally Posted by NotInControl

I do not see an attachment with your post so it's hard for me to say how my definition lines up with US Digital

I my haste to be responsive I forgot to attach it. Here it is. It's just a screenshot of a portion of page 1 of the E4P datasheet, which is available here.

So I am going to assume that the 500 PPR Cytron that you mentioned is actually a 500 CPR (using the US Digital and GrayHill definitions of CPR).

You said you were controlling 2300 rpm wheel speed with that 500 CPR Cytron encoder, but you didn't mention how you were decoding the signal, so it's not clear how many counts per rev you were getting. I'll just assume for the moment that you were using 4X quadrature decoding, so you'd be getting 2000 counts per rev.

You said you were polling the counts and computing the speed every 200ms. 2300 rpm is 7.7 revs every 200 ms. That's 15,333 counts every 200ms. So it's no wonder you are getting a clean speed signal: you are averaging the elapsed time of 15,333 counts to get your speed. That introduces lag. Lag in the sensor signal is generally not a good thing for closed loop control; it limits how fast you can make the response without causing oscillations.

Consider what would happen if you did this: use only one channel of the encoder, and configure the FPGA to count only the rising edges of that channel and to report the period based on the elapsed time between the 126 most recent counts. You would use the GetPeriod() method of the Counter class to get the period. The FPGA polls for rising edges at ~153KHz, and uses a 1MHz timer to measure the period. At 2300 rpm you should get single-digit rpm jitter with this setup, and with only 1/4 of a rev lag instead of seven and a half revs. You could ask for speeds at a 10ms rate and get a fresh reading each time.

With a clean, noise free speed signal with minimal lag (as described above) it becomes possible to use a bang-bang wheel speed control algorithm. That provides the fastest spinup and recovery times. The code is so simple that it can be run at 10ms without sucking up CPU time. No tuning is required, and the iteration rate of the control algorithm can be quite sloppy without affecting the control.

Here's a link to the use of micro-second timer to measure the exit speed of the frisbee from the shooter. A highly accurate feedback signal of frisbee exit speed would make it possible to tune the shooter wheel speeds to maintain consistent frisbee speed.

It's getting late and this post is getting too long. We can talk about the other stuff later if you want.