A brief history in time

 The history of this project, to date, is - believe it or not - the abridged version.
There have been lots of other ideas tried, exploratory into different technologies, connectors, numbers of sensors in the matrix, different types of sensors (inductive sensing looked promising for a while, while cross-talk with RFID readers meant that never really got off the ground).

We even looked at abandoning hardware altogether, and building an overhead Raspberry Pi camera, that would simply watch the game being played out, and use "AI magic" to track the pieces (this is still a possibility worth exploring in the future, but so far shadows and simply sticking your own big head in the way while moving the pieces means it's never an uninterrupted gaming experience).

The failure of Raspberry Pi was quite a lesson for us.
We could get it working by introducing a "trigger" - i.e. move the piece(s) as necessary, then instigate a trigger which told the Pi "now look at the board, see what's different, work out what moved and apply the game rules".


On a technical level, it kind-of worked.

But it broke the one golden rule we set, right at the very start of the whole project, ten years or more ago - it mustn't get in the way of playing the game.

The technology must work seamlessly with the game - players should be able to pick up pieces and move them around as they would as if the technology wasn't there. Sure, the technology might guide them (as in, you can't put a piece in that square so alert the user with a buzzing sound) but they mustn't have to change how they play the game just to accommodate the technology.

And the Raspberry Pi "move your piece then tell me when you've moved" approach broke that.

In fact, the only technology we'd managed to successfully implement this approach with was hall sensors. Glue a magnet to the base of your miniatures, place them on the board, and move them around freely - the sensors detect when pieces have been picked up and put down; the connected app knows if you've moved to a valid square or not (and can play the appropriate sounds to indicate success or failure to meet the game rules) - but ultimately the technology "stays out of the way".

So hall sensors it is!

The single-wire data line and complex connection methods (requiring a bluetooth enabled "master controller" to act as a bridge between the hardware and an app running on a mobile device) have remained a bugbear for years.

Unresolved, my electronically enhanced boardgaming playing surface (in its many different incarnations) remained in the bottom of a cupboard for a few years more.


Comments

Post a Comment

Popular posts from this blog

The ESP8266

Image
 Many long-time users of the Arduino platform are probably already familiar with the ESP8266. It started out as a wifi-to-serial module you could hook up to your Arduino and send messages over wifi to your flashing LEDs and motor controllers. Then it appeared as an integrated board, and multiple variations hit the market. A common one is the NodeMCU and it's derivatives. These are great little Arduino-compatible modules that you can set up in the Arduino IDE as programmable controllers (just like an AVR ATMEGA328 or similar microcontroller) but they have loads of other cool features (not least of all, multi-threading!) But most of us stick to using them like a beefed-up Arduino (they have loads  of RAM memory and plenty of programmable storage to run pretty sophisticated firmware on them). It was while playing with one of these for a completely unrelated project, that I suddenly hit on the idea of having a "network" of board game playing surfaces, all broadcasting over wi...
Read more

Understanding the hall sensor input matrix

Image
 We're using "multiplexing" to read our grid of 16 hall effect sensors. This means we don't need to use 16 individual input pins for reading inputs (which would just about max out an Arduino, and would be too many pins for a NodeMCU ESP8266 type microcontroller). Instead, we split our grid into "rows" and "columns". Then we activate each row, and read the values from each column. This means we need four i/o pins for the rows (outputs) and four i/o pins for the columns (inputs). Let's look a little closer.... Each hall sensor needs power (3.3v-5v supply) a ground connection and has a "floating" signal pin. When a magnet is presented to the sensor, the signal pin is forced "low" (to ground). When the magnet is removed, the signal pin is left floating (note, it is not driven "high" but allowed to "float" to whichever default value we want it to take - the technical term is "open drain" but we don...
Read more

Creating our first light-up 4x4 panel

Image
 Here's our first attempt at a 4x4 light-up panel. The idea here is to connect all the 5v and ground pins on the panel together, using copper tape, and create a daisy-chain effect from one strip of LEDs to the next By cutting away at the circuit board, where the 5v and ground pins are, we could create a continuous connection by adding a simple blob of solder from pin to copper strip. Needless to say, it didn't work! But that's probably a good thing - because when it didn't work, it forced us to abandon the idea of using copper tape for the LEDs (connecting each to the next using wires at the end of each strip) which allows us to use the same surface for running copper tape for our hall sensor input array. Our second design was much more successful. It may be easier to think of this as two panels, overlayed into one space. Firstly, there's the LED strip, chopped into bits, and connected up again, into a "snake-like" layout Then underneath this, we have our ...
Read more