All posts by dave

Photos from the machine wilderness workshop

Busy times at Foam Kernow, here are some photos from the Machine Wilderness Workshop weekend before last. This was a project between Foam Amsterdam and us, with 30 participants from all over the place geographically and professionally. My role was as facilitator, so mainly obtaining raw materials (electronic toys, recycled trash and e-waste) as well as a bit of cooking and general running around which I found very enjoyable. The machines invented and prototyped were grounded in the environment of the Penryn river in Cornwall, so common themes were seaweed biomimicry and experiments with estuarine mud, both as a surprisingly rich power source as well as a design medium in it’s own right.

I’ll leave the in-depth write ups to those leading the event, but one of my interests was to see how a workshop involving e-waste would work, practically and as an inspiration – with an eye to doing this with primary school kids and teachers. We managed to locate a good quantity of old toys from various local second hand stores and warehouses, quite a modest outlay in return for some very good mechanics, motors and electronic parts. Resisting the temptation to take them to bits beforehand meant that the participants could open them up and discover what they could use, one of the best items was a bubble machine – inside was a good air pump and lots of mechanics (total cost ~£1.50). This was incorporated into a robot lifeform that was in part augmented by moss growth and LED lights.

See the rest of the photos here.

22444642273_6d6b6c6769_k

22649609288_dedb77b1db_k

23065937055_1621cd69f4_k

23068027015_727ee3aef9_b

23077159031_f7021478d0_k

The UAV toolkit & appropriate technology

The UAV toolkit’s second project phase is now complete, the first development sprint at the start of the year was a bit of research into what we could use an average phone’s sensors for, resulting in a proof of concept remote sensing android app that allowed you to visually program different scripts which we then tested on some drones, a radio controlled plane and a kite.

photo-1444743618-504214

This time we had a specific focus on environmental agencies, working with Katie Threadgill at the Westcountry Rivers Trust has meant we’ve had to think about how this could be used by real people in an actual setting (farm advisors working with local farmers). Making something cheap, open source and easy to use, yet open ended has been the focus – and we are now looking at providing WRT with a complete toolkit which would comprise a drone (for good weather) a kite (for bad weather/no flight licences required) and an android phone so they don’t need to worry about destroying their own if something goes wrong. Katie has produced this excellent guide on how the app works.

The idea of appropriate technology has become an important philosophy for projects we are developing at Foam Kernow, in conjunction with unlikely connections in livecoding and our wider arts practice. For example the Sonic Bike project – where from the start we restricted the technology so that no ‘cloud’ network connections are required and all the data and hardware required has to fit on the bike – with no data “leaking” out.

photo-1444742698-352249

With the UAV toolkit the open endedness of providing a visual programming system that works on a touchscreen results in an application that is flexible enough to be used in ways and places we can’t predict. For example in crisis situations, where power, networking or hardware is not available to set up remote sensing devices when you need them most. With the UAV toolkit we are working towards a self contained system, and what I’ve found interesting is how many interface and programming ‘guidelines’ I have to bend to make this possible – open endedness is very much against the grain of contemporary software design philosophy.

The “app ecosystem” is ultimately concerned with elevator pitches – to do one thing, and boil it down to the least actions possible to achieve it. This is not a problem in itself, but the assumption that this is the only philosophy worth consideration is wrong. One experience that comes to mind recently is having to make and upload banner images of an exact size to the Play Store before it would allow me to release an important fix needed for Mongoose 2000, which is only intended to ever have 5 or 6 users.

photo-1444743271-137365

For the UAV toolkit, our future plans include stitching together photos captured on the phone and producing a single large map without the need to use any other software on a laptop. There are also interesting possibilities regarding distributed networking with bluetooth and similar radio systems – for example sending code to different phones is needed, as currently there is no way to distribute scripts amongst users. This could also be a way of creating distributed processing – controlling one phone in a remote location with another via code sent by adhoc wifi or SMS for example.

Procedural weave rendering

We’ve been working on new approaches to 3D rendering ancient weaves, using Alex’s new behavioural language (which describes a weave from the perspective of a single thread) as the description for our modelling. This new approach allows us to build a fabric out of a single geometric shape, where warp and weft are part of the same thread.

toothpaste-mix

This is mix of tabby and 2:2 twill, created by this code:

warp 12 24 ++ [TurnIn] ++ threadWeftBy'' Odd (rot 3) ([Over,Under]) 12 12 ++ threadWeftBy'' Odd (rot 3) ([Over,Over,Under,Under]) 12 12

I’m still learning this language, but more on that soon. This line produces an large list of instructions the weave renderer uses to build it’s model, turning the thread and shifting it up and down as it crosses itself.

In the video in his last post Alex describes using this to mix two separate weaving techniques together, which is one of our main reasons for developing this language – existing weave simulations cannot replicate the weaving technology of the ancient Greeks who for example, combined tablet and warp weighted weaving in the same fabric.

The second problem with weave simulations is shown by the following screenshot from a popular existing system:

wxsg2b

Fabrics modelled in this way are considered to infinitely repeating sections with chopped off threads. There is no consideration for the selvedge at the edge of the fabric – which as we’ve shown in our past research is almost like a completely separate weave system of it’s own, and rarely considered by notation systems or modelling (and often left to the weaver to ‘livecode’). Here is a different view of the same fabric:

toothpaste-edge

We can also now introduce other changes to the yarn structure, for example modifying the width using a sine wave.

toothpaste-yarnwidth

I still have a few glitches to fix as you can see above, but here is a video of the development process from the first script, getting the polygons lined up, fixing the turning, adding over/under, reading Alex’s code and finally lining everything up.

Weavecoding performance experiments in Cornwall

Last week the weavecoding group met at Foam Kernow for our Cornish research gathering. As we approach the final stages of the project our discussions turn to publications, and which ideas from the start need revisiting. While they were here, I wanted to give local artists and researchers working with code and textiles a chance to meet Ellen, Emma and Alex. As we are a non-academic research organisation I wanted to avoid the normal powerpoint talks/coffee events and try something more informal and inclusive.

IMG_1650

One of the original ideas we had was to combine weaving and coding in a performance setting, to both provide a way to make livecoding more inclusive with weaving, and at the same time to highlight the digital thought processes involved in weaving. Amber made vegetarian sushi for our audience and we set up the Jubilee Warehouse with a collection of experiments from the project:

  • The newly warped table loom with a live camera/projection from underneath the fabric as it was woven with codes for different weaves on post-it notes for people to try.
  • The tablet/inkle loom to represent ancient weaving techniques.
  • The pattern matrix tangible weavecoding machine and Raspberry Pi.
  • A brand new experiment by Francesca with a dancemat connected to the pattern matrix software for dance code weaving!
  • The slub livecoding setup.

IMG_1634

This provided an opportunity for people to try things out and ask questions/provide discussion starting points. Our audience consisted of craft researchers, anthropological biologists, architects, game designers and technologists – so it all went on quite a lot longer than we anticipated! Alex and I provided some slub livecoded music to weave by, and my favourite part was the live weaving projection – with more projectors we could develop this combination of code and weaving performance more. Thanks to Emma for all the videos and photos!

IMG_1692

IMG_1564

Airborne drag-drop programming, the next steps

This autumn we are continuing work on the UAV toolkit with Karen Anderson and her research group at the Environment and Sustainability Institute. This time we have a mission to help the Westcountry Rivers Trust by coming up with fast and cheap ways they can build maps of farms to determine water run-off problems, which gives farmers proof they need to get funding to fix pollution issues.

IMG_20151014_154601
Flight planning operations and photo checking

In order to make the software usable in this case, we decided on two directions. On the one hand there needs to be a simple way to start and stop programs (or “flight modes”) that read sensor data, as well as defining certain global settings, ie. flight altitude, desired image coverage etc. At the same time, the code to define what this does needs to still be programmable in the app – and more complex behaviours need to be possible to support both kites and UAVs. Our philosophy is that it has to be open ended, as we don’t know where the toolkit it might be useful (ie. crisis mapping situations) or what new sensors will be available on a device in the future.

Screenshot_2015-10-19-21-48-01
The new main screen

One specific set of new behaviours we need is for kite mapping. We already have the ability to choose when to take pictures based on GPS and altitude, but with a kite there can be lots of turbulence and the camera is in a much less controlled state, flipping around taking shots of the sky etc. So we need to calculate things like jerk from change in acceleration and use orientation sensors to only take photos when the lens is pointing directly down, within some degree of acceptable margin.

Below is a section of the code that calculates if we are pointing down using the magnetometer and accelerometer – the drag drop visual code can now be used to build normal Scheme functions using a touchscreen (a bit like scheme bricks). In fact I managed to do all of this work on the phone. There are now two types of code, the main programs or “flight modes” that you can run from the front screen, and a library of editable functions which they use. This means there are now three levels that the software can be used – using it without needing to see any of the code at all, editing the basic behaviour like which sensor’s data are captured, and finally modifying the more detailed code to make it do completely new things.

Screenshot_2015-10-19-22-08-12

Warping a 4 shaft table loom

The next stop on my exploration of loom technology for the weavingcodes project (after building a frame loom and learning tablet weaving) has been learning how to use a 4 shaft table loom. This has been kind of daunting to me, as it’s a much more modern weaving device than I’ve been working with up to now (frame looms and tablet weaving can be considered to be both neolithic digital tech). I also couldn’t really figure out much from books on the warping techniques, as it’s difficult to get the idea through images – so I had to just kind of jump in and try it.

I decided to use the double weave draft plan to start with from my last post – partly as I want to try this technique, but also it’s pretty simple warp threading for a first attempt.

double

The next step was to choose the material. A while back I bought 200gms of good quality 8/2ne cotton/linen mix which I’ve been saving for something like this. In order to calculate the amount of fabric the yarn will produce you can wrap it lightly around a ruler:

IMG_20151006_112054

This yarn is about 10 threads per centimetre, so we can use that to figure out roughly how many warp threads (or ‘ends’) to use – I decided on 160 ends in total (so ~16cm wide) comprised of the two alternating colours. I wound out two sets of 80 threads over a couple of metres, doing both colours at once to make it easier. I then attached each one to the back roller and wound them in a bit – this would have worked better later if I had used more bundles of fewer threads.

IMG_20151005_111456

You can see in the picture I’ve also bolted a “raddle” (thing with nails) on the back beam of the loom to help space out the warp threads – this is important later on. Now we come to the heddles. The threading chart is what programs this part of the loom, which in turn forms a fixed instruction set of pattern possibilities for the weave. You can see the 4 levers that operate the frames in the photo above – these essentially give us 4 bits per weft of information. 2 of the 16 possibilities are invalid – as all frames raised or lowered doesn’t provide a working fabric. Using different sequences of these 14 combinations for each weft thread, the possibilities become mathematically huge – even with a fixed warp like this.

doublethreading

Reading the frames and warp colours from the chart to provide a sequence, you hook each warp end through the eye of the heddle – this was the most time consuming part of the process.

IMG_20151005_115731

Once that is done, the reed – which is attached to the beater and used to pack down and keep the fabric evenly spaced, is threaded (or “sleyed”). The reed I used was a bit too course so I used two threads per gap – this could have done with being a bit more as it turned out.

IMG_20151006_120920

With all this done the warp ends can be attached to the front roller and the whole warp can be wound on through the heddles and back again to check the tension. Of course in practice (and as it was my first time) it actually involved a lot of tangles and swearing, and two broken warp threads, fairly easily knotted back together. The raddle was essential in helping untangle the warp threads, but I also had to fiddle around with the tension a lot, retying the knots attaching them to the rollers and using plenty of sticks (it seems you can never have too many sticks when warping a loom). This is a test that the warp is threaded correctly, with all black threads (frames 2 and 4) lifted – phew!

IMG_20151009_133825

After that we could try a little test weaving, going freestyle on the heddles.

IMG_20151009_171547

It turns out the reed is a little too wide, meaning it’s stretching the warp out as the woven fabric finds it’s true width – switching to a new one is possible without needing to do the heddles again, so we’ll see how it goes. Compared with tablet weaving, this is far more mechanised and efficient in terms of fabric production, but the flipside to that is that you lose a lot of flexibility, and the loom is less responsive to particular material properties like this.

“The mystery of the drawdown”

Double weave has intrigued me since first figuring out how it works with tablets – it shows how weaving is a 3D process, and is an example of shape making from code. It’s the starting point for more advanced methods for creating strong woven composite materials and structures. I’ve been reading this document by Paul O’Connor to understand the process for a 4 shaft loom. He includes this critique on current methods for visualising weaving:

The traditional method for creating the drawdown shows all the warp and all the weft threads in one layer. What is needed is a way to make two drawdowns, one for the top cloth layer and the other for the bottom cloth layer. Most of the commercially available computer weave programs display the drawdown in this same fashion, as a single layer.

This is a draft plan (the traditional notation technique) for double weave which contains the drawdown he’s talking about:

double

Drawdowns are designed for thinking about weaving as 2D pattern, and like any notation system they abstract a situation so we can reason about it, with the trade-off that they make it impossible to understand different aspects. This is a big problem we have in programming too – and is the reason we need to have many levels and hundreds of different languages to describe problems. I’ve noticed that if people (or organisations) stick with one too long, the specialisation starts to hinder ability to even recognise certain issues. It’s interesting to see such a clear analogy here.

In order to see what’s really happening with double weave, we need to switch to a different notation and look at the structure more closely:

double2

Hopefully you can see that all of the black threads are sitting on top of all the white threads, and forms it’s own plain or tabby weave fabric. The same is true for the white threads underneath. Below is the same structure rendered in the weavecoding dyadic device – this shows the heddles that need raising to create the sheds in the lift plan, and you can see a repeating zigzag pattern. As an aside, I’ve noticed that there seems to be some kind of underlying categorisation of lift plan patterns which I’ve not found mentioned anywhere yet – something else to look into at some point.

double-d

Mongoose 2000 version 2

Mongoose 2000 version 2 is now being used in the Banded Mongoose Research Project Fieldsite on the Mweya Peninsula, in the Queen Elizabeth National Park, western Uganda.

We’ve added two new focal observations – where a single mongoose in a specific life stage is followed, and has it’s activity recorded for 20 minutes. These observations include different events that can happen (fighting or cooperating with other individuals etc). Nearly all the interfaces are shown below – the system includes adding new packs or individuals, data review and syncronisation with other tablets via the Raspberry Pi.

interfaces-s

Hungry birds citizen science at the Paris Natural History Museum

Some photos of Mónica Arias running her “Hungry Birds” butterfly catching experiment at the Muséum national d’Histoire naturelle in Paris.

comp

The Museum’s internet capability was challenging, so we ran the game server on a Raspberry Pi with an adhoc wifi and provided the data collection ourselves. The project is concerned with analysing pattern recognition and behaviour in predators. We’re using ten different wing patterns (or morphs), and assigning one at random to be the toxic one, and looking at how long it takes people to learn which are edible.

hungrybirds2