Shooter consistency

[DampRobot]

Be fair warned, our software folk had a ton of trouble with the battery voltage dropping too low when we used the KOP photogates, to then point where they gave bad data. We were running 2 CIMs on our shooter, and the voltage the sensors were seeing dropped from 13v to 10v when we spun them up to full speed.

[Ether]

Originally Posted by Kevin Sevcik

Yes, though it's a little slow. You typically need a pretty wide stripe to get it to work. Too narrow a stripe and it won't register. Practically speaking, you can make the stripe take up half of whatever surface you're sensing and it'll work fine.

FWIW, the Rockwell catalog for the 42EF model sensor lists the "Response Time" as "1 to 16 ms".

It's not clear whether those numbers mean

a) the pulse width must be 1 to 16ms in order to be reliably detected, or

b) it takes the sensor 1 to 16ms to respond to a pulse (and the required pulse width is left unspecified, or

c) something else.

You need the stripe width to be 1/12 of a revolution at the point of sensing in order for it to be under the sensor for 1ms when the wheel is spinning at 5000 rpm.

[Ether]

Originally Posted by DampRobot

our software folk had a ton of trouble with the battery voltage dropping too low when we used the KOP photogates,

Read the last two paragraphs on page 2

Not sure if this rule exception is valid in 2013.

[thefro526]

Originally Posted by F22Rapture

Would the line tracking photoswitch from 2011 work, or is there another sensor that would be a better choice?

We use two of these on our shooter this year, one on each wheel, and used one last year. Thus far, they work really, really well. 'Jared341' can go into more specifics on the exact implementation if you PM him.

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

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

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

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

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

[Chris is me]

We have absolutely no speed control on our direct driven Banebots wheels. My theory is that the two-wheel combination as well as the slip in our system results in a consistent shot. I guess we're not exactly sure WHY it works, but it works.

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