Hall Effect Latch as an encoder/counter?

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

[cgmv123]

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.

[Gdeaver]

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.

[twiggzee]

Originally Posted by cgmv123

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.

I'm not familiar with FPGA hardware. Is that something in the digital sidecar or the digital module? How would one access the current count in the code?

[Ether]

Originally Posted by twiggzee

How would one access the current count in the code?

Look at the Counter class in WPILib.

[twiggzee]

great, thanks!

[iambujo]

As a followup to this thread, we have fully integrated the custom hall effect sensor into our 2012 robot. Using the WPI counter libraries we are able to get the current speed of the wheel. The shooter goes upwards of 4000 RPMs and the sensor as no issues in keeping up. We mounted 2 tiny rare earth magnets 180 degrees out of phase, opposite poles. So a single period of the square wave is 1 rotation.

I believe SW is now using getPeriod() in the counter class, but if they called it too often it sometimes had bad data (I guess before the period completed or before the internal API was about to update the value from the hardware?).

[twiggzee]

Originally Posted by iambujo

As a followup to this thread, we have fully integrated the custom hall effect sensor into our 2012 robot. Using the WPI counter libraries we are able to get the current speed of the wheel. The shooter goes upwards of 4000 RPMs and the sensor as no issues in keeping up. We mounted 2 tiny rare earth magnets 180 degrees out of phase, opposite poles. So a single period of the square wave is 1 rotation.

I believe SW is now using getPeriod() in the counter class, but if they called it too often it sometimes had bad data (I guess before the period completed or before the internal API was about to update the value from the hardware?).

can you verify that the getPeriod method in the counter class works? i've tried using it but only get "infinity" when i run it...

[wilsonmw04]

Originally Posted by twiggzee

can you verify that the getPeriod method in the counter class works? i've tried using it but only get "infinity" when i run it...

We are getting the exact same response. Can anyone shed some light on this?

We are getting a good square wave when hook up the sensor to a scope.

We can't even seem to get a count on this channel.

We have encoders working on the drive train, but we can't seem to get anything from this other sensor.

[wilsonmw04]

We could not find a sample code for what we were doing, but we got it working.

We forgot to call Start() method. So the return count was always 0 and the period was always "Inf." After we called Start() we are in business!