Dice analyzer machine project

[mouser]

So here is another article on someone who build a dice fairness machine:
http://science.slashdot.org/story/15/12/01/1715253/experimental-study-of-29-polyhedral-dice-using-rolling-machine-opencv-analysis

And here's a video of their device:

https://www.youtube.com/watch?v=UdA5ydENTHY

Basically its an arduino controlling a cup that shakes up a die and then a camera that senses what the die rolled, and it is used to test whether a die has equal probability of landing on each face.  [results show that physical dice are always somewhat off from fair].


I *love* this idea as a piece of modern artwork.. I'd love to have something small and beautiful, a standalone little thing that i could put on little coffee table (i'm thinking like an old ticker tape stock market machine), where you could just drop in any die, and have it do some automated testing for several hours and report out the statistics of a die.

I'd be willing to collaborate on writing the software if someone would do the hardware..  Raspberry pi, arduino, whatever.

Key is it has to be BEAUTIFUL and SMALL -- i'm interested in this as a piece of art.  Something like:




Other web pages that have done this kind of thing:
http://www.markfickett.com/stuff/artPage.php?id=389
http://timothyweber.org/dieroller
http://deltasdnd.blogspot.com/2011/10/testing-balanced-dice-power.html

[mouser]

So, as a lark I have been working on software for this, using Python and OpenCv:


It's not nearly as simple as it may seem, but lots of interesting machine vision issues to deal with.. I've learned more about the Stroke Width Transform and binary thresholding than I ever though possible.

The heart of the problem is getting something fully automatic and reliable, that does not need any human tuning based on the color of dice, etc., and dealing with different kinds of dice (pips, numbers, custom art).

Sometimes the difference between a 6 and a 9 is a tiny little dot present at the baseline.. otherwise known in machine vision as "noise"...


I have not spent much time thinking about the hardware.. that will come after..  I'm thinking Raspberry Pi with a nice touchscreen.
The two challenges with regard to the hardware are how to create a dice jumbler that can sufficiently randomize a die while looking like a nice piece of art, and the second is creating a sufficiently predictable background for the die (that is, ideally i'd like a die pretty well centered on a plain colored background with no shadows). 

One can consider two kinds of basic designs: Camera looking down vs camera from underneath.  Both have their own sets of difficulties, both in terms of hardware implementation and in terms of software vision processing.

[p3lb0x]

If anyone comes up  with a good idea for hardware and is willing to put down some money (I'd of course spend some myself), I could probably try building it.

[mouser]

Progress on code to extract and isolate the upright die face image:

[Deozaan]

I'm just commenting to say that I find this project interesting. Keep us updated.

[Target]

be interested to hear what constitutes a fair toss - several ideas come to mind, but this being 'controlled' I'm guessing there are some sort of expected 'standards'

[mouser]

Visualizing extracting foreground labels and rotating/scaling:

[mouser]

I definitely do need help with hardware -- both ideas and construction.

[wraith808]

so, it's recognizing based on pre-seeded shapes and orientations?  What about orientations that are not fully face up?  I see that in the d4 in your examples... do you just pre-extract those positioning?  So you have to know the geometry of the dice?

[mouser]

That image with the rotated shapes is just a little graphic i'm using to test my rotation and normalization function -- it's not meant to be instructive of anything, just a fun visual.


With regard to identifying dice faces, there are many alternatives, and different techniques needed for different dice.

Some examples:

For D6 dice with pips, the whole thing is quite trivial -- you can just COUNT the number of circular pips on the die face of a reasonable size, and as long as the die is reasonably centered under camera, the other faces don't interfere much.
In short, for D6 pip dice, the whole thing becomes relatively trivial.

Now for larger sided dice with labels, things get considerably more complicated because other faces (in addition to the face up on) are visible to camera, so that has to be dealt with.
This is a case where die geometry can help a lot -- and the more you can figure out the geometry of the front face the better you can isolate the front face from neighbors.  Unfortunately it's not an easy problem and the more the die is out of center the harder it is.  I can get pretty good results by identifying the CENTER of the die and then finding the graphic nearest the center..

In addition, there is no simple way to identify the face graphic identity as their is in counting blobs with pips.

In fact, the difference between a 6 and a 9 is often a tiny little dot.
However, for dice which are using numerical labels, you COULD train a learning algorithm (neural network, support-vector-machine, etc.) to identify numbers (from 1-20 let's say).  You might have to train several models based on different fonts, etc. but it's doable.

Now there are other kinds of dice which have CUSTOM graphics on each face (not numerical labels); for those, training a learning algorithm to do classification on a new kind of die would be much more painful for an end user.  it could be done but it would be INCREDIBLY time consuming for both man and computer doing initial training and hand LABELING.

The alternative with custom graphics is something like k-means clustering, where i tell you there are 6 custom die faces, and the computer can roll the die a few hundred times and try to separate all the front face graphics it sees into 6 "classes".  It doesnt know what the faces mean it just has some metric of similarity that will allow it to group them such that the same face is put into the same group reliably.

What i'm playing with in the image you see above with the ROTATED versions, is this latter idea -- of extracting foreground graphic and scoring it against previously seen graphics -- because this method is theoretically the most universal and requires no training.

So basically i try to identify foreground graphic, normalize it's size.  And then given any two captures, i will score their bitwise similarity (considering rotations).

[wraith808]

I have one for you that's becoming pretty popular these days in gaming - Fate/Fudge dice.

http://www.evilhat.com/home/fate-dice/

http://rpg.stackexchange.com/questions/39/what-can-i-use-in-place-of-fudge-dice

Fate Core is becoming quite popular in gaming, which drives the popularity of these dice.

[mouser]

Woo hoo!  My rotation and scale invariant recognizer code is working quite well (if the extraction of foreground is successful).
I think if i can get the foreground extraction fairly reliable, the recognizer code is going to behave quite robustly and be able to work with dice with arbitrary graphics.

[MilesAhead]

A few things to watch out for on your project.

Try to insure that:

a) the software does not crap out
b) the hardware does not spin out of control
c) that not too much of a load is placed on the system
d) try not to shave the parameters too closely
e) stop trying to do things the hard way
f) figure out how to blow on the dice through all that water
g) play audio in the background such as "baby needs a new pair of shoes" for verisimilitude

[wraith808]

I guess the reason that I was showing you those is to give you a challenge... with the multiple sides being the same

[mouser]

Multiple sides being the same is not a problem, as long as you tell the system ahead of time how many UNIQUE sides there are.
If you tell it there are 6 unique sides but really there are only 2, the system will find a way to group the images into 6 unique sides (e.g. differentiating two otherwise identical sides based on a small piece of dirt or minor discoloration).

[Deozaan]

Somewhat off topic, but, wow! These Dicecards are cool!

https://vimeo.com/55360505

http://dicecards.com/

[mouser]

now that is cool.

[wraith808]

now that is cool.

Yeah... I was on the kickstarter.  They were so cool, that I ordered more after.  I think he's out of stock on them now, however, and not planning a reprint.

[Deozaan]

now that is cool.

Yeah... I was on the kickstarter.  They were so cool, that I ordered more after.  I think he's out of stock on them now, however, and not planning a reprint.

He's selling a PDF for $5 which you can use to print your own:

http://www.drivethrucards.com/product/152577/Dicecards

[Ath]

My rotation and scale invariant recognizer code is working quite well (if the extraction of foreground is successful).

I assume you developed this on Windows, using C/C++, but will it run on a Raspberry Pi? Or does it require specific libraries or a specific amount of CPU power?

Don't expect it to run on Windows 10 IoT Core for RPi 2, as that darned 'thing' takes around 5 minutes just for booting into the 'desktop', and you'd have to rewrite your code into .net universal code (C#), and not much of a GUI. I've given up trying for this IoT incarnation, just using Raspbian (Wheezy/Jessie) for my RPi-IoT projects

[mouser]

currently it's python code using opencv machine vision library, both known to run well on raspberry pi.
pure cross-platform commandline tool, no gui.

i will eventually have to write c-for-python-module versions of a few of my key python routines in order to get them running fast enough to be suitable for a raspberry pi.

some unknowns:
issues regarding using a cheap raspberry pi camera.
coding eventual GUI interface using touchscreen raspberry pi touchscreen.

[cranioscopical]

The heart of the problem is getting something fully automatic and reliable

I had a go at this but… no dice.

[Ath]

currently it's python code using opencv machine vision library, both known to run well on raspberry pi.
pure cross-platform commandline tool, no gui.

Great, I love cross-platform solutions

some unknowns:
issues regarding using a cheap raspberry pi camera.

I don't have one of those, but have not heard bad things about the 'original' RPi camera, it seems to be quite reliable as there are several projects using them, even for recognizing the surroundings in semi-autonomous robots.

coding eventual GUI interface using touchscreen raspberry pi touchscreen.

I have that touchscreen, but I still have issues with typing on it, even using the recommended on-screen-keyboard drivers, and also the screen-space is quite limited at 1280x800 800x480 pixels, even using a webbrowser is a chore
The touch-input for moving the mouse is comparable to a 7" tablet, but Raspbian Jessie is not yet very optimized for touch interaction

[mouser]

Here's a screenshot showing the tool extracting the foreground label of a "camoflaged" die.

For dice with clear foreground vs background contrast, an automatic thresholding filter is used to automatically separate foreground from background, but with "noisy" colored die, the user must "calibrate" the die by clicking on a pixel in the camera image that is part of the foreground label.    At that point the system finds the major colors in the image (k-means clustering) to quantize colors (about 8 classes works fine) in the LAB colorspace, and identifies foreground as color-quantized pixels closest to the foreground color.

With foreground pixels identified, the shape of the die (and other tunable per-die-type parameters) are used to try to identify only the top die face and exclude any foreground labeling/graphics which are on side faces.  This can be tricky, and works best if die is fairly well centered under the camera.  Certain dice shapes are harder than others because they have irregular shapes (d10 for example).  In the screenshot below you can see the white circle on the 3rd image from the bottom left indicating the area in which the program expects the current die fact to be circumscribed.  This case is fairly simple -- but there are cases where it's non-trivial to determine when a label belongs to the front die face or a neighboring one.

[mouser]

And here's a screenshot of the tool running in "guessing" mode with that same die.

On the top left you see the live camers image, with inset view of the extracted foreground facing die label.
On the bottom left you see the training image for the 20 that the program saw in a previous labeling/training stage.
Note that it has ONE photo of EACH die face that it uses as it's prototype -- there is no training procedure per se, it's just one example of each die face.  In fact as you can see in this case, it's not even of the same die, just another d20 with similar font.

Then on right hand side you see the results of trying to match against it's stored set of 20 prototypes, showing the top 4 candidate matches, rotated and scaled in an attempt to find the best aligning match.  The right-hand window of each pair shows the "difference mask" after some processing.  So you can see how the "20" is the best match -- which you can see reported at the bottom. (confidence score reflects the difference between best match score and next-best match score).