ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

Dice analyzer machine project

<< < (17/19) > >>

Deozaan:
Are the numbers in those statistics ordered? e.g., If it rolls a 19, is that a 19 on the chart? Or is it more like "recognized pattern number 19" (referred to as classes in this post)?

And finally, how do you eliminate the possibility that it's your rolling mechanism which is unfair?

mouser:
If it rolls a 19, is that a 19 on the chart?
--- End quote ---
yes, after the system creates its clusters automatically, i rename the clusters according to their die faces.

And finally, how do you eliminate the possibility that it's your rolling mechanism which is unfair?
--- End quote ---

This is somewhat of a philosophical question.

The only thing you can really say from these results is that the die rolling outcome results are biased.

However, what we can say is that there doesn't appear to be any clear pattern in terms of transitions in the heat map that would suggest that the die roller is doing weird things like flipping the die between alternate faces.
To help validate that the rolling procedure was as fair as possible you could try comparing results to different rolling mechanisms, or more practically, i could extend the rolling times to see if that made much of a difference.  Finding some high quality trusted fair dice that evaluated to fair using the system would give more confidence.

But to see why this has to be approached somewhat philosophically, just consider how physically the die might be biased -- it could be because of uneven weighting, or assymetric shape, or rounded vs sharp corners, etc.  And these will effect different "rolling" procedures differently.  So the way the bias will show up is dependent on the way in which the dice are "rolled" (randomized).  The best we can say is that when the die is rolled in this fashion, they exhibit this bias.  If you asked a human to roll the dice to test for bias, you would have the same problem -- the bias may show up differently based on whether the user "shakes" the dice in their hand and drops them to the table, or rolls them a far distance against a wall, etc.

If you really wanted to be more specific about bias of dice for human use, you could try to ascertain whether the biases found by one rolling machine matched the biases found by a certain human method of rolling dice.

Ath:
the camera on the Raspberry Pi, while high resolution, has absolutely no focus control and would not focus well on anything shorter than about 24 inches from it
-mouser (February 25, 2016, 01:40 AM)
--- End quote ---
This page on eLinux.org list a lot of (usb) cameras that are tested with the RPi, but I don't know if they are compatible with the python libraries you've used. Some of them will have better focus control, and you might even own one of them listed ;)
It's not going to enhance the (lack of) processing-speed of the RPi, though :huh:

wraith808:
Thought you might find this interesting:

https://www.kickstarter.com/projects/1110051555/flip-dice-family-game-night-reimagined/posts/1504651

mouser:
I really want to return to this project and do a second version of it.. I'm still convinced that some better hardware (maybe 3d printed) that implemented a clever way of centering the die roll landing position would make all the difference, since I believe the major difficulty with the visual recognition is the fact that the die final resting point for different rolls can really skew its appearance and confuse the recognition system.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version