I'm a big fan of the board game "Risk" (down here we nickname it "the friend-breaker", for obvious reasons) And I've been thinking about building an electronic board that would spare the players of all the hassle of counting pieces and moving them around the board manually.

Anyway, the way I plan to build the board is a different matter. What I'd like to start with is with some device that could read the results of the dice after they've been thrown. And I mean real, physical dice. I do not want to use a simulator or any other thing that would rob the player of the pleasure experienced when he tosses real dice.
Normally, we toss the dice inside the top side of the cardboard box that the game came packaged in. So the optimal thing would be to use a similar sized box where the dice would be tossed and later read by whatever technique is devised for this purpose.
The first idea that comes to mind is to use a camera or smartphone placed above this box that would take a snapshot of the result and read the dice values through image recognition. But I'm trying to avoid that, since programming would be too complex, and because it would require a special jig or structure placed above the box to hold the camera.
Another idea would be the use of some RFID circuit placed inside the dice that would also have some way of detecting the orientation in which they landed, and transmit that information to a receiver. I'm not afraid of causing an unbalance of the dice since it wouldn't be too hard to compensate placing counter-weights... I've got the equipment to do that readily available.
Then again... I feel there has to be a simpler solution for this... some sort of ingenious Forrest-Mims-like circuit or sensor that I haven't thought of.

I'd really appreciate it if the members of this forum shared their thoughts and ideas about this little project of mine. Are there other techniques or technologies that you might deem worth considering?

 

The first idea that comes to mind is to use a camera or smartphone placed above this box that would take a snapshot of the result and read the dice values through image recognition. But I'm trying to avoid that, since programming would be too complex, and because it would require a special jig or structure placed above the box to hold the camera.

actually i don't think the image recognition programming would be that complex at all. It's not facial recognition, it's black dot recognition. Place the camera under a glass plate and toss the dice on the glass. Use frosted glass or some sort of opaque glass where things behind the glass do not show through; only things directly sitting on the glass. Find out how many black pixels in a single die dot. Count the total black pixels in the image and divide by the number of black pixels in a dot. I need to think more about it, but for now i think you should be able to do the math to find the values of the die tops from looking at the die bottoms, without even having to distinguish individual dice, just counting total dots (as long as you know how many dice were thrown). I could be wrong, probably am.

 

actually i don't think the image recognition programming would be that complex at all. It's not facial recognition, it's black dot recognition. Place the camera under a glass plate and toss the dice on the glass. Use frosted glass or some sort of opaque glass where things behind the glass do not show through; only things directly sitting on the glass. Find out how many black pixels in a single die dot. Count the total black pixels in the image and divide by the number of black pixels in a dot. I need to think more about it, but for now i think you should be able to do the math to find the values of the die tops from looking at the die bottoms, without even having to distinguish individual dice, just counting total dots (as long as you know how many dice were thrown). I could be wrong, probably am.

Yeah... it sounds simple... for someone with experience in the field... for someone like me, it looks like a complex analysis.
Thanks for taking the time to look at this thread. I look forward to hear more from you... cheers!

 

Yeah... it sounds simple... for someone with experience in the field... for someone like me, it looks like a complex analysis.
Thanks for taking the time to look at this thread. I look forward to hear more from you... cheers!

I wouldn't say I have experience in the field; ihave never done any type of image analysis programming, only read about it. From what i have read about, this seems trivial. But it could be much more complex than i imagine, and if it is, i apologize. But i doubt it is.

Something like this would be a good candidate for raspberry PI IMO, which is commonly programmed in python. Here is some lecture on counting black pixel clusters in python. http://software-carpentry.org/v4/media/stars.html It is part of a series apparently, maybe more good info on either side of it.

Raspberry pi has CMOS camera accessories available.

 

Also i think I'm right about being able to resolve the other side of the dice without distinguishing individual dice. Let me explain, and let me know if I'm wrong.

Each die has opposing sides totalling 7
1 is opposite 6
2 is opposite 5
3 is opposite 4

With one die, if we see 2 on the bottom, we know 7-2=5, so 5 is on top.

With two dice, if we see 4 dots on bottom, we know (2*7)-4=10, so we have 10 total on top. This is true whether we have a 1 and a 3 on bottom, or two 2s on bottom.

With 3 dice if we have 9 dots on bottom, (3*7)-9=12. With 9 dot on bottom we could have combinations of 1,2,6 or 3,3,3 or 2,3,4, or whatever, makes no difference. The top total will be the difference of the bottom and 7*number-of-dice

 

I wouldn't say I have experience in the field; ihave never done any type of image analysis programming, only read about it. From what i have read about, this seems trivial. But it could be much more complex than i imagine, and if it is, i apologize. But i doubt it is.

Something like this would be a good candidate for raspberry PI IMO, which is commonly programmed in python. Here is some lecture on counting black pixel clusters in python. http://software-carpentry.org/v4/media/stars.html It is part of a series apparently, maybe more good info on either side of it.

Raspberry pi has CMOS camera accessories available.

Nice... but I'm sort of allergic to raspberry and arduino... I'd rather go to the lowest level of things (counting MCU's or course) or skip to a smartphone with Android. On the other hand, reading pixels is not just about levels of black and white... there is color saturation, contrast, boundary recognition and all sort of things... But this is a subject for a different type of discussion.
What about technologies other than visual/image/optical? There has to be something else!

 

Also i think I'm right about being able to resolve the other side of the dice without distinguishing individual dice. Let me explain, and let me know if I'm wrong.

Each die has opposing sides totalling 7
1 is opposite 6
2 is opposite 5
3 is opposite 4

With one die, if we see 2 on the bottom, we know 7-2=5, so 5 is on top.

With two dice, if we see 4 dots on bottom, we know (2*7)-4=10, so we have 10 total on top. This is true whether we have a 1 and a 3 on bottom, or two 2s on bottom.

With 3 dice if we have 9 dots on bottom, (3*7)-9=12. With 9 dot on bottom we could have combinations of 1,2,6 or 3,3,3 or 2,3,4, or whatever, makes no difference. The top total will be the difference of the bottom and 7*number-of-dice

Yeap... I had already thought of that.. thanks, really... but then again... how do I do that without optics involved?

 

[QUOTE="cmartinez, post: 833914, member: 9198".
What about technologies other than visual/image/optical? There has to be something else![/QUOTE]
wishful thinking, i think. I will be surprised if anyone can provide a more simple solution.

 

Nice... but I'm sort of allergic to raspberry and arduino... I'd rather go to the lowest level of things (counting MCU's or course) or skip to a smartphone with Android. On the other hand, reading pixels is not just about levels of black and white... there is color saturation, contrast, boundary recognition and all sort of things... But this is a subject for a different type of discussion.
What about technologies other than visual/image/optical? There has to be something else!

You might want to check out the winbook tw700. $65 tablet with integrated camera and windows8. You coukd install python on it or even visual studio.

 

[QUOTE="cmartinez, post: 833914, member: 9198".
What about technologies other than visual/image/optical? There has to be something else!

Yeap... that's why I started this thread... to see if anyone had a better idea...
But I have to agree with you, it's going to be hard to find something other than visual... it's either going to be something too hard or complicated... or something so simple that everyone has overlooked until now... I'm placing my hopes on the latter..

 

Create an app for that.
Just set the smart phone to view the dice from above or sideways and you're done. Image pattern recognition is straight forward after that. Code has already been written.

 

Create an app for that.
Just set the smart phone to view the dice from above or sideways and you're done. Image pattern recognition is straight forward after that. Code has already been written.

Ok... now I'm interested... Code has already been written you said... where can I find that code?

 

I would also go for the general solution of writing image recognition software.

But if this were 20 years ago and I didn't have the processing power in a smart phone, I would try to force the dice to land in a confined area, the field of my camera. That way, I could be assured that the faces of the dice were in focus and oriented straight towards the camera. Let's suppose the dice were white, with black spots on them. I would have them roll onto white felt. Then, I would take a picture, and in software, figure out the general lighting level of white by sampling a few pixels. Let's say that the value of brightness (look up algorithms on how to calculate from RGB, very quick) for white was 177. Then I would set a discrimination threshold in software, and count how many pixels in the picture are below that value. Since the size of the spots on the dice presumably would always be the same, the total number of spots showing would be proportional to the number of pixels below the threshold (that is, the number of black pixels).

Now if this was 40 years ago, and I didn't have a digital camera, I would use (nearly invisible) ultraviolet paint on the faces of the dice. The 6 face would have no paint on it, the 5 face would be 20% painted, the 4 face would be 40% painted, ... all the way down to the 1 face which would be 100%. I would then use a brief flash from an ultraviolet source, and measure total brightness in an analog fashion. The detector would need a visible light filter, of course.

 

I've seen this http://www.roborealm.com/ demonstrated and it looked real easy to use. Not terribly expensive but it does require a computer and camera.

 

I've seen this http://www.roborealm.com/ demonstrated and it looked real easy to use. Not terribly expensive but it does require a computer and camera.

Wow... very interesting, and not that expensive either! Only $50 bucks for all that power! This will definitely come in handy for other projects as well. Thanks Richard!

 

google opencv dice recognition

example:

http://nerdclub-uk.blogspot.ca/2014/12/dice-reading-photo-image-processing.html

 

google opencv dice recognition

example:

http://nerdclub-uk.blogspot.ca/2014/12/dice-reading-photo-image-processing.html

Very.... VERY interesting... thank you!

 

You really put me into a fit with this one, Martinez. I'm not sure why; honestly the whole concept just seemed a little Rube Goldberg to me, but I suppose I've been itching for a reason to try some computer vision stuff and you gave me one. So for a few days I've been playing with this a little here, a little there.

Most of my programming of late has been Python; that's what's fresh in my head so that's what I wanted to use. I explored many avenues for image processing in Python (including opencv as Mr Chips linked); all of them turned me off in one way or another. Too complex, too much overkill, too little documentation, etc. So I went looking for the best language for simple image processing. I wanted something stupidly simple, as you alluded to maybe being a little programmatically averse, and whatever it would be, would be something I've never seen before. Seemed like anything that was good at image processing was hard to learn, and anything easy to learn had little or no native imaging capability. Then, in my quest for "simple image processing" I stumbled upon "Processing" - it's a java-based environment targeted at retards, noobs, and children (I meet all the criteria). I read about it in the past in "Making Things Talk" when playing with Arduino. I never downloaded it, but the book made it seem as if it were just some limited PC version of the arduino software. The IDEs look the same and in both the project is called a "sketch." Anyway, long story short, I was wrong. Processing is actually pretty badass. Stupid simple, good with images, plenty of examples come in the standard distribution. I never once had to google "how to _______ in Processing" - I was able to piecemeal my code together from the provided examples and fill in the gaps with intuition. It's less that 200MB fully extracted and requires no invasive installer. Very light on resources; I actually downloaded it to my little 7" winbook tablet and programmed everything you'll see here on that tablet (screenshots are from the tablet too, and I'm typing this on the tablet).

Here it is, without further ado...





code:

PImage img;  // Declare variable "a" of type PImage
int blackpxcount =0;
int notblackpxcount =0;
int hasran =0;
int pixelsperdie = 187;
int dots = 0;
void setup() {
  img = loadImage("dice2.jpg");  // Load the image into the program
  size(img.width, img.height); // scale the window to match the image
  image(img, 0, 0);// Display the image at its actual size at point (0,0)
}

void draw() {// begin main script...

  if (hasran == 0){ //run only once, not continuously
  int begintime =millis(); // set the stopwatch, and we're off..
    for (int y = 0; y < img.height-1; y++) { //for each row of pixels...
      for (int x = 0; x < img.width-1; x++){ //...and for each pixel in that row...
        color c = img.get(x, y);// read the color of the pixel, and...
        if (c < -10000000) {// if that pixel color is below a threshold, ...
          blackpxcount +=1;// we consider it black, and count it.
        }else{
          notblackpxcount +=1;
        }
      }
    }
    //determine how many dots there are, based on how many black pixels we counted:
    dots = blackpxcount/pixelsperdie;
    // wrap it up and report our findings...
    int runtime = millis()-begintime;
    println("DONE! execution time: ", runtime, "mS.");
    println("total pixels: ", (notblackpxcount+blackpxcount), ", black pixels: ", blackpxcount,", not black pixels: ", notblackpxcount);
    println("number of dots showing: ", dots);
    //TO DO: ADD SOME CODE HERE TO OVERLAY THE NUMBER OF DOTS ONTO THE DICE IMAGE IN LARGE FONT (INSTEAD OF JUST THE DEBUG WINDOW)
    hasran = 1; //set this high so that the script does not run again, until...
  }
  if (mousePressed) {// ...we click the mouse.
    blackpxcount = 0;
    notblackpxcount = 0;
    hasran =0;
    //TO DO: ADD SOME CODE HERE TO ADVANCE TO THE NEXT FILE IN THE FOLDER, IF IMAGES ARE TO BE TRANSFERRED
    //IN FROM ANOTHER SOURCE. -OR- ADD FUNTIONALITY FOR THE SCRIPT TO ACCESS THE TABLET'S ONBOARD CAM DIRECTLY
    //AND IMPORT A NEW IMAGE UPON CLICK/TAP
  }
  //TO DO: ADD A "LEARNING" FUNCTION TO CALIBRATE "pixelsperdie" PARAMETER IF (WHEN) DOT COUNT
  //BECOMES INCORRECT DUE TO DIFFERENT DICE OR DIFFERENT CAMERA POSITION OR OTHER FACTORS
}

I realize that this method works artificially well, using static images. No matter how many times I copy and paste those dice, they do no change, and I will always get the right answer. Real dice are bound to be a little more tricky, but I think that if conditions are controlled, the effect will be negligible.

I picture a trash bin with a tablet fixed in the bottom and a frosted glass plate on top. Think of a clear glass with wet (or maybe oiled) white paper on it. it is translucent and the camera can't see anything past the surface. Only what is sitting directly on the glass(or on the paper on the glass), and the glass is always at the same focal point, and light conditions inside the bin (provided by the tablet) should remain constant. I am confident that using 145 lines of code with an overkill computer vision plugin will not give any better end result than using these 39 lines of Processing caode with trash bin setup and tuning the threshold for die-dot-pixel-color and number-of-pixels-per-die-dot to your specific camera and trash bin depth.

 

I'm a bit late to this this party but I have done a bit of work in the past with OpenCV, I was using it to detect the position of a laser dot in an image and it turned out to be pretty straight forward so detecting dice dots, especially if the dice are always the same colour and the background is uniform should be quite simple.

 

I'm a bit late to this this party but I have done a bit of work in the past with OpenCV, I was using it to detect the position of a laser dot in an image and it turned out to be pretty straight forward so detecting dice dots, especially if the dice are always the same colour and the background is uniform should be quite simple.

In what language were you using it?