When it comes to getting the shooter velocity, we have a prox sensor that registers one raised edge per shooter rotation, and then we use the Counter class in LabVIEW to handle the input. This uses the FPGA to calculate the MS time between raised edges of the input (don’t have access to the code and the specific VI) and we just convert that to RPM.
Something like that may be possible with these encoders, if the FPGA can register all of the raised edges. The only issue we have found is that we occasionally get very large times resulting in astronomical RPMs (nearing 100,000 I believe). We just throw those out and feed in the last code cycle’s RPM value.
It doesn’t look like I’ll have a chance to write code to test, or use Bill’s, on a robot before Championship.
Specifically, we are using the WPI_CounterGet.vi, and the Period (sec) output, then dividing 60 by that output to obtain RPM. If you had more than one rising edge per wheel rotation, you could presumably multiply by that factor to obtain RPM.
IIR filtering is related to one of my favorite jokes (explaining the difference between math/science and engineering):
There’s a game show and the contestants are a mathematician and an engineer (both male).
The host explains the game as follows: There’s a beautiful model on the other side of the room. For each question the contestants answer correctly, they get to move half way toward the beautiful model.
At that point the mathematician throws his hands up in the air in anger: “What’s the point! If I move halfway there every time, I can never get to the model! This is pointless.” Then he storms off the stage.
The host then turns to the engineer and says, “after hearing that, why are you sticking around? You can never get to the model!”
The engineer says, “while everything he said was theoretically correct, I can get close enough for practical purposes.”
(rim shot and laugh track here)
How does this relate to IIR filtering? The part of “you move x-fraction of the way toward the goal” is what IIR filtering is about. It’s called “infinite impulse response” because you can NEVER get to the goal because you always approach it at a fixed fraction of the way there.
FIR filtering (Finite Impulse Response) means you actually get to achieve your goal (hence the “finite”). If the game show were changed to: “the model is 100 feel away and you get to move 10 feet closer with each answer”, that would be an FIR filter - in 10 answers you would get to the final result.
(my answer about how we’re filtering is in a future post - I didn’t want to clutter my joke with too much other stuff)
We’ve settled on PID because we simply can’t get the bang-bang method to give us better results. The real issue that I think I’ve hit is mechanical - we’re at the limits of what our system can provide. No matter how we play with gains, filtering, etc, we’re struggling to get the shooter more than +/- 40 to 60 rpm (actual RPM, not filtered much at all other than to remove big spikes that are obvious errors).
Filtering the speed before our ‘enable shooting’ vi really doesn’t help shooter run any more consistently - it just makes it easier for us to check the limits.
I did put a 4 sample moving average in to filter the pid input. That helped with some of the oscillation. We also turned down our proportional gain (we wrote a velocity PID, we’re not using the position PID) to help some of the oscillation. The shooter still spins up in around 2 seconds, but that helped the oscillation as well.
I had hoped to manage a major improvement before nationals. We’ve improved our velocity control probably 50%, but other folks are reporting numbers that are still close to 100% better than ours. That means that in real time ball shooting, we’re seeing something like +/- 1 foot in height when hitting the backboard.
Hey, I didn’t read the whole thread but just wanted to mention that this will not work with a Spike. I haven’t tested, but a while ago I read into how the Spike works and it cannot coast, it either powers the motor or breaks.
Custom circuits shall not directly alter the power pathways between the battery, PD Board, speed controllers, relays, motors, or other elements of the Robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the Robot’s electrical system is acceptable, if the effect on the Robot outputs is inconsequential.
Or, more likely this one:
All electrical loads (motors, actuators, compressors, electric solenoids) must be supplied by an approved power regulating device (speed controller, relay module, or Digital Sidecar PWM port) that is controlled by the cRIO on the Robot.
Each CIM motor and Fisher-Price motor must be connected to one and only one approved speed controller. These motors must not be connected to relay modules.
Servos must be directly connected to the PWM ports on the Digital Sidecar. They must not be connected to speed controllers or relay modules.
If used, the compressor must be connected to one and only one approved relay module.
Each other electrical load (motor or actuator) must be supplied by one and only one approved speed controller, or one and only one relay module.
Electric solenoids may alternatively be supplied by a Solenoid Breakout Board connected to the NI 9472 cRIO module, which is powered by 12V.
As for the Spike, I’m not sure.
I remember hearing/reading about it being one, and it seems to behave like any electro-mechanical relay I’ve used also. (Mainly, the clicking sound when it switches)
Neither of those rules seem to apply unambiguously in this case. The first rule you cited arguably doesn’t apply (“custom circuit”) and the second rule explicitly allows a Spike to be used to control certain motors.
(Mainly, the clicking sound when it switches)
Well that seems like a dead giveaway. I’ve never listened to one. (And if I had, I probably couldn’t hear it anyway).