A rough account of ‘The Gavel’ – project initiated by Donovan Hide, John O’Shea, Adrian McEwen and Andy Freeney at ScraperWiki Hacks and Hackers Hackday Liverpool, Friday 16th July 2010.

Early on in the Hack Day (described in previous post) potentially interesting data-sets were identified.  I had recently found various sources of information relating to legal processes, which are being made available via HMCS (Her Majesty’s Court Service) which I felt might lead somewhere.  Donovan Hide, a programmer (whose current projects include Churnalism*) also felt that this data was of potential interest and public value and together we decided to make something which would attempt to make legal process data more tangible.

Our first task was to identify appropriate sources and we found a couple of interesting things.  One early contender was Criminal Online Results, a government site in a BETA stage (so not using REAL data) but basically which will be publishing the names of persons accused and the length and dates of their jail sentence!

However, a second HMCS site we found seemed more appropriate to our project: Xhibit Court Services displays a kind of commentary on various Crown Court legal protocols and seems to be continually updated.  Donovan decided that he would like to develop some kind of REAL-TIME application which could notify the status of every court in nice clean data.  ScraperWiki would not be the right tool for this kind of continous live data and so Donovan opted for node.js which is a really fast way of writing a web server which could churn out an aggregation of court data in real-time.

Adrian McEwen (whose Bubblino** device has been a fixture of tech conferences across the country for the last year) also joined us and he had various bits of electronic hardware with him.  Together with Andy Freeney, part of the technical team at Liverpool JMU and self-described ‘tinkerer’, we all began to discuss what kind of physical output might be appropriate.

‘The Gavel’ (judge’s hammer) just seemed synonymous with the finality of legal rulings (even though they are rarely used today!) so we decided to find a way to bring a whole multitude of data and output to this one simple action – a judge, banging the gavel on his bench.

Strands of data scraped from the HMCS site are interpreted in different ways by the arduino micro-controller causing the gavel to strike the bench.

Example applications:

• tune-in and follow individual through court process
• notification of all legal proceedings in a specific geographic location
• hammer comes down every time a case is closed
• hammer comes down every time someone is given life!

Our presentation from the day is shared here and there are links to various other elements (including the scraper) below:

our scraper:

• http://github.com/donovanhide/The-Gavel

a project Donovan has begun developing in the days after the event:

• Cause List
• Track what’s going on in the courts of England & Wales right now
• http://causelist.org/

flickr photos from the day:

• http://www.flickr.com/photos/john0shea/sets/72157624554065844/

*’Churnalism‘ uses various analytical methods examine news articles and determine what proportion has been directly lifted from press releases.

**’Bubblino‘ is a networked object which can be tuned into twitter #hashtags – when a specific hashtag is used, Bubblino blows bubbles!  Although simple in premise, I have grown fond of Bubblino’s rendering of dispersed data into a kind of processed physical FLOW.

ScraperWiki is a collaborative environment for building, running, storing and sharing web screen-scrapers and their resulting bounties of data.  (Here is a handy introduction to ScraperWiki by Paul Bradshaw.)  I was lucky enough to encounter ScraperWiki right at the very beginning when Julian Todd and Aiden McGuire launched the concept at Liverpool’s first Barcamp (at the end of 2008) and last Friday I had the opportunity to take part in the ScraperWiki ‘Hacks and Hackers Hackday‘ at open labs LJMU.

The object of the day was for ‘hacks’ (journalists + activist bloggers and curious citizens) to work with ‘hackers’ (programmers + geeks and persistent meddlers) to collaborate in attempting to dig out publicly available data from over the internet and use this to tell new stories.  Although, ScraperWiki was the proposed tool for doing this, the emphasis throughout was on accessing, understanding, re-interpreting and sharing previously oblique data.

The day began with presentations explaining the power of good data-visualisation and information graphics.  Examples cited were:

• BBC ‘best graph of the election’ – showing convergence of 3 Political Party’s public spending and taxation plans – suggesting very high chance of coalition govt.
• Nick Clegg on They Work for You (data from Public Whip) – showing data-vis need not be graphical (computer generated sentences.)
• Schooloscope (visualising schools in relation to OFSTED reports)
• GapMinder – Hans Rosling (below) – 2d comparisons over time – less divided world than we might think!

The delegation in attendance comprised of roughly three groups:

• professional journo’s (Liverpool Echo thru to Graniud) on ‘professional development’
• hardcore coders (already invested in ScraperWiki)
• & a sizeable contingent of those invaluable (and uncategorisable) people who are becoming harder to ignore these days now they are identified as the long tail.

What impressed me most about the event was the total commitment of all of those present to be involved in the process and deliver a fresh idea.

The value of such analytical approaches to journalism is immense and might well mark a sea-change away from soundbite political media. However, my own interest in screen-scraping is perhaps more inclined towards provocative and experimental data-usage and applications which demand reflection on the unanticipated dormant potentials within our familiar networked technology and databases.

Some more blog posts about the day here:

• Policemen, Judges and Libraries – ScraperWikiBlog
• Liverpool’s ScraperWiki Hacks and Hackers Hack Day – Alison Gow
• Hacks meet Hackers – Mike Nolan
• Using Data to Track Bobbies on the Beat – Ed Walker

I chose this example to illustrate that it isn’t such a big deal for children to express that they don’t have knowledge about something, but I think, as we get older (and more ’specialised’) it can become increasingly difficult (and socially embarrassing) to admit that our knowledge or ability is in some way inadequate.

This very lo-fi demo brought up some interesting questions about what exactly the project is trying to do.  In the above example – wearers draw or write on the back of their lanyard something which they want to learn about and then they are in control of when (and to whom) it is revealed.  This is akin to the kind of ’speed-dating’ or ’social-networking’ games which already take place within conference environments and is not really the type of interaction I’m trying to get at…

The device which I am building would not be activated by the wearer – instead it would be activated by the presence of others members of the community and it would *involuntarily* reveal inadequacies (or short-comings) in the wearer’s knowledge or ability.

Progress…

1.  Arduino —> Programmable Display

I used this LCD display:
http://www.coolcomponents.co.uk/catalog/product_info.php?cPath=45_71&products_id=151

And this tutorial helped a lot: http://www.arduinoprojects.com/node/13

Problems:

* need to make secure connection to LCD

* need to control contrast of LCD

Code already called the LiquidCrystal library at setup and interfaced seven of the arduino digital pins to the LCD:

// include the library code:
#include <LiquidCrystal.h>
// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(2, 3, 4, 9, 10, 11, 12);

I put the wire controlling the LCDs contrast (pin 3 on the datasheet excerpt below) into the arduino digital pin 5:

// contrast variable to digital pin 5
const int contrastPin = 5;

And then established the best contrast level for this 16×2 LCD using PWM (which runs from 0-255) via analogWrite – 118 seemed a good value:

//PWM value
analogWrite(contrastPin, 118);
//info http://arduino.cc/en/Tutorial/PWM

* need to work with Arduino Nano

* http://www.arduino.cc/en/Main/ArduinoBoardNano
* http://www.ladyada.net/learn/lcd/charlcd.html
* http://www.maplin.co.uk/Module.aspx?ModuleNo=1500

2. Programme —> allow switching of display

(Demo with tilt sensor shows principle)

3. Transmit / Receive Infra-Red Signal

bought these IR components:

http://www.maplin.co.uk/Module.aspx?ModuleNo=10379#features

sought advice here:

http://tthheessiiss.wordpress.com/2009/08/05/dirt-cheap-wireless/
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235097384

got stuck!

tried this instead:
http://www.instructables.com/id/How-to-make-an-arduino-IR-link/

but also does not seem to work :-(

4.  (received vibration motor – have not yet integrated into programme)

5.  Cut out a simple housing on the laser cutter to demo the concept and give an example of layout:

IR transmitter and receiver mounted above and below electronic display.  (I added a button to the bottom right which would allow the device to be triggered ‘manually’ by the wearer themselves.)*

*added later – in retrospect, the last minute addition of a ‘manual’ button, allowing the wearer to trigger the device themselves is totally unnecessary and undermines the concept of the device.

The device translates the ‘turning over’ action associated with the traditional egg-timer into the revealed words ‘tick and ‘tock’ – archetypal (and now redundant) by-products of clock mechanisms.

Basically, an Arduino micro-controller has been pre-programmed to send alternate bursts of full and zero power to a DC motor from a 9v battery ONLY when the device is turned over (because the action of turning over is detected by a mercury tilt sensor).

See TiltTickTock in action below:

Full power is supplied for 3.4 seconds (a time established by trial and error) and this rotates the single aperture in the yellow acrylic ‘face’ around to the approximate position of the written words – ‘tick’ and ‘tock’.

It should be pointed out that a servo motor would give far better ‘accuracy’ in designating the exact position of the ‘face’ if that were desired.  The challenge here was to make something interesting with these quite blunt and clumsy components and actually, the inevitable inaccuracy of the DC motor solution (due to friction, difference of power, loss of power etc.) works well here as an interesting analogue to the the problems faced by the early manufacturers of the mechanical clocks in keeping to time (prior to the design of various escapement, containing and regulating the mechanism.)  If you observe carefully you will be able to see that the TiltTickTock runs slightly ‘fast.’

Another aspect of the device which is aesthetically interesting is the way in which the circular aperture of the yellow ‘face’ appears to eclipse the white ‘tick’ and ‘tock’ elements – indirectly invoking movements of the earth, sun and moon (by which we measure the passage of time).

Images of parts/process, various schematics (thanks to Fritzing) and arduino code below:

components/tools identified:

• Arduino microcontroller
• breadboard
• DC Motor
• mercury tilt sensor
• TIP120 transistor
• 10Kohm resistor
• 9 v batteries (for both arduino and motor)
• wires
• various circular lids etc. to test rotation
• clear plastic sweetie box is excellent for containing projects!

…add ‘tick’ and ‘tock’ circles (authentic typed and re-scanned from my typewriter) – ‘face’ simple vector cut out using laser-cutter:

//TiltTickTock by John O’Shea
//Monday 10th May 2010
//MRes. Digital Media DOING Module – Jamie Allen
//Newcastle University Culture Lab

// Arduino code allowing tilt sensor to trigger motor via transistor

// micro-project translating ‘egg-timer’ metaphor to ‘escapement’ metaphor
//via electronics and code

// constants won’t change. They’re used here to
// set pin numbers:

const int tiltPin = 7;     // the number of the tilt sensor pin
const int transistorPin = 9;      // the number of the transistor pin

// variables will change:
int tiltState = 0;         // variable for reading the tilt sensor status

void setup() {
// initialize the transistor pin as an output:
pinMode(transistorPin, OUTPUT);
// initialize the tilt pin as an input:
pinMode(tiltPin, INPUT);
}

void loop(){
// read the state of the tilt sensor value:
tiltState = digitalRead(tiltPin);

// check if the tilt sensor is activated.
// if it is, the transistor is open and the clock programme runs:
if (tiltState == HIGH) {
// turn transistor on:
digitalWrite(transistorPin, HIGH);
delay(3400);
digitalWrite(transistorPin, LOW);
delay(1000);
}
else {
// close transistor (clock circuit off):
digitalWrite(transistorPin, LOW);
}
}

/*
this code is a hybrid of:
Button
2005 by DojoDave <http://www.0j0.org>
modified 17 Jun 2009
by Tom Igoe
This example code is in the public domain.

http://www.arduino.cc/en/Tutorial/Button

&
High Current Loads @ ITP Physical Computing

http://itp.nyu.edu/physcomp/Tutorials/HighCurrentLoads

with reference to Arduino site:

http://www.arduino.cc/en/Tutorial/TiltSensor

*/

This piece emerged out of the DOING class where we were asked to simply build an electronic circuit between a sensor and actuator which is controlled using a micro-controller.  I selected various movement sensors (including one of the kind used in pedometers – piezo vibration sensor) and my tutor, Jamie Allen, also loaned me a mercury tilt sensor “to get started…”

Immediately the tilt sensor became the focus of my attention because I wanted to get a sense of what it was that differentiated this sensor from a mere mechanical switch or digital trigger.  (See above my tilt switch test based onthe circuit at this arduino site tutorial)  The tilt sensor can be used to discern physical orientation in a way akin to how we understand the liquids of the inner ear to function.  Utilising the earths gravitational force, the liquid metal mercury acts as a switch by making or breaking the circuit.

Below is an illustration of a concept I would like to develop:

I’d like to use the ‘turning over’ action (typically used to commence an hourglass) to trigger an arduino programme which can control power to a DC motor – alternating between FULL and ZERO.  A perforated circular disk attached to the motor will reveal the words “TICK” and “TOCK” alternatively.

“TICK” and “TOCK” are the traditional onomatopoeic by-product of the mechanical clocks escapement (for more on this see I AM A WATCHMAKER.)  In translating the hourglass ‘turning over’ action into the words ‘tick & tock’ the piece will be, in a sense, a ‘mechanical metaphor mixer.’

More on this piece VERY soon – for now I’ll leave you with Jayne Mansfield…

* some examples where I have previously considered the nature of intuitive physical interaction either by building a prototype to test or exploring thru writing/dialogue on this blog:  SIMPLE TWISTING INTERFACE, NOTHING UNLESS SHAKEN and PHYSICAL PETITION (this list is not exhaustive.)

- Jayne Mansfield image used without consent of copyright owner (if you are the copyright owner please get in contact.)

I presented a working prototype for my internal assessment at Culture Lab on the 9th of December 2009, where I used the device in conjunction with an arduino board which was relaying the analog information to MAXmsp in order to trigger and control sample audio files.

Thoughts on interface:

Aspects of the Mk 1 hardware are not ideal.  The prototype device is not using a truly ‘continuous’ potentiometer (if such a thing were to exist) – it is using a standard potentiometer which has been butchered and hacked to go all of the way round. The problem is that this leaves a gap in the turn (the resistive element inside is ‘c’ shaped rather than a continuous ‘o’) and as a result of trying to work with this, the principles of code for the current Max patch are heavily compromised.

The demo MAX patch is very buggy and only worked intermittently during the presentation – it is clear that it needs much more rigorous development.

• For a Mk 2 it would be highly desirable to find a better solution than the modified potentiometer for sending ‘full twist’ analogue data to arduino.
• A new MAX patch could then be developed which uses ‘clean’ change in acceleration data rather than periodically polling for difference in values  (which is the clumbsy way the demo ‘worked’)

Thoughts on concept:

During the presentation I was asked ‘why exactly THIS twist?’ and ‘why THIS outcome?’

The action of twisting a pen or pencil in the reel of a cassette tape is something that the majority of the adult population will at some time have done – regardless of technological confidence.  The ‘twisting action’ is the result of some kind of inate human inventiveness which arises in an attempt to fix the tape.

I had begun working with this simple twist because the action is very satisfying, and I wanted to see what kinds of things could be done with the resulting data output that might have some kind of ‘intuitive’ relevance to the cultural associations of the object and so, conceptually speaking ‘feedback’ or echo…

This approach relates to aspects of our recent theoretical study where we considered J. J. Gibson’s ‘Theory of Affordances’ (1977. pp 67-82) in the context of designing for interaction.  Early in the article Gibson, talking about the origin of his theory quotes from ‘Principles of Gestalt Psychology’ (1935, Koffka.)

Each thing says what it is…

…the handle “wants to be grasped” and things “tell us what to do with them

Later though, in a footnote, Gibson warns about making naive assumptions about the simple consequences of our interaction:

THINGS THAT LOOK LIKE WHAT THEY ARE

If the affordances of a thing are perceived correctly, we say that it looks like what it is.  But we must, of course, learn to see what things really are – for example, that the innocent-looking leaf is really a nettle or that the helpful-sounding politician is really a demagogue.  And this can be very difficult.

Strategy:

It is very interesting to work simply from this one ‘action’ and to try and see how much ‘resolution’ there is within it.  In order to make a successful Mk 2 ’simple twisting interface’ I will take the following steps:

1. use bourns continuous potentiometer to make MAX patch work ‘properly’ for demonstration.  This potentiometer allows 10 full turns (based on an internal spiral) so this will allow full development of the patch – key is that I understand how to calibrate MAX and control samples using the device.
2. Make MAX patch work with Rotary Encoder (Encoder to Arduino – how? then Arduino to MAX – filter prior to debugged patch?)
3. Make processing piece using rotary encoder - Arduino to Processing-
4. Do something interesting!

Finally

What might be  interesting outcomes if this were to be a kind of instrument for triggering music tracks, for instance, rather than a mere demonstration of principle? (and art object?)

It might be interesting if:

• initial turning ie. too slow, too fast, speeding up corresponded to audible experience (akin to ’scrubbing’ the playhead)
• turning at a consistent speed for a set period (eg. 5 seconds) allowed the track to take over and play itself
• twisting fast toggled thru available tracks (in this way, more than one track could be played at a time and tracks could be cued using the scrubbing action.)

Original drawing identified basic principle:

1. Twist pencil in tape reel
2. This action twists potentiometer
3. potentiometer relays DATA
4. Arduino board receives ANALOG data in 0 –> 5V
5. Arduino script translates ANALOG voltage to DIGITAL serial data
6. Serial data transfered via USB lead into MAXmsp patch
7. MAXmsp patch interprets data allowing user to triggers samples

Although I considered different configurations (eg. geering) the simplest approach for this test was to directly engage the modified ‘continuous’ potentiometer with the pen lid through the cassette reel.

AND this just felt really ‘RIGHT’!

When building the MAX patch I attempted to identify 3 ‘triggers’ that I wanted to isolate from the user input data:

• twisting
• not twisting
• twisting fast

I basically attempted to identify these 3 triggers using the METRO object to periodically (every 1 sec and every 200 milliseconds) read data coming into MAXmsp and then, using conditional statements eg. pictured, compare the previous two values to identify the rate of change.

I am aware that this is in no way the most sophisticated way of using MAX to interpret this rate-of-change / acceleration data but, this was the fastest way for me to prototype this and get a result with my fledgling knowledge of MAX.

Working on this piece has totally re-affirmed this statement:

simpler interface = more complex interaction

It is fascinating how much data is contained within such a simple single twisting action and there are really huge ramifications for my future ‘user interface’ work if I can develop my skills at using code and software to interpret and translate this data.

Download my ‘Echoes’ MAX patch here.

- PLEASE COMMENT! -

Assumption – scarcity means that ‘continuous potentiometer’ requires ’special’ technical facility.

Jamie – probably just something in there stopping it going all the way round…

Take apart – discovery – OBVIOUS! – ‘afraid to look under the hood’

Now – Arduino needs to communicate with MAX over SERIAL port – Short answer – NOT WORKING!

Joey provides workaround in shape ov OpenFrameworks application (have the feeling I’ll be using O.F. a lot more…)