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.

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

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

[lori558]

Here is our slightly modified code. 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. Therefore we changed 0 to -0.3.
(Keep in mind, our values are negative simply because this is how our code is written. This can be fixed in the Begin.vi if needed but this is working for us.)

By changing the value to -0.3 it makes it impossible (based off of this code) to shoot below 30%. However, the Frisbee will barely go anywhere at that percentage anyway, therefore that number is perfect for us.

Since the minimum value was changed to -0.3, this caused the wheel to spin at a constant speed of 30% if the desired RPMs were ever lower than that. Thus we added the =0 select value into the code to make sure that when we do not want the wheel to move, it doesn't.

As for the rest of the code, it is the same as using a tachometer and the more basic code so graciously provided by billbo911.

[Ether]

Originally Posted by lori558

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.

[edit] First things first: check to make sure the motor controller brake/coast jumper is in the coast position. If it's not, put it there, change that "-0.3" back to zero, and try it. (hat tip to Billbo911) [/edit]

If that doesn't fix the problem, continue:

The code is not running fast enough.

Take that waveform chart out of there and change the loop timing to 5ms and see if it fixes the problem.

Therefore we changed 0 to -0.3

Hmm. What motor controller are you using?

[billbo911]

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

[Ether]

Originally Posted by billbo911

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

Yikes! You could be right!

That wasn't even on my radar - I just assumed folks knew it should be coast.

[lori558]

The jumper is in the coast position. We made sure as we were wiring the robot that it was put there.
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. It could just be the way that our bot is designed and programmed, but it works for us.

[Ether]

Originally Posted by lori558

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.

Did you try it without the waveform chart ?

It could just be the way that our bot is designed and programmed, but it works for us.

Understood. But here's a chance for you to help those who helped you. We'd like to understand what's going on; to contribute to the community knowledge base.

[Kevin Sevcik]

So turn the robot on and leave it in disabled mode. Try turning your wheel by hand, then unplug one of the motor wires and try turning it by hand again. If it doesn't get easier to turn when you unplug a wire, then it's definitely in coast.

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.

[billbo911]

Originally Posted by Kevin Sevcik

...

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.

Excellent point!
An ideal system for Bang Bang have very little resistance to rotation and a considerable amont of rotational inertia.
Maybe Lori's solution is something to consider when using Bang Bang on a less than optimal system. This is deffinately something I would like to invetigate a bit more.