Hi,
I am wondering if someone knows where to buy an arduino compatible wheel encoder? I want to use it to make a mini fortune wheel game for the kids.
Probably going to have to make your own.
Two sensors.
One tripped once per revolution of wheel... to give you "start counting" signal.
Other tripped 20 times per revolution if your wheel has 20 segments with fortunes to be won.
Hope that makes sense?
What sort of sensor? What sort of tripper? That's a matter for your level of interest and "carpentry" skills. I'd probably go with a twin post IR emitter/ detector sensor, and little blades projecting down from the wheel.
Or magnets activating reed switches or Hall effect sensors.
Raid an old computer mouse perhaps?
Here's a wheel.
Create your wheel with enough steps to match the number of places on the "wheel of fortune" and set the bits to hold that many steps (e.g. 20 positions would require 5 bits, 16 + 8 + 4 + 2 + 1 > 20). You'll then need an equal number of IR sensors as bits in your wheel; this board from Pololu will provide 8 bits which would be enough for a 256 position wheel.
Use "plain binary" encoding or the developed wheel will confuse you. The outer ring is the 1 bit.
Use "plain binary" encoding or the developed wheel will confuse you.
Ah! But where's the fun in doing things the simple way??
Seriously: If you are going for a multi-bit aboslute position sensor, it is worth mastering the "confusing" Gray code....
Ok, so I may make one an encoder.
After looking at the info above I think the Gray code is the way to go since it will always know the position of the shaft without a need for an index.
My questions are:
How many bits do I need for 360 points / rev. 8 Bit?
I am using this to make the wheel, but am confused what settings would work best
http://www.bushytails.net/~randyg/encoder/encoderwheel.html
In regards to sensors, how narrow of a "line" will they work with?
2 ^ 8 = 256, and 256 < 360.
2 ^ 9 = 512, and 512 > 360. You need 9 bits.
Y'know, 360 positions on the wheel is an awful lot of positions. Is this going to be a huge wheel?
Regarding Gray code vs. binary, both encodings will still give you absolute positioning. The difference is that with consecutive addresses in the Gray code that there's only ever one bit of difference; in other words if the wheel happens to land between positions then there's only ever one bit that is different. That's advantageous, but it also means that the positions will not be consecutively numbered as they would with plain binary encoding.
According to the specs for that Pololu board I posted a link to, the sensors are 3/8" apart and the optimum sensing distance is 3mm. I'd have to think that they'd be fine sensing a 3/8" wide band. Of course, if you screw up your wheel you can always just print up a new one.
So you know the number of positions you need, you now know how to select the right number of bits ... the rest of it is just the sizing of the wheel and whether or not you want guidelines, etc, and that's going to be trial and error. Good to go from here?
Hello JJ48956,
Velleman has a kit called MK152
http://www.vellemanusa.com/products/view/?id=351406
that mimics electronically the Wheel Of Fortune function,
That is , push the button to start a spinning action and the
spinning speed gradually decreases until finally it stops
and one LED remains lit.
There is a schematic of the MK152 on the assembly manual at
http://www.vellemanusa.com/downloads/0/minikits/manuals/manual_mk152.pdf
So the trick would be to translate the Wheel Of Fortune function
created with discreet components on the MK152 to code for an
Arduino sketch. Also one would be limited to 13 positions on the wheel
because there are 13 digital outputs on the Arduino. Might be able to
to go to 26 or 39 with some register shift tricks to mulitply the
number of outputs.
Allen in Dallas