Our team would like to have feedback from our shooter wheels, but we know that a problem occurs when there is feedback of 5000 RPM and over. Does anyone have suggestions as to how to get speed feedback from the wheels?
What problems occur? How many pulses per revolution are the encoders you are using?
We are working on setting up a latching Hall effect sensor, with one pulse per revolution.
I think there’s a thread about it here somewhere…
We’ll let you know how it works out.
The encoders that come in the kit are rated at up to 10,000 rpm. Even at that speed, that’s only ~42,000 counts per second. 24 microseconds should be plenty long enough between counts for the CRio to handle… I hope? Or is there something here I’m missing?
Here’s a thread from Jan 2010 on the NI forum. Can anyone confirm the advice given there is accurate and current?
*
*
Thank you. As we’ll be running much slower than 10,000 rpm and not taking advantage of quadrature (because we think it’s likely redundant at these speeds), I think we’ll be fine.*
and by that, I mean “our programming team is working on that as well as several other problems right now!”*
**and by that, I mean “how cool is it that 1551 can finally use the phrase ‘our programming team’ without being ironic?”
Just to clarify, those are the USDigital E4P encoders. The rotary magnetic encoders are effective up to 30 000 rpm, although they do detail in sect 8.6 how to account for latency.
We are planning to connect the encoder to the Jaguar, so the question from us is: how fast can the Jaguar count? I can’t seem to find that info in the Jaguar spec.
^^^that’s from the Jag’s microcontroller chip datasheet
this is from the datasheet for the Jag itself:
Our programmers are overloaded already from our pivot drive and targeting - ranging. To keep the rpm issue simple we are using another motor to generate a voltage proportional to rpm. Do an analog sample and feed it into the PID. They have this down. The counter and timing was confusing them with their all ready pressured state. The Crio has 12 bit 10 to -10 volt ability. We will take advantage of the 0 to 10 range for the first time. Should have something running this weekend.
Team 358 did a paper on this a while back:
*
*
I thought you guys had pivot drive all figured out. Are you doing something different this year?
*
*
Yes, the microcontroller in the Jaguar can handle 12.5 MHz, but that is when the MCU is running at 50 MHz. Jaguar firmware sets the MCU to run at 16MHz.
We specify the maximum transitions per second at 1 million. Yes, at 16MHz the MCU can read up to 4M transitions per second, but with 10K pull-up resistors and an unknown capacitance in the encoder lines, 1M is more realistic.
-David
Ether, Programmers graduate. This year it’s time for others to step up. The game this year is computationally challenging with the target acquisition, ranging and aiming. The pivot code has to be optimized or simplified to free up resources for the ball gathering and shooting. If they do not tighten things up lag will rear it’s ugly head. Our robot is programmed by student. If they do not write it, it does not go on the bot. Our programming mentor supports them and guides them but in the end the students must do it. I find it amazing that high school maturity students can step up and perform at this level But they do have limits. I’m trying to simplify the physical as much as possible to help them.
You’ve piqued my interest. How does your team measure throughput margin?
*
*