Quote:
Originally Posted by aphelps231
Our main technical mentor said we can't put an encoder on our shooter, driven by mini CIMs, because it would overload the code or something.
|
Encoder signal detection and processing is handled by the FPGA in the roboRIO. Your code runs in the CPU. So using an encoder will not steal resources from your code.
Quote:
|
Being the one who designed and built the shooter, I've been kicking myself in the butt trying to figure out how to get some type of low res encoder on it. So far we've tried a Hall effect sensor and a metal proximity detector, with magnets on the shaft and bolt heads on a hex hub, respectively. Both didn't work.
|
I wish you had posted here when you were trying to get it to work. Many many teams have successfully used Hall sensors for shooter wheel speed control.
Quote:
|
would an encoder reading downwards of 2,000 cps (counts per second, 5,800 RPM @ 20 ticks/rotation = ~2,000 cps) overload the code/RoboRIO?
|
No. See previous comment about FPGA vs CPU.
Quote:
|
I'd like to say no since the RoboRIO operates in the MHz (I think) and that should be plenty but id love it if you would share your experiences.
|
The FPGA samples the DIO for edges at 40MHz. This is completely separate from the roboRIO's CPU, which has 2 cores each running at 667 MHz. Your code runs in the CPU.
Quote:
|
The same mentor suggested we use an algorithm based on battery voltage to decide how much voltage to give the shooter.
|
This can help, but it's not as effective as using speed feedback.
Quote:
|
I really don't like this option, I'd rather run it open loop since battery voltage is constantly fluctuating.
|
The whole point of using a voltage-based algorithm is to compensate for the fluctuating voltage. But it's not the best way to control speed.
Quote:
|
There is a 20 tick encoder on andymark that mounts directly to a mini cim.
|
What is the part number of that encoder?