Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

Read the last two paragraphs on page 2

Not sure if this rule exception is valid in 2013.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

Please do, if you have it handy

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


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

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.

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

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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

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.


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

Re: Shooter consistency
 

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