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?
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.
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.
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.
What we used was a photoswitch from the 2011 KoP to count the spokes on the wheel.
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.
What kind of motor, gearbox/drive train, shooter wheel, material on the “fixed” shoe, any other disc guides?
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.
We had great luck putting a piece of reflective tape on our wheel and having the sensor count rotations of that instead.
Good to hear.
Would you mind answering a few questions to make this useful for other teams?
-
What optical sensor are you using?
-
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?
-
What wheel speeds were you measuring?
-
Were you indeed “having the sensor count rotations” or were you using the FPGA to measure the period? (That’s an important distinction).
-
What speed control algorithm did you use?
I can definitely get an answer by tomorrow. I wasn’t the one who worked with the optical sensor.
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.
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.
Paint the wheel black and then attach a piece of reflective tape and use an optical sensor.
Would the line tracking photoswitch from 2011 work, or is there another sensor that would be a better choice?
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.
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.
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.
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.
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.
Sorry it took so long for me to respond.
-
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).
-
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.
-
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.
-
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.
-
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: