No longer updated!

My blogspot site is no longer updated. Most of the posts here are archived at along with new content.

Friday, 31 December 2010

December machinery

The Turing machine ran three instructions in a row on Wednesday morning. I caught the 9am Tuesday train down to London Hackspace and worked through till 9am on Wednesday. The only problem remaining is getting the ball bearings to land reliably on the correct grid space. Direction change and movement are all solved problems now. I've added a gate released by an existing cam to stop the ball bearings exiting the machine too quickly, but the ball bearings often miss their correct grid spots.

This can be fixed by placing guards onto the grid, but I really want to avoid modifying the grid. Modifying an infinite tape requires infinite effort.

Wednesday, 22 December 2010

BigTrak + IGEP

So here's what I've done with the BigTrak so far. I've mounted the IGEP on the back, mbed in the nose and arranged battery power for all the electronics and set up WiFi to remote control it. Boring technical details are at The audio on the video is poor, sorry about that. I wanted to be able to hear the motors and my voice is pretty soft at the best of times.

Annoyingly, the biggest challenge by far has been getting the drivers working on the IGEP. It's a neat board, but not very popular so there isn't much community support out there for it. It took me a couple of weeks to get WiFi and usb-acm (necessary to talk to the mbed) working at the same time, and the next challenge is to get it to recognise a USB webcam.

Wednesday, 24 November 2010

November Turing machine update

Had a couple of days to work on the Turing machine during November. It's now on its fourth revision lifter, this time there are two lifting arms, one which will stop at the top of the state box and the second containing the magnets which will continue on, so the magnets are separated from the ball bearings at the top. This seems much more reliable. It needs a longer movement on the string which lifts the arms up, so there's a pulley system to double the effect of the cam lever. I've also made some changes to the reversing mechanism, using a weight which is just slightly stably balanced so requiring a very small force to switch over to the other direction. This should be operating at the end of another day's work.

Sunday, 31 October 2010

Robot Hackday success

Nearly three years ago I wrote a little blog post about the MUTR micro rover kit which I'd just received then. I put together a basic rolling chassis then but then got distracted and didn't do anything more with it - until this opportunity came up.

Enter Robot Hackday, a day organised by MadLab and HacMan. People bring down old electronic junk and attempt to make automata out of them. We succeeded in making an army of wonderful robots, from scribblebots and shaking Altoids tins to furry tanks with glowing eyes. It was great to have a bit of banter with other hackers as we tried to get a robot ready within the day. One of the special guests this year was Tim Hunkin, a hero of mine since he presented The Secret Life of Machines many years ago. Tim's a really friendly chap and he spent ages helping me get my robot working.

In the photo is WrigglyBot, the robot I built on the day. I seem to have been photobombed by a robotic raptor. Someone else there (I forgot your name, sorry) named it as the front of the chassis ended up low enough to the ground to scrape chewing gum off the floor. The axles needed trimming to fit both gearboxes side-by-side, and then I drilled holes for the rear axle and redrilled the rear wheels so they were loose on the axle. There are three relays controlling the motor, one does the forward/reverse control for each motors, and the third is the main on/off control for both. As it stands, it can't run just one track at a time.

The relays are switched by the ever popular ULN2803 chip, and the whole caboodle is orchestrated by an mbed board. This is the first thing I've used an mbed for, and apart from a minor panic when MadLab's wifi left me without access to the mbed online compiler, it worked very nicely - certainly a lot less hassle to program than my usual microcontrollers. There's two batteries on board - the main 4x C cell runs everything, and would have run the mbed but it kept resetting when I switched the motors on, so I put in a separate 9v battery to run that.

The only problem is the clip-in worm gear sets. The worms tend to rise up when the gearbox is put under strain, and this will strip the gears if allowed to run for too long. Mine was still slipping despite lots of Araldite and wire holding the motors down. I think they need something to hold the worms down at the front.

Thanks to everyone at MadLab and HacMan, that was a great day out.

Sunday, 26 September 2010

September progress on the Turing machine

As of this evening, all the cams are working correctly and the main sequencing events (lift data, reset direction, drive) are working. The drive system is driving too far backwards, three grid spaces instead of two. The data lifter also requires far too much force to drive. Ideally, this could be counterbalanced by adding some lead weights, but there isn't a great deal of space to add anything right now.

The cams have been a lot more problematic than expected. Attaching a cam to a 5mm steel shaft requires some sort of flange which itself has to be secured to the shaft. I made several flanges out of aluminium which were meant to be fixed to the shaft by set screw, but in a lot of cases the thread failed before I could tighten the set screws enough to hold the cam. Filing flats on the shaft helps to some extent, but means the angle of the cam has to be decided then and there. When this machine is completed I think there might be quite a lot of subtle adjustment needed in the timing, so I'm reluctant to go filing or drilling the drive shaft right now.

Forward/reverse movement has been a cause for some concern. The 'punt' mechanism is working, but I'm not convinced it will be reliable in the long term. I also have plans for a more conventional forward/reverse gearbox and have a sprocket which will interface with the steel grid, thanks to Razorlabs.

We'll see how it goes.

Friday, 24 September 2010

A modder's guide to the 2010 BigTrak

Zeon Tech have started making a replica of the Big Trak (or bigtrak, or BigTrak, whichever you prefer) so I bought one to see how it'd work as a mobile robotics platform.

In the box you get the BigTrak, a manual and a pack of stickers to make it look like the illustration on the box. I think having stickers to apply yourself is great, so please continue with that, toy companies. As with the original, the centre wheels are driven and the front and rear axles are free. The front axle on this one allows some vertical movement, although it's not sprung. This presumably allows the machine to keep the weight on the middle wheels at all times, although it does mean it will rock back and forwards a little bit. The whole unit runs off 3 D cells, unlike it predecessor which needed a separate 9V battery, presumably to run the computer.

Underneath, there are plenty of screws to remove. The only difficult one is at the back, highlighted by the yellow arrow here. The plastic moulding on the back will come off with a bit of prodding, and you can see where the clips are if you remove the rest of the screws and open the case up a little. By pressing in in four places, it will come free. Don't bother removing any of the screws from the wheels or the grey drive unit underneath yet.

Once all the screws are removed, you can see inside. The ribbon cable goes up to the membrane keypad, which is unfortunately glued onto the case. However, the glue isn't strong and you can remove the keypad without damaging it. Wires at the front go to the 'photon beam' LED and speaker. One of the first mods you'll probably want to do is snip one of the speaker wires, although it will make programming the existing circuit board more tricky. The other wires go to the battery box and a tiny circuit board on top with the on/off switch and an IR LED; presumably the IR LED is for the trailer attachment, when that comes out. There's a lot of empty space inside the case, which is good news for modifying it.

Removing the ribbon cable and snipping the rest of the wires allows you to remove the drive unit. This is the least destructive way to get the drive unit out, as the controller board is soldered directly to the motors and can't be easily removed. The grey drive unit will now just drop out of the chassis. The circuit board is not particularly interesting, having two chips marked CE3962 which is the model number of BigTrak itself. There's a few discrete transistors on the underside of the board, which are probably the motor drivers. You might be able to modify this to operate the motor off TTL signals, but I'm not particularly interested in using it.

So now the important bit. A few more screws removed and you can see the gearbox. I was expecting this new model to have skimped a bit on the components compared to the original, but this actually looks good - it still has encoders on the second set of gears, and it still has the magnetic clutch between the motors. This clutch keeps the motors in sync if you drive them at roughly the same speed, to improve your chances of driving in a straight line. The motors look small, but they didn't have any problems driving on thick carpet when I briefly tried them.

I'm pretty happy with this; my next plans are to install my IGEP board on it and connect up a couple of electronic speed controllers to run the motors. You can see the IGEP mounted (not connected to anything at the moment though) and the BigTrak with the (badly) applied stickers to the left. Amazon seem to the be the cheapest place to get them at the moment; I paid £32.48 for one including P&P through a reseller.

Saturday, 31 July 2010

Camping with dry ice

Quick report: Is it feasible to take dry ice on a camping trip and keep your drinks cool with it? Yes, although it's not cheap or particularly easy. The results are however much better than car-powered cool boxes, in my opinion. You'll need to find a dry ice supplier who is either on your way to the campsite, or who will deliver to you before you set off. I found All About Ice, based in Hemel Hempstead, which was handily on the route I was going to take to get to Swanage. I paid 35 pounds for 10kg of dry ice pellets and a thick polystyrene container for them. The container is a cube about 40cm on each side. Needless to say if you want to pick up dry ice you'll need to get there during normal working hours, which probably means a day's holiday from work for you.

The next problem is transporting it - dry ice is constantly subliming into carbon dioxide gas, which will suffocate you in a closed container, and if you're driving you'll probably kill more people than yourself if that happens, so be really careful with it. This means you drive with all the windows open, and if it rains you get wet.

Once you've actually got the dry ice to a campsite, most of the difficult parts are done. You'll need another cool box, as you can't put food or drink straight into the dry ice container - it's about -86 centigrade in there. Put some heavy gloves on and transfer some dry ice into the bottom of a cool box, then cover that in a bit of cardboard and put your food or drinks on top of that. If bottles come into excessive contact with dry ice they will freeze and could shatter. If you need to cool something quickly, you can put another layer of cardboard on top of your beer and then shovel some dry ice on top of that. Now you can enjoy cold beer and wine well into the second and third day of the weekend and be the envy of the campsite. You'll probably only want to transfer a little bit of dry ice into a cool box at a time. I also found I could leave the cool block things you get for cool boxes in with the dry ice overnight without them exploding, but your milage may vary on that.

Lock the dry ice in your car when you don't need it, to prevent children and idiots playing with it - it will burn you if you touch it. Don't forget to give your car a few minutes airing with the doors open before getting in if the dry ice has been in there overnight. Don't put dry ice or any container containing it in your tent, for obvious reasons. Apart from that, the only problem will be disposing of it if you don't want to take the remainder home. Rather than just dumping it somewhere children or pets could burn themselves on it, you'll want to pour a lot of (ideally warm) water on it to disperse it. This could be quite a lot of water, so be prepared for a few trips to the tap.

Wednesday, 14 April 2010

Plans for a mechanical Turing machine

This is a project I've been planning for many years. It's a design for a fully mechanical universal Turing machine. My self-imposed constraints are to use no electronic or even electrical components, to be driven by a single rotating input shaft, and to be constructable with simple hand tools, without relying on high precision parts.

Trying to design something like this is an interesting challenge, and something I've found I can work on entirely in my head when I'm stuck somewhere with some spare time and not even as much as a sheet of paper to draw ideas on. Some of you might like to stop reading here and try and figure out a design yourselves before this plan taints you.

I had most of the conceptual design finished at the start of this year, and it's taken until now to get a fully specified model made up in OpenSCAD. I think this is now ready to manufacture.

One of the most difficult initial problems is how to store a reasonable amount of data, such as the tape for a Turing machine without having to manufacture a large number of custom parts. My design uses ball bearings on a sheet of pattern perforated metal as the tape. The position of balls on the grid is the data, and the machine moves back and forward on the grid. To be strictly universal, the perforated metal sheet needs to be infinitely long. I haven't carefully examined the sheet RS have sent me but will assume it to be infinite for the time being.

I'll now try to describe how the rest of the machine works, which is pretty difficult and I don't think this will be immediately clear. I hope to have a working prototype soon which should make its operation clearer.

This schematic diagram shows the main components of the machine.

The next component after the grid and set of ball bearings is a lifting arm or raiser (red) which picks up the 'input symbol' under the read head and lifts it to the top of a block of channels not unlike a marble alley. The run needs to contain some state which will direct the ball down different channels, and needs levers which will update the state for the next ball, and set the direction the machine will move. It also needs to direct the ball back to a new position on the perforated sheet to 'write' the new symbol.

First in the run is the 'state box' (cyan) which diverts the ball down down one of two paths depending on the position of the gate. The position of the gate is the state of the Turing machine. Paddles on the gate also turn the gate as the ball falls, setting the new state of the machine. The output of this box is a ball in one of ten positions, representing the combinations of five input symbols and two initial states.

The next part is the 'direction box' (green) which has levers in some of the ten paths which will alter the direction of the Turing machine later on. If a lever is hit, the machine moves left, and if not, it moves right. The actual movement isn't carried out in this phase, as the falling ball won't have nearly enough power to move the whole machine, but it sets state which will be picked up later.

After falling through the state box, the ball falls into the 'maze' (orange) which maps the ten input positions into one of five output positions, which is the output symbol for the machine. A set of gutters under the maze will return the ball to the grid in its new output symbol position.

Behind the marble alley, there's a tower which performs the movement for the whole machine. A cam (blue) drives a set of three levers (brown) which move the machine. The bottom lever can be easily deflected from one side to the other while it's raised; this is done by a linkage from the direction box. The cam drives the levers downwards, where they engage with the grid and push the whole machine forward or backward two grid spaces.

There are other cams to run the raiser and to reset the direction box each cycle.

The whole machine rides on wheels which ride on top of the grid. Using round wheels on a square grid will provide a small amount of alignment so the machine doesn't drift away from the positions of the balls.

This machine is a 5-symbol, 2-state Turing machine. The configuration comes from Stephen Wolfram's "A New Kind Of Science", which shows this to be a universal machine. While it's relatively simple, it's also ridiculously inefficient and could not be used as a practical computing device. It's just meant as a demonstration of how simple a universal computer could be.

Sunday, 11 April 2010

Fab Lab success

This is a picture of two attempts at making a machine component. I'll explain what it actually does later, but this is mainly a post about how I made them.

On the right is my first attempt, cut by hand with a Dremel with a router accessory. As you can see, it's pretty rough, but it just about works - you can drop a ball bearing into one of the slots and it will roll down to one of the exit holes in the base. Sometimes they'll stick, so it needs a bit more work yet.

On the left is a CNC milled block which I was able to get made due to the opening of Fab Lab Manchester. I mentioned this a while ago when they made their press release, and they've just opened so I went along on Saturday. It's an amazing place and free to use on Fridays and Saturdays so long as you don't mind sharing the details of your project. This was cut using their enormous ShopBot CNC vertical mill.

I'd never got on well with 3D modelling programs and tended to use POVRay to model projects since I'm used to working with code rather than WYSIWYG editors. At Maker Faire UK this year I discovered OpenSCAD which is in some ways similar to POVRay - it takes a text scene description file and produces a 3D representation which can then be exported as an STL file - a format which milling machines and 3D printing machines can understand. The maze shown was just a piece of text in an editor on Thursday night, and by Saturday afternoon I'd been able to turn it into a physical object. For an amateur mechanical engineer like me, this really changes the game and allows a huge number of ideas that I'd never otherwise be able to realise. I'm very grateful to Fab Lab and especially Hayden who spent most of his afternoon showing me how to set up the mill.

If you're still interested in what it does, the diagram to the left might make it clearer. The idea is to drop a ball bearing into one of the central slots, marked by the yellow squares. The two columns represent two states of a state machine, and the five rows are the five different input symbols. Based on the state and input symbol, the ball bearing rolls down to one of five output holes. The vertical position of the output hole is the output symbol. In short, this is part of the control logic for a 5-symbol, 2-state universal Turing machine - the Wikipedia article may help explain this if you're not familiar with them.