Hello -
I have been looking at other methods to count rotational speed of a wheel, in this case of a wheel could be spinning at 50+ Hz. Those US Digital KOP sensors have their place, but can be hard to work with if they are not going on a COTS transmission/gearbox with the correct size shaft already available. I am not concerned about direction.
We first looked at the Rotary magnetic encoder in the FIRST Choice parts this year, but that isn’t going to work based on the data sheet. It provides angle based on the orientation of the magnet’s poles, and I don’t think it would be realistic to sample it at a high enough frequency to catch a desired analog value or PWM width.
I had some Melexis US1881 Hall-Effect latches sitting in my bin of goodies and figured they might work as long as their switching speeds were fast enough and they were sensitive enough. We bench tested today with a CIM and two magnets (one north oriented, the other south 180 degrees seperate on the hub). We spun up the motor and got a perfect square wave on the logic analyzer over the whole range of RPMs. The thought is to just pass this output into a digital input, run the wpilib counter and timer functions on it and calculate frequency.
So this brings me to my question - has anyone done this before successfully on a competition system? It seems to work great as a bench test proof of concept. The biggest concern I have is ensuring we mount the magnets safely on the wheel. I looked through the robot rules manual and didn’t see anything excluding the use of magnets (in general or in a manner such as this).
Have you looked into reed switches? We were thinking about using them as limit switches – that way, we could directly connect them to the jaguar’s limit switch pins.
Iam,
There doesn’t seem to be any rule that would prevent this application. I would tender that answer with a caveat to insure that magnets do not come loose on the wheels. Traversing the barrier is going to put a lot of stress on wheels and typical plastic hubs will take the brunt of the shock causing deflection and breakage. Should your magnets find their way into a competitors robot during competition, there could be nasty results. While the hall effect sensors meant for the transmission are difficult to use, they do produce significant resolution when used on the high side of the reduction.
It’s designed for counting gear teeth but any ferrous material passing by it will trigger a detection. We counted the number of times a screw head mounted on the end of our roller/shooter would zip by the sensor.
Our programmers are having trouble with the timing concept but have it for distance traveled. Have not tried it for the shooter. May go the analog route for the shooter.
Squirrel - that’s the part I have had good luck with. I got it from sparkfun.
Al - We are looking to use this on a flywheel (hint hint). So I hope it won’t take as much abuse as a drive-train wheel, but it will be spinning faster so loose parts would be even more dangerous. If we can’t be sure we can attach safely we will certainly abandon the idea for this application.
As for a reed switch. I have never used one. They contact due to magnetic field detection, but it is a mechanical motion right? So I was concerned about lifespan (how many times are they design to switch) and switching speed. I am certainly curious if someone thinks they can work for this as well.
I really like the looks of that Honeywell sensor mentioned above. That’s a pretty steep price compared to the hall latch (under $1), but if it provides a simple and stable solution it’s certainly worth trying out.
I love FRC build season - it really gets the brain going non stop!
Reed switches might work for your application but they are notorious for generating noise (contact bounce) so you need to take appropriate steps for accurate readings.
FYI - I have done a PCB layout using expresspcb.com’s service and the boards should be in tomorrow. If all goes well we are considering ordering a larger batch to sell kits/assembled units for those not ‘in the market’ of developing their own sensors. Would anyone be interested?
And here is the assembled and functioning PCB. It is about 1.75"x.75". Hope it works out our pitcher this year! I used expresspcb.com’s SW to do the layout and used their protoboard service for the board manufacturing.
We have not tried interfacing it to SW yet, I hope to on Saturday.
squirrel - If you don’t mind me asking - was your team able to use encoder lib calls from WPI or did you have to build your own timer/counter algorithm for the hall latch?
I don’t know of having got that far yet, we got the sensor wired up and working but haven’t actually tested it with running motor…hopefully first thing tomorrow afternoon we’ll get working on it, since we finally got the new shooter (with a place to put the sensor and magnet) put together tonight.
I like the layout on your board. I suspect the LED is totally superfluous for operational purposes but will be useful in ensuring things are working. Let us know how it works out.
One of our students wired up our prototype sensor board. Its a kludge but it appears to work when we watch it with our handy-dandy voltmeter. More testing will be required. Hopefully the counter vi in the WPI library will work well with it but we aren’t there yet.
Thanks. Yup the LED is for user feedback only, it tracks the state changes of the output. I dislike that most of the typical KOP sensors have no visual status that they have power and are functioning.
We have 9 PCBs and parts enough to solder them up. Once we are sure the design is working we’ll probably make some of them available if anyone is interested, just PM me. If there is interest we can order more boards.
Our team is considering using this as an encoder/counter as well. my concern is that it might not work as well at high speeds.
if, for example, a wheel was rotating at 5000 rpm = 83 rps = 0.083 rp(ms) and the teleop loop runs every 20 ms, then that would mean that the wheel would have spun 1.67 times before the next cycle in the teleop loop. wouldn’t that mean that we will miss a revolution every now and then?
by those calculations, the max speed of a wheel that the sensor could measure is 1/20 rp(ms) = 50 rps = 3000 rpm???
on top of that, the hall effect sensor we have is latching meaning it turns on when a north pole passes it and turns off when a south pole passes it (i might have that backwards). so that means it actually has to count twice as fast and max speed of the wheel is only half of that 3000 rpm.
is this the right thinking? i’m kind of new with coding sensors so excuse me if this is totally wrong.
we’re using a banebots motor with an enclosed cim-u-later gearbox so we can’t mount it anywhere else other than the wheel. we’re trying to avoid having another auxiliary gear system just for the sensor (that’s why we can’t use an encoder).
any ideas on how to get around this in the code? or perhaps a different sensor (other than an encoder)?
The counting is independent from the loop. The FPGA (hardware) does the actual counting. All your code does is ask it for it’s current count. Note that the FPGA can only handle up to ~39000 pulses per second.
We have gone to an analog solution. We took a wire coil, some metal and a 12 pole magnet to make an alternator. We get a AC sine wave voltage output proportional to RPM. Next the AC is passed through a full wave bridge and then filtered by a cap and resistor. We then have a nice clean DC voltage that is proportional to the shooter RPM. One of our mentors brought in a scope to check the ripple and we have a nice clean responsive output. Also, the C-rio AD Is -10 to +10 volts. At full speed we are above 5 volts and are taking advantage for the first time of the high resolution that is available. So far it seems to work well. We originally used a small DC brushed motor until we got shot down by the GDC in a Q and A. Hint have you ever taken a stepper apart? There are many advantages to this kind of Tach.
I used 