tag:blogger.com,1999:blog-24462446203223215772024-03-14T05:00:14.782+00:00srimechsrimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-2446244620322321577.post-14050586534450317482013-06-13T01:23:00.000+01:002013-06-13T01:23:40.595+01:00Grue detection t-shirts<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-wGshom9rYG0/UbkNrcpVjZI/AAAAAAAAAXE/-USPERnw7xI/s1600/P1060095.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="http://4.bp.blogspot.com/-wGshom9rYG0/UbkNrcpVjZI/AAAAAAAAAXE/-USPERnw7xI/s320/P1060095.JPG" width="320" /></a></div>
When adventuring it is very important to stay away from grues. I have developed a grue-detecting t-shirt which will warn your party about potential grue danger. When in a good light source or using your lamp, the t-shirt will look as it does in this picture.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-mSIY0eg2jcA/UbkO0e8LkcI/AAAAAAAAAXQ/l3n1pGBxw4U/s1600/eatenbyagrue.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="http://2.bp.blogspot.com/-mSIY0eg2jcA/UbkO0e8LkcI/AAAAAAAAAXQ/l3n1pGBxw4U/s320/eatenbyagrue.JPG" width="287" /></a></div>
In low light conditions the t-shirt looks like this. Find a light source quickly.<br />
<br />
I had this prototype made at spreadshirt.co.uk; in case it's not obvious, it's a combination of reflective and glow-in-the-dark vinyl print. Unfortunately, spreadshirt can't guarantee the alignment of these two print materials, otherwise I'd be offering a link to buy these essential pieces of safety equipment.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-47899150197576048062013-01-31T20:49:00.000+00:002013-01-31T20:49:23.294+00:00Reimplementing TinyHack in PyGame<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-RVPZV3WZwtg/UQq8p9ln5RI/AAAAAAAAAUo/y0GTlREDM3k/s1600/Screenshot+at+2013-01-31+18:49:00.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-RVPZV3WZwtg/UQq8p9ln5RI/AAAAAAAAAUo/y0GTlREDM3k/s1600/Screenshot+at+2013-01-31+18:49:00.png" /></a></div>
This is a small exercise I did today. It's a reimplementation of Rob Beschizza's <a href="http://boingboing.net/rob/tinyhack/">TinyHack</a> in PyGame. Of course, I don't expect anyone to download and play a game which you can play a better version of in your browser. This is just for fun and possibly as a starting point for other Roguelikes.<br />
<br />
It's a reimplementation rather than a port; Rob did provide the source, but it's in Flash format which I've no idea how to read. The 'artwork', levels and sounds are remade from scratch, using <a href="http://www.drpetter.se/project_sfxr.html">SFXR</a> again for the latter. It's stripped down somewhat - the world is smaller, only having three 'dungeons', there's no magic, and no village, although the pub still exists.<br />
<br />
Behind the scenes, there are two main global stores of information in the game. There's a large map, a 2D array of integers, which changes occasionally (squares which represent gold or items are replaced with empty squares when the player moves over them). The second part is a 1D array of 'Entity' objects which contains the mobile things; the player and any enemies. Entities have an x and y position and HP (health) as well as a few other bits. To make things simple, the player is always at index 0 in the entity array. To draw the screen, it's only necessary to draw the map around the player and then the entities. Timing is basic; the game waits for a keystroke to do a player move, and then does an enemy move if the player did actually move anywhere. Enemies have very basic AI, and will just move towards the player if they can. When trying to move in any direction, the game needs to check both the map and the entity list for space. If there's an entity blocking the target square, the entity may attack the target. Enemies are marked as one team which is different to the player, so they won't attack each other. Finally, the player has the extra option of moving into 'teleporters' which are the red squares on the map.<br />
<br />
Items and gold aren't part of the movement routine, but are checked for after moving. Gold just disappears and a counter is incremented. Items need to do different things, so there's a static Python dictionary which maps coordinates of items to types. (39,14) is the shield, for example. A similar dictionary maps teleporters to their destinations. There are also some special teleporters, such as the pub and the jetty, which are marked as special by having a destination x coordinate of 0. The y coordinate in these is an action index which is taken instead of moving the player. 1 is the pub which restores the player's health and 2 is the jetty which ends the game.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-VeCdakWFrjc/UQrS0SYkIWI/AAAAAAAAAU4/pgx-pXW2wrE/s1600/Screenshot+at+2013-01-31+20:17:47.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="176" src="http://4.bp.blogspot.com/-VeCdakWFrjc/UQrS0SYkIWI/AAAAAAAAAU4/pgx-pXW2wrE/s320/Screenshot+at+2013-01-31+20:17:47.png" width="320" /></a></div>
The map and teleporter/object data could be coded directly in Python, however it's a lot more convenient to do it in <a href="http://www.mapeditor.org/">Tiled</a>. As well as making the base map, it's also possible to use Tiled to specify the teleporter relationships and other bits using an object layer. The collectible items, for example, are marked by small objects on the map with the 'item' property set to either 'hp', 'sword' or 'boat'. The code to read this data out of Tiled's XML and into Python structures is in the separate file 'tilereader.py'.<br />
<br />
TinyHack removed a lot of common Roguelike features to make it work in a simple graphical environment: Lighting, line of sight, decent enemy AI, inventory, statistics, skills, fine-grained turn timing and random level creation are all missing. It's still a fun game though. As I said, MicroHack is a starting point, and I'd like to add to it. The question is, which of the missing features are actually important?<br />
<br />
As usual, the code is in github at <a href="https://github.com/jmacarthur/2dgames">https://github.com/jmacarthur/2dgames</a>, in the 'microhack' directory.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-6885660235644365772012-11-02T23:43:00.000+00:002012-11-02T23:43:17.806+00:00Error correction of the NPL time signal<a href="http://1.bp.blogspot.com/-fqP81fOiIb4/UJRM9kMEe7I/AAAAAAAAAT0/zpGUS0MPHaE/s1600/NPLStuff.jpeg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="http://1.bp.blogspot.com/-fqP81fOiIb4/UJRM9kMEe7I/AAAAAAAAAT0/zpGUS0MPHaE/s320/NPLStuff.jpeg" width="320" /></a>There's a project on the back burner at London Hackspace to make a <a href="http://wiki.london.hackspace.org.uk/view/Project:AlarmClock">better alarm clock</a>. One of the first things we need for this is a way to figure out the current time, instead of bothering the user to set it.<br />
<br />
There are a number of ways to obtain this automatically. Both GPS and GSM could be used, and in most houses, WiFi could be used to connect to a time server. DAB is also a possibility in Europe. None of these are particularly cheap though. It would be difficult to get a receiver working for under 20 pounds with any of these methods.<br />
<br />
The National Physical Laboratory transmits a time signal by low frequency radio from Cumbria. This is also known as MSF from its old radio call sign. Similar services exist in Germany and the USA, at least. A receiver can be had for 9 pounds from <a href="http://www.pvelectronics.co.uk/index.php?main_page=product_info&products_id=2">PV Electronics</a>, however, using it hasn't been particularly easy. The signal coming from the module is TTL level, but in my experience, very noisy in the time domain. The signal I got on the first try looked more like this:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-UJ-jDEaR6cI/UJRNXVHxU4I/AAAAAAAAAT8/ehJSubAVsGA/s1600/NPL-timing-diagram.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="263" src="http://3.bp.blogspot.com/-UJ-jDEaR6cI/UJRNXVHxU4I/AAAAAAAAAT8/ehJSubAVsGA/s320/NPL-timing-diagram.png" width="320" /></a></div>
<br />
Eurgh. Some of this is due to the power supply; the module needs a very clean power supply and it took me a long time to get any sensible data while running from a mains supply. Giving the Symtrik module its own linear regulator, some big capacitors and a choke seem to have improved it. The orientation and position of the antenna is also important; I've noticed that it will produce garbage if it's too close even to an AVR running at 1MHz. LCD monitors in particular seem to drive it crazy.<br />
<br />
We could use analogue means to try and get an average value over the expected length of a pulse, or sample it several times and take the most common value. Those are approaches I might go back to, but for now, I'm sampling it just once in the middle of the pulse.<br />
<br />
The <a href="http://www.npl.co.uk/upload/pdf/MSF_Time_Date_Code.pdf">MSF Specification</a> is pleasantly simple. The most important thing to recognise is the minute marker, since all the remaining data frames' meaning is dependent on their sequence after it. If you treat all the frames as 4-bit frames, sampled at 150, 250, 350 and 450ms from the first rising edge, then the minute frame is all 1s, while the other frames always look like XX00. By using four samples it's unlikely to detect a false minute marker, and it's better to miss a minute marker than detect one when there wasn't one. Note that the Symtrik module outputs an inverted signal, which is why the diagram above is upside down compared with NPL's diagrams.<br />
<br />
Unfortunately the signal only has four parity bits for error detection, and only one of those covers the hour and minute information that's really interesting to us. So the best resort we have is to collect data over several minutes, and compare them until we get a sequence of minutes which give us enough confidence to change our current idea of the time.<br />
<br />
This means we now maintain three notions of time:<br />
<br />
<center>
<table border="0" style="text-align: center;">
<tbody>
<tr><td>Display Minutes</td><td>Expected Minutes</td><td>Radio Minutes</td></tr>
<tr><td>Display Hours</td><td>Expected Hours</td><td>Radio Hours</td></tr>
</tbody>
</table>
</center>
<div style="text-align: center;">
<br /></div>
<div style="text-align: left;">
Display time is what we currently display and consider the current time to be; this isn't something we want to change lightly and of course increments by itself. With a crystal oscillator we can expect an AVR to keep good time for months.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Expected time is what we'd expect the next radio frame to say; this also needs to be incremented automatically when we don't get a sensible radio time. Radio time is the time read from the radio this minute. At the end of the minute it's compared with the (pre-incremented) expected time and if it matches, we increment a sequence counter. If it doesn't match, that counter is reset and the radio time is incremented and becomes the expected time for the next frame.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Once we get a high enough sequence (at the moment, 3 agreeing minutes) we can use that to set the display time. If we don't have a current display time (just after power-on, for example) then the standards can be lower.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
I'll provide some C code for the AVR when I have it working well. Debugging is an annoyingly slow process, being locked to the minute cycles of the NPL signal.</div>
srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-42115548203372928272012-08-12T18:26:00.000+01:002012-08-13T12:36:16.125+01:00Simple, headphone-controlled phone robot<a href="http://1.bp.blogspot.com/-5tTh5UMO5cE/UCfhTdYqzII/AAAAAAAAATQ/sYewcyHzC7k/s1600/minibot.jpeg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="http://1.bp.blogspot.com/-5tTh5UMO5cE/UCfhTdYqzII/AAAAAAAAATQ/sYewcyHzC7k/s320/minibot.jpeg" width="320" /></a>TL;DR: The headphone socket on some Android phones is a good enough signal generator to control servo motors almost directly.<br />
<br />
I had an idea recently that servo motors could be driven directly from the headphone socket on an Android mobile phone. I was probably subconsciously remembering this old <a href="http://hackaday.com/2010/05/26/sound-card-driven-servo-motor/">this old Hackaday link</a>; anyway, it turns out that it's very easy to do.<br />
<br />
Servo motors expect a square pulse of 5V of between 1 and 2 milliseconds, usually once every 20 milliseconds. 1 millisecond is canonically fully left, 2 is fully right, and 1.5ms is in the centre, although there is quite a lot of variation. So, I created a suitable square wave by hand in Audacity, saved it as a .WAV file and played it back on my phone's default media player app, while looking at the headphone levels on an oscilloscope. There are lots of reasons to not expect a square wave to come out of an audio amplifier, but the result was actually a very faithful reproduction of my square wave. The maximum voltage I could get out of it was just under one volt, not enough to drive a servo directly, but enough to turn a transistor on. On both the phones I've tried - a HTC Hero (G2) and Desire C - the voltage out of the headphone port is negative with respect to the value in the wave file, so the wave file needs to be between 0 (off) and -32768 (pulses) for a 16-bit sample. As well as playing back standard audio files, it's pretty easy to generate audio on the fly, so you can control servos direct from your application.<br />
<br />
Here's my circuit diagram (I've only done shown one channel - it's identical for both). I'm not suggesting you try this - it might break your phone in some way I haven't thought of. This is just to show what I've done.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-1uwmLb4iy90/UCfjiX05wWI/AAAAAAAAATY/zr2sKYY4VFc/s1600/circuit.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="http://4.bp.blogspot.com/-1uwmLb4iy90/UCfjiX05wWI/AAAAAAAAATY/zr2sKYY4VFc/s640/circuit.png" width="640" /></a></div>
<br />
<br class="Apple-interchange-newline" />
I've used two bog standard NPN transistors in my circuit; the second is acting as a second inverter as the first one inverts the signal once. I think it should be possible to do this with one transistor, and an inverted wave file (using 0 as the pulses and -32768 the remainder of the time) but it hasn't worked when I've tried it and I don't have ready access to an oscilloscope to figure out why.<br />
<br />
Nonetheless, this is a very cheap way of controlling servos from a mobile phone and I would like to find out whether it works on more Android devices. The transistors cost about £5 for a hundred and there's just another 3 resistors per channel to make it work. It is limited to two servos, so if you want more connectivity, you'll probably be after more powerful devices like the IOIO.<br />
<br />
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/lIXjgXOrEsw?feature=player_embedded' frameborder='0'></iframe>This idea gets more useful when you use continuous rotation servos. Here's a video of my old phone running two such servos with wheels attached. Even old Android phones have cameras, accelerometers and wifi, which makes them great brains for simple robots. Running two servos from the headphone socket gives them very cheap mobility.<br />
<br />
PS. I've since become aware of <a href="http://www.gluemotor.com/">http://www.gluemotor.com/</a> which is a very similar device. They don't have any transistors; but use a capacitor on each channel to provide AC coupling. I couldn't get this to work when I tried it with my Android phone - maybe with more experimentation. Still, nice work.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-18844127373676620232012-08-12T14:58:00.000+01:002012-08-12T14:58:53.717+01:00Two more demos: Meteor Miner and Platformatic<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-drHpELLZTTk/UCezNvGm41I/AAAAAAAAAS4/wWIyrC8GXJ8/s1600/MeteorMinerScreenshot.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="253" src="http://4.bp.blogspot.com/-drHpELLZTTk/UCezNvGm41I/AAAAAAAAAS4/wWIyrC8GXJ8/s320/MeteorMinerScreenshot.png" width="320" /></a></div>
Here's another couple of PyGame demos. Meteor Miner is a fairly straight clone of an old BBC Micro game, Thrust. Thrust was probably cloned from another platform, but it's not a style of game that has been used much recently. You control a spaceship by turning left or right and accelerating forwards, much like Asteroids, but the goal is to fly inside the structure of a meteor and recover ore. You can also shoot forwards to destroy the guns which will attack you inside the meteor.<br />
<br />
Fuel is limited and ore makes you heavier. You can escape the meteor with just one tonne of ore, but the goal is to recover all of it.<br />
<br />
This is the first game I've done with sound, although on all the platforms I've tried (Ubuntu, Windows 7 and Android) the sound suffers from an annoying latency. The game works well with the <a href="http://pygame.renpy.org/">PyGame subset for Android</a> but as PyGame doesn't handle multi-touch devices yet, I can't emulate the buttons on a touchscreen, so it will only be playable with a keyboard.<br />
<br />
<a href="http://3.bp.blogspot.com/-AaVVxhNf4Nk/UCezSHuznkI/AAAAAAAAATA/TUBLCFsrt4A/s1600/titlescreen.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="http://3.bp.blogspot.com/-AaVVxhNf4Nk/UCezSHuznkI/AAAAAAAAATA/TUBLCFsrt4A/s320/titlescreen.png" width="320" /></a>Platformatic is a puzzle game which looks like a platformer; rather than asking the player to time jumps exactly, it asks him or her to place instruction symbols onto the screen, which the character will follow when it treads on them. This partly came out of my frustration with platform games which require you to make a long sequence of carefully timed actions, often repeating the first ones hundreds of times until you finally get the last one correct.<br />
<br />
I'm not particularly pleased with either of these games, but I've forced myself to bring them to a point at which I can publish them, as I otherwise tend to abandon old projects while half-finished and start on new ones.<br />
<br />
Both games are available from my 2dgames repository on github and are MIT licenced: <a href="https://github.com/jmacarthur/2dgames">https://github.com/jmacarthur/2dgames</a>. As before you'll need PyGame to play them; as I get better at creating games, I'll consider packaging some of them up or porting them so they can be played more easily.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-52515282803687284972012-07-18T17:03:00.002+01:002012-07-19T13:52:23.467+01:00Investigating Raspberry Pi performance problems<a href="http://2.bp.blogspot.com/-acV79YyenIM/UAbWqm9gjtI/AAAAAAAAASc/Zx-DDAycFgA/s1600/Raspi-Thrust.jpeg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="240" src="http://2.bp.blogspot.com/-acV79YyenIM/UAbWqm9gjtI/AAAAAAAAASc/Zx-DDAycFgA/s320/Raspi-Thrust.jpeg" width="320" /></a>I bought a Raspberry Pi some time ago and have been trying to run some of my PyGame games on it. I'm going to describe one performance issue I've seen with it. This isn't a criticism of the board in general, which I still think is excellent for the price.<br />
<br />
I wanted to show something off at the Raspberry Jam last weekend in Cambridge, so shunted one of my games onto the SD card and started it up. The good news is that the Pi's standard distributions come with Python 2.7 and PyGame already installed, which saves a lot of time and effort. The bad news is that my game, previously running at 120+ frames per second on my desktop was down to 5 FPS on the Pi, which makes it unplayable.<br />
<br />
Of course you wouldn't expect a 700MHz ARM1176 to be as quick as my Core i5, but this isn't a particularly taxing game, and I expected it to be well within the Raspberry Pi's capabilities. It's a 2D game, using lots of blits to draw tiled scenery, some bitmap rotates and vector arithmetic for collision detection.<br />
<br />
My first suspect was floating point, as my game uses a fair amount to do polygon overlap calculations and I'm using PyGame's libraries to rotate bitmaps. The old Debian linux distribution for the Pi didn't use hardware floating point. Yesterday, the new <a href="http://www.raspberrypi.org/downloads">new Raspbian image</a> was released with hardware floating point support, so I gave that a try. No luck - it's still at about 5 FPS.<br />
<br />
Python has a built-in profiler which can be invoked with<br />
<span style="font-family: 'Courier New', Courier, monospace;">python -m cProfile myprog.py</span><br />
<br />
It's best to sort samples by time and save this to a file, so I use:<br />
<span style="font-family: 'Courier New', Courier, monospace;">python -m cProfile -s time myprog.py > profileoutput</span><br />
<br />
(You can also use "-o file" to redirect the profile output to a file, but it's saved in a binary format if you do that, so it's easier to redirect stdout, although this does mix the profiler output with the output from your program)<br />
<br />
Here's the profile from the Rasbperry Pi, with some information stripped out for brevity:<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;"> 225868 65.576 {method 'blit' of 'pygame.Surface' objects}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 1 47.159 thrust.py:1(<module>)</module></span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 605 3.082 {method 'fill' of 'pygame.Surface' objects}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 605 2.802 {pygame.display.flip}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 64433 1.967 {range}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 76268 1.741 {shipIntersectsBlock)</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 10030 0.977 {pygame.draw.circle}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span><br />
<span style="font-family: inherit;">It's often useful to look at the profile on the well-performing case, so this is the profile from my desktop machine:</span><br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;"> 748686 11.493 method 'blit' of 'pygame.Surface' objects}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 1 2.859 thrust.py:1(<module>)</module></span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 2321 2.523 {pygame.display.flip}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 2321 0.405 {method 'fill' of 'pygame.Surface' objects}</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 499709 0.246 (shipIntersectsBlock)</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> 247663 0.081 {range}</span><br />
<div style="font-family: inherit;">
<br /></div>
<div style="font-family: inherit;">
Time at the file level of thrust.py has gone up proportionally on the Pi, but this is probably because the desktop version ran for longer and initialization code wasn't such a significant part. This wasn't a very carefully controlled test. The main thing to note is that 'blit' is what we're spending most of our time on, in most cases. </div>
<div style="font-family: inherit;">
<br /></div>
<div style="font-family: inherit;">
To test this, I removed one blit from the code which blits the static background onto the screen every frame. As might be expected, the performance went up from 5.2 FPS to 8.8 FPS. That's small in absolute terms but a very significant chance proportionally.</div>
<div style="font-family: inherit;">
<br /></div>
<div style="font-family: inherit;">
Now, there's a number of ways to reduce that - the scenery doesn't change often, so it may be more efficient to construct a single scenery image and keep blitting this to the screen rather than blitting each tile individually, each frame. There's also a lot of settings to play with regarding pixel depth.</div>
<div style="font-family: inherit;">
<br /></div>
<div style="font-family: inherit;">
I've got a suspicion that one of the biggest problems is the resolution I'm running - 1824x1104, which is a lot of work for the graphics hardware. My game only runs at 640x480, but I haven't figured out how to get the Raspberry Pi's framebuffer to use a lower res - using a smaller monitor would be the easiest way, if I had one.</div>
<div style="font-family: inherit;">
<br /></div>
<div style="font-family: inherit;">
Update 19th July 2012: Tried this on an Android tablet (Asus TF300) and got 25FPS; and on a laptop with an Intel U4100 @1.3GHz; Radeon 4550 - 50 FPS. Both of these devices are quite capable of doing lots of 2D blits at 50FPS without breaking a sweat, so the culprit is likely to be a software problem.</div>srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-66284012748021456512012-07-03T21:24:00.000+01:002012-07-03T21:24:23.874+01:002D Platform games with PyGame<a href="http://4.bp.blogspot.com/-0VhY1WMSkjo/T_NS-2w4TJI/AAAAAAAAARs/eKtaeySKEbY/s1600/collector-screenshot.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="284" src="http://4.bp.blogspot.com/-0VhY1WMSkjo/T_NS-2w4TJI/AAAAAAAAARs/eKtaeySKEbY/s320/collector-screenshot.png" width="320" /></a>I've been writing computer games for quite a long time but rarely finish anything and never publish them. Just to show that I can actually finish things, here's <i>Object Collector 2D</i>, a tiny game very similar to <i>Manic Miner </i>and a hundred other old platform games. It took one day to program and comes in at 388 lines of Python while still, hopefully, being fairly readable in case any newcomers to Python or PyGame want to use it as an example. Don't expect a competitor to <i>Braid.</i><br />
<br />
I have a tendency to spend a lot of time working on the mechanics of games, finely tuning collision resolution and other rules. There's a great talk on YouTube by Martin Jonasson & Petri Purho called "<a href="http://www.youtube.com/watch?v=Fy0aCDmgnxg">Juice it or lose it</a>" which shows how much more you need than good mechanics to make an enjoyable game, and it's these things I need to work on.<br />
<br />
The code is in my github repository "2dgames", under the directory "collector": <a href="https://github.com/jmacarthur/2dgames/tree/master/collector">https://github.com/jmacarthur/2dgames/tree/master/collector</a>. You'll need PyGame to run it.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-42124323485360061172012-06-08T02:10:00.000+01:002012-06-08T02:12:57.120+01:00Exhibiting the Mk2 Turing machine<iframe width="560" height="315" src="http://www.youtube.com/embed/fIYIV7VHXKk" frameborder="0" allowfullscreen></iframe>
<P>Here's a short video clip of the Mk2 Turing machine working at Derby Maker Faire. It took about 6 weeks from sending the plans off to RazorLab to having a working machine at the Handmade Digital exhibition in Manchester. There are still lots of handmade parts in the Turing machine, but having the majority of it laser-cut has made it much easier to construct.
<P>There are also a lot of bugs in the design. One of the great things about the laser-cut design is that I can record these bugs as though they were software defects, which they are in many ways. The design for the machine is on github, at <a href="https://github.com/jmacarthur/millihertz/tree/master/scad/newbuild/">https://github.com/jmacarthur/millihertz/tree/master/scad/newbuild</a>, although it may not be very intelligible at the moment. I really need to spend more time documenting the design.
<P>Lots of people have said they like the shiny black laser-cut Turing machine, and others have said they prefer the scrappy style of the original. Personally I'd prefer to hand-make the final version out of solid brass, but that will be several iterations away.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.com19 Full St, Derby DE1, UK52.9255091 -1.47725652.9252101 -1.477873 52.9258081 -1.4766389999999998tag:blogger.com,1999:blog-2446244620322321577.post-51915194489831343952012-03-12T21:45:00.010+00:002012-03-15T22:16:02.639+00:00Automating layout of laser-cut models<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-5gJ-o3uaA9A/T15u5-UTTrI/AAAAAAAAAQ8/qTZ6O4JJrTg/s1600/lifters-openscad-screenshot.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 154px;" src="http://3.bp.blogspot.com/-5gJ-o3uaA9A/T15u5-UTTrI/AAAAAAAAAQ8/qTZ6O4JJrTg/s320/lifters-openscad-screenshot.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5719130519066857138" /></a><br /><br />On the left is a rendering of part of my revised Turing machine. The important feature of this, for this post, is that it's a 3D object made up of flat cuboids 3mm thick, which means its parts can be cut out of a sheet of 3mm material by a laser cutter. It's designed (or perhaps written) in <A href="http://www.openscad.org">OpenSCAD</a>.<br /><br />Turning this into a 2D drawing to feed into a laser cutter is a manual process at the moment. The best way I've found to do it so far is to comment out all but one top level object at a time, then add an OpenSCAD projection primitive; compile, then export the resulting object as a DXF. This needs to be done for each part, with potentially different projection settings for each, and then the DXFs need to be manually combined.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/-4DQ1ST2E9ak/T15veSdu8wI/AAAAAAAAARI/RocAcuOL1iM/s1600/flattenned-pieces.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 302px; height: 320px;" src="http://4.bp.blogspot.com/-4DQ1ST2E9ak/T15veSdu8wI/AAAAAAAAARI/RocAcuOL1iM/s320/flattenned-pieces.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5719131142950417154" /></a><br />This next picture is a rasterized SVG which was produced by a perl script I wrote to do this job automatically. The only post processing I've done is to move the top level objects around, as they end up on top of each other at the moment, and to increase the line width. As you can see, this is not perfect, as there are more cut lines there than there should be, but it is automatic. Another advantage of this method is that the produced diagram has true circles in it, rather than the polygonal approximations OpenSCAD produces. The script won't work on objects that are not within a thin plane; the model shown was already split into those objects and had the tabs added by hand. This script is just doing the job of rearranging objects into 2D form.<br /><br />I am hoping to get the <a href="http://www.angusj.com/delphi/clipper.php">Clipper</a> library involved next to do 2D unions and intersections necessary to produce useful laser cutter drawings. This library can also do outsetting, which will be useful to correct for the diameter of the cutting beam. (Inkscape can do outsetting too, but there is a bug in the current implementation relating to small lines at right angles.) For example, the tabs on the end of the thin bars shown above should be part of the same object. The script knows that these are part of a union, so should be union'ed in 2D to remove the line separating them.<br /><br />There are of course restrictions in what this can produce; it's limited to orthogonal cubes, cylinders and polygons. Anything that produces an edge not perpendicular to the plane of the object will not work, but then it couldn't be produced by a normal laser cutter anyway. It shouldn't be limited to orthogonal planes - any orientation should work, although I've not tried it with non-orthogonals yet.<br /><br />This perl script runs from the processed CSG output from OpenSCAD. This is thankfully very easy to parse. I used Parse::RecDescent to parse it. Then there are several passes of tagging elements in the tree and determining which shapes are positives and which are subtracted from the original solid; then a lot of matrix maths to identify top level objects which all fit into a 3mm thick plane segment and to project all its components into the same 2d plane. I hammered out the perl script in one day, and it's full of bugs and very badly written, so I'm not going to publish it right now. If anyone is interested in it, I'll tidy it up and open source it.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-27635993369600002182012-02-12T04:08:00.001+00:002012-06-08T03:06:54.885+01:00Chorded keyboard for mobile phones<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-F8N7JORc_ic/Tzc7ootZRDI/AAAAAAAAAO4/zKF-7Us7aZw/s1600/chordkeyboard.jpeg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://1.bp.blogspot.com/-F8N7JORc_ic/Tzc7ootZRDI/AAAAAAAAAO4/zKF-7Us7aZw/s320/chordkeyboard.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5708096622024016946" /></a><br />
This is a <a href="http://en.wikipedia.org/wiki/Chorded_keyboard">chorded keyboard</a> mounted around the edge of my mobile phone, a HTC Hero. Chorded keyboards have existed for ages and never really caught on, but I thought applied to a mobile phone it might be quite useful. I find existing keyboards for phones are a bit lacking; hardware ones are bulky and software ones are fiddly and take up screen space that could be better used. Chorded keyboards can potentially be more compact, and also have the advantage that they can be used without looking at them. It's currently -3 degrees centigrade in Cambridge, and I'd quite like to be able to control my phone without taking it and my hand out of my pockets while outdoors. <br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-x4uVZzaxWVU/Tzc72WJ6E5I/AAAAAAAAAPE/t1rwSBl83rU/s1600/chordkeyboard2.jpeg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://1.bp.blogspot.com/-x4uVZzaxWVU/Tzc72WJ6E5I/AAAAAAAAAPE/t1rwSBl83rU/s320/chordkeyboard2.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5708096857561502610" /></a>
<br />The keyboard is just five key switches connected to a <a href="http://ytai-mer.blogspot.co.uk/">IOIO board</a>. To type a character, you hold down a combination of the buttons. The first button sends 'A', the second 'B' and holding down both then releasing gives you 'C', and so on. On a production keyboard, you would organise the most common letter to be the easiest key combinations. 'E', 'R', and 'T' would be single clicks, and 'Q' would require the least comfortable click combination.<br /><br />There are 31 possible combinations of the 5 keys, which is room for the alphabet and a few extras such as space, backspace, shift lock and a couple of extra escape sequences to add numbers and symbols. <br /><br />
The IOIO board isn't ideal for this application, because it requires external power to operate rather than drawing power from the phone, hence the 9V battery. That and the bulky USB connectors make this impractical to use. I could replace the IOIO with another microcontroller capable of hosting USB if I wanted to make this a real device. <br /><br />I also need to figure out how to write the necessary Android code to make this a general input method rather than just typing text into a custom application. <br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/-bOfkkd5z7QQ/Tzc8ISIH7uI/AAAAAAAAAPQ/ezocKZN4bZs/s1600/chordkeyboard_case.jpeg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://2.bp.blogspot.com/-bOfkkd5z7QQ/Tzc8ISIH7uI/AAAAAAAAAPQ/ezocKZN4bZs/s320/chordkeyboard_case.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5708097165717925602" /></a>The case is 3d printed by Shapeways. It fits over the phone and replaces the normal back cover. There are spaces in it for the volume control, camera and headphone socket. The volume control could also be used as a 6th & 7th button for chording, if desired. <br /><br />As it stands, the keyboard isn't particularly comfortable to use. The keyswitches require too much force and aren't in quite the right places yet. I think it's got potential though.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-57639836961318943122011-03-16T22:41:00.000+00:002011-03-16T23:05:13.138+00:00Turing Machine and Maker Faire<iframe title="YouTube video player" width="425" height="344" src="http://www.youtube.com/embed/40DkJ9vt5CI" frameborder="0" allowfullscreen></iframe><br />Here's a video I shot at Maker Faire UK 2011. I took the Turing machine along having just rebuilt it without testing, but it worked fine over the weekend after a little prodding and adjustment. I don't think everybody understood it, but everyone was positive about it and those that did understand what it did seemed very amused by it.<br /><br />I didn't get much chance to have a look around the rest of Maker Faire, but it was an excellent event with some great minds getting together to create some great hacks (a video of Kinect controlled Tesla coils is doing the rounds at the moment). <br /><br />Now that deadline's over, I can go back to the drawing board and start thinking about how to make a more reliable, precise version of this machine, or a more powerful machine which could actually demonstrate something useful - which would be better than explaining that this Turing machine would take months to add two numbers together.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-15152976599518438032011-03-06T23:50:00.000+00:002011-03-07T00:44:50.844+00:003D printed cellular automaton<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/zslHoquO5zk?hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/zslHoquO5zk?hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />Work on the Turing machine continues steadily, but in the meantime I have been working on a backup plan for Maker Faire. Since I have a fair amount of spare time when I can't get to London Hackspace to do stuff with drills and hacksaws, I started work on a 3D printable automaton. The result is in the video above. It's missing two levers since I plain forgot to include them in the order, and this prevents it from actually computing anything - but this video shows the robot reading input data and altering the output data. When the levers are in place, it'll only move some of the output data, thus doing something interesting.<br /><br /><br /><br />The input data is the row of ball bearings on the bottom of this video. They're all ones for the purpose of this video. The output data starts off as all zeros, and gets set to ones as the machine moves along. In doing so, the machine calculates the (n+1)th row of a rule 110 cellular automaton (top row) based on the nth row (bottom row). <br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-ajQrLTenevk/TXQo3RTVKXI/AAAAAAAAAKE/i5WHV1ko7Mw/s1600/P1050129.JPG"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://1.bp.blogspot.com/-ajQrLTenevk/TXQo3RTVKXI/AAAAAAAAAKE/i5WHV1ko7Mw/s320/P1050129.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5581130768221284722" /></a><br /><br /><br />Although it's a lot simpler than my mechanical Turing machine, it does exactly the same function - but it needs replacing manually at the end of each row (generation). Moving in only one direction is a really big deal, and makes everything much simpler.<br /><br />Both this and the Turing machine will be on display at <a href="http://makerfaireuk.com">Maker Faire UK</a> next weekend in Newcastle (12th & 13th March). At least one of them will be working, but sadly I've had to forego steam power in order to run it indoors.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-52063813808094735292011-01-08T21:46:00.001+00:002011-01-08T22:03:41.586+00:00Turing machine preview video<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/Kzs-uPcCU7k?hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Kzs-uPcCU7k?hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br />Here's some video I shot at <a href="http://wiki.hackspace.org.uk/wiki/London_Hackspace">London Hackspace</a> last weekend. The machine isn't working properly, but this should show roughly what it'll look like when it does. There's some mild swearing on the soundtrack; mute it if that offends you.<br /><br />I'll be back at the Hackspace tomorrow, making another lifter (5th revision!) which should make it easier to pick up ball bearings and allow more space for a better centering system when the ball bearings are returned to the track.<br /><br />I've been accepted to <a href="http://www.makerfaireuk.com/">Maker Faire UK</a> in Newcastle in March - I'll have the machine running on a stand there with some more cellular automata stuff. See you there hopefully.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-61445784864472081872010-12-31T05:27:00.001+00:002010-12-31T05:35:35.606+00:00December machineryThe 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.<br /><br />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.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-70709443231017702002010-12-22T22:42:00.001+00:002010-12-22T23:09:44.924+00:00BigTrak + IGEP<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/fGax2SJQyCU?fs=1&hl=en_GB"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/fGax2SJQyCU?fs=1&hl=en_GB" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object><br /><br />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 <A href="http://www.srimech.com/projects/bigtrak/">http://www.srimech.com/projects/bigtrak/</a>. 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.<br /><br />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.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-19307796737526925172010-11-24T23:03:00.000+00:002010-11-24T23:17:23.757+00:00November Turing machine update<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_8BsbSnZCbEs/TO2Z3aXUaiI/AAAAAAAAAJw/2F_B7qkK9qI/s1600/tmachine-nov.jpeg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 214px;" src="http://1.bp.blogspot.com/_8BsbSnZCbEs/TO2Z3aXUaiI/AAAAAAAAAJw/2F_B7qkK9qI/s320/tmachine-nov.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5543255893611932194" /></a><br /><br />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.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-5617017448911941132010-10-31T21:14:00.000+00:002010-10-31T22:03:10.471+00:00Robot Hackday success<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_8BsbSnZCbEs/TM3g-T3B_yI/AAAAAAAAAJo/TiVi3cgKM2g/s1600/wrigley.jpeg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://2.bp.blogspot.com/_8BsbSnZCbEs/TM3g-T3B_yI/AAAAAAAAAJo/TiVi3cgKM2g/s320/wrigley.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5534326878195810082" /></a><br />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.<br /><br />Enter Robot Hackday, a day organised by <a href="http://madlab.org.uk/">MadLab</a> and <a href="http://hacman.org.uk/">HacMan</a>. 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 <i>The Secret Life of Machines</i> many years ago. Tim's a really friendly chap and he spent ages helping me get my robot working. <br /><br />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. <br /><br />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. <br /><br />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. <br /><br />Thanks to everyone at MadLab and HacMan, that was a great day out.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-53264665948863699652010-09-26T23:55:00.000+01:002010-11-24T10:15:51.428+00:00September progress on the Turing machine<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJ_VtPxZhCI/AAAAAAAAAJg/yXRki2N2fLY/s1600/turing-26092010.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJ_VtPxZhCI/AAAAAAAAAJg/yXRki2N2fLY/s320/turing-26092010.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5521366641484071970" /></a><br />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.<br /><br />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.<br /><br />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. <br /><br />We'll see how it goes.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-41239856616487391922010-09-24T00:39:00.000+01:002010-09-24T01:43:15.053+01:00A modder's guide to the 2010 BigTrak<P>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.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_8BsbSnZCbEs/TJvlqm2ytcI/AAAAAAAAAIw/CSa-qaUS9Fs/s1600/unboxedd.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://2.bp.blogspot.com/_8BsbSnZCbEs/TJvlqm2ytcI/AAAAAAAAAIw/CSa-qaUS9Fs/s320/unboxedd.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520258288420304322" /></a><br />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.<br clear=left><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_8BsbSnZCbEs/TJvl5tvMg8I/AAAAAAAAAI4/tQIAQawKjic/s1600/onbackd.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://4.bp.blogspot.com/_8BsbSnZCbEs/TJvl5tvMg8I/AAAAAAAAAI4/tQIAQawKjic/s320/onbackd.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520258547965526978" /></a><br />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.<br clear=left><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJvmG476UQI/AAAAAAAAAJA/OTBMRcwzQ9g/s1600/insided.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJvmG476UQI/AAAAAAAAAJA/OTBMRcwzQ9g/s320/insided.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520258774309949698" /></a><br />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.<br clear=left><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJvmTCFxCbI/AAAAAAAAAJI/QLgGOezemWM/s1600/driveunitd.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_8BsbSnZCbEs/TJvmTCFxCbI/AAAAAAAAAJI/QLgGOezemWM/s320/driveunitd.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520258982925633970" /></a><br />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. <br clear=left><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_8BsbSnZCbEs/TJvmeApypXI/AAAAAAAAAJQ/mqdmxY8553k/s1600/gearboxd.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://4.bp.blogspot.com/_8BsbSnZCbEs/TJvmeApypXI/AAAAAAAAAJQ/mqdmxY8553k/s320/gearboxd.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520259171518424434" /></a><br />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.<br clear=left><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_8BsbSnZCbEs/TJvz6Je7rYI/AAAAAAAAAJY/ipaGVwCiC2Q/s1600/igep-bigtrakd.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://1.bp.blogspot.com/_8BsbSnZCbEs/TJvz6Je7rYI/AAAAAAAAAJY/ipaGVwCiC2Q/s320/igep-bigtrakd.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5520273948576296322" /></a>I'm pretty happy with this; my next plans are to install my <a href="http://www.igep-platform.com/">IGEP board</a> 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. <a href="http://www.amazon.co.uk/gp/product/B0035IZ85G?ie=UTF8&tag=wwwsrimechcom-21&linkCode=as2&camp=1634&creative=6738&creativeASIN=B0035IZ85G">Amazon</a> 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.<br clear=left>srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-6056329347932546252010-07-31T01:24:00.000+01:002010-07-31T01:57:54.009+01:00Camping with dry iceQuick 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.<br /><br />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. <br /><br />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.<br /><br />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.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-55821016882065592172010-04-14T00:35:00.000+01:002010-07-31T21:41:42.010+01:00Plans for a mechanical Turing machine<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_8BsbSnZCbEs/TFNctOLubwI/AAAAAAAAAIY/0TBK_dqsUlk/s1600/turing-1.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 248px;" src="http://4.bp.blogspot.com/_8BsbSnZCbEs/TFNctOLubwI/AAAAAAAAAIY/0TBK_dqsUlk/s320/turing-1.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5499841501920653058" /></a><br /><br />This is a project I've been planning for many years. It's a design for a fully mechanical <a href="http://en.wikipedia.org/wiki/Universal_Turing_machine">universal Turing machine</a>. 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_8BsbSnZCbEs/TFNmoBzKjhI/AAAAAAAAAIg/tRD6OT0lMPo/s1600/turing-schematic.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 169px;" src="http://4.bp.blogspot.com/_8BsbSnZCbEs/TFNmoBzKjhI/AAAAAAAAAIg/tRD6OT0lMPo/s320/turing-schematic.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5499852407813344786" /></a>This schematic diagram shows the main components of the machine.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />There are other cams to run the raiser and to reset the direction box each cycle.<br /><br />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. <br /><br />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.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-31025237691675508892010-04-11T13:02:00.000+01:002010-07-31T21:42:38.283+01:00Fab Lab success<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_8BsbSnZCbEs/S8HB_-xyQqI/AAAAAAAAAII/GYPtf9rlWv8/s1600/two-mazes-med.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://1.bp.blogspot.com/_8BsbSnZCbEs/S8HB_-xyQqI/AAAAAAAAAII/GYPtf9rlWv8/s320/two-mazes-med.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458857528277484194" /></a><br /><br />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. <br /><br />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.<br /><br />On the left is a CNC milled block which I was able to get made due to the opening of <a href="http://www.fablabmanchester.org/">Fab Lab Manchester</a>. 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.<br /><br />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 <a href="http://openscad.org">OpenSCAD</a> 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.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_8BsbSnZCbEs/S8HC0FtyyDI/AAAAAAAAAIQ/n8VGYzYqbq0/s1600/rect2822.png"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 275px; height: 320px;" src="http://2.bp.blogspot.com/_8BsbSnZCbEs/S8HC0FtyyDI/AAAAAAAAAIQ/n8VGYzYqbq0/s320/rect2822.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5458858423492986930" /></a><br /><br />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 <a href="http://en.wikipedia.org/wiki/Turing_machine"> Turing machine</a> - the Wikipedia article may help explain this if you're not familiar with them.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-21816442762372585672009-12-16T00:23:00.000+00:002009-12-16T00:55:58.581+00:00Madlabs and Hackspaces<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_8BsbSnZCbEs/SygpCL8Mw6I/AAAAAAAAAH4/q_dG590yYJk/s1600-h/IMG_1067.JPG"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 320px; height: 240px;" src="http://3.bp.blogspot.com/_8BsbSnZCbEs/SygpCL8Mw6I/AAAAAAAAAH4/q_dG590yYJk/s320/IMG_1067.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5415623669454783394" /></a><br /><br />2009 has been very interesting for collaborative hacking. <a href="http://stockport.hackspace.org.uk/">Stockport Hackspace</a> caught my attention first, and I went to a few meetings and met some very cool people there but trekking down to Heaton Chapel after work got a bit too much for me. Recently, <a href="http://madlab.org.uk/">MadLab</a> started up in Manchester as well. I went along to their hackday on Saturday. They have a great working space of three floors in some of the otherwise unused buildings in the northern quarter. There were some great people there as well, mostly working on small robots from the high tech micromice to simple shufflebots. MadLab looks very promising and I'll take along some stuff to break apart and hack together next time they run an event.<br /><br />Stockport Hackspace are planning on (and seem well on the path to) opening a Hackspace in central Manchester.<br /><br />On the heavier side, <a href="http://pitstartgarage.com/">PitStart garage</a> caught my attention. It's a pay by the hour garage with tools included. I have to wonder how much I'd end up paying if I drove in and then made my car undriveable, as I often do when I try to fix things on my car myself. It's also in London so not a great deal of use to me, but I'd love to see more of this type of thing around the UK.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-82033605099629962282009-07-31T23:24:00.000+01:002009-12-16T00:59:09.090+00:00Golf GTI shakedown<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_8BsbSnZCbEs/SnN8ixrDjtI/AAAAAAAAAG8/02X3377YzKw/s1600-h/DSC00066.JPG"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 200px; height: 150px;" src="http://4.bp.blogspot.com/_8BsbSnZCbEs/SnN8ixrDjtI/AAAAAAAAAG8/02X3377YzKw/s200/DSC00066.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5364768518019714770" /></a><br />Faced with the possibility of 600 miles through England and France with five people in a car to accompany my parents on holiday, I decided to buy my own car. <br /><br />Not wanting to take an easy option, I bought a 1985 Volkswagen Golf GTI Convertible. This replaced my previous but younger 1990 Nissan Sunny 1.4 LS, which was a remarkably reliable and well handling car if not particularly sporty. <br /><br />This Golf is in good mechanical condition for a car of its age, and its chassis has been sealed well and is free of rust. I bought it from a private seller in Stockport and immediately took it to a garage for a check over. We fitted a new clutch, timing and alternator belt, and had both rear wheel brake cylinders replaced and the tyres re-sealed. This service cost almost as much as the car cost me in the first place, but I was expecting that.<br /><br />The first run out was to Wales for a camping weekend. The fuel delivery problem became apparent during this run. It started kangarooing and cutting out while driving through the centre of Manchester, but with a good battery to keep starting it, it managed to get out without any serious problems. Once on the motorway it had no problems.<br /><br />The Mk1 Golf GTI uses a Bosch K-Jetronic fuel injection system, which is an entirely mechanical multipoint but non-direct petrol injector system. A fuel pump under the driver's seat pumps fuel at injection pressure (I think) into an adjacent accumulator to cope with peak demands, which then feeds up to a fuel distributor in the engine compartment. The problem manifests as an infrequent but sometimes severe lack of power, often enough to stall the engine. My own experience from driving it makes me think there are large air pockets in the fuel, but I have been very wrong about diagnoses in the past. I think it's likely this problems does occur while driving on the motorway but is not noticed in the momentum at those times.<br /><br />The fuel problem had been declared by the previous owner when he sold it to me, and he had done a lot of work to try and resolve it - fitting a new fuel pump, fuel distributor and injectors amongst other things but these evidently hadn't fixed it. Mk1s often suffer from rusted fuel filler tubes, and while this had been replaced on mine, there is a strong possibility of rust in the fuel tank contaminating or blocking the other systems. Just before leaving for France, I replaced the fuel and air filters as I had no evidence of their being recently changed. The old fuel filter did emit ominously brown fuel at the tank side when removed. I hoped the new filter would permit more fuel through and solve the problem.<br /><br />As well as this, I replaced the fixed offside mirror which was deflecting under motorway winds with a decent one with remote cable controls. This would be especially important when driving in France. I also replaced the original cigarette lighter socket with a modern one which would accept an accessory plug without falling out, and correctly connected the passenger door lock so it could be locked and unlocked from the inside.<br /><br />Unfortunately, at nearly the last minute I also noticed the reversing lights were not working. I had lighting problems with my old Nissan and patch wired them, but reverse lights are a bit tricky because UK law (as I understand it) requires that they can only be activated when reverse gear is engaged - a switch on the dashboard won't cut it. After a while prodding at a rather inaccessible switch unit on the gearbox, I decided to fix a microswitch to the gear lever housing in the cabin. I used Polymorph, a low melting point thermoplastic to construct a solid structure for the switch around the gear lever. I would recommend keeping a pot of this stuff around for emergency repairs to any engineer.<br /><br />With that fixed, I set off for the Latitude festival. The fuel problem appeared once again while picking up a friend from Manchester, but after that there were no problems. Me and the Golf proceeded on to Saint-Barthelemy in Brittany and back, the only problem being an embarrassing incident while loading onto the return ferry. Near the top of the loading ramp, it cut out and would not restart for more than a few seconds, and this required us to raise the ramp and push it into position on the car deck. After sitting idle for 10 hours on the deck, it restarted with no problems and proceeded to drive back to Bolton via Hertfordshire without any further issues.<br /><br />The fuel problem will be an interesting one to debug. A full inspection of the tank and the fuel lines will be the next project. One of the rear wheel cylinders also appears to be leaking again, but hopefully this will be fixed under guarantee.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.comtag:blogger.com,1999:blog-2446244620322321577.post-61041530703828965362009-05-01T10:37:00.000+01:002009-05-01T10:43:28.136+01:00"FabLab" opening in ManchesterSome vague details have appeared in the press of a 'FabLab' opening in Manchester later this year. It sounds like a low-volume, general manufacturing plant. I'm imagining some CAM and 3D printers. This could be very exciting if it goes ahead. <br /><br />News article: <a href="http://opensource.sys-con.com/node/940106">http://opensource.sys-con.com/node/940106</a><br /><br />The main backers seem to be <a href="http://www.manufacturinginstitute.co.uk/">manufacturinginstitute.co.uk</a> although there aren't many more details on there yet.srimechhttp://www.blogger.com/profile/01431109582044364593noreply@blogger.com