Electronic board game - almost ready for testing

Maybe Steve had a point. He said we should forget about making a CNC pick-n-place and just get some board game sections made up, to prove everything works as it should. Of course, there's no way we're going to give up on a CNC - not least until it's moving in both the x and y axis, and then it starts to get a bit tricky and we'll get bored and move on to something else.

But for a long time, Steve's been saying we should just bite the bullet and solder up a few boards by hand. It's a tedious, laborious task, but - every now and again - we've taken to spending 40 minutes or an hour or so with the soldering iron, and have ended up with a few board sections now.

They are in various stages of completeness, but there's one thing that we have made sure of, and that's they all work! We did have a couple of boards with a few dead squares, but some careful levering with a tweezers-and-soldering-iron combo, and we were able to replace the dead sensors. So every square on each of these boards is working.

We've pretty much got enough pieces now to actually try out a game on the modular sections. A few people have already commented and said that the game looks reminiscent of "Space Hulk". And while it can be used for that, we're more inclined to say it's "Laser Squad on a board game" (not least of all because we don't want GW thumping the door to Nerd Towers down in a fit of pique!)

Even with a relatively few board sections, you can make up some pretty interesting-looking playing surfaces.

This layout reminds us of one of the spaceships in the early 90s Star Trek programmes (the ones with Patrick Stewart in them). A few more board sections to make the "wings" a bit wider and it's a dead ringer:

The long corridor sections could be broken up with the use of doors, much like the early Space Hulk and Space Crusade board games. This could really add some tension to the gameplay - with a player opening a door, only to reveal a hoard of alien monsters, waiting on the other side!

RFID door entry enclosure

Steve has done a fantastic job of the enclosure for our new door entry system. We're using one of the ABS enclosures kindly donated by Nathan a few months back. The first thing to sort out was where the LCD display should fit. Given the shape of the enclosure, it seemed pretty obvious!

The LCD has rather a large, chunky display on the front, and a massive backlight lumped onto the side, but luckily we don't have to have the entire screen pushed into the opening - the display can be set back slightly, to leave the screen more-or-less flush with the face of the enclosure

Next, Steve scanned in the enclosure, to get a 1:1 layout for the artwork.

Then it was time to get busy with PotatoShop

The printed version was run through the CraftRobo cutter....

....and the final design is ready for fitting:

All that remains is to check everything lines up properly to make sure the scanner wasn't set to "scale to fit" or the scanned image was set to something crazy like 98%

A perfect fit! Another amazing bit of "branding" from Steve - the whole thing not only works well, but looks pretty impressive too. As there are people likely to be using the 'space over the weekend, it's looking likely that we'll have to wait 'til at least Sunday evening (perhaps Monday) before putting the new system live. But at least when we do, we know it'll look  awesome!

Schematics for RFID door entry system

Our door entry system - rather unusually - uses a mix of PIC and AVR microcontrollers; the AVR acts as a serial/UART-to-ethernet gateway and does little else. Most of the work is done on the PIC, but when it needs to send and receive data to/from the 'net, it passes it over to the AVR via serial.

We programmed the AVR by putting an ATMega328 DIP into an early revision of a full-sized Arduino Duemilanove board, uploaded a sketch using the Arduino IDE, then popping the chip out of the socket.

Here's our schematic for the entire entry system - an RFID reader, a 24C256 eeprom, PIC16F886, 16x2 character LCD, LM7805 voltage regulator, 5v coil relay, a few transistors and ENC28J60 UART-to-ethernet module

RFID door entry system

BuildBrighton RFID door system - ready to go live!

It was touch and go for a while at the last BuildBrighton meet-up. The ethernet module was proving most disagreeable - sometimes it worked, sometimes not. Sometimes it seemed like the server wasn't listening, sometimes the response came back almost instantly.

So to just get a serial-to-ethernet (and back again) interface working, we threw an Arduino Mini Pro onto a board and loaded in the UIPEthernet library. Everything was screaming "nooooo! Learn to do it properly" but we just needed some results - and quickly. So Arduino it was.

Even using a library, the response was intermittent, until Steve discovered a single line of code that seemed to fix things: Ethernet.maintain() is a function call that makes ethernet connections much more robust; and suddenly our project worked first time, every time.

Here's a quick video of it working:

The video shows the members website where keyfob IDs can be assigned to members, and credentials set (who can open the door, who can use the CNC etc.)

When a key is presented to the reader, it seamlessly queries the website and pulls down the latest credentials for the keyfob. The video also shows that keys can be revoked by unticking the "is a valid key" box - when the updated keyfob is presented to the reader, the hardware shows a message "not valid" (and refuses to activate the relay which activates the door). In the same manner, we can easily activate new keyfobs, and add "permissions" to different users, all through the web-interface.

Having proven that the system works end-to-end, we just need to package the circuit up so that it can be put into a suitable enclosure and mounted outside the main BuildBrighton door. We've already had a lot of interest in the new door entry system, with quite a few members being given their own keyfobs, ready for when the system goes live. With a bit of luck, it'll be some time tomorrow evening!

Pushing the case for a CNC pick-n-place

When Steve found out we were spending time on a CNC rather than just go heads-down and hand-solder some boards for our prototype game, he made a wager - a bet that the CNC chews up more than 20 hours (the time we reckon it'd take to hand-solder a dozen or so board game sections). The prize? A bacon butty.

It looks like Steve is likely to win the wager.
But only because he bet we'd spend more than 20 hours on the CNC - had the wager been we'd spend more time on the CNC than on soldering the boards, it might be a different outcome.

Because of the two boards we soldered by hand the other day, neither worked!
Inspecting them shows some really nasty blobby joints:

A lot of this probably comes down to dabbing on too much solder paste at the start (and so a stencil, rather than a pick-n-place machine would probably be the answer). But there were at least two instances when a shaky of a wobbly hand spread the paste around a bit, across the tracks (so perhaps a solder mask might also have been useful!)

Normally we don't worry too much about this - with plenty of flux on the board before soldering, any excess is usually burnt away, leaving a nice, clear joint. But obviously something is not quite right, with both of these boards refusing to work - and a failure rate of 100% means it'll take a lot longer than our rather conservative estimate of 20 hours to solder up enough board sections to try out a half-decent game.

So, having already arranged to meet Alex to collect some RFID keyfobs for the new BuildBrighton door access system, and being at the hackspace already, and having a few hours to hand, it seemed a shame not to spend them productively - with a view to getting a moving head on an x/y axis as quickly as possible.

Here's pretty much how we left our CNC x/y axis on Monday evening. So last night, we fixed the x-axis travelling head in place, and mounted the y-axis rails and secured everything, making sure it was as square as we could get it

We used Arthur's approach to squaring up the rails - screwing down opposite corners and pinching them tight, then backing off the screws a quarter-turn: secure enough to hold the rails, but not so much to stop them from re-aligning if necessary. We then ran the carriage up and down the rails a few times, and tightened up the rail mounts wherever they had settled.

The whole carriage assembly glides up and down the y-axis rails perfectly. We we expecting at least a little binding or resistance somewhere along its travel, to indicate that either a rod was bent, or the linear bearings were not quite aligned, or that the rails weren't quite parallel. But - amazingly - the carriage glides up and down the rails with no stickiness at all.

It's all very encouraging - and with the 2.5mm pitch belt in place, it's easy to see how steppers will pull the carriage along. The belt needs to be pulled tight and fixed solid at either end of the y-axis rail. This means that as the stepper motor rotates, it causes the carriage to move along the length of the belt.

Because this is our first belt-driven system, we decided to use two steppers - one on each end of the carriage. Normally we'd be tempted to go with the least hardware and the simplest design (i.e. a single stepper per axis) but we've no idea how this belt works when under load. If we had just one belt on one end, it means that the single stepper is driving one end of the carriage, while dragging the other end behind it (a single belt down the centre of the y-axis would be ideal, but we need to keep our working surface clear so we can place circuit boards anywhere within the x/y reach and not worry about the belt getting in the way).

If all the rails are perfectly square - the two rails on each axis are perfectly parallel, and the rails on the other axis exactly perpendicular to them - then an single-stepper-down-one-side arrangement should be just fine (it's how most laser cutters work, for example). But given that we were cobbling something together out of scraps of stainless steel rob, laser-cut mdf and some left-over chipboard for a base, there was always the chance that something wouldn't fit quite right.

So we've gone with the dual stepper approach. Both steppers will be driven exactly in sync, and this should ensure there are no dragging or twisting forces on the y-axis as it travels up and down our (rather shonkily-built) rails.

As it's BuildBrighton Open Night tonight, there's a chance that not much more will get done on it until the early hours - though perhaps we might just forgo the tea and pizza and keep cracking on with it - once the new door entry system has been fitted, of course!

Testing RFID door entry system for BuildBrighton

Next Thursday night is BuildBrighton Open Evening, and we'd promised to have the new door entry system working. In principle, it's a fairly straight-forward idea, but - as with most software (and hardware) development - most of the effort seems to be going into the "fail-safe": what happens if, for example, the internet connection goes down?

Firstly, here's the theory of how it works:
We have a members website for BuildBrighton, and our key-issuing members can access an admin screen, which allows them to issue keyfob numbers to members, and to activate certain "flags" on the keys (so the same keyfob could, in future, be used to access lots of different pieces of equipment - for now, we're concentrating on opening the door).

Each member has an RFID keyfob number against them, and a number of flags to say what that keyfob can do. This can be administered by anyone with admin access to the BuildBrighton members website.

For testing, we've removed the ethernet-to-UART module, and have plugged in our PICKit2 Programmer, which has a simple UART interface, so we can emulate sending data backwards and forwards between the RFID reader and the website (it can be difficult, during testing, to force a network error - or diagnose an error reported on the hardware, when everything looks like it should be working, and there's fault on the web server!)

We've also added in loads of logging into the microcontroller handling the data between the RFID reader and the web server, so that we can see how different conditions are being handled.

The first thing to do is present a keyfob/rfid card (the reader works with any 125khz RFID tag) to the reader. The hardware displays the number read from the fob on the character LCD (the reason for this will be explained in a moment) and then tries to contact the web server.

As we're using an ENC28J60 ethernet modules with another microcontroller attached (it'll be an ATMega328 but we're prototyping on a full Arduino) to do all the talking over the internet, we can simply send this ID number over serial/UART. The ethernet module will post this ID number to a URL and await a response from the remote web server. Any data sent back from the web server appears on our hardware here as a serial string of data.

We're emulating this by simply typing data into our PICKit2 UART module.
When a correctly formatted response is received on our hardware, it displays the name of the keyholder for confirmation:

So far, so simple.
The bulk of the work in this project, however, has gone into making sure the device works when there's a network error. So, each time valid data is received from the internet, we store it in some local eeprom (that's what the 24C256 eeprom chip is doing there). That way, if ever we don't get the expected response from our web server, we can compare the keyfob ID against a known "database" of valid fob numbers. If there's a match, we use the credentials stored in eeprom, rather than over the 'net.
The next time the same keyfob is presented to the hardware, it checks against the web server first - so any updated credentials get downloaded to local eeprom, once the internet connection is back up and running.

Here it is in action:

And here's the massive data logging output.

Starting keyfob reader
Flushing buffer 176 96 193 131
Keyfob reading complete
Sending data to ethernet
176096193131:0100:0
Data received: OK:8761:Chris Holden

Reading eeprom address 0
Data from eeprom: 255 255 255 255
Keyfob serial: 176 96 193 131
Writing new record at 0
End writing eeprom

Starting keyfob reader
Flushing buffer 35 70 141 26
Keyfob reading complete
Sending data to ethernet
035070141026:0100:0
Data received: OK:8761:Steve Carpenter

Reading eeprom address 0
Data from eeprom: 176 96 193 131
Keyfob serial: 35 70 141 26
Reading eeprom address 32
Data from eeprom: 255 255 255 255
Keyfob serial: 35 70 141 26
Writing new record at 32
End writing eeprom

Starting keyfob reader
Flushing buffer 35 70 141 26
Keyfob reading complete
Sending data to ethernet
035070141026:0100:0
Data received: ERROR

Reading eeprom from 0
Data from eeprom: 17696193131
Keyfob serial: 35 70 141 26
Reading eeprom from 32
Data from eeprom: 357014126
Keyfob serial: 35 70 141 26
Record foundData received: OK:8761:Steve Carpenter


Starting keyfob reader
Flushing buffer 176 96 193 131
Keyfob reading complete
Sending data to ethernet
176096193131:0100:0
Data received: OK:0000:Chris Holden

Reading eeprom address 0
Data from eeprom: 176 96 193 131
Keyfob serial: 176 96 193 131
Data found at address0
Updating record
End writing eeprom

Starting keyfob reader

So what's happening in the video?
To begin with, we presented a new card to the system. It queried the remote server (sending the key ID 176096193131) and we emulated a valid response. The response "OK:8761:Chris Holden" tells the hardware who the key belongs to, and which flags are set for that person (effectively, which bits of equipment this keyfob is valid for, so they can be compared to the flags in the hardware device).

This activity is reflected in the log above.
After receiving the data, the hardware then looks through the eeprom chip, reading 4 bytes at a time and comparing them to the 4 bytes read from the RFID tag. If it finds a match, it will update the following "record" in eeprom. If it finds a series of four 0xff bytes, this indicates a blank bit of eeprom memory (where we've reached the end of all the records) and so writes a new record at this address.

We can see this happening, in the log above.
At address zero, there are four lots of 0xff (since the eeprom chip at this point is completely empty). So a new record is written, starting at address zero.

Then, in the video, we pick up the blue keyfob and present this to the reader.
The results of this can be seen in the log above - the web server responds with an OK message and identifies the keyfob as belonging to Laser-Robot-Steve. If you read through the log, after this, you can see that the previous record is found in eeprom, at address zero, so it skips forwards 32 bytes, and reads another 4 bytes back. This time, four sets of 0xff are found (blank data) so it knows it's reached the end of the data in the eeprom chip, and adds another new record.

So what if we present a keyfob but the internet connection is down?
We simulated this by having the serial response from the ethernet module read "ERROR"
And you can see in the video, the hardware identifies the error, but then after querying the eeprom chip, validates the keyfob as belonging to Steve - and so activates the door lock and lets him in, even though the internet connection was down.

By reading through the log above, we can see that after receiving an ERROR response, the hardware queries the eeprom chip. At address zero it finds four bytes, but these do not match the ID from the keyfob, so it jumps forward 32 bytes and tries again. This time, it does find a match, and so validates the user as Robot Steve, and opens the door.

Now Steve's been let into the 'space, he can reboot the router and get the internet connection working for anyone else who needs to access the space using their RFID tag. Without this safety net, there's a good chance that we'd end up with a queue of people all on the outside, not able to get in, to sort out the problem causing the internet connection failure that was keeping everyone out!


The last bit of logging (not shown in the video) shows how keyfob credentials are updated by the members-only website. In the last example, the flags for Chris Holden have been reset to zero on the website (as if the keyfob has been revoked). When the revoked keyfob is presented to the RFID reader, the new credentials are downloaded from the web server, the appropriate record is found in eeprom, and is updated/overwritten. So in the event of another internet failure, the key remains revoked once contact has been made with the web site (and doesn't let Nasty Chris in, if he's cut the cables to the phone lines on a future visit, for example!)

Hopefully we don't have to worry about revoking access with BuildBrighton members.
But exactly the same principle can be used to grant additional access to tools, equipment etc. to users in future. So once a user is issued with their own RFID tag, they could use this to, say, activate the laser cutter and log time used on it, or power up the CNC with their RFID tag.
We're a long way from it, but the principle could be extended by other people using this system for things like snack purchases and donating for hardware use, even if the member doesn't have any cash on them at the time.

Hopefully we'll have more ideas on Thursday evening, when the new system "goes live".

Why we need a CNC pick-n-place

It was good to spend a few hours this weekend actually making stuff again, rather than just coding and coding and doing yet more coding! So good, that we thought it was time to make a few more board sections for our electronic board game.

In about two hours we managed to get just two pieces made up. Mostly this was down to dabbing the solder paste onto just three or four sets of pads at a time, then hand-soldering each SOT-23 sized hall effect sensor, and each 1206 sized resistor in place.

Hand-soldering SMT components is slow going. And almost an hour per board section is pretty woeful. So it's time to start seriously thinking about this CNC pick-n-place machine. Steve is going to go beserk.

I went down to BuildBrighton for a few hours this evening, with Grumpy Paul (he doesn't have a G+ link). Over a few hours, we cobbled together a basic x/y axis, using some 12mm linear bearings and stainless steel rods that have been lying around for ages. We've mounted the steppers onto the y-axis carriage - one on each side rather than a single long belt down the middle, as we need to keep the middle clear for placing components. Also, because we're expecting the head to travel to the edge(s) to pick up components from a tape reel, we couldn't really use the moving y-axis bed approach we implemented in our CNC drill from about 18 months ago.

We've gone for "proper" stepper motors this time, and a 2mm pitch timing belt, and proper CNC pulleys (rather than some cheap plastic mouldings and £2 motors from China!)

Here's the x-axis carriage being assembled. The steppers are mounted on each end. A belt will run along the outside edges, over the pulleys on the motors that are mounted on the carriage, to a fixed point at each end of the travel - using this sort of arrangement:

As usual, the entire thing is being designed and built on-the-fly.
There's no real planning gone into the design so far (as Grumpy Paul will testify, having had to take a rasp file to it on more than one occasion). We're using Arthur's method of getting everything square - that is, to fix one end, run the carriage up and down the y-axis a few times, then bolt it all down onto a scrap sheet of wood, wherever it rests!

The travel on the y-axis is surprisingly smooth. Maybe it's because of the added weight of the stepper motors (we expected these to make the travel worse, not better). Maybe it's because we lightly sanded the rods with some wet-n-dry paper, as the linear rails felt a bit sticky in places. But in all honesty, it's probably Paul's idea that made all the difference - a tiny blob of lithium-based grease on the rods makes the carriages glide up and down with hardly any resistance at all.

We didn't actually get much further than laying everything out tonight (despite nearly five hours, and staying 'til almost midnight). But there's every chance that we'll have the CNC moving in at least two axes on Thursday night. That's if Steve doesn't put his foot down and ban us from doing any more work on it 'til the board game is finished!

The thing is, at our current rate of construction, we're going to need about 20 more hours just to make up enough board sections to call it complete. Surely spending a few hours to build the tools to speed up finishing off the board game it time well spent? Isn't it?