Originally Posted by lori558 (Post 1240697)

...
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.

Originally Posted by Ether (Post 1240704)

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.

Originally Posted by billbo911 (Post 1240718)

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

Originally Posted by Ether (Post 1240726)

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

Originally Posted by billbo911 (Post 1240746)

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

Originally Posted by billbo911 (Post 1240718)

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.

Originally Posted by Woolly (Post 1240752)

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.

Originally Posted by Ether (Post 1240726)

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

Originally Posted by lori558 (Post 1242498)

With the minimum value being at 0, this caused a more inconsistent shooter since the wheel would turn off and on with too much of a difference between the two speeds.

Originally Posted by billbo911 (Post 1242513)

I'm thinking the Break/Coast jumper is in the break is position.

Originally Posted by lori558 (Post 1242673)

Before we modified the code we had tried changing the 10ms to 1ms and it was way better, but still not as consistent as it is with the modification.

Originally Posted by Kevin Sevcik (Post 1242699)

...

Also, if it's fairly hard to turn even with a wire unplugged, then you just have a lot of mechanical resistance in your system. That would also explain why you're seeing better stability with a -0.3 instead of 0. The extra mechanical resistance is slowing your wheel down more rapidly, so giving it a little push instead of letting it coast makes it ramp down slower. So you're having to bump it less often to keep it in tolerance, which I assume is what you're counting as better stability.