Im working on a magnetic sensor for our shooter this year. We can get a reading off of it using the counter class. The problem is that it keeps counting. Is there a way to set some kind of interupt so it reset every second so we can get a type of rpm?
What kind of magnetic sensor is this? How many counts are you getting per revolution of your shooter wheel?
i believe it was this one im not 100% sure because i dont have the packaging its with the our other robotics stuff right now.
Hrm. Are you using that to sense a magnet on a wheel, or teeth on a gear? I’m trying to figure out how many counts per revolution of your wheel you’re expecting to get. If you’re only expecting 1 count/pulse per revolution of your wheel, there’s a better way to determine your wheel speed.
I can get a reading off of it by using the counter class and counter.Get();
You seem to be in a sort of no-man’s land here with that setup. You should be getting 6 counts per revolution like that. That’s not enough counts per second to do any reasonable speed control. On the other hand, it’s probably too many counts per second to use 60/counter.GetPeriod() to give you an RPM to control. You can try this method, but I don’t think it’ll be super stable for your current sensor setup.
What I’d recommend is changing your sensor to this:
Then gluing a small magnet to your wheel with the south pole facing that hall switch. That will work similarly to your current setup, except you’ll only get one pulse per revolution, which will make the 60/counter.GetPeriod() RPM value much more stable.
Your other option may be to change out 5 of those screws with flat head screws and countersink the holes so that the you only have one screwhead that will trigger your gear tooth sensor.
Or, if that aluminum hub has a setscrew in it, you might re-orient your sensor to pick up the setscrew as it comes around. Or add a setscrew just for this sensing purpose. The whole idea here is that you only want one pulse per revolution of the wheel.
If he’s getting good counts with that sensor, all he has to do is change the getPeriod() FPGA sample averaging ring buffer from the default value of “1” to “6”.
For Java and C++, this requires making a small change to the WPILib code.
So im still confused how will that help me? im getting current counts and its counting right i checked it. for the rpm im planing on doing something like:
Counter gts; float rpm . . . rpm = ( ((1/gts.GetPeriod())/6)*60)
I might have missed a ( somewhere
I thought there was something like that, was just leery to suggest it because the period between each of the 6 pulses would likely be a bit different. Though I suppose it works out with a buffer of 6, as it’d have a full revolution of pulses, so physical variance between the pulses should cancel out.
You other other option is doing as Ether suggests and changing the averaging ring buffer for the counter, then using 10/counter.GetPeriod() as your feedback RPMs.
The idea there is correct, our concern is that your screwheads aren’t perfectly spaced and there’s 6 of them. That means you’re going to have a noisy signal. 6 screws means pulses are 1/6th as long, means at 5000 RPM, your period is 2ms. Ether will probably come in with the exact formula for how much inherent noise you’ll see in a 2ms period, but it’s definitively more than with the 12ms pulse. Add in the fact that each screw head is going to trigger the pulse at a different time, and you could end up with pretty noisy feedback that won’t be fun to control.
You can fix that by making the edit to WPILib that Ether suggested. That will create a buffer of the last 6 period measurements and output the average of those. That means you’ll get an average over all 6 of your unevenly spaced screws, which will even things out and greatly reduce the noise in your feedback.
So where is this file that i have to change?
EDIT: found it
so now my function would be
(1/gts.GetPeriod)/60 which would give me my rpm right?
Your question was answered in a previous post.
ahh kk ty
Well i changed that values from a 1 to a 6 so it looked likes:
Then in my code I have this:
float rpm Counter gts; . . . rpm = (((1/gts.GetPeriod()) / 6) *60);
to find the rpm and when i print out the rpm i get strange results. most of the prints say inf the others say something like 23334.053 for rpm. What is going on with that?
Inf would be because you’re getting 0 for the period. Try setting the MaxPeriod to something reasonable. gts.SetMaxPeriod(0.25) or so. The counter class clears out the buffer if it doesn’t see a pulse in within MaxPeriod seconds, and I don’t know what the default is. Past that, I made my own class that did a little filtering of values so I’d ignore values I knew were bad. I’ve attached the files, you can try using it. You’d just need to modify “prevResult = 60.0 / period;” to read “prevResult = 10.0 / period;” And you’d want to reduce periodThreshold in the .h file to something like 1e-3 just so it doesn’t limit the max RPM to something less that what you can actually output. It’s set up so you can use it as a PIDSource for a PIDController.
RPMCounter.h (1.04 KB)
RPMCounter.cpp (2.04 KB)
RPMCounter.h (1.04 KB)
RPMCounter.cpp (2.04 KB)
i changed :
and im getting a consistant rpm with that function i had in there. every once and a while ill get a blip of 30k rpm or something should the set max period fix that?
Edit: consistent rpm of 247 rpm when i do
Does it looks like your wheel is turning at 247 RPM? That’s about 4 revs per second. Max period wouldn’t help with the 30k blip. That’s why I added a minimum period check in my RPMCounter class to ignore any period values that were obviously too small. Max period will help if your feedback is going from some number like 100 straight to zero. or flashing between 0 and 100. That’s the counter thinking the wheel hast stopped and sending a 0 for period, then sending a good value when it sees the next pulse. Less likely to happen on your setup since you have 6 screw heads.
The 30k problem might be your screwheads. The GTS might be picking up the small gap in the screwhead for the flathead screwdriver. Using a hex-head fastener or something without the gap in the middle would probably work better.
ok sweet the only problem im having now is the random blips of high rmp you said that in your rpm counter class you used a function to ignore small rpm can i do that to ignore the high ones as well?
Take a look at the RPMCounter class I uploaded. In the GetRPM function I’m comparing the period with a constant value I set in the .h file. The idea is that if the period is less than some value, you ignore it and return the previous value.