The Airman

Generative audio from found 16mm film.

Projecting the found footage of “The Airman” using a scratch built film projector (created using a few parts from a defunct projector, 3d printed parts and threaded rod).

The film is projected onto a small screen and captured by a USB webcam feeding into Quartz Composer to process the footage and then capture pixel values, which are then passed by midi to Pure Data.

The PD sketch was created by Martin Brinkmann, and adapted to accept the passed midi controller values to adjust the sounds being created.

In future, I hope to get the film sync'd with a strobing light source, to produce a still image; and to construct a PD (or similar) sketch from scratch to generate the music.

We very quickly decided that the advertised uses of the technology (retail, museums etc) weren't very interesting and we should build a game instead. iBeacons allow you to use proximity to either standalone beacons (e.g. Estimote), or to other devices that support the profile (later iOS devices running iOS7).

The idea that emerged was game based on viruses, where the aim was to infect everyone else without being infected yourself. The game mechanic would be (for extra geek points) Rock-Paper-Scissors-Lizard-Spock, where when coming into close proximity with another player, you would have to choose one of your viruses to play against them with, and then fight for who infects who.

iBeacons in the end turned out to be harder to get working reliably than we‘d first anticipated and are very slow to recognise the change in proximity (probably due to limitations or configuration of the underlying Bluetooth LE system). However, we presented the game and won the ’Hardware - Best use of other features prize'! 👍

iBeacons are definitely something Steamshift will be revisiting in the future.

First up, I didn't take advantage of the fact that Fritzing manufactured boards can have tracks on either side; meaning that I ended up with a number of jumpers. Not a major issue, but more stuff to solder up.

The 2nd issue is that I'd just used an RGB Led from Fritzing and not checked whether it was common anode or cathode. Turns out my board needs a common anode, and the LEDs I bought were common cathode. So in the interests of getting a board working, I found a common anode LED and soldered it up with long wire legs so it would fit.

3rd up, OOPS! I managed in the design to connect GND and +V on the Atmega chip. A little creative soldering and that was resolved too!

The 4th issue was that I missed that the LCD required a link to ground from pin 5. Again, no problem with a bit of wiring.

And finally, I found that I'd forgotten to put a resistor connecting the data pin of the temperature to +5v. I wired that in line, and off we went.

All of these issues will be rectified in the next version of the boards, but considering its my first crack at getting something made, I'm pretty pleased with the results. Especially as it does actually work!

Next job, solder one up and see how it works!

As much as I would have loved to go to WWDC this year, I decided that if I had a couple of grand spare (haha!) or perhaps rather less, that I would rather spend it on being part of the maker revolution - hence the eShapeOko post from the other day; and now 3d printing.

As a first foray into this field, I'm lucky enough as a member of SoMakeIt to have access to the 3D printer that member Chris has lent to the space (in part in thanks for all the expertise from Bracken and others that has helped get it running). I figured that a good place to start (apart from the inevitable Minecraft stuff that my son would undoubtedly like me to print) would be a few bits for the eShapeOko.

Thanks to Thingiverse I was able to find this cable chain which looks ideal for keeping the router's cables out of the way whilst its moving, a series of pen holders and an Arduino (Uno) Altoids Insert.

In terms of software, we need Slic3r and Printrun; I'm running these jobs using a mac so needed the Mac binary of Printrun available here.

And thanks to standing on the shoulders of those who've been there before I was able to get Slic3r configured using a config file pre-prepared for the SoMakeIt 3d-printer.

Starting with the simplest model - the Arduino altoids insert - I downloaded the .stl file, imported it into the configured slic3r app and exported the GCode.

With that I was ready to import into Pronterface and do my print! (Next time I'll cover the printing itself)

So, here is BrewSwitch Mk2 (breadboard version):

and here is the PCB:

First up, I found that my Atmega chip was unflashed, so I needed to burn the bootloader this tutorial made it very easy!

Then I used this tutorial for setting up the software and then using a combination of this breadboard arduino tutorial, and the photo from the follow up from the initial tutorial.

However, the bit that neither tutorial mentioned, but in retrospect should have been obvious was connecting power to the logic-level converter.

So, here's what I ended up with:

I found a a neat product called a brew belt designed for exactly such a scenario. Depending on the outside temperature, you place the belt on your fermentation vessel at different heights to ensure it warms it the right amount. Trouble is, that my kitchen isn‘t always a certain temperature … and I didn’t really want to keep checking the temperature and moving the belt. If only there was a way of switching the belt on and off depending on the actual temperature of the brew…

Inspired by the (vastly more elaborate) brewpi project, I've rigged up an arduino, connected to a wired thermometer which can (safely) swich the brew belt on or off depending on the temperature of the brew.

Building on Hacklet #12, adding a waterproofed version of the DS18B20 one wire thermometer using this handy tutorial and connecting a cheap Maplins remote controlled mains switch and a tutorial for hacking that, I now have myself an automatic brew temperature switch.

Using the RC switch means that the mains power is completely isolated from the arduino etc.

So, all that remains is to test out how well it works!

Read on for the arduino code …

Hmmm, I wonder what we could use that for…?!

Here is the final arduino code (I'm currently using Michael Krolls BLExplr for testing)

I found this tutorial and the one one learn.adafruit.com very useful to get it started.

Here is the code; I know its horrible (really really bad); I'm worrying about hardware not learning python for now! I'll clean it up before I do any more :)

Without further ado, I give you RoboBear (Mk I):-

An aluminium frame added to the bear provides a stable support for a Pan and Tilt kit which controls the head movement. I upgraded the servos because the included ones didn't have enough torque to get a decent range of movement, and the both servos are currently controlled with an arduino.

In this first iteration it runs through a simple predefined set of movements, with the programming of movements and adding things for him to respond to next on the agenda.

Rather than writing one for this demo, I based the hacklet off the How to Make a Platform Game Like Super Mario Brothers – Part 2 tutorial on the ever excellent RayWenderlich.com.

On the iOS we've just replaced the sound playback code from iPyPiDrum with method calls that replace the touch events in the Koalio game.

So where to start? First up, I needed socket server, after messing about for good few hours with “Twisted”, I hit upon this tutorial / script - Asynchronous socket server in python.

With a little hacking (gist at end of the post), I was able to get button data sent over sockets to initially telnet clients.

telnet 192.168.0.22 12345

Next issue, sockets on iOS; as is often the case, Ray Wenderlich provided the answer How To Create A Socket Based iPhone App and Server.

Once I had data flowing from the socket server to iOS I found that the data was getting corrupted somehow. Adding …

.encode("utf-8")

… to what was being sent fixed that issue.

A bit of iOS hacking and we have our iPyPiDrum!

The python code:-

The reason for working with the PS2 dualshock controller was, apart from some intriguing possibilities with connecting games controllers to iOS games / apps, was to try getting the Taiko no Tatsujin controller to work with iPad. I loved the arcade version of this game and was almost tempted to buy a Japanese or American PS2 specifically for this game (stupid region locks).

Again using USB Overdrive, I was able to confirm that the TnT controller worked in exactly the same way as the dualshock controller and therefore would work with the RPi in exactly the same way.

So using exactly the same python program as for the dualshock comtroller - we have ourselves a drum pad!

Obviously there is loads of latency, but it proves the concept!