PID vs Bang-Bang for Shooter Consistency

[billbo911]

Originally Posted by lori558

...
We tested the code that billbo911 posted and it worked!
With a few very minor adjustments we got it to work specifically for our robot perfectly. I pulled up a graph of the speed and output and it was very consistent.

I think our problem this whole time has just been the fact that we were making it too complicated. ...
Thanks everyone for taking the time to help out with this! It really helps our team out.

Well, this is going to make my wife very happy!!!
I was going to swing by Kennedy this evening, but now I get to spend the evening with her because it looks like you guys are going to be just fine!! Good luck in San Diego!!

Originally Posted by Ether

Bill has posted various versions using different decoding methods. For the benefit of readers of this thread, could you please post the final code that worked for you? Please include both the "begin" and "TeleOp" portions.
Again, for the benefit of readers here, would you please post a screenshot of the graph.
That's what's great about CD and the FRC community.

I'm not going to post what I believe they are using, I'll leave that to Lori so that we see exactly what is working for them.

As she stated, complicating Bang Bang is not necessary. It is actually a very simple controller IN THE RIGHT SITUATION. I believe the key to making it work is, a reliable way to measure the output being controlled.

I still have a couple questions that will probably need to be answered by Mark McLeod, although you may know the answer to this Ether.

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

[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)

[Woolly]

Originally Posted by billbo911

As she stated, complicating Bang Bang is not necessary. It is actually a very simple controller IN THE RIGHT SITUATION. I believe the key to making it work is, a reliable way to measure the output being controlled.

Right, I know for our shooter wheel we had to average the last 5 10ms samples to get consistent data out of our US Digital 256 count encoder.
Not to mention we complicated our controller by using an equation to look up the approximate base power needed for the RPM we wanted, and then have it Add or subtract a certain amount from that based on whether we were over or under our setpoint.
After all this fuss, it has become quite reliable though.

[Ether]

Originally Posted by Woolly

Right, I know for our shooter wheel we had to average the last 5 10ms samples to get consistent data out of our US Digital 256 count encoder.

This should not be necessary with that encoder if the counter object is set up properly so that the FPGA, not your code, is doing the period computation. You should be able to get very accurate and rock-solid rpm readings without doing that kind of averaging.

Averaging like that introduces phase lag in the sensor signal. Bang-bang does not like phase lag.

What language were you using?

Not to mention we complicated our controller by using an equation to look up the approximate base power needed for the RPM we wanted,

That's called feedforward, and is totally unnecessary with bang-bang.

After all this fuss, it has become quite reliable though.

If it's working well for you, now is not the time to be changing the competition code on your robot. But if you'd be interested in exploring this further (maybe on an old robot), start another thread and we can have a discussion about it.