D, I & E Intensive 2 Day 2

10AM

In thinking about the design approach to my tile, I have tried to establish a hierarchy of inputs and outputs to assist clarity.

The primary input I think is the pressure sensor (a footstep) as this is the direct interactive input from the audience, so output responses to this should be dominant over other outputs - and immediate. Probably all responses to inputs should be fairly immediate, else they loose legibility. So therefore responses have to either be short, additive or interruptible - rather than queued.

There are 4 neighbour communication channels (inputs/outputs). These must be treated equally I think so that the tile is robust enough to be placed anywhere. For example if a tile is placed in the bottom right corner where it has no right neighbour then it would be silly to have a response behaviour that can only be turned on with a signal from the right and equally it would be silly to try to pass output signals only to the right. Therefore  I think that all neighbour outputs should always be the same signal and that the relevant neighbour input signal states are limited to: 'I am recieveing a signal from a neighbour', 'I am recieving a signal from more than 1 neighbour', 'I am not recieving a signal from a neighbour' and 'I have not recieved a signal from a neighbour for x period of time'. In a 9 square grid - 3x3 - there is 1 centre square that has 4 neighbours, 4 squares that have 3 neighbours and 4 corner square that have 2 neighbours.

Outputs are a bit of a balancing act - between variety of responses and legibility. I could have simply on/off, which might be a bit boring (?) but very clear. At the other extreme, given that we are using analogue signals, I could have continuous gradients to give numerous variations (0-255), but these would likely be harder to distinguish. I am leaning toward steps - perhaps 3-5 to be determined by protyping (eg 3 steps would be LOW: 0-85, MID: 85-170 and HIGH: 171-255).

The output responses will be various combinations of light and sound, including varied brightness, blinking, delays, duration, and frequency, and may be thought of as calls that can be made once or perhaps repeated in a pattern.

For example:

• Pressure LOW   >   Response 1 (OFF)
• Pressure MID    >   Response 2
• Pressure HIGH   >   Response 3 
• Neighbours ALL LOW   >   Response 4 (OFF)
• Neighbours ALL LOW for x time   >   Response 5
• Neighbours 1 x MID   >   Response 6
• Neighbours 1 x HIGH or 2+ x MID   >   Response 7  
• Neighbours 1 x HIGH & 1+ x MID   >   Response 8
• Neighbours 2+ x HIGH   >   Response 9 

That is already 9 different behaviours - at least 6 calls - perhaps even this is too much for clarity?

12PM

Stephen has suggested that as our casing has four quads that we design four pixels per tile. So visually our grid will be 9 square super cells and 36 square sub cells (6x6). We are now planning on passing out different signals on each side (regardless of whether a neighbour exists on that side) and having each pixel behave individually.

Stephen is keen that we first set up all of the tiles to behave in the same coherent way - that is is you step on a tile all four of it's pixels turn on, and then pixels in neighbouring tiles ripple on (each pixel turns on after a second delay if its neighbouring pixel is on). Each pixel has two sides (potentially two neighbours) and only recieves signals from one neighbour and only passess signals to the other neighbour (because each tile has four light sensors and four pixels) - this means that communication paths will be quite particular through the grid.

Stephen has also suggested that we dont need seperate LEDs for communication with neighbours - that leaked light from our diplay LEDs should be sufficient to register differences with the light sensors. We will prototype this and see. The great benefit of less LEDs is that is simplifies our wiring - and we only have limited breadboard space and particularly limited input/output pins on the Arduino microprocessor. We are also concerned that the little red LEDs that we are prototyping with wont be bright enough to make the display engaging - we will have to wait and see how it all comes together tomorrow. We will be able to make changes before the exhibition in Belconnen.

5PM

An update on fabrication - we collected the materials (and learnt how to tie knots to secure them to the roof of the car) and began getting the ply CNC routed in the workshop. The router doesnt cut all the way through so that pieces can be held together stably. Kudos to Nathan Evens who led documentation and supervision of the routing.

CNC router - showing different profile routs and cuts

The acrylic was already cut into 38cm squares for us by Plastic Creations and the ply came from Mitchell Building Supplies as Bunnings Warehouse doesnt keep 25mm ply in stock. We also picked up some non-slip rubber underlay from Clark Rubber.

While I had been working in the fabrication team Vanessa Wang,  Anaer Anaer, Subyeal Pasha and Natalia Lopez had been leading development of the code.

12AM

This evening I was trying to tidy our code with classes but found that they dont behave the same way as in Processing and in fact need to be set up as libraries. Perhaps I can try to implement this tomorrow.

I was also experimenting with different ways to make lights fade off - for example our first code dimmed the brightness by 1 each loop (255 = on, 0 = off). A loop might take up to 15 milliseconds if there is lots of code and I didnt want to change from integers to longs - so my ideas for lengthening the fade time were to either have a counter each loop and only every nth count dim the brightness by 1 or to have a time step and only dim the brightness by 1 after each time step had passed. I went with the time step because I thought it would be more accurate.

Also I was thinking about allowing internal communication via code between the four pixels in a tile about their state (on, off etc).