Hall Effect Latch as an encoder/counter?

[Al Skierkiewicz]

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.

[MrForbes]

That sounds like a neat way to do it. I didn't know they made such a thing as a Hall-effect latch.

http://search.digikey.com/us/en/prod...1EUA-ND/431867

(obviously we're trying to figure out how to do the same thing you are!)

[BitTwiddler]

In 2009 we used one of these on our turret.
http://search.digikey.com/us/en/prod...2021-ND/701375


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.

[Gdeaver]

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.

[MrForbes]

I ordered a couple of the latching hall effect sensors to play with.

[iambujo]

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!

[Gdeaver]

We put a 1/2 x 1/8" N52 neodymium magnet on the end of our shaft and get good readings out to 3/8" gap. Good non-contact sensing device.

[Al Skierkiewicz]

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.

[iambujo]

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?

[iambujo]

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?

[MrForbes]

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.

[BitTwiddler]

Originally Posted by iambujo

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.

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.

[iambujo]

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.

[twiggzee]

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)?