On the Penelope project, our plan was to develop technologies that could be useful in constructing a swarm of robots which could be livecoded by using the pattern matrix – a general purpose tangible programming system based on the Raspberry Pi. In order to make communication possible remotely, radio is the most obvious approach to get up and running quickly (other options that are intriguing are infra-red and audible sound).
A commonly used and extremely cheap module for radio communication is the nrf24l01+, which uses the 2.4Ghz band (the same as wifi) and allows you to send messages between arbitrary numbers of transceivers. It provides a very flexible networking setup – you can address them all individually, or broadcast to many at one go (which doesn’t seem to be mentioned anywhere), or you can construct a mesh network, passing on messages to receivers outside of the range of the original sender.
There are a few examples online for getting these working with both Raspberry Pi, Arduino and bare-bones ATMel microprocessors as used in our prototyping system. However the tricky thing about radio communication is that it requires you to have both a transmitter and a receiver operating before you actually can tell if it works – it can be extremely difficult to know what is happening when you are developing both at the same time.
I found this quite a challenge – probably not helped by using different hardware at each end, as I needed to cobble together multiple examples to get anything to happen. Here are some things I picked up that might be handy if you are trying to get these radios to work:
- Before doing any sending or receiving, check that the SPI serial is set up properly by reading registers on the nrf24l01 and checking that they match the default settings in the data sheet.
- Then try writing to them and reading again to check that the writes actually take effect. Note that this only works when the radio is not sending or listening for transmissions! Not reading the documentation carefully cost me a few hours here.
- Make sure _all_ the registers match on both sides, there are obvious things like the frequency channel and data rate but also auto-acknowledge, crc and payload size all need to be exactly the same otherwise not even the interrupt will fire to let you know something has been received. Although it should have been obvious, most of my problems came down to this – using different example code and not knowing the defaults to begin with made it tricky to know for sure what was going on.
- Get the transmitter working first. There is a very useful function on the nrf24l01+ which allows you to check if a carrier signal is detected on a frequency without doing any other processing. There is an Arduino library scanner example program in the RF24 library which steps through all the frequencies checking for any carrier signals. You can easily see where your local wifi is with this, so you can pick an empty section of the frequency band to broadcast on and then watch for it’s carrier to be detected. Once I had seen that the Pi was actually sending *something* (you need to make it send as many messages as possible for this to work well) I could concentrate on why the receiver was rejecting or not tuned to it.
- There is a lot of stuff on the internet about power supply being a problem – I worried about this a lot and tried many different capacitors across the voltage pins, but in the end all my problems were software based. On the robots we’re using 3.7V Li-Ion batteries and a 3.3v regulator (a low-dropout one as the voltages are very close) plus 2.2uF capacitors to keep the supply smooth on both the 3.3v and 3.7v sides, which works fine even with the servos sharing the power.
Penelopean robotics are about rebuilding technology in the woven cosmos. You can read more about the theory in part 1, but roughly our aims are to:
- Embody Penelopean technological practice – they should be easily undone (taken apart) so they can be understandable, self documenting and repairable.
- They are not automated looms, but must eventually be capable of weaving in some form, maybe by interacting with ancient Greek weaving technology.
- Capable of embodying elements of ancient Greek poetry and dance, perhaps via livecoding.
- Be constructed in the spirit of Simone Giertz rather than Boston dynamics
Some potential further directions we have discussed are swarm robotics and the use of May poles as a stepping stone between dancing, braiding and weaving.
This is a story of one Penelopean robot.
The original concept of the weaving robot as described in the project was an ‘arachnoid mechanism’. We wanted to stick with this general direction and begin by building a six legged insectoid. After a bit of acting out of the movements required, and looking on youtube for similar robots it seemed that it was possible to do this with 3 servos, two for the front and back which rotate horizontally and one in the middle which rotates vertically.
Weaving crops up in plenty of medical, space and industrial situations – the strength and lightness of woven structures has lots of advantages over other techniques used in engineering, and in the spirit of the project it seems appropriate to try tablet weaving as a way to construct the main framework for the robot. For more info on how to do tablet weaving yourself, see this previous post and this one.
Double weave can be used for this as it allows you to weave tubes and pockets without any cutting or stitching, so they have very strong joins. Here is a sketch of the initial design:
Three joined tubes can hold the micro servos in place, and I later added another smaller one in between for a cylindrical lithium ion battery from Adafruit that was the perfect shape for this.
The process of weaving was a case of starting with a normal section, followed by beginning a double weave split via two weft threads, and checking it every couple of wefts to fit the first servo. When it’s big enough to tightly fit you close the first tube and immediately start a second, for the battery – then the middle servo (which fits at right angles to the others so is slightly smaller) and finally the last servo, with a normal section of tablet weave to close it up. This didn’t take very long, but to make more I could easily count wefts based on the first one and do a lot more quickly – for example, manufacturing swarms of these robots.
As a comparison, this process would be much more difficult and slow via 3D printing – as you can’t generally change anything on the fly, and the design needs to be completed before printing, and the softness turns out to be important.
Although the weave is strong in itself, it still needs a skeleton for the robot to stand up. I used 2mm wire for both this job as well as the legs. One piece of wire is used for the top (which loops around
the battery) and another bent double for the lower side. This scaffolding means that the middle legs will be able to push against something to raise the other legs to walk. Then all you need to do is tie loops of thread around each servo to hold it in place along with the scaffold. This may be unnecessary with a bit more development.
The PCB for the microcontroller and radio (more on that in a later post) can also be tucked under the top wire so it’s locked out of the way of the legs on top.
Christian Faubel showing us the unique nature of analogue computation and what happens when you apply this to robotics at the Penelope robotics workshop in Munich.
At the time of of the Penelope robotics workshop I could get the robot to shuffle a bit in generally the right direction but it wasn’t very efficient or convincing. It took a little servo sequencer programmed by the pattern matrix (in a similar manner to how it sequences music) to experiment with it and work it out properly. This takes a short list of symbols representing angles (from -90 to +90 degrees) which loop.
This is the working code for walking on the pattern matrix – more descriptive tokens will be made in future! These patterns are sent over radio to the robot whenever they change.
The general idea is that if you have 6 legs you can keep 3 feet on the ground while moving the others, which is much more stable than if you need to balance. The front and back servos job are to drive the robot forward and have the same movement as each other at the same time. The role of the middle legs are to lift the side of the robot up in alternate phase so only the ones pushing ‘back’ are touching the ground.
This meant we could use the pattern matrix to do things like switch direction by inverting the middle row above, which controls the central servo. This lifts the robot’s sides in the inverse phase, which means its feet (following the same pattern) move it in the other direction.
You can see a selection of different patterns of movement on this video:
The best aspect of the woven structure was how strong it was – it could throw itself around all day without problems and the flexibility helps too with the movements required. I could also stuff the robot into the bottom of a bag and it would be fine the next day.
There will be more info here on how to build them – for now the code is all here, the electronics is based on this prototype board – watch this space for more of the details on the radio enabled tangible robot livecoding.
We are working on a lot of hardware projects at the moment as we are interested in how to to rebuild technology from various alternative starting points. It seems most “off the shelf” hardware has converged on increasingly inaccessible and conservative forms, but luckily (and probably not due to entirely unrelated reasons) at the same time there has been an explosion in the availability, community documentation and potential of open hardware and DIY micro controllers, modules and components.
Right now we are simultaneously working on Viruscraft – building a tangible programming interface inspired by and for constructing virus geometry, Penelope where we are making more tangible interfaces and robotics inspired by ancient weaving tech (watch this space), Midimutant – re-purposing obsolete sound technology (more on this soon also) along with Sonic Kayaks – live sonification of underwater sensor data.
We start these projects with a more or less standard approach, prototyping and testing components using breadboards connected to Raspberry Pis or Arduinos, seeing if we can get them to work and investigating how it all performs. The next step would generally be to design a series of custom PCBs and eventually build a finished product.
The problem for us is that there seems to be a gap missing when we want to test something that needs to work in a relatively robust way (for a workshop, event or performance) but we do not have the final design settled yet, and need still need a lot of flexibility. Breadboards are problematic if you need to move things around a lot or depend on it for an workshop event. Strip board is very nearly good enough – except that you end up doing a lot of work rebuilding the same circuit many times, and it’s a very time consuming process. On the other hand, it’s wasteful ordering a custom PCB as you may well need to discard most of them.
In order to try and make this process a bit easier, we have designed a modular hexagonal ‘perma-proto’ PCB that can be ordered in large quantities and shared and reused for entirely different projects and uses.
The requirements were:
- Make it small – both so it can be used when space is a constraint and so it can be cheap to manufacture, so we can have lots of them.
- Include a small freeform prototying area – with a built in power bus.
- It should have a second stackable breakout PCB version for more prototyping space.
- Work with atmega328 or 168 – which are familiar Arduino compatible 8 bit microcontrollers with loads of library code.
- Use a ‘through hole’ chip so we can use a socket for swapping them around, removing them after accidentally destroying them etc!
- Expose all ports on pin headers in a logical way.
- Include an ISP header so we can program it directly.
- Include 4 pin power and i2c so it’s compatible with the rest of our recent hardware.
This is the main microcontroller board and stackable “hat” which has more space for adding components.
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!
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.
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?
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.
While we experiment with new fabrication techniques in order to shorten supply chains (with a philosophy of collapse in mind), electronics is problematic. Components can be salvaged and reclaimed but a particular problem is printed circuit board manufacture.
Like many we have tended to outsource this work to China, where the costs allow us to do short-run prototyping with our tiny budgets. Are these lower costs simply due to scale and the Communist support of the Maker community there? Or more worryingly, is this due to reduced regulations in the areas of employment rights and environmental protection?
Either way, outsourcing this kind of fabrication sometimes doesn’t make sense. For Viruscraft we need a finer understanding of the materials involved to design our tangible virus interface. We need to detect the ‘shapes’ of receptors attached to a physical virus capsid, and the first approach we want to try is using voltage detection of the kind used in things like the Makey Makey. If we give each virus receptor three bits of information we can represent seven different receptor shapes, which is plenty for our needs. We need some kind of connection point that can read this information – a printed circuit board with exposed conductive ‘touch pads’ embedded in the virus capsid seems a good way to proceed.
This is also a chance to experiment with PCB manufacture, which is pretty messy and involves very nasty chemicals. In ‘doing it ourselves’, the theory is we can learn ways to minimise environmental degradation which could impact our designs in future, even if we end up having to outsource their manufacture.
The general concept is that copper clad boards are etched with acid in patterns that control the flow of electricity when components are soldered to them. We will be using some (quite old) sodium persulfate crystals here, added to water to form an acid bath for the board, which will be immersed until the exposed areas of copper are dissolved. We wanted to try two approaches to creating a ‘resist’ that would prevent the etching, one using insulation tape (actually horse leg bandage tape – well, we are based in a rural setting!) – the other simply using permanent marker to draw the circuit.
First we design a outline and print it out at the correct scale, you can see this in the background in the photo below. As we are using triangular plugs/sockets, we need to be able to ‘read’ the receptor in any orientation, so 18 pads are needed in total.
Then we completely cover a copper clad board in insulation tape. One of the big lessons from this process is that etching large areas uses up more acid and takes longer – so you only want to expose the absolute minimum.
We stuck the template to the board and used it to guide cuts that go all the way through the tape to expose the copper.
We are trying two different methods and designs here – one using just the tape cut-out where we create 18 separated islands which we can drill though and solder to create raised touchpads, and another drawing a more complex circuit with a sharpie felt tip pen. The second approach provides a flat connection area, as no soldering is needed on the touch pads themselves – but we can still solder connections on the edges of the board (this becomes a bit clearer later).
Here we have dissolved the sodium persulfate crystals to create the acid bath – note we are doing this outside, as the process creates fumes you don’t really want to be breathing. We started the temperature at 50 degrees – you are supposed to maintain this but we didn’t have a way to do that. The etching took about an hour and a half, it would probably be more like 10 minutes at the proper temperature, but it doesn’t seem to matter if you are not in a hurry.
Afterwards we store the acid as it can be used again, the blueness indicates the amount of dissolved copper – when this gets too dark it stops working, then you can neutralise the acid by adding bicarbonate of soda and take it to the tip for safe disposal. Obviously the labelling is important – not just the fact it’s toxic but the date it was made, for future use – it should last a few months.
Here is the etched board after washing well in water and drying – no copper visible!
The next step is to remove all the resist – both the tape (and the glue that comes with it), and the marker pen. That requires a bit of alcohol and elbow grease.
Here we can see the copper and mostly nice clean tracks – there was one place which required some work with a scalpel to break a remaining connection, but we didn’t expect it to be this good for our first attempt!
Now the PCBs can be separated…
And finally – tested on a Raspberry Pi, using the GPIO pins for now to read the receptor type directly. On this PCB we have two of the three sets of connectors working – so six values in total. This redundancy means that the more that match, the more confident we can be that we have the correct reading.
Things to try next are some tweaks to the Pi so it can read the receptor more sensitively as currently it needs nearly the full 3.3V to register on the digital pins. The Makey Makey seem to do this by using large pull up resistors to detect the presence of tiny voltages and filtering the noisy signal this creates in software.
It’s not clear at this point if we will be making the final connectors in this way, but it would be nice if we can (and get a bit better at it) – at least we are now able to quickly iterate their design ourselves.
Other options to be looked into include using a small CNC mill to drill out PCB tracks, and more exotically – the use of micro-organisms to eat copper.
Here’s an article on midimutant we did with Aphex Twin for MagPi Magazine, written by Sean McManus. Most of the work on this project recently has revolved around exploring custom hardware using old FM synth chips from games consoles, but with any luck there should be some more evolved DX7 sounds around here soon.
One of the great unknowns following the first weavecoding project was the nature of tablet weave. Other than a few primitive attempts that didn’t work in all cases and lead us to further questions, modelling tablet weave fully was left as an undeciphered mystery. Tablet weave is a complex and particularly ancient form of weaving, while it’s simple to do with easily found materials, it produces a kind of double weave with twisting, and you can create crazy higher level 3D structure as it is free from the constraints of fixed loom technology.
The trick to start understanding this (I still have quite some way to go) came from only thinking about a single square tablet. If we follow the paths of each of the four threads while turning the square 90 degrees at a time we can see how tablet weaving is a combination of a weave (up and down movement) and a braid (left and right), as it twists the threads in relation to each other.
From this sketchy starting point it was possible to create two 3D objects to represent each twist, one for clockwise and another for anticlockwise. If you colour the separate threads appropriately and combine them together you get something like this:
While this looks fancy, it’s wrong. The threads may be in the correct form conceptually, but woven structure comes about as a relationship between the positioning of the threads and the tension applied to them. Many of the threads above should be pulled straight and push others out of the way to give a pattern that was actually straight stripes of colour, rather than chevrons. So how can we add tension?
One way to approach this problem would be to use a physical simulation of the kind usually applied to cloth simulation, and ‘relax’ the the threads to achieve a realistic result, using a stochastic approach to iteratively tighten them within collision constraints, until it ‘looked right’. The problem with this is that it wouldn’t lead to a deeper understanding of what is going on here. This in a way is related to a bigger issue with AI and machine learning, where techniques like artificial neural networks can be trained to solve problems well enough to be useful, for example in speech recognition – but do not provide any new knowledge about language or understanding of deeper scientific issues.
So if we want to understand some of the ‘thread logic’ of table weaving, we are can approach this in a more symbolic manner. Can we add additional straightened threads to our two twisted ones?
As with the twists, there need to be two forms of straightening – left or right twist to straightened threads, and then we need to get back from a straightened thread to a left or right twist.
Notice that some of these shapes connect, while others are incompatible. We can start with the original twisted weave above, and process it to pull the threads straight. In order to do this we need to know the past and future actions of the weaver, or the current twist in the context of those before and after it. This makes sense, as when weaving structure emerges fully a few wefts behind the current one you are weaving – only as the tension is applied to the fabric does it take form.
The rules to describe this turn out to be well represented as a diagram. The nodes are the 3D shapes required and the edges are the actions of the weaver (the special ‘floating’ state change interestingly depends on the action before the last one – memory does seem important in tablet weaving).
For example, we can ‘left twist’ repeatedly (the top right state) as the arrow points to itself. If we start going in the other direction we then need to pass through two straightening states to get to a full ‘right twist’. If we start going backwards and forwards in smaller numbers of turns then more complex things happen.
When we process the first weave with these rules, you can see some of the straightening effects. The tension on the threads means that some cover up others, e.g none of the yellow threads are now visible on the top of the fabric at all.
The structure is more visible here than on a real weaving as the threads are thinner that they would be for the resulting weave which would be more densely packed together (this is less realistic but helps to understand what is going on).
How do we know if any of this is correct? The only way to test this for sure is against real weave. We can try out different sequences of actions and see if the model matches. As indicated above, tablet weaving is a technique that comprises several categories of weaves – these define some specific types of structure we can test.
Type 1: Repeated twists and turn back
Most normal tablet weave consists of twisting repeatedly 90 degrees in the same direction and weaving a weft each time. In practice there is only so far you can go in the same direction before the unwoven warp threads behind the tablets get tangled up, so you need to change direction and go the other way until they are untangled, providing some symmetry to the pattern. The first example has all the tablet threads aligned in the same sequence – and we weave 8 turns one way and 8 turns back again. You can see in the middle when we change direction we create a short straightened ‘float’ section which causes the tension to pull the threads straight here.
One of the further mysteries that our first tablet weaving simulations couldn’t previously recreate were situations where the pattern on the back and the front of the weave were not opposite of each other. This is highly unusual in weaving, but this model seems to represent this correctly. Here the actions are the same as the first example – 8 one way and then the other, but the thread colours in the tablets are offset from one another so they are staggered and you get the diagonal patterns.
Type 2: Single faced double weave
Part of the complexity of tablet weaving is because it is a kind of double weave – there are two intertwined weave structures happening at the same time. If we repeat two wefts of 90 degrees one way followed by two more the other direction, the two weaves remain on the same side of the textile – which can be seen clearly if we colour them appropriately. This example keeps the white weave on the top side with the brown one on the lower side.
Type 3: Degenerate floats
The third type of weave is not really a weave but a breakdown of the process caused by only weaving single 90 degree turns backwards and forwards repeatedly. This means half of the threads are not incorporated into the weave and ‘float’ along the surface on both sides.
While the language to fully describe the tablet weaving has yet to be developed properly, you can have a go yourself with this model which is currently online here (takes a few moments to render at first).
This gets us closer to a working model of tablet weaving, and provides something we can start to use for a more advanced aims of the Penelope project. For example, can we use the pattern matrix to tangibly livecode tablet weaving? Does this make it possible to explore and explain this type of weaving?
If this kind of textile wasn’t complicated enough, people in ancient times combined multiple weaving techniques, for example tablet weaving and warp weighted weaving in the same piece of fabric. Creating a kind of ‘grand unified’ weaving model is an additional future challenge, so we can start to understand better the thought processes involved in these advanced techniques.