Shooter consistency

We've had near perfect accuracy with our shooter, and it's essentially a 2-wheel linear shooter using the AM 8-inch pneumatics without the pneumatic inner tubes inside the wheels on AM Spinboxes powered by a CIM and a MiniCIM. No feedback whatsoever, constant 100% power on the wheels when shooting.

[Brandon_L]

Originally Posted by Andrew Lawrence

We've had near perfect accuracy with our shooter, and it's essentially a 2-wheel linear shooter using the AM 8-inch pneumatics without the pneumatic inner tubes inside the wheels on AM Spinboxes powered by a CIM and a MiniCIM. No feedback whatsoever, constant 100% power on the wheels when shooting.

Were running almost the same, our theory is that were basically shooting in a straight line and power would only effect how far our disc goes before it drops, unlike last year where different speeds would give different arcs. Have you found this to be about true? I haven't had the chance to play with shooting with near-dead batteries yet.

[jordansch]

Originally Posted by Ether

Would you mind answering a few questions to make this useful for other teams?

1) What optical sensor are you using?

2) What angle of arc is subtended by the tape at the radius where the sensing is taking place? In other words, what is the width of the tape (in the circumferencial direction) where it passes under the sensor, and how from the center of rotation is the sensing element located?

3) What wheel speeds were you measuring?

4) Were you indeed "having the sensor count rotations" or were you using the FPGA to measure the period? (That's an important distinction).

5) What speed control algorithm did you use?

Sorry it took so long for me to respond.

1. The photo switch we are using is a Banner M12 series metal barrel sensor(i can post a .pdf with the specs if you want me to).

2. The piece of reflective tape we are using is roughly three-quarters of an inch wide. Our photo sensor is mounted about three inches above the wheel, looking down on the tape at a ninety degree angle.

3. At full power to the motors, our sensor was measuring roughly 12,500 RPM, and at 75% power, which we use more often for our shooting positions, it measures at about 8,000. Our numbers are not completely accurate, as the sensor is always reading about 100 RPM on each side of the actual value.

4. We had the photosensor programmed into the code as a counter. We then took the time between when the sensor picks up the tape, ran some math on it, and got the RPM of the wheels.

5. We had to create our own homemade velocity pid loop. The motor will increase power by .005 each iteration of the code until we get to within, say, 1000 RPM. Then it will slowly move closer to the point, increasing or decreasing by .001 each iteration, and it will hold the same power once it gets within 100 RPM.

Hope this helps anyone having difficulties with measuring RPM. Remember, just because something works doesn't mean it's the simplest or most effective solution.

[Jared Russell]

Our 2011 KOP Allen-Bradley sensors are being used for speed measurement, as Dustin noted. Here is our exact arrangement:

4.875" BaneBot wheels (black plastic), with the sensor looking at the side (e.g. visual axis of the sensor is parallel to the axle) of the wheel about 2/3 of the way between the axle and the outer diameter. We used a ~1.5" x 1.5" patch of retroreflective tape from an optical tachometer kit (very similar to the tape on the goals) at one point on each wheel. The sensor is about .5" from the plane of the wheel/tape. We used the trim knob on the sensors to ensure we got a strong, unambiguous 0/1 signal from the tape and the background. The sensors are powered by 24VDC from a solenoid breakout, and are designated as WPIlib 1x Counters (count rising edges only) in the code. We use getPeriod() on the Counters to measure the time between consecutive measurements.

We nominally spin our first wheel at 3000RPM, and the second at 4700RPM. But I have measured speeds up to about 6000RPM without issue (haven't tried faster than that). We do no filtering of the speed signal whatsoever.

We do speed control with a Feedforward + P controller, using Victor 888s in coast mode (RS550 motors with 3:1 reduction). We run the following algorithm at 100Hz:

Output = Max(0, [Kv * desired_rpm + Kp * (desired_rpm - actual_rpm)])

We are using a Kv that maps to the free speed spec of the motor (e.g. to spin an RS550 with free speed ~19000RPM at 3:1 reduction at 3000RPM, you want about 50% power).

We use a Kp of 0.01. This means if we are below our setpoint by >=100RPMs, we apply full power to the motor (regardless of Kv, so we actually go full tilt on the motor even closer to our setpoint using a nonzero Kv).

It is worth noting that our control scheme is exactly equal to bang-bang control if you set Kv = 0 and Kp = (infinity). We did not have time to do a lot of experimentation on the various control regimes; we simply found one that worked (similar to what we used in 2012) and ran with it.

Our software only lets the autonomous program or driver fire discs if both wheel speeds are within 120RPM of the specified value.

[Ether]

Originally Posted by jordansch

.

1. The photo switch we are using is a Banner M12 series metal barrel sensor(i can post a .pdf with the specs if you want me to).

Please do, if you have it handy

2. The piece of reflective tape we are using is roughly three-quarters of an inch wide. Our photo sensor is mounted about three inches above the wheel, looking down on the tape at a ninety degree angle

How far away, radially, is the sensing element from the center of rotation?

3. At full power to the motors, our sensor was measuring roughly 12,500 RPM, and at 75% power, which we use more often for our shooting positions, it measures at about 8,000. Our numbers are not completely accurate, as the sensor is always reading about 100 RPM on each side of the actual value.

If you use the getPeriod() method in the Counter class, you can do much better than that. More below.

4. We had the photosensor programmed into the code as a counter. We then took the time between when the sensor picks up the tape, ran some math on it, and got the RPM of the wheels.

From the above description, it sounds like what you are doing is this:

a) get the counts from the sensor
b) subtract the previous count value to get the change in counts
c) divide that by the corresponding elapsed time

That's a good method to use for high speeds with a high-CPR counter, but it's not the best method to use for a one-count-per-rev sensor like what you have.

What you should do instead for a one-count-per-rev sensor is this:

a) instantiate your sensor as an up/down counter from the counter class and configure it to count up only
b) use the getPeriod() method in the counter class to get the period.
c) compute rpm = 60/period

Using that method, you should do much better than +/- 100 rpm.

5. We had to create our own homemade velocity pid loop. The motor will increase power by .005 each iteration of the code until we get to within, say, 1000 RPM. Then it will slowly move closer to the point, increasing or decreasing by .001 each iteration, and it will hold the same power once it gets within 100 RPM.

What you are describing is not a PID controller. It is a voltage-ramped on/off controller with a deadband.

[jordansch]

Here is a link to the .pdf: http://info.bannerengineering.com/xp...ure/129721.pdf

The reflective tape is roughly an inch away from the center to the wheel, and the radius of the wheel is roughly two inches.

Our team uses LabView to program our robot, and we are using the Counter Get vi to get the period. We then divide one by the period, then multiply the value by 60 to get our RPM. Attached is a screenshot of the code. The Boolean input is the "run shooter motors" button. The only real output is the Output indicator. The others, including the waveform chart, are there so we can monitor the value in the program during testing.

Apologies for the misuse of terminology. That was just the best way I could think of to describe the way that we coded the system.

[Kevin Sevcik]

Exactly which sensor are you using? There's about 10, heh.

At any rate, rough calculations indicate that you probably want a wider strip of retro tape. At 12,500 RPM, your 3/4" strip is in view for something like 500-600 microseconds. Which is right at the response time of your sensor. Doubling or tripling the width of the strip will at least keep you from risking a runaway condition where your wheel spins fast enough that pulses no longer register and you end up permanently driving the motor at full power until you disable your PID.

[Tom Line]

Our shooter currently runs up to 7500 RPM. We're using a Us Digital S5 optical encoder with 512 counts per revolution (good to 10k rpm). Originally we were using an optical encoder from digikey but at speeds above 5k it would begin showing noise (we were missing counts).

We attach it to the shooter shaft using surgical tubing to remove any alignment issues our hand-machining (aka dewalt drill) creates. You could attach the encoder to any protruding shaft (you almost always have at least one....)

[Ether]

Originally Posted by Kevin Sevcik

Exactly which sensor are you using? There's about 10, heh.

At any rate, rough calculations indicate that you probably want a wider strip of retro tape. At 12,500 RPM, your 3/4" strip is in view for something like 500-600 microseconds.

For students wanting to know how to do this calculation:

tapeWidthInches = 3/4
0.75
radius = 1
1
theta = asin(tapeWidthInches/2/radius)
0.384
tapeWidthRevs = (2*theta)/(2*pi)
0.122
rpm = 12500
1.25e+004
minutes = tapeWidthRevs/rpm
9.79e-006
seconds = minutes*60
0.000587
microseconds=seconds*1e6
587

Which is right at the response time of your sensor.

I don't see where they define what they mean by "response time". Is there a generally understood meaning of that phrase in this context? It seems it could have different meanings:

a) the pulse width must be at least that long in order to reliably be detected, or

b) the sensor takes that amount of time to respond to a pulse (and the minimum required pulse width is not specified)

Also, the "repeatability" is listed at 95 us. If that means random +/- peak noise, at 12500 rpm your sensed speed could range from 12,300 to 12,800.

...until you disable your PID.

He's not using a PID. But I suppose the same thing could happen.

[Ether]

Originally Posted by jordansch

Our team uses LabView to program our robot, and we are using the Counter Get vi to get the period. We then divide one by the period, then multiply the value by 60 to get our RPM.

That's the right way to do it. But see Kevin's post about the sensor's response time.

[Woolly]

We've actually been able to see speeds of ~6750 RPM this year with our 250 CPR US Digital Encoder.
All last year we were running ours at up to the rated 10,000 RPM before it would stop reading at least somewhat correctly.

In both cases we were normally running the wheel at roughly half the max speed.

[PhantomPhyxer]

Originally Posted by Ether

How fast is "that fast"? The OP did not say what speed they are running their shooter at.

A "standard" US Digital E4P 250CPR encoder, if setup properly*, should be able to easily handle speeds up to 5000 rpm.



If the spokes are not wide enough, that detector will have difficulty keeping up at high speeds.


* connect only Channel A. Leave Channel B disconnected. Instantiate it as an up/down counter in the Counter class, and set it to count up only. Set the FPGA sample averaging ring buffer to 125. Use the getPeriod() method in the counter class, and compute rpm = 60/(250*period). See attachment.

You are correct; last year our team had to change from Optical encoders to the US Digital EP4 Encoders but we use 360 count encoders last year and this year.

[Tom Line]

I wanted to update this post with some more info we found yesterday.

While the S5 encoder from US digital states a maximum rpm of 10,000, they only state that is for the bearings. In practice, we're seeing a loss of signal around 8600-8800 rpm. The sensor will begin missing counts and you will see a drop in rpm feedback as you increase the speed of the motor above that.

As a backup, we tried one of the $12 allied electric photo switches (more info on specifics elsewhere - just do a search). They don't have a response time listed so we had low hopes, and it didn't work.

We then switched to allen bradley photo switches from 2011. We have half the wheel colored black, the other half with reflective tape. We have extremely good feedback up to our max speed of around 11,500 rpm.

It appears, however, that this sensor is not widely available anymore. Does anyone have a source with reasonable shipping times? Is there a drop-in replacement that anyone is aware of?

[Mr. Lim]

Tom,

I personally have had a lot of success with Banner's QS18VN6D (IR) and QS18VN6LV (Visible Light - Red) sensors for these types of FRC applications.

They are close to a drop-in replacement for the ABs, but these only need 12V.

Sourcing them for us has been easy and fast because they used to come in the KoP, and being an older team we've built up a stockpile of them. You could probably call up one of more generous very old MI teams, and there's a good chance they'll have a bunch kicking around.

Else, you can order them direct from Banner at http://www.bannerengineering.com

We're using the QS18VN6D (IR) right now on our 2013 robot.

Sometimes it's easier to prototype with the QS18VN6LV (Visible Light - Red) since you can see the light being emitted, making alignment much easier. Even though the specs say it is supposed to be used w/ retro reflective tape, at close ranges (i.e. < 1ft) a black/white painted/coloured regular diffuse surface will work fine.