By now most of us are familiar with the Arduino platform. It’s an inexpensive and fairly easy way into the world of microcontrollers. For plenty of projects, there’s no need to go beyond that unless you have a desire to learn more of the inner workings of microcontrollers in general. [Cristiano] was interested in expanding some of his knowledge, so he decided to build this electronic dice using a PIC microcontroller instead of the Arduino platform he was more familiar with.
As a result, this project is set up as a how-to for others looking to dive further into the world of microcontrollers that don’t have the same hand-holding setup as the Arduino. To take care of the need for a random number for the dice, the PIC’s random number generator is used but with the added randomness of a seed from an internal timer. The timer is started when a mercury tilt switch signals the device that it has been rolled over, and after some computation a single digit number is displayed on a seven-segment display.
While it might seem simple on the surface, the project comes with an in-depth guide on programming the PIC family of microcontrollers, and has a polish not normally seen on beginner projects, including the use of the mercury tilt switch which gives it a retro vibe. For some other tips on how to build projects like this, take a look at this guide on how to build power supplies for your projects as well.
Nice project. It explains the need for a seed to get better randomness. Very important!
But is it a fair dice roll?
Making it fair to ensure each value has equal chances of showing up instead of only making it random (i.e.: unpredictible), is surpisingly hard to do on a microcontroller.
Hint: using the rand() function doesn’t ensure any faireness at all.
You can make it better by tweaking the MAXINT value as it uses modulo logic internally.
You always need to start counting from 0 and MAXINT needs to be set to an integer multiple of your required maximum value – 1
Even then it will still not be 100% fair as the rand() function uses a counter that gets reset when MAXINT is reached. The reset takes more CPU cycles/time than increasing the counter by one, making that last values chances slightly higher than any other value to occur and making it an unfair dice.
This is (one of) the reason(s) why you should’t write your own encryption algorithms as the devil is in such details.
Hi! Author here.
You raise an interesting point about randomness vs fairness but, should a dice, for the purpose it is traditionally used, be fair?
Suppose you algorithmically force the dice to be fair, by it meaning each number will get an equal chance of being selected. Now suppose that, after five throws, we get the sequence: 5, 2, 3, 4, 1. So the next (6th) throw will have a high chance of displaying 6, making this “fair” dice predictable and potentially useless for the games of chances it will probably be employed.
Thank you for the feedback!
– Cristiano
This isn’t correct. If the random function is “fair” (uniform), then any single number has exactly a 1/6 chance of being selected. There’s no dependence on previously generated values.
Hi,
Currently it doesn’t rely on the output of rand(); instead, it’s seeded by sampling a constant running timer each time a “shake” is detected on the tilt switch. It’s expected that you shake it varying the number of shakes and the pattern (as one does with a real dice) and allowing each player to do the same. Each human being is different, naturally each one will create a unique pattern of timing between shakes, number of shakes etc. The seed variable is kept for the life of the battery, effectively mixing the shake patterns of different throws and players. That should capture enough entropy to make it as usable as a regular dice, me thinks.
A better way would be to incorporate an accelerometer and capture X, Y and Z data for seeding, but that would increase power consumption and cost.
Would like to hear other suggestions for a MCU.
Thanks!
– Cristiano
… and of course you can always write your own random number function…
https://xkcd.com/221/
“Never roll your own crypto!”
Sorry, it was irresistible. It just kept calling my name!… :D
Cool project! I like the fact it uses a normal down-to-earth sensor, also! 🙂👍
While there used to be discrete TTL circuits I’m more familiar with,
the PIC is nice to have for additional features, visual animation effects or sound effects. 🙂
How about a real random roll for your seeds? http://www.realrandom.co
Looks interesting, but that’s a cloud based service making use of APIs, right?
The dice is an offline, no setup, quick grab-and-go device, like a real dice.
Do they offer a library or something that will generate the random number on a MCU with no need for an internet connection? Checked the site but only saw mentions to their API.
Thanks!
Here’s a thought, create a physics model based on simulations on an ai-trained model that factors in shake, throw, dice weight, collisions, and timing.
Once the physics model has been trained on ai, then throw in a random intitial number seed based on time of day (or a variable that cannot be predicted as your rand offset) to apply before dice is thrown. Then incorporate the accelerometer that applies the physics model and throw it!
… Or, you know, you can stick to using a non-microcontrolled regular die. :)