Christmas lights would be cheaper

Some time back I bought myself a string of generic WS2801 driven addressable LEDs and they've languished in a box ever since. These are 'smart' RGB LEDs with a little driver chip that means you can daisy chain an arbitrary number of them and control each one individually with just two connections for the whole string.

I thought I'd use them for the Time Machine but in the end they were simply too big and the wire between each one too short.

Last night I finally dug them out and had a go with the Adafruit library. This is fifty of them running a slightly faster version of their example code.

They work really nicely but again I suspect they'll be 'wrong' for my next project which needs to have a retro look. So much so that I suspect it'll be done with incandescent bulbs, relays and lots of messy point to point wiring as that's actually what it's supposed to look like.

Although these would make it really easy to make.

Raspberry Pi GPIO:101

My brother always gives me interesting presents. He's got a head start as we both like and do similar stuff.

One of these was a Raspberry Pi T-cobbler kit, which is essentially a way to extend the GPIO connector outside of a case and  plug it into a breadboard for prototyping.

Wiring up simple inputs and outputs to microcontrollers is bread and butter for my projects but I've never actually done this with a Pi. So this morning I pulled the T-cobbler out, soldered it up and did a bit of messing around.

I'm finishing up a project which has a Pi embedded at the moment. It uses a slave Arduino Nano to do most of its interface to the real world and it's going to be properly embedded with the expectation you don't normally have a screen, keyboard or network available.

So despite the presence of the Arduino I want to be able to have some basic control and feedback from the Pi that doesn't rely on anything else working. The python script on the Pi that does the heavy lifting occasionally crashes and while I'm making it more stable some of it is just V4L being  flaky rather than anything I can actually fix in my code. At least that's my excuse.

So I want the following directly linked to the Pi.

• Shutdown button so it can be cleanly shut down rather than just yanking the power. No good will come of that eventually. For this I need GPIO really and I'll probably do it like this.
• Status light that shows the state of the main script, again more GPIO.
• One or two buttons to change the state/behaviour of the main script
• Reset button. Easy, just connect a switch to short jumper P6.

What I've done this morning is connect three buttons and an RGB LED to the GPIO. Pushing each button lights up one of the colours of the LED using a simple Python script.

This is easy peasy stuff that anybody could do with a little looking on Google but it's on these foundations that you can build something that actually 'does stuff'.

I took my medical scanner prop to a UKLTA lasertag game yesterday and people cooed over it again. Given the 'cottage industry' the UKLTA has going building guns for the hobby I'm surprised there aren't more things like it floating around. Some of the people there are far more capable at building things than I am. There seem to be a lot of people around who think this stuff is voodoo when if they set their mind to it could actually turn out some really cool stuff.

...with frickin' laser beams aimed at their heads!

I do a reasonable amount of LARP with the UKLTA who use lasertag as their combat resolution system. It's not dissimilar to Airsoft at first glance except there's no physical hit so you don't have to worry about eye protection and you have to wear a sensor, by convention on the head. It does however have some real advantages as a LARP combat system.

The particular variant they use started out as a toy product in the mid 80s which they adapted for adults and through the hard work of their members have kept alive long after the effective death of the original brand. The 'laser' in the name is a misnomer as it uses normal infra-red light and the guns are essentially similar to IR remote controls. Souped up turbo-charged remote controls.

For some time the UKLTA have had to build their own guns and sensors. A lot of the guns are actually converted from other things like Airsoft or Nerf although there are plenty of scratch built ones around. There's a real 'cottage industry' in the hobby and at events people end up cooing over each other's latest builds.

Over time the capability to send small amounts of data has been developed and nowadays the system can handle different effects from weapons and on the sensors. This includes things like armour, regeneration, healing effects, variable damage, 'stun', ongoing fire or radiation damage etc. The sort of things that make it work well for LARP of the modern or sci-fi variety. Very recently in a game we had a 'techno mage' with a fancy staff that did various effects.

With modern IR emitters being very powerful and microcontrollers small and cheap, you've got a solid combat resolution system where the guns can have ranges in the hundreds of metres and the sensor keeps track of everything for you automatically. The thing it can't really handle is melee or hand to hand combat but people have experimented with making short range 'tasers'.

I have for a while wanted to get involved in making a prop that interacts with this system and one of the people behind a lot of the developments, Phil Higgins, gave me some Arduino code that would generate a simple lasertag shot.

Last night I uploaded this on one of my spare Nanos and connected up an IR emitter fitted into a piece of brass tube I had kicking around left over from the Enigma build to make it more directional. Proper tag guns have carefully set up lens & emitter assemblies but an unlensed one is good enough for use indoors or short range outdoors.

I'm now working on integrating this into a fun prop and will try making my own gun over the winter. If I'm feeling saucy I'll use an Arduino inside and build it from scratch rather than use one of Phil's boards, mostly as a bit of fun.

Hiding the GM behind the curtain

I have, for a while wanted to do something to use technology to enhance how some things work in LARP. This is my first stab at a practical application.

I've made a fake medical scanner which goes through the motions of scanning a sample in a test tube you drop into it. So far, that's nothing particularly interesting. What I've added to it though is a 'GM interface' which can be accessed over Bluetooth.

The photo on the left is where I mocked it up using some breadboard. In the end I used a bigger screen and there's an Arduino Mega inside as I needed the extra pins for bits and bobs. The Uno really doesn't have the memory or flash space to handle driving the display if you use the very nice libraries written by Henning Karlsen.

Once the sample is loaded a GM can connect, set what the outcome is and how long it takes to process. There's a facility for them to type free text and it just outputs it on the screen at the end. I still need to do more work on the software so it handles events in a less linear fashion but I think it's coming along nicely. It better be, the LARP is on Friday.

It's not all code and soldering

I regularly play in a local fantasy LARP and my partner came up with an idea for a jokey motivational sign based on multiple in-game screw-ups we've had.

This weekend I chucked this together using things I had kicking around. I'm not in the least bit artistic so the lettering is done with laser printable transfer sheet. I love this stuff.

I found a small piece of slate, cut it down with an angle grinder, notched it for screws and also used hot glue to stop it moving about.

Having a lump of stone that you write on with chalk seemed the appropriate thing for a fantasy LARP, rather than an LED matrix. :-)

Beaglebone Black Unboxing

Just took delivery of this today. Very impressed so far with the fact that it's usable via USB out of the box as it powers the board and at the same time gives you a virtual Ethernet adaptor over which you can connect to it.

Having stuck a real Ethernet cable in it's merrily updating the distribution and once it's done that I'll have a play with running some of my resource heavy Python code on it. It's been bought to see if the faster, later ARM chip it's based on delivers the performance boost I'd like. An overclocked Pi is OK but only really has the grunt in Turbo overclock mode and this is slightly unstable in my experience.

I lack a micro-HDMI lead so I've not been able to play with the GUI but to be honest I've been using that as a bit of a crutch with my current Pi-based project. I need to start changing it so that it starts up when the Pi boots and can be controlled by GPIO connected buttons or remotely with SSH.

Raspberry Pi Motion tracking in Python Pt. 2

Not all USB webcams are created equal.

OK, this is obvious, cheap things are on average crappier than expensive things but the difference here is really marked.

I've built one of these cheap '6 LED' webcams into my project and until I got the code sorted wasn't that worried it would only do 8 FPS.

I was kind of expecting an imperfect image from a cheap webcam but now my code is good the difference in performance is really noticeable.

Knowing I can hit 18-20 FPS or higher with the MS Xbox 360 Live Camera I picked up later is really annoying as the basis of the project is mostly physically built and I thought I could just concentrate on the coding.

The Xbox camera also does a much sharper image with more consistent colour balance and contrast. Which is important as if the camera jerkily changes colour/contrast of the output as the cheaper one is prone to, this gets detected as motion.

None of this is overly surprising as the Xbox cameras were originally reasonably pricey and MS tend to make nice accessories for their consoles.

So unless I can get to the bottom of the poor performance of the original camera (unlikely) I'm going to have to pull it out and replace it with an Xbox one.

If you're thinking of a webcam based project these Xbox ones are really solidly made and seem to be supported by V4L just fine. More importantly they can be picked up secondhand for £1 from CEX, which is a bargain. So you can order a handful of identical cameras to mess about with and embed in things without worrying about cost much.

The ultimate thing to use is probably the official Pi camera which produces fantastic images. But that's 25x the cost for a bare board you need to make or buy an enclosure for.

Raspberry Pi Motion tracking in Python Pt. 1

My next project involves using a Raspberry Pi to do motion tracking. Not something that is difficult nowadays with well developed libraries for image processing like OpenCV.

What I did discover is that a lot of the example code I found was targetted at more powerful things than the Pi and runs at a snail's pace.

So I took one of these projects as a starting point and after initially trying to slim it down and failing I've started from scratch, taking inspiration from a couple of the examples I found.

I now have some Python/OpenCV code that will do >25fps from a USB webcam on the Pi if you keep the source image small.

Here's some of the output of this, with the object outlined and the green blobs showing the track it has moved through. My next step is to do some anticipation so it can track ahead of the object.

Ideally you need to overclock the Pi for best performance but if you only use a 160x120 source image it's still fine at 700Mhz.

I've ordered a Beaglebone Black for this project by way of an upgrade, but for now I'll stick with the Pi as I've managed to squeeze enough performance out of it to be going on with.

To keep power use and heat down the script drops the FPS deliberately when nothing is moving and then ramps up when something happens. I'm not sure if this is 100% necessary but it feels like something you should do and the temperature definitely stays down a bit.