Foam Kernow mini update

A short update on the things currently going on at Foam Kernow alongside the stuff I’ve been blogging about lately. We are near completion of a new version of the butterfly hunting game – this time being developed for the National Museum of Natural History in Paris, where it will be a citizen science exhibit to collect data on visitor’s perceptions of the wing patterns. A brand new Open Sauces web tool is under development as well, much conversation concerning database models for cuisines, menus, recipes, ingredients and flavours.

We’re planning our first ever biohacking workshop, in Cornwall led by the London Biohackspace. As part of that we need to construct a bunch of high power LEDs to expose yeastograms to UV light to create pictures. With all the precautions required for this (you don’t want to get too close to them), it seems like we’re constructing a giant space laser.

The beginning of the year has also been about moving long running projects on to their next stage. Mongoose 2000 has now had 4 months of parallel data collection in Uganda at the same time as their old system, and they agree by 98%, which is good enough for them to move completely over to the Raspberry Pi and android tablets. We’ve also incorporated a ton of feedback from this testing time. Symbai also has been improved ready for it’s next outing to India in May, mostly synchronisation fixes as this system needs to sync photographs and audio files as well. Also a bit of in depth reading about SQLite’s query planner has led to a dramatic speedup for both these applications.

Also in the workshop vein – this year’s Raspberry Pi Minecraft hacking workshop will be happening on April 2nd at dBsMusic in Cornwall College. Bring on the networked mayhem!

Minecraft Easter Taster2

New tangible weavecoding device – pattern matrix

We’re starting construction of version 2 of the flotsam tangible programming device, specialised to weaving – and henceforth known as the ‘pattern matrix’. This will be tested during May at our upcoming performance/workshop/residency at Munich’s Museum für Abgüsse Klassischer Bildwerke (Museum of Casts of Classical Sculpture) with the Coding weaves project, and then for later use in Cornwall (more on that part soon).

1

The first thing we are exploring is removing the need for physical plugs – although I like them a lot, they are problematic for people as it takes time to learn how to align the blocks in the current prototype. In order to get around this, and maintain the cheapness of the programming blocks themselves we’re looking at using magnetism to represent information. We can use blocks with no connections, painted white and black on different sides and detect their orientation and position via a magnet in the centre.

Initially this idea came from thinking about reed switches with Francesca, and playing with mobile phone magnetometers on the UAV project led to us investigating Hall effect sensors (the building blocks of magnetometers). We had a bit of a testing workshop with Andy from the Falmouth University makernow fablab who are helping with construction of this project.

halleffect

Hall effect sensors allow us to detect the polarity of nearby magnetic fields – and seem to be restricted enough in range that they can be very precise. Even with fairly weak magnets we found we could put the sensors right next to each other (see above) and still determine the difference between two opposed or aligned fields.

For the warp/weft weave pattern structure we only need 1 bit of information to be detected, but for future extensibility for the yarn colour programming setup it’s important to be able to read more (4 bits are encoded in the flotsam blocks).

Our plan is to try putting 4 sensors in a square which adds an intriguing possibility of rotating the blocks to change their meaning, as well as flipping them. The great thing is that this gets very close to tablet weaving in terms of the notation and the actions required. We can also represent all 16 states with only 4 blocks – if negative is 0 and positive is 1, and we read the code as binary clockwise from top left:

Starting state [0,1,5,6]
- -   + -   + -   - +
- -   - -   - +   - +

Rotate clockwise [0,2,10,12]
- -   - +   - +   - - 
- -   - -   + -   + +

Horizontal flip [15,11,10,12]
+ +   + +   - +   - - 
+ +   + -   + -   + +

Rotate counter-clockwise [15,13,5,6]
+ +   + -   + -   - + 
+ +   + +   - +   - +

Vertical flip [0,4,5,6]
- -   - -   + -   - + 
- -   - +   - +   - +

Here is Andy’s design for the PCB we’ll use under each of the 25 board locations:

hallboard

Organisation hacking (part 1)

Over the last six months I’ve been taking a crash course in company formation, treating it like any other investigation into a strange and esoteric technology. Last year I registered FoAM Kernow as a UK non profit organisation in the mould of FoAM Brussels. Starting off with absolutely no knowledge at all (but with a lot of help from FoAM’s wider friends and relations) I found a lot of confusing fragments of information online so I thought I’d document the process here as much as I can. It’s important to state that I’m not a lawyer or professional in these matters at all, so no substitute for proper legal advice – and any corrections would be most welcome.

What does non-profit mean?

A non-profit company is simply one that is not allowed to have shareholders. A for-profit company can pay a set of people who own shares part of the profits called dividends. In a non-profit the money outflow is more tightly controlled and can only go to employees or to pay costs for the company. Contrary to popular belief, there is no limitation on the size of the company, how much it pays employees or the money it makes in total (there are some very large non-profits out there).

In place of shareholders, a non-profit is “limited by guarantee” – a more legally correct term for this type of organisation. Individuals guarantee a set amount against liability (debts). The default is a whopping £1 each.

As far as I understand it “limited by shares” and “limited by guarantee” are the two main different types of organisation in the UK. There are also a cluster of other subcategories: charities, community interest groups, co-operatives and social enterprises for example. These are a little bit more fuzzy it seems, but they tend to be different flavours of limited by guarantee companies with more legal paperwork (especially in the case of charities) to determine the precise purpose and role of the organisation, and ultimately access to profits – what the money can and can’t be used for.

Why form a company?

Having a legal entity with which to work from rather than being an individual (sole trader) is better for larger projects, and bigger institutions are happier collaborating with legal entities. This is partly a matter of indirection or abstraction, e.g. if I get hit by the proverbial bus, the legal entity continues to exist. More importantly, it means multiple people can work together as part of a legal structure with a publicly stated set of shared values (called the articles of association). There is also a well established democratic process to make organisational decisions (more on that later).

Sole traders on the other hand can employ as many people as they want, but the structure would be fixed as a simple hierarchy – and the organisation has no legally defined purpose. Also things like insurance are different, but I won’t get into that yet!

Why form a non profit company?

A non-profit fits well with the goals of FoAM. Generally we focus on exploring ways of doing independent research, we are strict on non-exclusive rights to our work (participating in free software and creative commons) and finding a place between arts and sciences. None of this requires conventional fund raising by selling shares.

Another big reason is an issue of trust. We work mainly with people in spheres of arts and research – and it turns out a lot of people don’t want to work with companies that are run on a for-profit basis. In fact I would go so far as to say that some of the most interesting people we work with are wary of this. There is a somewhat justifiable worry that their contribution may be exploited via pressures to make a return on investments made by third parties.

The downsides are mainly tax related – for-profit companies can use dividends to pay investors (who can be employees too) which are not taxed – this is a very common practice. Usually small companies employ people at the minimum taxable wage then pay the rest by dividends. There is no way to do this with a company limited by guarantee – all payments to people need to be accounted for as normal employment or subcontracting and subject to income tax. It turns out that there are other upsides to being non-profit that may counteract this in the long run as you get treated differently in some contexts (e.g banking). For the next installment (if I find time!) I’d like to talk more about that and the formation process too…

Test flight day!

View of ground control from a OnePlus phone mounted on a Y6 UAV:

photo-1421927742-36242

A report from the first flight test of the new UAV android software with the Exeter University UAV science group. We had two aircraft, a nice battle hardened fixed wing RC plane and a very futuristic 3D robotics RTF Y6. We also had two phones for testing, an old cheap Acer Liquid Glow E330 (the old lobster phone) and a new, expensive Oneplus One A0001. Both were running the same version (0.2) of the visual programming toolkit which I quietly released yesterday.

IMG_20150122_104141

Here is the high-tech mounting solution for the RC aircraft. There were a lot of problems with the Acer, I’m not sure if the GPS triggering was happening too fast or if there is a problem with this particular model of phone but the images appear to be corrupted and overwriting each other (none of this happened in prior testing of course :) Despite this, there were some Ok shots, but a lot of vibration from the petrol motor during acceleration.

photo-1421923592-621148

photo-1421923613-98013

We tried two types of programs running on the phones, one triggered photos by a simple timer, the other used GPS distance, altitude and camera angle in order to calculate an overlap coverage. Both seems to work well, although I need to go through the sensor data for each image to check the coverage by positioning the images using the GPS. One thing I was worried about was the pitch and yaw of the aircraft – but with the Y6 this was extremely stable, along with the altitude too, which can be controlled automatically at a set height.

The vibration seemed less of a problem on the Y6, but on one of the flights the power button got pressed bringing up the keylock screen which annoyingly prevents the camera from working. We did however capture lots of sensor data – accelerometer, magnetometer, orientation and gravity with no problems on the Acer.

The OnePlus phone worked pretty flawlessly overall, and we left it till last as it’s a bit less expendable! It’s possible to mount phones easily underneath the batteries on the Y6 without the need for tape, which looks a bit more professional:

IMG_20150122_114937

We still have problems with vibration, which seems to cause the bands of fuzziness (see the bottom and top photos) so things to look at next include:

  1. Cushioning for the phone (probably just a small bit of foam).
  2. Reproducing and fixing the Acer camera problem.
  3. Some kind of audio indication from the phone that the camera is working etc.
  4. Try again to lock the keys on the phone or override the key lock screen.
  5. More camera controls, override and lock the exposure.
  6. Output raw files instead of running the jpeg compression in the air! This seems to take longer than actually taking the photo, and we don’t care about space on the sdcard.

IMG_20150122_113543

photo-1421927801-544702

Livecoding UAVs for environmental research

Some screenshots of the UAV livecoding visual programming language. Weather being on our side, we’re planning some test flights later this week! The first program uses GPS to take photos with an overlap of 50% at 300 metres altitude, based on the vertical camera angle as reported from the device. It assumes the the flight orientation is level:

Screenshot_2015-01-20-23-17-49

The blocks are all drag and drop and get converted into Scheme code which is run by a modified tinyscheme interpreter. The code can be saved and loaded, and I’m planning to make it possible for people to share code via email.
This is a simpler program which takes a photo every 3 seconds and records a handful of sensor data to the database:

Screenshot_2015-01-20-23-18-44

At the bottom you can see a squashed camera preview – I’ve tried various approaches (hiding, scaling to 0 pixels etc) but android requires that there is a preview somewhere in order to take a photo properly. You can view the recorded data on the device too, for checking. There is also a ‘flight mode’ which locks and turns off the screen, and ignores all button events. On some phones you need to take out the battery to stop the program running but unfortunately on others you can still use the power button to close the program.

Screenshot_2015-01-21-01-09-56

3D warp weighted loom simulation

One of the main objectives of the weavecoding project is to provide a simulation of the warp weighted loom to use for demonstrations and exploration of ancient weaving techniques. Beyond the 4 shaft loom dyadic calculator we need to show the actual process of weaving to explain how the structures and patterns emerge. Weaving is very much a 3D process and these visualisations fail to show that well. It also needs to be able to be driven by the flotsam tangible livecoding hardware so running on a Raspberry Pi is another requirement.

Sketch and rendering

I’ve decided to make use of the Jellyfish procedural renderer to build something fast and flexible enough, while remaining cross platform. Jellyfish is a lisp-like language which compiles to a vector processing virtual machine written in C++, and approaches speeds of native code (with no garbage collection) while remaining very creative to work with, similar to fluxus livecoding. Previously I’ve only used it for small experiments rather than production like this, so I’ve needed to tighten up the compiler quite a bit. One of the areas which needed work (along with function arguments which were coming out backwards!) were the conditional statements, which I removed and replaced with a single if. Here is the compiler code at the lowest level which emits all the instructions required:

;; compiler code to output a list of instructions for (if pred true-expr false-expr)
(define (emit-if x)
  (let ((tblock (emit-expr (caddr x))) ;; compile true expression to a block
        (fblock (emit-expr (cadddr x)))) ;; compile false expression to block
    (append
     (emit-expr (cadr x)) ;; predicate - returns true or false
     (emit (vector jmz (+ (length tblock) 2) 0)) ;; if false skip true block
     tblock
     (emit (vector jmr (+ (length fblock) 1) 0)) ;; skip false block
     fblock)))

Then I can implement cond (which is a list of different options to check rather than one) as a purely syntactic form with a pre-processor function to create a series of nested ifs before compiling them:

;; preprocessor to take a cond list and convert to nested ifs 
(define (preprocess-cond-to-if x)
  (define (_ l)
    (cond
      ((null? l) 0)          ;; a cond without an else returns 0 
      ((eq? (caar l) 'else)  ;; check for else clause to do
          (cons 'do (pre-process (cdr (car l)))))
      (else (list 'if (pre-process (caar l)) ;; build an if
          (cons 'do (pre-process (cdr (car l))))
                  (_ (cdr l)))))) ;; keep going
  (_ (cdr x))) ;; ignores the 'cond'

Here’s an example of the if in use in the loom simulation at the ‘top’ level – it gets the current weaving draft value for the weft and warp thread position and uses it to move the weft polygons forward or back (in the z) a tiny amount to show up on the correct side of the warp.

(define calc-weft-z
    (lambda ()
        (set! weft-count (+ weft-count 1))
        (set! weft-z
              (if (> (read-draft) 0.5)
                  (vector 0 0 0.01)
                  (vector 0 0 -0.01)))))

One of the reasons I’m writing about all these levels of representation is that they feel close to the multiple representations present in weaving from draft to heddle layout, lift plan, fabric structure and resulting pattern.

Coding structure with threads

IMG_1532

One of the most inspiring things we heard from Leslie Downs (our Advisor on textile innovation) was about the way he manufactures high specification structures for aerospace engineering by weaving on ordinary looms, sometime even hand looms for their flexibility. It turns out that some of these techniques are also possible with tablet weaving: I came across this mysterious diagram in ‘Byways in Handweaving’ by Mary Meigs Atwater:

IMG_1537

The text doesn’t really go into much detail about what you can do with “Icelandic double weave”, nor is there much information online that I could find, so I had a play. Normally you weave tablets by rotating the cards quarter turns and using the shed between the top/bottom sides of the cards with them straight. With this technique you rotate quarter turns back and forward from the orientation in the diagram instead, and use two separate wefts for the top and the bottom sheds. This results in two separate fabrics woven at the same time which can be reattached by going back to normal weaving, or crossed over like this:

IMG_1580

This technique is very versatile and results in strong structures. It’s possible for example to connect the weaves along the edges and create long tubes or weave more than two layers attached in different ways. In this way, weaving is an ancient 3D printing process that converts code into structure (and only produces biodegradable waste).

There are some things that you can only do with tablet weaving. As the ‘loom’ as such is just a disconnected pack of cards it’s possible to reorganise it as you go along, for example if you use two wefts and split the weave in half, you get two separate fabrics which can be rejoined later on – they don’t even need to be connected in the same way, I tried crossing them over here – which seemed to work easily enough:

IMG_1587

IMG_1577

With the use of four wefts you can even do a double layer weave at the same time as a split like this to create more complex structures, I had a go at that but I ended up with my threads in a mess and accidentally attached the two layers by mistake – I need more practice, and possibly using more than 10 cards would help too.

You can also turn corners with tablet weaving, my first attempt at that wasn’t so great as I found it really difficult to maintain the tension and lost count of my wefts, but you do this by simply gradually adding extra wefts to one side of the weaving. I attempted a full “u-turn”, shown here after some smaller double weave sections:

IMG_1582

It would be interesting to think about how to add these structural modifications to the current tablet language. They all involve adding/removing wefts or skipping warp threads with wefts – notating this is probably fairly simple, but modelling the results would be very challenging indeed, if it’s even possible.

A language for Tablet weaving

After the tablet weaving experiment, here is an attempt at a language/notation for understanding it better. You can have a go here.

Lets start simple:

(weave-forward 16)

foward16

The card rotations are shown on the left for each of the 8 cards, the predicted weaving is on the right for the top and bottom of the fabric. This is setup with a double face weaving on square cards, so black, black, white, white in clockwise from the top right corner. (weave-forward 16) turns all the cards a quarter turn and weaves a weft and repeats this 16 times.

We can offset the cards from each other first to make a pattern. rotate-forward turns only the specified cards a quarter turn forward without weaving a weft (rotate-back also works):

(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1)
(weave-forward 32)

diagonal

We can’t really weave 32 forward quarter rotates without completely twisting up the warp so lets go forward/back 8 instead to make something physically weavable:

(rotate-forward 0 1 2 3 4 5)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1)
(repeat 4
  (weave-forward 4)
  (weave-back 4))

zigzag1

Now we get a zigzag – if we change the starting pattern again:

(rotate-forward 0 1 2 3 4 5 6)
(rotate-forward 0 1 2 3 4 5) 
(rotate-forward 0 1 2 3 4)
(rotate-forward 0 1 2 3)
(rotate-forward 0 1 2)
(rotate-forward 0 1)
(rotate-forward 0)
(repeat 4
  (weave-forward 4)
  (weave-back 4))

zigzag2

This zigzag matches the stitch direction better. Instead of the rotation offsets we can also use twist, which is more traditional, you can use it to form any pattern. It takes a list of cards to twist, and results in these cards effectively reversing direction compared to the others.

(weave-forward 7)
(twist 0 1 2 3)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))
(weave-forward 1)
(twist 2 3 4 5)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))
(weave-forward 1)
(twist 1 2 5 6)
(weave-back 1)
(repeat 2
  (weave-forward 2)
  (weave-back 2))

mip

The twist needs to happen when the cards are in the right rotation – if we repeat this example, but change the first (weave-forward 7) to (weave-forward 6) we get this instead:

miperror

If we put the twists in the loops, we can make small programs with complex results:

(weave-forward 1)
(twist 0 2 4 6)
(repeat 4
  (twist 3)
  (weave-forward 4)
  (twist 5)
  (weave-back 4))

twistpat