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

Coding with threads: Tablet loom

Tablet weaving is an ancient form of pattern production using cards which are rotated to provide different sheds between warp threads. It’s used to produce long strips of fabric, or the starting bands and borders that form part of a larger warp weighted weaving. We’ll come to the second use later in the weaving codes project.

Tablet weaving

There are quite a few programs around to simulate the tablet weaving process – I used this program to get an initial understanding, here’s an example screenshot:

tab

When using square cards the convention is to name the holes a,b,c,d in clockwise order from the top left corner. The thread that is facing, so creating the colour is shown on the left. This program allows you to choose forward or back 90 degrees at a time for all the cards (the up/down arrows on the right) as well as flipping individual cards (the list of / and \ at the bottom).

To start with I decided to try a double faced weave, using two colours. There is a good site that describes tablet weaving here. I chose this kind of setup as it’s possible to create the warp using 4 continuous threads making it quite fast to get started.

Warping a double faced weave

The best weaving technique I found was to attach one end of the warp to a fixed object behind me and the other to a piece of wood I use to maintain tension with my feet, and pushing the weft threads away from me.

There are many different ways to manipulate the cards to affect the structure created, most of the time you rotate all the cards 90 degrees either forward or back between each weft. There is a limit to how far you can go in one direction before the warp behind the cards gradually gets tangled up, so you need to maintain a balance. You can also flip them so they change direction in respect to the others and also the warp becomes twisted differently which affects the pattern. You can also rotate the cards forward and back individually too, although this doesn’t seem to be used much.

Here is a section of the tablet weaving I managed to produce, both sides are shown:

flip

Section A was an attempt at direct pattern control, all the cards are matched up in terms of rotation, but I’m using flipping to change the ‘facing’ colour one by one to manually create a diagonal line. The process I was following consisted of turning forward 90 degrees, one weft, back 90 degrees one weft, then flip the individual cards and repeat. This unfortunately results in a bad structure with long floats.

In section B I tried going forward one more turn before going back two. It took me a while to work this out as it means the same shed (and card configuration) actually creates different colours based on what you did in the previous step – this weaving has a memory! I need to look closer at the structure, or perhaps set up a huge tablet weaving with rope to figure out exactly what is happening here. This structure works much better than A, but notice the jagged edges on part of the diagonal – this is because the pattern is going against the twist direction of the warp in these sections.

Section C is an indirect pattern technique, and much more satisfying – I changed the relative rotation of the cards at the end of section B, then rotated them all together 90 degrees back and forward throughout section C, the change in the pattern is down to the ‘balance’ of backs to forwards. The ‘memory’ effect smooths the pattern, and it always goes with the warp twist, but notice that with this technique the different sides of the fabric have a different pattern, it’s not the inverse – I’m not clear exactly why this is yet.

Coding with threads: Frame loom

After writing the 4 shaft loom simulation the next job was to try weaving the structures with real threads. Would I be able to replicate the predicted patterns and structures? Ellen warned me that the meander weave would result in unstable fabric, but it would depend on the nature of the material used so was worth trying. Originally I planned to warp up the Harris loom but I need to work up to that as it’s a big and complex job, so I quickly built a frame loom with some bits of wood and nails at 5mm intervals to hold the warp in place.

A simple frame loom

Here you can see it set up with the all important first ‘shed’ (name given to the gap between subsets of warp theads), which defines the order of the threads. I packed the warp too tightly and messily so this was important – luckily as the yarn colours alternate so it made it easy to make.

'sleying' the warp

Here I’m sleying the shafts using threads to pick up the warp as defined by the simulation toggle buttons. The threads (which form heddles) are tied on to wooden poles which are pulled in different combinations during weaving. This is the approach we saw on the warp weighted looms in Copenhagen, I’m not sure if it’s usually used on frame looms – it was cumbersome but much faster than counting threads manually each time. It’s important to use thinner threads than the warp, but you need to put quite a bit of tension on them so they need to be strong. There is something very appropriate in the context of this project about coding threads with threads in this way.

Four shafts set up ready to start

Here it is finished and ready to start weaving. I numbered the shafts with pencil but it’s actually very obvious based on the order they are attached so I never used them. Following the lift plan from the simulation was quite easy, thinking about the pattern more than the combinations of numbers – as I went on I could tell where I was based on the nature of the shed, keeping an eye on the rhythm of the warp threads picked up. Also the parts where I need to lift 3 and leave 1 was really tricky – not helped by the fact that the resulting weft was difficult to see at that point.

Picking up shaft 4

In relation to livecoding, I was surprised to the extent that improvisation is required when weaving even based on a predefined pattern. There is a lot of reasoning required in response to issues of structure that cannot be defined ahead of time. You need to respond to the interactions of the materials and the loom itself, the most obvious problem you need to think about and solve ‘live’ is the selvedge – the edges of the fabric. In order to keep the weave from falling apart you need to ‘tweak’ the first and last warp thread based on which weft yarn colour thread you are using. The different weft threads also need to go over/under each other in a suitable manner which interacts with this. This will be important to include in the simulation properly, but this will only give an early indication of problematic decisions, rather than a failsafe solution.

Meander closeup

Here’s a closeup of the meander pattern compared to the simulation. The yarn is cheap and a bit fuzzy, but hopefully you can see the structure – the differences are interesting. I’m not sure how this will distort further when I remove it from the loom and the tension is gone.

Freestyle patterns

Here are some more freestyle patterns, the boxy ones turned out to be more stable than the meanders – it’s really satisfying to see them emerge from the abstract set of rules that you work with to lift the shafts, not unlike graphics programming. Which of the 4 shafts to lift can be thought of like 4 bit opcodes with different ordering resulting in indirect pattern shifts.

There are three types of limitation that I’d like to note and think about (especially in terms of incorporating them in a programming language). One is the selvedge, as I mentioned earlier – another is floats, which cause the problems on the meander pattern (long threads not incorporated into the fabric). The third is more subtle, some sequences of sheds cause problems when packing down the weft, for example if you are not too careful you can cause the ordering of the weft colours to be disrupted in some situations.