PID vs Bang-Bang for Shooter Consistency

[lori558]

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!

[Greg McKaskle]

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

[lori558]

Originally Posted by Greg McKaskle

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

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

[Greg McKaskle]

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

Greg McKaskle

[Kevin Sevcik]

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.

[Ether]

Originally Posted by lori558

...

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

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

With PID programming, we used the counter

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.

With the Bang-Bang theory, we used the example provided by Billbo911 located at http://www.chiefdelphi.com/media/papers/2665.

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.

We have 1 stripe on our wheel

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

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?

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.

Bottom line is how can we get a consistent shooter if neither PID nor Bang-Bang theory is working for us?

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

And if there is no other option, why is our code not working?

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

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

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

[billbo911]

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.

[lori558]

@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?

[Kevin Sevcik]

Originally Posted by billbo911

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.

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?

[Ether]

Originally Posted by Kevin Sevcik

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?

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.

[lori558]

Originally Posted by Ether

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

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

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

Currently it is set up according to a tachometer:

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

How exactly do I go about programming that?

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

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

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

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 )

The code thus far is attached!

[Ether]

Originally Posted by lori558

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

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

Currently it is set up according to a tachometer:

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

How exactly do I go about programming that?

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

The code thus far is attached!

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?

[billbo911]

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.

[lori558]

Originally Posted by Ether

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

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.

[Ether]

Originally Posted by lori558

We tested the code that billbo911 posted and it worked!

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.

I pulled up a graph of the speed and output and it was very consistent.

Again, for the benefit of readers here, would you please post a screenshot of the graph.

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

That's what's great about CD and the FRC community.