Configure Timers

[Ether]

Sampling the signal does not provide any lag... I do not understand what you mean by average, because the points are not being averaged.

Averaging causes lag. Speed is your process variable, not counts. In the code you posted, sampling the counts every 200ms and dividing the difference by the difference in time produces a speed signal which is the average speed over the past 7.7 revolutions, not the instantaneous speed at the moment of sampling. It's effectively a low-pass filter, which introduces lag. That average speed lags the instantaneous speed, if there was any acceleration taking place during the past 200ms.

If instead you use the WPILib GetPeriod() method, this happens:

1) the FPGA returns the elapsed time (measured with the FPGA's 1MHz clock) between the most recent N+1 counts detected, then

2) WPILib divides that elapsed time by N.

You can then use this in your code to calculate speed. Using this method, you don't need to average the speed over seven and a half revolutions to get a clean signal. One-quarter of a revolution will given you a clean speed signal, with less phase lag.

I can shorten my sample time in order to reduce lag.

Sure you can. But your computed speed will get noisier, due to the 1ms resolution of your timer and the discrete nature of the counts.

I have never been able to get a clean signal from the period() function.

The default value in WPILib is to set up the FPGA to return the elapsed time between the most recent 2 counts (i.e. N=1). Have you ever changed that default value? If not, I can understand why you couldn't get it to give you a clean signal at high speeds.

I haven't looked into why the getPeriod() function produces a signal so noisy

I have. At high speeds with many CPR, the FPGA 1MHz timer and 153KHz polling frequency aren't fast enough to measure the elapsed time between just 2 counts without introducing excessive jitter. That's why you need to configure the FPGA to return the elapsed time between the N+1 most recent counts, instead of the most recent 2 counts, when using an encoder. If you use a one-per-rev counter, the FPGA default value N=1 works well.

why do i need to ask for a speed signal every 10 milliseconds? The Driver Station Packets are sent every 20 milliseconds, so any calculations done faster than that, are simply being thrown out and not making its way to the robot.

The speed signal comes from the sensor on the robot, not from the Driver Station. The only time the 20ms would come into play is when the driver changes the speed setpoint, which is typically a step change, not something that's continuously changing every 20ms.

As for the control of bang-bang, It is a good way to control velocity of the wheel for its simplicity, but you need to manage the oscillations around the setpoint.... You are ignoring inertia

You've got that backwards. I'm not ignoring inertia, I'm depending on it. Inertia plays a critical role in making bang-bang speed control work cleanly. Bang-bang speed control likes a high inertia load, a fast control loop, and low phase lag in the speed feedback. Compared to the approach you are using, GetPeriod() gives a smaller phase lag for the same signal-to-noise. And bang-bang code is so simple that it's not a problem to run it at 10ms. It also has the fastest spinup and recovery time.

I would love a nanosecond timer

GetPPCTimestamp(). It's not nanosecond but it's better than millisecond.