PID vs Bang-Bang for Shooter Consistency

[Ether]

Originally Posted by billbo911

How does the FPGA derive the "period" value? Is it just the time between rising, or falling, edges of a signal?

The FPGA has an oscillator running at 40MHz. This is divided by 40 to produce a 1 microsecond timer for time-stamping events (like the detection of rising and/or falling edges).

Additionally, the 40MHz clock is divided down by 261 to create a 153257 Hz (6.515 microsecond) polling frequency. The FPGA polls all the DIO inputs synchronously at this frequency.

Whether the FPGA counts and timestamps rising edge only, or both rising and falling edges, or both rising and falling edges on both channels, is determined by how the user sets up the counter (or encoder) object.

In encoder 4X mode, I believe FPGA counts both rising and falling edges on both channels, and by default computes the period using the 5 most-recent counts (i.e 4 periods). Then in WPILib, the period returned is divided by 4 to give the actual period between consecutive edges, which is the value returned to the caller.

Will the duty cycle of the signal influence the "period" value?

For a simple 1-channel counter (either a one-per-rev or an encoder with only one channel connected), an object can be created which counts only rising edges. So for a single piece of tape, the width of the tape doesn't matter, as long as it is wide enough for the sensor (and the FPGA) to detect it. The WPILib default for this type of counter is to use the 2 most recent counts to compute the period. This works well for a one-per-rev sensor, because there's only one rising edge per revolution, so there's no error due to tape placement (since it's always the same edge which is being detected).

[billbo911]

Originally Posted by Ether

The FPGA has an oscillator running at 40MHz. This is divided by 40 to produce a 1 microsecond timer for time-stamping events (like the detection of rising and/or falling edges).

Additionally, the 40MHz clock is divided down by 261 to create a 153257 Hz (6.515 microsecond) polling frequency. The FPGA polls all the DIO inputs synchronously at this frequency.

Whether the FPGA counts and timestamps rising edge only, or both rising and falling edges, or both rising and falling edges on both channels, is determined by how the user sets up the counter (or encoder) object.

In encoder 4X mode, I believe FPGA counts both rising and falling edges on both channels, and by default computes the period using the 5 most-recent counts (i.e 4 periods). Then in WPILib, the period returned is divided by 4 to give the actual period between consecutive edges, which is the value returned to the caller.



For a simple 1-channel counter (either a one-per-rev or an encoder with only one channel connected), an object can be created which counts only rising edges. So for a single piece of tape, the width of the tape doesn't matter, as long as it is wide enough for the sensor (and the FPGA to detect it). The WPILib default for this type of counter is to use the 2 most recent counts to compute the period. This works well for a one-per-rev sensor, because there's only one rising edge per revolution, so there's no error due to tape placement (since it's always the same edge which is being detected).

This is basically what I expected but I wanted to verify.
The additional detail also helps whenever we will be using encoders, counters and timers.

[Ether]

Originally Posted by billbo911

The additional detail also helps whenever we will be using encoders, counters and timers.

Special thanks to jhersh for providing the detail about the FPGA clocks in a PM earlier this month.

[flameout]

Originally Posted by Ether

1 microsecond timer for time-stamping events (like the detection of rising and/or falling edges).

153257 Hz (6.515 microsecond) polling frequency. The FPGA polls all the DIO inputs synchronously at this frequency.

WPILib default for this type of counter is to use the 2 most recent counts to compute the period.

Ether, thank you for this info -- this information would be very useful for deciding whether to use this rate determination functionality or numerical differentiation in calculating an encoder's speed (in terms of "lag" and noise for any given sensor and rpm)