4The gap between my last post and now has been filled with sporadic bursts of activity curbed mostly by the amount of time that can reasonably be spent on projects and whether I’m in the right frame of mind to focus on something that requires a degree of patience and accuracy. All that aside the intervening time has been spent on three particular projects.

1) Arcade machine.

I’ve wanted to build one of these for a while and with the I3 finished and most of the parts already collected it seemed like an ideal opportunity to tackle this one once and for all. A flurry of jigsawing, gluing, screwing, bogging and sanding quickly turned this

20140313_191908 (Resized)

into this

20140325_084114 (Resized)

20140325_084123 (Resized)

20140325_084131 (Resized)

20140325_084142 (Resized)

For anyone interested the plans can be found for free here.

At the moment the base of the table is pretty much finished, all that is needed wood wise is the table top and the braces for the control panels. The top of the cabinet only needs a quarter sheet of 25mm thick plywood but no one seems to sell sheets that small and the people who assure you vehemently that they regularly have offcuts of that size in that thickness never seem to … If anyone knows a good source for less than full sheets or somewhere with a price so good that I could buy a full sheet then I’d be greatly appreciative.

On the control panel front the diagram for the plans was sent off (and then sent off again because everyone bar one source seem to be too lazy to convert 3 measurements from imperial to metric) to 6 places that do sheet metal fabrication so I could get a couple of blanks knocked up. Eventually the quotes started trickling back with prices ranging from $48 for two to a whopping $160 +GST. In the end I settled on the supplier that could be bothered tacking the imperial conversions (even though I later sent them the plans in metric). They responded quickly, had a good price and did a good job. Thanks Classic Sheet Metals in Henderson.

20140314_132505 (Resized)

These blanks were then drilled to a template cobbled together from various other arcade panels and the buttons and joystick were then test fitted

20140315_180555 (Resized)

20140315_180600 (Resized)

and given several coats of satin black spray paint before the buttons and joystick were refitted

20140319_073201 (Resized)

2) ARCredit

Turns out that two player machines need two coin slots. Guess that makes sense. This caused a problem as the coin slot thingy that I had only had one slot and the supplier no longer sold identical units. Average.

Anyway coins are on the way out, contactless payments are where it’s at so introducing ARCredit.


Arduino Nano with RC522 RFID reader and the obligatory JY-MCU Bluetooth Module.

This particular reader was chosen due to its low-cost and eBay availability, this came at the cost of having a less than ideal method of communication with the MCU namely SPI. The even more annoying this is that the IC that the reader is based around also has a serial connection, it’s just not broken out. Instead then of issuing simple strings out a software serial port I had to resort to using a specific library created to communicate with this reader, but unfortunately at some point written in Italian? with not much basic documentation. After spending a couple of days trawling through the code and trying different things I managed to get the code working well enough for my specific application and another couple of days of fiddling around had the turd fully coated in glitter.

Basically the reader works with the Mifare chips which you can get in token or card form. Using a custom access key the reader pulls the factory serial number and a 16 byte string from two different places on the chip and makes sure that they both match the strings written into the code. A third location is read with a single byte retrieved which represents the number of “credits” remaining on the token. In practice a player would hold down their “coin insert” button on the arcade machine and swipe their tag. The Arduino would check that the tag is valid and then trigger an output pin to send the coin insert signal to the arcade emulator. Each successive swipe deducts one coins worth of credit from the tag and then triggers another coin insert signal. The software has a customizable pricing structure in which you can define the number of credits that are taken off any particular tag each time the token is swiped.

The Bluetooth module is there for the purpose of adding credit to the tags. Connect a cellphone running the ARCredit software and send the appropriate string to the Arduino. The next tag that is swiped will then have its balance set to the value sent from the cellphone.

Once the rest of the arcade machine is finished the reader module will be mounted to the a perspex window in the side of the cabinet with the Arduino and Bluetooth mounted properly on a PCB elsewhere inside. As usual the code is up on Github, any misuse and token fraud will be met with severe repercussions.

3) Battery Charger

I think I’ve mentioned before that the battery charger in the Shopping Trolley is a little suspect. I’m sure that F&P make some good stuff and that the original charger is perfectly good for the stock batteries but ever since I put the new double capacity batteries in the charging light has always been on and the battery level indicator has been a bit suspect. The last thing that I want to do is over discharge the batteries and shorten their life

To remedy this and protect the investment made in the batteries I decided to fiddle around with the charging system, specifically setting it up to better balance and maintain the batteries when the trolley isn’t being used.

As a result 6 massive-key-switches-of-doom have been added to the foot well. Switching the three on the right connect the batteries in series to the rest of the system for riding around where is switching the three on the left connect them in parallel for charging.

20140331_073345 (Resized)

20140331_073357 (Resized)

The string is there to make sure that only one side can be switched on at once and even though the switches each came with one key (making 6 in total) three have been destroyed in the fires of Mt Doom (hidden away where ill never be able to find them). This combined with a healthy dose of “NEVER EVER DO THIS [AGAIN]” to any potential operators should prevent potential 12v deep cycle battery short-circuit fun.


Assistive Technology

So part of Vicky’s (my wife) job as an Occupational Therapist includes sorting out Assistive Technology for those with various physical disabilities. Initially I had little idea of the scope of application that this covered from the various devices that needed control to the various input devices to the actual end function that needed to be performed. I still have a very minor understanding of the various ways in which Assistive Technology is implemented but now at least know terms such as “switch adapted” and “scanning” in this context. It seems that there is almost a need for anything from light switches to electronic deadbolts to iPads to be controlled by any method including push buttons, pressure, levers, joysticks both wired and wirelessly.

I’d heard of things such as “switch enabled mice” and “switch interfaces” to connect large and small momentary push buttons to computers and based on the price had assumed them to be highly configurable devices with many options and much shineyness. Imagine my surprise then upon first laying eyes on one of these switch enabled mice to discover that it’s nothing more than a 2 button USB mouse with a mono 3.5mm socket drilled into the side and wired in parallel with the left mouse button. How can this cost $50?? The same went for a joystick with 3 buttons for a left, center and right click which sells for a cool $750…

I’m sure that there are likely to be some development costs that are being recuperated in regards to the joystick and I guess the number of these devices that are being sold probably drives the cost up a bit but still in an age where you can now use an $19 Arduino to emulate a mouse and a keyboard I would have thought that the cost of these things would have been a lot lower.

Breaking down the mouse conversion you get the following;

  • Microsoft Basic USB wired mouse = $14.95
  • 2.5mm mono socket = $1.50
  • 15cm wire = $0.036
  • Work involved = Unscrew the one screw from the bottom of the mouse, drill hole in side of the mouse and install socket, make the 4 solder connections to the nice large pads that the current button uses (add hot glue is desired), screw mouse up again. = 10-15 minutes work. (pics below)




(Connection points being the top rightmost two solder pads)

Assuming that someone can knock 4-5 of these out an hour then that means that they’re earning at least $60 an hour soldering sockets into mice.

It’s insane the price that some of this stuff is selling for considering what is actually in it. Even more insane when you factor that that price is what is keeping these devices out of the hands of people that could really benefit from being able to use them.

I know that there are people out there that are doing great things converting gaming controllers to make them more accessible to those with disabilities and already working on some custom and reasonably priced equipment but there is still a large gap of need that can be filled by those with even a rudimentary understanding of electronics. Need a keyboard interface? Take that old coffee filled keyboard and solder a couple of buttons or sockets directly onto the controller! That’s all the original buttons are doing after all. 25 minutes later, Job done.

In saying all this it is important to insert this disclaimer. Modifying keyboards and mice is great, it’s easy, it’s fast and it’s relatively safe. Creating new input devices to interface with PC’s Macs, iPads and Tablets is pretty safe too. Unless you absolutely know what you’re doing however don’t play around with critical stuff like electric wheelchair controls, custom devices or anything that could potentially injure someone or destroy an expensive piece of equipment if it all goes wrong.

If you’ve heard of something great that’s happening in this area then chuck it in the comments below. Also if you’ve got anything to say about the above then go for it.

Oops, Pics

Ok so I promised pics of the finished I3 a couple of days ago but didn’t manage to get around uploading them what with work and going camping over the weekend. The quality is a bit average but anyway











Finished I3

So the I3 is finished. One more project ticked off the list and officially marked as done, one more project moved from the “when will it be finished and when can I stop worrying about it” box to the “now I just need to keep it going” box. (Pics tomorrow I promise)

First thoughts?

Well the design is pretty good. Although Ive not used the increased z build height yet I can defiantly see how it could be an advantage. Also the more open design over the V2 also looks like it could end up being advantageous. Truth be told thus far Ive only printed three parts on it so not really enough to justify any concrete opinions about its long term performance.

As both printers sit there printing as I write this one thing is apparent however, for all its quirks and failings, for its constant need of attention, maintenance and freshly printed parts I know that my Prusa V2 will be my first 3D printer love. The cables may not be routed as neatly, it may not have the same precision and resolution and it definitely at times pisses me off beyond all belief but as it stands tonight its knocked out 4 going on 5 parts (albeit at a lower resolution) compared to the 2 from the I3.

The ugly duckling is definitely here to stay..

Update to Robot in a night

So continuing on from the last post about the Zumo robot and controlling it from a phone I started looking into the other functions that the MIT app inventor package provided.

One of the sensors that the app interfaces with on the phone (depending on the model) turns out to be the accelerometer. Three numbers are returned, the pitch and roll of the device along with the compass direction in degrees as a number so I figured if it was possible to capture these numbers in a usable format then they could then be passed over Bluetooth to the robot to be used as a method of control.

The pitch and roll data turned out to be the most useful, when lying flat they return a floating point number that increases and decreases to -90 and +90 as the phone is pitched up and down and rolled left and right. This then needed to be converted to a signed integer before having any applicable leading zeros added. A string identifying the X and Y data as well as the direction of pitch and roll is then combined with these two numbers to make up a 10 digit string that is passed over Bluetooth every 150ms to the Pololu Zumo.

Screenshot_2014-03-04-15-27-08 (Resized)

On the Zumo side of things the start of the string is identified by the character “Y”. The 9 successive characters are then read into an array for processing. 4 IF statements then set a couple of variables to represent the direction of travel in the Y direction (Forward and Reverse now) and the X direction (Left and Right).

As the data is stored in an array as Chars the 6 positions holding the roll and pitch values are then multiplied by the appropriate factor (after having 48 subtracted from them to compensate for the fact that the decimal value for the ASCII character 0 for example is 38) to break back out an integer.

Values between 0 and 50 degrees of pitch and roll are considered to be valid, anything over 50 degrees is ignored and the variable is set to 50 instead. A deadzone of 10 degrees in the middle is then added. After that the values between 0 and 50 are mapped to values between 0 and 400 to be more compatible with the values that the Zumo Motors library works with.

From there the Y direction of travel determines whether the motors drive backwards or forwards by the Y speed value mapped above whilst the X direction of travel determines which motor should slow or accelerate depending on the X speed value. If one of the X or Y motor speeds exceeds 400 or -400 (the max and min supported by the motor driver chip) then the that motor is set to that limit and the other motor is slowed in the opposite direction to create the desired turning force.

Kind of convoluted but it seems to work at the moment 😛

The code is up on Github, I’d love comments on the way things are structured, how to do it better etc, especially the section that deals with the scaling and calculation of the motor speeds based upon the values and direction information coming in from the phone. If you’d like a copy of the APK file to try on an android phone leave a comment below.

Next time… is the I3 finished?

Robot in a night

So in the spirit of complete disclosure I have to say that the robot was from a kit, and that the only additions were three resistors and a bluetooth module but still  its pretty cool that home / hobby electronics has progressed to the point where its possible to build a robot in one night that you can control over bluetooth from a cellphone.

20140303_085757 (Resized)

The base of the robot is a Pololu Zumo ( As per the website these are a small, tracked robot platform that is less than 10 cm on each side – small enough to qualify for Mini Sumo competitions I got mine from along with the 100:1 metal gear motors and a Funduino Uno.

20140303_090342 (Resized)

Onto that I added a JY-MCU bluetooth module. These can be found on multiple websites for around $8USD. Looking through the various forum posts it appears that people have had various levels of success in interfacing and using these modules in their project, mainly due to the limited documentation available, the various levels of firmware (which generally is either not listed on the site selling the module or is incorrect) and the copied-out-of-china lineage most of the available offerings have.

20140303_085813 (Resized)

About 6 months ago I purchased three of these modules off deal extreme for a good price but thus far they have just sat in my interesting parts bin waiting for a worthy project to come along. Now after my success with them on this robot I’m going to jump on again and grab some more as they seem to have a whole lot of potential.

The first step in getting the module to work was wiring it up to the Pololu shield. The module apparently takes 3.6 to 6v according to the silk screen but several other blogs indicated that in fact the modules liked nothing other than 3.3v to work correctly. Fortunately the Uno clone has a 3.3v regulator on board with enough capacity to power one of these units. Connect this to the VCC pin on the bluetooth module and the GND pin to the GND on the shield and half the jobs done. The TXD pin can be connected to any of the free pins on the Pololu shield (I used pin 5) and then connect the RXD pin (via a 1k resistor) to another pin (I used 4). Also connect the RXD pin to GND via either a 2.2k resistor or as I did two 1k resistors in series. This is to level shift the 5v output from the Arduino to something more 3.3v friendly. Make sure when choosing the data pins that you don’t wire it up to a pin that is already used for motor control or the buzzer or something, Check the datasheet!

20140303_085833 (Resized)

The shield is quite well designed in that unlike most Arduino shields all the components face the Arduino board so careful placement is needed to ensure that nothing collides but at the same time is really annoying. There is little if no prototyping space on the shield and what space there is is almost written off due to clearance issues with the USB socket on the Arduino board. As a result I had to squish all the bluetooth stuff in one corner.

20140303_085823 (Resized)

Once the hardware side of things is done its time to start on the software. The Arduino code is really simple. A software serial port is setup on pins 4 and 5 (or whatever pins you choose to connect the bluetooth module to). In the loop section of the code the any data coming in the serial port is read into a single byte variable which is then compared to expected values in 5 “IF” statements. If the expected byte was received then the robot triggers the motor outputs in the expected direction. Code available on GitHub.

On the cellphone side of things a quick program was chucked together in the MIT app inventor software online. One drop down list automatically populates on program start with a list of all paired devices. When a device is picked from the list then the software tries to open a serial connection with the chosen device. Once the connection is open then the 5 direction buttons are activated allowing you with the press of a button to send one of 5 bytes representing the ASCII characters L, R, F, B and S (left, right, forward, back and stop).

Screenshot_2014-03-03-08-59-51 (Resized)

Unfortunately at the moment the MIT software doesn’t have a button down function meaning that it only sends the command once when the button is first pressed. Basically this means that the two options are to either tell the robot to drive forward when the button is pressed and continue until another command is received or to drive forward for a set period of time and then stop until another button is pressed. Ideally the software would send through the forward command as long as the button was held down and would stop as soon as the button was released. If anyone can thing of a way of doing this programmatically using only a single trigger when the button is initially pressed I’d love to know 😀