Viruscraft: tangible interface electronics

We needed to get a working prototype of our tangible interface running for the second Viruscraft workshop, so that we could have a complete system up and running from the custom hardware to the on-screen game world for people to test and give us feedback on how it worked.

You can read Amber’s full report on this workshop here.

A recap on how this is supposed to work – we need to plug different types of ligand (protrusions on the outside of viruses that allow them to attach to cells in order to infect them) into a large wooden model virus capsid (the body of the virus) that we are building for use in exhibitions. The choices of shape you pick affects which host species your virus can infect on a simulation that is being run in real time. The best ligand shapes to use will change over time, as the hosts adapt to your mutations.

We decided to start by using a simple conductivity system to detect which ligand shape is plugged in, with three sets of three pairs of conductive pads on each triangle face of the capsid that can be connected (or not) with strips of copper on the bases of the ligands. This means we can detect between 7 different shapes in total. It’s very cheap and simple, but a conductivity measurement like this will never be 100% accurate, which is why we are doing it in triplicate – the redundancy allows us some leeway if they are not plugged fully in, but this also results in a lot of connections we need test.

We started by using 6 digital inputs on a Raspberry Pi GPIO – just reading two sets of connectors on one triangle. Even with the triple redundancy, the connection across the pads is never going to be perfectly conductive, so in order to increase the sensitivity of the digital inputs (which need quite a bit of voltage to register as ‘on’ without extra circuitry) we added gigantic pull up resistors (22 Mohm). This means they default to on (+5V) but with very little current passing through – so a tiny amount of conductivity to ground will drop the voltage enough to register as ‘off’. This means they are so sensitive that you can trigger a change just by bridging the gap on the pads with your fingers – this is exactly the same way that MakeyMakeys work.

Based on our previous experiences with the self-etched PCBs we designed some neater ones that we could get manufactured so they would be consistent. In the meantime we have also recently got our hands on a CNC mill we can use for future PCB construction like this – but haven’t quite had time to get it set up for production yet.

The next step was to come up with a more scalable way to read the signals, by moving everything onto a ATmega328 microcontroller – which is much cheaper than a Pi and suitable to embed in a custom circuit. The first plan was to keep it simple for the workshop and use it’s 18 of its i/o pins to directly read just 2 triangles, so we could quickly get on with the job of connecting it to the game world. We didn’t have time to get a PCB specifically designed for this, so I used strip board for rapid construction, just a few days before the workshop. To speed things up a bit I tried using KiCAD to help with the layout design.

Although KiCAD is not really designed for strip board it works quite well if you stick to a few rules. You set the grid to 2.54mm (1/10 inch) and use the lower copper side to represent the strips – drawing each one as you need them and leaving spaces to indicate where you need to cut the copper tracks. The top side copper layer is used to plan where the jumper wires will be placed to connect across the tracks where needed. The idea is to minimise these wires to make it simpler to build – and KiCAD is good for checking the circuit is correct for you as you organise everything. We then printed each side out on paper for reference, and glued the bottom side to the board to indicate where to cut the tracks.

One advantage of prototyping in strip board rather than making PCBs is that it’s much easier to modify things in an adhoc manner. For example, halfway through building this we made the wooden parts of the capsid structure, and thought it would be a better demonstration to use 3 or more faces for the workshop if we could. At this point we could use a multiplexer chip to allow the microcontroller to select which triangle it is reading and share the 9 digital pins between all the triangles connected, in order to read each one in turn. This would mean we could use a single microcontroller to read 16 (or more) entire triangles (144 digital signals) rather than just 2 (18 signals) which is probably be enough in fact for the final design.

To do this we used a 74HC4067 multiplexer chip left over from the flotsam tangible programming project. These work like a general purpose digitally controlled switch, allowing you to connect a single pin to one of 16 connections and select them using 4 inputs as a binary address. We can now use this chip to select which face is connected to ground, meaning that the microcontroller would only be able to read the connections for that one face – even though they are all sharing the same microcontroller input pins.

This seemed to work well on the breadboard, but has a big problem that in the pre-workshop rush gave me a frustrating time to figure out precisely. When a selected face has a connection on the same position as another face which is currently unselected by the multiplexer, the ground connection loops back round the circuit to the unselected face too. If that unselected face also has a connection across the pads in a location that the selected face doesn’t, then the microcontroller will mistakenly read that as a connection signal as well as it will be grounded and effectively read both of them at the same time.

The problem is that this only happens in particular arrangements of ligand codes, which means the interference doesn’t always occur. In order to prevent this grounding problem where it ‘leaks out’ to the rest of the circuit the fix is to add diodes to each separate face connection, which only allow the current to move in one direction.

So this simple conductivity system turned out to not be quite so simple as hoped!

Emergency diodes…

Connecting this to the simulation, which is running in the browser (entering the world of the web) was actually much less of a problem than that of stray electrons. The microcontroller is connected to a Raspberry Pi via i2c serial for data – this setup is borrowed from the pattern matrix, which means the Raspberry Pi can read part the microcontroller’s memory. A python script reads the state of the ligands over i2c and overwrites a text file each time a change is detected. This text file is accessible to a web server that is also hosting the game. The code running on the browser (in this case on the workshop participant’s laptops, but eventually on an exhibition computer) reads this text file every second and updates the virus that is used for the simulation automatically when it is changed by a player.

In the workshop we used the Raspberry Pi to serve the game over a wifi hotspot that people could connect their devices to, and we could get participants to test the tangible interface by adding/changing ligands. As they did this it would mutate the virus running in all their simulation worlds so they could see what was happening on the physical virus – and the hosts would get infected by the new virus on each player’s world.

Penelopean robotics theory and the woven cosmos (part 1)

The Penelope project is concerned with many things, pattern structures in ancient poetry, comparisons of Andean and Greek mathematics, and the role of liveness in thought processes – to name just a few. We can also add robotics to this list.

A weaver in action is often mistaken for a robot – perhaps it’s the repetitive actions that mask the accompanying thought processes from our eyes. Similarly, a livecoding performer typing code into a laptop can face a problematic interpretation that they are grandstanding their expertise, rather than simply attempting to contribute to a party atmosphere at an Algorave. These activities often seem to be misunderstood in a similar manner but in different directions, perhaps partly due to the fact they both employ technology that is either greatly over or under-played by the ubiquity of their end results.

The Penelope project is concerned with using these technological misunderstandings in order to search for deeper assumptions we may have. One case we’ve discussed for a while has been to combine the situations above, if a weaver livecodes a robot which is operating an ancient loom – what is the response to this?

One way to design these situations well is to use an ‘artistic conceit’, a implicit fictitious assumption that provides a framework to fit things together so they make sense. For example, working with the Quipu database, we used the central idea that the Inca were attempting to communicate with us to naively employ cryptanalysis, visualisation and sonification in an attempt to understand their untranslatable knotted thread codes.

An important reference for the Penelope project for me is Carl Sagan. In his influential series ‘Cosmos’, weaving is mentioned many times as a central ordering principle of time and space for the Ionian thinkers of ancient Greece, who initially wrote down many of the fundamental scientific ideas he is introducing. He embarks on a thought experiment considering what life would be like today without the destruction of the library of Alexandria – which contained much of their discoveries and ancient knowledge from all over the world, now lost forever. His conjecture is that this single event may have set us back as much 500 years in scientific thought, so it’s just possible that without this event occurring, on a different timeline to ours – around about now, the first space ships would be returning from the surveying planets orbiting other stars.

It it this kind of imagination and suspension of disbelief that can give us a new perspective on our current predicaments – and perhaps a more humble position with which to question that our ways of thinking are inevitable, obvious and about as good as they can be.

For example, if the invention of general purpose computation and robotics had occurred in a society much earlier – one founded on the woven cosmos, what could it have looked like, and how would it have worked? What might it tell us about different ways of doing things?

Building Viruscraft planets

The last months have been booked solid with production on various projects, so I’m very behind with blogging. This means that there are a few loose threads that I need to look back on and write about, one of which is the Viruscraft world.

This is a screenshot of the current ‘alpha version’ of viruscraft we tested with the custom tangible interface (more on that soon) during the second game testing workshop. You can read Amber’s report on this workshop here.

It took a while to develop this planet, we started with a more conventional system:

This was a planet modelled in blender, the idea being to create islands and regions for different host species to live. We automatically made zones for different species to live (sea and land mainly but also higher terrain is possible) and then populated this with host organisms. There are two problems with this approach, one is that it’s a static model – we could have a set of variations on planets but e can’t change the terrain. One of the initial obvious references we talked about to the Wellcome Trust was Minecraft – which allows players to modify a procedurally generated terrain. Another problem with this is that if we look at our initial mood board for the project, where we collect artistic references:

There are lots of interesting ideas here, including perhaps using geomtric virus shapes in an interesting way. There is a problem I’ve seen on many games projects where if there isn’t a strong artistic style at the start, a more photorealistic logic takes over and pushes things into less and less interesting territory. So we decided to try something a little stranger and more interesting – could we create worlds built from triangular sections of terrain in the same was as viruses are created from triangular proteins?

There is also a distinct advantage to a procedural technique we can do with modular world building because the shape of the land affects how viruses spread – the number and physical location of population clusters has a big affect on how difficult it is, as a virus – to spread and become successful. The more dynamic and controllable we can make the world, the more interesting the game will be.

We chose a shape called a ‘Pentakis icosidodecahedron‘ – basically an 80 sided sphere built from triangles. One mistake I made with this was to not read the mathematical fine print – it took quite a lot of swearing before I figured out that it’s not regular, some of the triangles are equilaterals and others are isosceles. This means we have to squash and stretch the components to fit precisely, otherwise there are gaps between them.

Once we can arrange the triangles in the right places we need to make sure the terrain edges match up. It turns out there are 8 possible arrangements – from all sea, all land to the 6 varieties of crossings that can occur between the edges of the triangles:

We can also control the probability of a triangle of containing land, and use a slider as a sea level setting. Roughly speaking, the more unified the planet – the less, bigger populations possible and the easier it is for your virus to spread. The more fragmented and diverse the populations, the harder it is.

We’ll be adding more controls here in the future, so you’ll be able to customise your planet quite a bit more. We then made some animated low-poly host creatures to populate the planet. These have receptors for the virus that match the different shaped ligands – they breed and evolve to gain resistance to your virus over time.

In order to place them correctly on the right habitat we created some test ‘flat worlds’ to make sure everything was lined up correctly. It works by calculating barycentric coordinates in each triangle based on the particular terrain section, so we can generate a random location and check if its land or sea.

Another possibility is to have different themed planets, an ice world, urban planet, etc – perhaps rather than creating them you could explore a galaxy planet by planet. One important idea that came from the feedback would be to use the ‘difficulty setting’ that we’ve figured out from the terrain composition to provide tutorial levels that you could work through in increasing difficulty.