PID vs Bang-Bang for Shooter Consistency
 

Currently our team is having problems with shooter consistency. Both PID and Bang-Bang have yielded negative results for us.

We are using a photoswitch (provided in 2011 KoP) in place of an encoder...

With PID programming, we used the counter and wired it into a PID function and attached the output to the motor. However, according to the gains we test, the wheel will either not move, jerk back and forth, or spin at full power. Thus far, we have never been able to get PID to work.

With the Bang-Bang theory, we used the example provided by Billbo911 located at http://www.chiefdelphi.com/media/papers/2665.
We have 1 stripe on our wheel and thus the numbers on the example were indeed changed from 360 to 1. So that is not the problem. When tested, the wheel would either not do anything or would spin at full power.
We have gone through the thread http://www.chiefdelphi.com/forums/sh...d.php?t=113029. The modified code in there has been tested as well and that seemed to yield some results. The wheel would spin according to the number that was put in, however, the shots we fired were not very consistent. Therefore that leads us to believe that the code was not working for us.

Ultimately, our goal is to make our frisbee shots consistent. We have researched a lot on this idea and not much seems to be working for us.

Additionally, the idea has been brought up that I might as well ask here; is it reasonable to use battery voltage as a factor and create a wheel speed equation that consistently maintains the desired speed by taking battery power into the equation?

Bottom line is how can we get a consistent shooter if neither PID nor Bang-Bang theory is working for us? And if there is no other option, why is our code not working?

If anyone could help out on this that would be great!

Re: PID vs Bang-Bang for Shooter Consistency
 

One thing that may help is to post some data. It is pretty straightforward to add indicators that chart the sensor value over time and on the same plot you can add in the output value. This helps people spot many common issues from noisy sensor to feedback to programming errors. Then take a screenshot of the chart and post it here.

Greg McKaskle

Re: PID vs Bang-Bang for Shooter Consistency
 

Okay I will try and get on that. Should I do this for both PID and Bang-Bang Theory?

Re: PID vs Bang-Bang for Shooter Consistency
 

Your choice. The bang-bang may provide the most informative.

Greg McKaskle

Re: PID vs Bang-Bang for Shooter Consistency
 

Not in my FRC boot, so I can't check, but does the Labview PID VI have a feedforward term and integral anti-windup? Both of those are really necessary to get good performance from a PID loop on a shooter.

Also, you say you're using a Counter and you said you changed from using 360 to 1. Are you using the counts from the Counter, or are you using the period? The single count encoder trick only really works if you're using the period from the Counter. You don't get nearly enough of those single counts to do any kind of control. So instead, you use 60/period which gives you a fairly accurate measure of RPMs. That should be your input to your PID or Bang-Bang.

Re: PID vs Bang-Bang for Shooter Consistency
 

It would be helpful if you could post a picture of what you are detecting with the photosensor. Is it a piece (or pieces) of tape? Is it reflective paint? Is it an LED shining thru a hole (or holes) in the wheel? You get the idea. (I see later in your post you mentioned a piece of tape. Please post a picture).

When you say "the counter", what do you mean by that? How are you decoding the sensor signal? There are two very different ways to decode the signal, and it's important you do it the right way. The two ways are 1) read the counts from the sensor and divide the change in counts by the elapsed time, or 2) use the FPGA's high frequency sampling and 1 microsecond clock to measure the period (the elapsed time between counts).

With a low count-per-rev sensor, you want to use the 2nd method, not the first.

Post a screenshot of your code so we can see if you are using the correct method.


I think that uses method1 (the "counts" method), which is the wrong method for a 1-count-per-rev sensor. I think Billbo911 and Mark McLeod both posted LabVIEW examples of the method you should use (method2, the "period" method) at this thread.


Please post a picture of that stripe. Not all stripes are created equal; there may be a problem with the way you did it.


You do not need this once you have bang-bang working correctly. It will automatically compensate for any voltage changes to maintain the correct speed, as long as the speed you are trying to control at is sufficiently lower than full speed so you have some voltage headroom for the controller to work (the same would hold true for voltage compensation also). PID can be sensitive to voltages changes in some situations.

You can make it work, if you have the willingness to stick with it and provide the needed detail so we can help you.


Please post screenshots of your code, and see explanation above.

You came to the right place. Now, work with us.

Additional information needed:

1) What motor(s) are you using, what is the total gear ration from each motor to each wheel, what motor controllers are you using.

2) What speed are you trying to control at?

3) The graphs Mark requested would be a good idea

Re: PID vs Bang-Bang for Shooter Consistency
 

Hi Lori,
Check your e-mail. I just sent you a customized version of the Bang-Bang.

I'll post the content here for others to see as well.

Kennedy is using a single count per rev. "encoder".
This encoding works best with measuring the period and converting to RPM than measuring counts during a given period and then converting to RPM.

Once the measured RPM is established, controlling the RPM becomes a simple matter of comparing the actual RPM to the desired and turning the speed controller on or off.

Note in the attached image, the point where the value is obtained from the "Counter Get" is the period output.
Additionally, if this method is followed exactly, it is only capably of tracking RPM up to a theoretical maximum of 6000 RPM. But, that is perfect for use with a direct drive CIM powered shooter.

Re: PID vs Bang-Bang for Shooter Consistency
 

I am not currently in the position to take a picture of the wheel right now. For the moment, I can try and explain it as best I can. The wheel we are using is an andymark 6" wheel with 6 spokes. We have attempted to use just one stripe of paint covering one spoke, however, the photoswitch didn't pick up the 1 stripe at high RPMs. So we switch and put a piece of tape that covers the gap between 1 spoke to another. So it is a thick stripe...


Currently it is set up according to a tachometer:


How exactly do I go about programming that?


Absolutely! We have been working on this for weeks now and are still set on getting it to work.



a) We are using a CIM motor with a direct drive between the wheel and the motor. The motor is controlled by a talon.
b) We are aiming for any and all speeds
c) Graphs coming soon (when I can get back to the robot again :p)

The code thus far is attached!

Re: PID vs Bang-Bang for Shooter Consistency
 

@billbo911 Great! Based off of what Kevin said I revised the code to use the period. I knew I was doing something wrong in the program I just wasn't sure what. So the problems we are having is mostly based off of the fact that is a single count "encoder" and the program does not work for that?

Re: PID vs Bang-Bang for Shooter Consistency
 

Bill,
I'm pretty sure that will work for higher RPM unless Labview is somehow mangling the period output and WPILib isn't. We use C++ and I'm doing essentially the same thing on our small wheel shooter and I'm measuring up to 11,000 RPM. Why do you think that's limited to 6000 RPM?

Re: PID vs Bang-Bang for Shooter Consistency
 

A 1-per-rev sensor should be no problem for FPGA (or WPILib) well over 11,000 rpm.

If there's a high-speed limit, it would be in the sensor itself. That's why I asked him to post a picture of the wheel with the tape on it. If the tape doesn't cover a sufficient angle of arc, at high speeds the pulse width may be too small for the sensor to detect reliably.

Re: PID vs Bang-Bang for Shooter Consistency
 

OK, that is what I was concerned about. That photosensor isn't exactly a speed demon. It needs a wide stripe. The wider the better (up to 180 degrees of arc, no more).

Yes, that's the "period" method (method2) that I was talking about in my previous post.


If you're using this, you're already doing it.

The code doesn't look right to me, but I'm not a LabVIEW guru. It looks like you are converting the period to rpm, then subtracting the previous rpm value from it, then comparing it to a period. Bill or Mark, can you please jump in here and help him?

Re: PID vs Bang-Bang for Shooter Consistency
 

Kein and Ether,

If you take a look at the example I posted, it has a 10ms "wait". I based my comment on 60sec/.010 sec = 6000.
I realize now that the FPGA will return the latest sample, or period, regardless of how often it is called for. Thus my number is probably way off and 11K RPM number is more reasonable. Good to know.

Re: PID vs Bang-Bang for Shooter Consistency
 

Okay great, I was concerned that the stripe was too thick to provide an accurate count. That gives me some relief, thank you.


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. In addition, when I was first looking into the bang-bang theory I did not understand it all that well but this really clears it up.

Thanks everyone for taking the time to help out with this! It really helps our team out.

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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

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?

Re: PID vs Bang-Bang for Shooter Consistency
 

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

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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?

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


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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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)

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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


Hmm. What motor controller are you using?

Re: PID vs Bang-Bang for Shooter Consistency
 

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

Re: PID vs Bang-Bang for Shooter Consistency
 

Yikes! You could be right!

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

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

Did you try it without the waveform chart ?


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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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.

Re: PID vs Bang-Bang for Shooter Consistency
 

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.