Shooter consistency
 

At our recent regional in Lubbock, we had an issue with our autonomous shooting not being consistent despite our measuring and adjustments to positioning. One of the ideas that came up was that a 13V charged battery vs a 12V battery may give the shooter more power causing it to shoot harder/higher. our shooter is a fixed position. Any ideas on what we can do to correct that or what may be wrong?

Re: Shooter consistency
 

Get a sensor to measure your shooter speed such as a halleffect sensor. By using the feedback of the sensor to determine shooter RPM you can determine if the shooter is actually at the correct speed. There are numerous ChiefDelphi threads about this.

Re: Shooter consistency
 

A standard encoder might not be able to handle a wheel spinning that fast. What we used was a photoswitch from the 2011 KoP to count the spokes on the wheel.

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

What kind of motor, gearbox/drive train, shooter wheel, material on the "fixed" shoe, any other disc guides?

Re: Shooter consistency
 

I can vouch for hall effect latch sensors on shooters and a well designed feedback/pid implementation. My team is able to pinpoint our desired speeds in about a second. We use a US1881 and custom pcb. Feedback from a sensor is key as others have stated, battery charge/quality can add a lot of variation otherwise.

Re: Shooter consistency
 

We had great luck putting a piece of reflective tape on our wheel and having the sensor count rotations of that instead.

Re: Shooter consistency
 

Good to hear.

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?

Re: Shooter consistency
 

I can definitely get an answer by tomorrow. I wasn't the one who worked with the optical sensor.

Re: Shooter consistency
 

Would voltage control mode on a CAN Jaguar be consistent enough to get away without a feedback loop? The way our shooter was done, I can't really see an easy way to add one. Transmission used belts, and the wheels we were given are Aluminum (so no magnetic sensor), and an encoder mount is impossible without redesigning the entire gearbox. We also used pneumatic tires with a custom machined rim (so no holes to track with an optical sensor). Unless we attached a magnet to the wheel and used a hall effect sensor below it... but that would destabilize the already fairly shaky wheel unless we used a *tiny* magnet.

Re: Shooter consistency
 

Betcha you could put a piece of reflective tape on your belt and use a IR proximity sensor on that. Don't get too attached on putting the sensor on some rotating thing, yeah?

As for the voltage control on a CAN Jaguar, that's better than nothing, not as good as actual feedback control. It will compensate somewhat for state of charge differences in your battery. It won't compensate for the spin down from firing a frisbee and it's going to deal poorly with rapid voltage changes from, say, your drivetrain or some other system making voltage fluctuate. Feedback is really the best way to go for getting fast, consistent shooting.

Re: Shooter consistency
 

Paint the wheel black and then attach a piece of reflective tape and use an optical sensor.

Re: Shooter consistency
 

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

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

Re: Shooter consistency
 

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.

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.

Re: Shooter consistency
 

What is your wheel diameter, what motors are you using, and are you giving 100% voltage to each one?

Re: Shooter consistency
 

How are you decoding the signal ?

Re: Shooter consistency
 

In theory the arc changes with changing launch speed. But if the shot distance is short enough and the launch speed is fast enough then the change in the arc may be small enough to allow some variation in speed and still score.

Re: Shooter consistency
 

Wheel Diameter: 4.875" Orange Banebots
Motors: 1 CIM 1 Mini CIM.
Both get 100% voltage. Minor (~4-5 feet) performance change between 2 mini-CIMs and 1 mini one full like we have now.

We were *shocked* at how easy it was. I was planning on making something very similar to what Jared described and doing a bang-bang controller on the final wheel, but we just don't need it at all.

Re: Shooter consistency
 

I'd agree with your original assessment. You're probably way past the point of diminishing returns on wheel speed, so slowing it down doesn't have much of a difference.

Re: Shooter consistency
 

Our discs fly in a very flat trajectory at the ranges we specifically target (all the way from just in front of the goal to about midfield). So flat, in fact, that our auto-aiming function simply aligns our shooter's angle so that the goal is in a constant place in the image frame coming from the arm-mounted camera. I had anticipated nonlinearities requiring a range-to-offset table (e.g. assume shot drop at longer distances and different trajectories at higher angles, etc.), but this turned out to be unnecessary.

Our shot trajectory is not very different with our nominal setup (3000 and 4700RPM) than if we run both wheels at 100% voltage open loop (~6000RPM). The real benefit of speed control/measurement in this application is that we can maintain a high rate of fire with consistent shots (we know exactly when we can fire the next shot), and we manage the wear on our BaneBots wheels by limiting the slip on the disc (and balancing the wear between the front to back wheels).

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

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?

Re: Shooter consistency
 

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.

Re: Shooter consistency
 

I don't see anything in the rules about it, so I would say no. It wouldn't hurt to contact FIRST and see if they can add the exception back in.

Re: Shooter consistency
 

many teams had great accuracy this year. What was really amazing is that both main types of shooters, linear and semicircle, worked great. 1706's shooter was deadly this year, but sadly teams caught on in eliminations and played excellent defense, a well earned victory. http://www.youtube.com/watch?v=U5PgpTQCgBc

Re: Shooter consistency
 

This is what we learned at our 2nd MAR district and we ended up with the most Autonomous points. We had the same problem. Make 3 in Autonomous and then for some strange reason, frisbees were high. So we said, slow down the speed. Didn't seem to help. Our analysis was that at slower speeds with the frisbee encountering a lot of air resistance, the frisbee had a tendency to "float" and end up high. We cranked up the speed (within reason - there may be a point of diminishing returns) and adjusted our angle. If you can not adjust your angle, then position your robot differently (works great when shooting from the side of the pyramid). This works. Watch how other teams shoot. Keep it simple and good luck!

Re: Shooter consistency
 

our team was having trouble with encoders as well. Yes different battery voltages do matter when sending a value to a Victor because the value sent to the victor is the equivalent of a percentage of your current voltage. So to try to get a better measurement, I tried a last minute fix.


Wheel Motor Voltage = Value sent to Victor * Battery Voltage.

Therefore, Value Sent to Victor(Or other speed controller) = (End Voltage / Battery Voltage).

All you have to tune is the End Voltage that you want your wheel to have. Batter Voltage can be calculated (in Java) by instantiating a DriverStation object and using the getVoltage() method.

Same method should be in other API's.

It didn't give us 100% consistency but it did significantly improve it. There are of course other variables.

Re: Shooter consistency
 

I'd recommend caution with this technique. You can end up with some interesting interactions since you'll be drawing more power, which will drop the voltage more, which will draw more power, etc. etc.

Re: Shooter consistency
 

You can have the best shooter consistency but you have to feed it first.

195 at Virginia could snipe cross field, but they suffered one flaw. THe hopper into the shooter was poorly fed. They had to jostle the robot to get it down several times, that threw off the aim.

1610 had jam issues twice and two different ways. They could get up close enough to the bar and touch it to line up but if the hopper jammed, it was for naught.

I saw another half dozen such jams, poor feeding issues, etc.

Great shooter or not, consistent or not, your hopper/feeder has got to provide the Frisbee.