myTram: a personalised Melbourne network map

This is an October 2010 data visualisation project to develop a data form (object from data) that meaningfully interprets and embellishes the source data (the Melbourne tram network). The project was undertaken in collaboration with Kerrin Jefferies as part of the Master of Digital Design.

myTram data forms - laser cut/etched ply and perspex from Ponoko

Trams are critical in the definition of Melbourne urban form and culture as a primary and iconic mode of transport for inner city residents and visitors. Trams unlike trains follow the main streets, the tram network mirrors the principal geometries of the inner city grid and rotated CBD grid and as such is recognisable even to residents who do not use trams. Each route has distinct corners, bends, branches or kinks and so even a small portion of the network is identifiable.

Mapping personal use of the tram network - frequency and destination of trips, as well as the time spent at and walking range around destinations, gives a dataform that reveals substantially how the city is inhabited. As wearable jewellery or other intimate use object such as placemat or coaster, myTram is intensely personal and richly meaningful, able to prompt memory, discussion and movement from an intuitive and implicit understanding of the city to one that is more explicit.

GPS locations for each tram stop allowed accurately scaled drawing of stop locations which were matched with lists of stops on each route to approximately locate routes by drawing straight lines between stops. The route lists had misplaced stops which were removed by filtering for outlying distances between stops. As stops were located on both sides of the road and routes had travel in two directions there were selection interface issues that were exacerbated once myTrips and myStops were added. These issues were overcome with switches that could be toggled to narrow selection possibilities.

myTram interface - routes through Domain Interchange highlighted

myTram interface - myTrip Route 8 along Chapel St highlighted

myTram interface - editing time spent at and walk radius around myStops

While graphic representation on screen allowed relatively detailed information to be encoded with layered transparencies and fine lines, augmented with popups and rollovers, and navigated with filtering buttons, the laser cut data forms had to be significantly simplified to be legible. A thicker line weight was required for structural integrity and only two depths of etching were employed to ensure high contrast.

The final form was refined to just myTrips with no contextual information (grid and other routes were removed) and only two modes of trip frequency (frequent, thick line; and infrequent; thin line), time spent at myStops (primary, large radius and deep etch; and secondary, medium radius and shallow etch), and walk range around destination (greater than 500m, ring with 500m radius to scale; and less than 500m, no ring).

myTram is legible as an embellished section of a network diagram.

I reviewed this project again, now in the context of thinking about the project for the NMA collections, to remind myself of the importance of context when working with data. In this project the context is urban and personal, both rich and specific. The NMA data set is much larger and much of the context of individual objects I expect to be more ambiguous or abstract -  time, location, like items. I will have to be careful in drawing together any narrative that it is appropriate. 

Exploring the NMA catalogue - first thoughts

As part of the Master of Digital Design, this semester we will be developing data visualisation projects from the National Museum of Australia's digital catalogue. Project development can be followed with the tag 8199 (the unit number). The project is being led by Mitchell Whitelaw.

This is an exciting (and daunting) culmination of work to date. The NMA is in the process of digitally cataloguing it's very large and important collection (of collections). The NMA conserves the 'National Historical Collection' which contains more than 200,000 objects representing Australia's history and cultural heritage, of which so far 48,000 objects from 1003 collections have been catalogued. A tiny fraction of these objects make up the public exhibitions at the Museum - some of the exhibition material is valuable such as many of the indigenous artefacts, while some of it is perhaps not especially so but is important because it illustrates cultural stories (in one of the displays there is a windmill with a cut out magpie).

Phar Lap's Heart, National Museum

My first approaches to all of these objects online has me overwhelmed. Here there is no curation. I am confronted with a search box. Without having in mind something specific like Phar Lap's Heart I look to browse elsewhere. At the side there is a random selection of object thumbnails (many of the objects dont have photos, and most of them appear to be low resolution). Initially I didnt realise that these were links, but they were all the same engaging. Next there was the opportunity to browse by object type - this I found to be the most interesting - cabinets, cake tins, canoes, chemical jars, cricket balls, cut throat razors... Then there was the opportunity to browse by collection - here I was confronted by many unfamiliar names that I assumed to be donors or the focus of the collection. Unfortunately I couldn't access a description of the collection, only a list of the objects it included. Elsewhere on the NMA website I found descriptions of some of the most significant collections.

Examination of individual object records left me feeling no better connected to the material of the collections. Each item that I viewed (except Phar Lap's Heart) had a very brief factual description of the object, but little contextual information other than a date and place. I could not tell what the significant of the object was (surely some of the objects are more significant than others?) and I was not told why it was part of the National Historical Collection.

So the task I am most interested in is constructing a better narrative around these objects. Data items that stand out as possibilities to construct some analytic context are date, place, materials, dimensions, collection size and number of object type. It is my expectation that visualisations based on these data items can better situate oneself within the collection and assist navigation / browsing. It is my intention to make both visualisations of and an interface to the collection.

The designed ability to zoom in and out within a dataset and to comprehend the scale of the whole and it's parts allows large and complex data that was previously only superficially understood to become powerful and sophisticated information tools. Of course data analysis is only as valid as the source data and data can be misunderstood when it is out of context - or in a wrong or partial context.

Mitchell Whitelaw's visualisation project for the National Archives is a great demonstration of the potential for design to transform the accessibility and legibility of a large data set that was previously incomprehensible. The overview Series Browser is able to represent the entire data set of series in a way that reveals structure and relationships, while the zoomed in A1 Explorer uses a word frequency cloud and histogram to indicate some of the contents in a more succinct and engaging way than a contents or index page possibly could (the A1 series contains 65,000 items). Both visualisations suggest themes to focus or zoom further in on - and being interactive are part analytic, map and interface.

National Archives Series Browser, Mitchell Whitelaw, 2010 - series are arranged
chronologically with their size and provenance indicated

D, I & E Tile Processing Mockup V3

Is this the winning formula? Finally I have a balanced version that has multiple pressure input legible and allows emergent pattern. I have added a lock out that stops endless cycling after a reasonable time to see emergence (15 sec) if a low gate condition has been reached (lights on 3 times in that 15 sec). During a lock out period (10 sec) I imagine pressure input would result in a low buzz to indicate it was disabled.

I have kept the min off time to a minimum to maximise feedback from pressure input, and increased the flag delay and limited the max on time to ensure not all lights are on at the same time. Also I think mode 2, clockwise internal communication arrangement, is most coherent to use, because the communication between tiles is clockwise. Controls are still enabled - so keep playing!

D, I & E Tile Processing Mockup V2

Here is a revised version with controls to change variables so that everyone can have a bit of a play.

I have added the potential to set a minimum time that cells must be off before they can be turned on by neighbouring cells being on. This can be used to break the endless cycle and makes responses and interactions from simultaneous pressure sensor inputs at opposite sides of the board more legible. Unfortunately pressure sensor inputs can not be communicated to neighbouring cells that are serving a minimum time off (this is possible to code, but our physical communication setup can not differentiate the cause of neighbouring cells' lights being on). There is also then the potential to set a maximum time that cells can be off before they randomly turn themselves on.

I am not sure what the optimum arrangement is for our installation, and if it would be interesting or too unintelligible for each tile to have individual settings. So keep playing!

D, I & E Tile Processing Mockup

Here is a quick Processing mockup of our current tile arrangement to demonstrate that lights are communicated in circles. I have also tested some alternative arrangements that produce various other emergent patterns, such as diagonal stripes, by communicating between cells within tiles. All of the arrangements produce endless loops from a single pressure sensor input, but unfortunately in all of the arrangements multiple pressure sensor inputs produce either no legible response or fairly uninteresting interactions.




Controls:
mouse click = pressure sensor input / footstep (to begin)
key q = turn all lights off
key 1 = only neighbouring tiles (current arrangement)
key 2 = neighbouring tiles plus internal cells clockwise
key 3 = neighbouring tiles plus internal cells anti-clockwise
key 4 = neighbouring tiles plus internal cells diagonal
key 5 = neighbouring tiles plus all internal cells
key 6 = neighbouring tiles plus internal cells horizontal
key 7 = neighbouring tiles plus internal cells vertical

D, I & E Reflection

A very big thank you to Stephen Barrass. I very much value the intensive delivery mode of the Digital Design technology units where I feel like I can quickly progress by implementing and then expanding upon learning immediately - before it can be forgotten and then require recapping as in other potential delivery modes. As with previous Digital Design units, Design, Interaction & Environment has opened up a whole new world.

I have never before played with electronics or microprocessors, let alone felt audacious enough to attempt an interactive installation. Of course with any newly learned skills I will need to keep practicing, and it can sometimes be difficult to find the initiative to do this - however I believe that the rapid progression through this unit will now make it more likely that I have the confidence to attempt a project of complexity sufficient to be inspiring. In fact, if I have time, I would like to set up an interactive installation for the my end of year architecture graduating exhibition, which tends to be well attended and a bit of a party.

A particularly appreciated learning experience I think was the production of an installation, which in many ways was a 'real' project. Group work can be very stimulating, but can in a University situation be more often than in a workplace challenging because of unclear roles, lack of (or competing) leadership and group members who don't pull their weight. Thankfully this unit, as a whole of class group project led and facilitated by Stephen, proved to be very productive, and group members who had diverse backgrounds were able to contribute in different ways.

The best bit of the realness of this project was that Stephen left in all the messy bits: we were able to develop a design direction collectively, which is not the easiest processes; we had to shop for the components and materials, which were not always available meaning that we had to adapt the design; we had to investigate and learn new fabrication technologies; and ultimately we ran out of time to finish within the intensive class time! All wonderful lessons in production.

So through this unit I learnt some technical skills like constructing simple electronic circuits and drawing circuit diagrams, and working with various potentiometers and a microprocessor. I also gained great confidence in the adaptability of my programming, particularly in learning Arduino code, which is slightly different to Processing, and in figuring out how to make a library when I was stuck trying to implement classes.

More importantly perhaps were considerations of pertinent content, meaningful interaction, and legible interfaces and environmental responses in the design of installations. Although we were only able to include in our project some of these design and theory ideas, and perhaps in a fairly limited way, I found the class discussion on background readings and research for project proposals most engaging and worthy of expansion in future classes.

I am looking forward to continuing to work on our installation over the next couple of months. I hope that it can still be somewhat collectively curatable - that is I think that more than one person will be able to fit on the tiles at the same time and so suggest that a focus should be interaction between responses to multiple footfalls.

The theme of exploring self organisation is also something that I have had an ongoing interest in. I like very much the tactility of seeing and interacting with self organising systems that are rendered outside of the computer screen.

R&Sie(n) 'I've heard about'

R&Sie(n) 'I've heard about'

Taking research at the intersection of self organising systems, architecture and physical computing to a conceptual extreme are R&Sie(n), whose project 'I've heard about' for example envisions an architecture not centrally controlled, self constructed and continually grown and adapted, by landscape secreting 'Viabs' which respond to local conditions including chemical emissions data of it's human inhabitants. This biostructure no longer seems quite so futuristic.

D, I & E Intensive 2 Day 3

We now have the projects substantially finished, but we didnt get to install them today or test how they interact or give them individualised behaviours. We will get together for another workshop in the holidays and do a test install then before the exhibition at the Belconnen Arts Centre. I suppose that is an important lesson in just how long all the little things take to get done, and how often things dont work smoothly as expected and so need resourceful on the spot thinking.

I do feel like I have come a long way in 6 days, and have confidence now to finish my tile myself - and then go on to do any other project on my own. I had never worked with electronics before this.

SOFTWARE

I wrote my first library! What a challenge - after spending the evening before adapting our code to classes as I would set them up in Processing, I spent almost the entire morning figuring out how to make them work in Arduino as a library.

Code with library header and class files in foreground

Essentially Arduino is built on C++, which has similar syntax to Processing which is built on Java - but they are not the same or directly compatible. I will have to read up more about this. The previously linked to tutorial was very helpful and got the basic setup for me.

However after hours of debugging and browsing the Arduino forums I still had one unsolvable problem - I couldn't get the constructor to recognise instances of custom classes. I had made seperate led and light sensor eye classes, and was trying to get the led class to know about their own eye as well as the other 3 eyes in the tile. So I got around this by unifying the classes in a single cell class. Lesson - try to make two classes talk to each other at your own peril!

There are a few other key differences between this and a Processing implementation:

1. the code is written in separate files that are saved in the libraries directory of the Arduino install directory (Arduino/libraries) and edited in a text editor such as notepad, these are:
1. Cell.cpp, the class file where all the code goes
2. Cell.h, a header file which is like a contents
3. keywords.txt, a list of keywords to highlight the code in Arduino
2. there is additional wrapping syntax before the constructor and other functions in the class file (ie Cell : : )
3. there must be a link to the standard Arduino library (ie #include "WProgram.h" ) and any other libraries you are using (if you can get them to interface!)
4. the header file lists the constructor and all the parameters and functions, so is a handy reference to remember the names you can call - public functions and parameters can be called, manipulated, updated etc in the same way as you would with Processing classes - private functions and parameters can only be called from within the class
5. in your Arduino code you need to import the library (ie #include <Cell.h> ) and remember to restart Arduino to get it to recognise a new library

It should be easy to hack the library as the code resembles Processing - just remember to add new parameters and functions to the header file. Perhaps adding a timer to keep track of the time that the light has been off would be useful.

However I have tried to design the library to be flexibile so that for most of the things we might want to achieve with the tiles we shouldnt have to touch it. There are some global variables that can be updated via the cellSettings() function. I have added parameters to control the eye flag threshold for turning on/off the LEDs, change the delay between the eye flags and the LEDs turning on, and to set a minimum time that the LEDs have to be on before they can be turned off. I have also added a boolean switch to turn on/off the fade and a time step to lengthen the time it takes to fade.

There is lots that can be done from outside the library - for example the knob is hooked up to change the flag delay via the cellSettings() function and the buzzer is set up with all of it's parameters (frequency, duration etc) outside the library and is hooked up to make a tone when it recieves a toneSet signal which is sent when a cell turns on the lights in the function doLight(). The pressure sensor controls lights differently, outside of the library ( ie not in doLight() ), by simply setting brightVal to be 255. The LEDs can be set at anytime to be any gradient of brightness by changing brightVal.

Also I gave each of the cells specific names (topLeftCell, bottomRightCell etc) not because it matters which way the tile is oriented, but so that it would be easy to program communication between cells remembering which cell is clockwise or anticlockwise adjacent or diagonally opposite. Internal communication may need to be considered by the whole class because with the current code and physical circuit setup ripples will not propagate beyond the tiles immediately adjacent.

Anyway the main outcome that I was trying to achieve was robust base code that has plenty of room for others to develop some differentiated individual behaviors for their tiles.

HARDWARE

Concept diagram showing neighbour communication paths

Circuit diagram showing inputs on left and outputs on right

With limited materials we put together a couple of working protoypes. Richard Spellman and I worked together. There were a few issues that we met.

The red LEDs we have been using are not very strong so we are back to planning to seperate neighbour communication LEDs from display lighting. However we have almost run out of pins on our Arduino microprocessor - there are still a few digital pins, but these can only be ON or OFF. The breadboard is also very busy and we ran out of wires so have confused colours (eg we put the knob on the output side and used black, blue and white wires for ground). It would be nice to have multiple breadboards, and particularly breadboards with positive and ground rails (this would save a lot of wiring).

The piezo pressure sensor creates it's own current so doesnt need connecting to positve. It needs to be wired accross a resistor to register differences in current and we had to change to a 1 mega ohm resistor so that it would be more sensitive. The piezo only creates a tiny amount of electricity so we need a big resistor to draw out the time it takes for it to flow to ground. The piezo we are using is salvaged from a piezo speaker.

Each light sensor responds markedly differently and so will need individual calibration. Also we need to consider if we want to access the knob from outside of the tile casing.

When we setup the circuit in the casing we will need longer wires for neighbour communication light sensors and LEDs, and perhaps other things too, and not everything will be on a bread board. We will have to be careful fixing components down and will need to remember to case exposed wires so they dont short circuit.

We still need to test the audibility of the buzzer through the acrylic and whether we need some pin holes. We also have to prototype different display LED configurations to test the brightness and how they display through different backing sheets, patterns etc - this is something that we will each be doing now individually.

A working prototype Richard Spellman and I put together

The prototype as it fits in the casing - the pressure sensor will sit in the middle just under the acrylic tile, and LEDs and light sensors will be in each cell 

Some longer wires for the LEDs and light sensors prepared by Richard

Stephen Barrass, Natalia Lopez and Nathan Evans drilling the casing together

Also an over site - full credits for the project! Our lecturer is Stephen Barrass and the class is Vanessa Wang,  Anaer Anaer, Nathan Evans, Subyeal Pasha, Natalia Lopez, Amber Standley, Richard Spellman and myself.