One of the key themes for this year’s Victorian State of Design (SoD) Festival is mobility and a focus of events on Tuesday 20th July. Susan de Vere, Adam Leggett, Dan Hill and I participated in the workshop on the Mobility New Thinking Demonstrator and we then attended Chris Bangle’s public talk on the Future of Personal Mobility.

SoD director Lou Weis convened the group from industry and research to consider four components of our urban journeys; initial choices, waiting, the journey experience and arrival.

Storyboards were provided for three mobility scenarios for discussion and interesting discussions were really the result of this three hour workshop. One of the most interesting discussions were from the group who adapted all three scenarios to reflect mobility difficulties confronted by someone in a wheelchair. What if we all used wheels as personal mobility devices and transport was designed for people to roll on and off?

The group Leaders were – LtoR above – Robyn Healy (RMIT),  Chris Bangle, (former BMW and now Chris Bangle and Associates), Soumitri Varadarajan (RMIT) and Michael Trudgeon (Crowd Productions). Robyn spoke about clothing for mobility, how do you make all modes accessible through clothing transformation, Chris followed with strategies to rethink journeys, Soumitri pulled the premise apart – as only Soumitri can and Michael inspired us to think about the future and where these changes can be best sited in the city.

Each table had a digital scribe – fantastic drawings that I hope we can link to sometime.

In between the workshop and Chris Bangle’s public talk we visited the Creating Liveable Cities exhibition. Greg More told us about his Flowing Data visualisation project for Melbourne Water in which the last ten years of water catchment and use data has been presented to illustrate patterns of use. Its particularly interesting as Melbourne is still under water restrictions from the longest drought in living memory and Greg had us watch one dam when seasonal rains failed to fall and the after effect of never really being able to catch up were evident in the visualisation. Fantastic link between the graphics and sound design.

Below is the Fortune 5000 installation – thousands of suspended test tubes filled with water and messages. Take one to read and reflect. Mine ended up in a bar later on. A lovely piece.

Smartphone user waiting for tram, Sydney

This update is in three parts: ‘our approach’; ‘the hardware’; and ’sensing’. This entry is continued from ‘the hardware’.

It turns out few people have Bluetooth turned on and visible by default. When my colleague at Arup Jason McDermott helped create an urban sensing installation in central Sydney (Smart Light Fields) they observed around 8% of passers-by had Bluetooth on and visible. A colleague in Barcelona reckons it’s more like 20-30% around La Ramblas (is Bluetooth more prevalent in Europe due to a more mature applications market?).

Either way, we can only see a sample of passers-by with Bluetooth. So our approach is to then move through a stack of sensing, moving on to wi-fi (on smart-phones and other connected devices like netbooks), GSM and so on.

Wi-fi is particularly interesting, as we’d initially thought it wouldn’t register much – as the phone needs to be configured to auto-connect to networks, and a network and router i.e. a wireless access point (WAP), needs to be present to enable that. Even if we could prime the environment with a router (leaving aside the provision of amenities and apps approach – see later), we’d assumed a very small percentage of phones would be detectable. If you know the MAC address of a device, you can ‘ping’ it – but how to discover the MAC address? Leaving aside issues of privacy and ethics momentarily, this was proving a challenge just on a technical basis alone.

However, CRIN have been pursuing an approach called “packet injection” (which most wi-fi dongles don’t support, but some do). To cut a long story short, using this, you can prompt a wi-fi port to respond to and reveal its MAC address. It sounds somewhat scary – and there are those ethical issues to the fore about how we reveal the presence of this system, how to reveal its seams, and so on – but this could be extraordinarily powerful It would mean that all wi-fi-enabled devices i.e. most smartphones, all netbooks, could be triggered to reveal their MAC addresses. This initial process can take up to a minute – again, lending itself to environments where phones/devices are stationery or slow-moving, relative to movement at least – but once you have the MAC address, you can trigger it far more quickly.

A couple of sensors might be deployed here. One, in ‘wide range’ at an entrance, say, would be learning MAC addresses. The other might be tighter and more focused, pinging those addresses already discovered – this only takes a second or two once discovered.

GSM is more complex again, and we’ll report on that later (but in essence, unless you’re network provider you can’t trigger a phone to communicate (strictly speaking you can, but it’s illegal to), and so you rely on how often phone sends a ‘ping’, which it does when it’s crossing a cell location area boundary, when it’s on a call or SMSing, or every 2 hours 20 or so in Australia, depending on how the network configures such things.) With 3G the update periods are shorter, and there’s likely to be more data transfer occurring, which can also be detected. 4G, 3.5G (LTE/WiMAX etc.) are even more likely to be capable of being detected.

The next challenge then, other than refining both sensing processes, is to combine the Bluetooth and wi-fi sensing together to give an aggregate view of phones/devices across both. A lot of shuffling of pings and prompts and duplicates is required here. Beyond that, to get the hardware prototype to a state where we can test in a few environments – at UTS and perhaps at Arup, and then into the wild.

So now we have significant process in both the sensing side (Bluetooth and wi-fi both delivering results, albeit independently at the moment, and the hardware side, with a ‘box of tricks’ coming together nicely.

One of the key questions this might be able to answer are those deceptively simple questions about how people use transport. “How many people get off the number 12 bus here and change to the number 34?”, for instance. Although answers are usually attempted via spot-surveys and manual tracking, this very simple analysis is actually difficult to get at in any systematic sense – particularly when scaled up to all buses, all bus-stops, and in real-time. (The shift to real-time data driving decision-making in urban planning is fundamental, and not without complexities, but will surely happen. This project is a prototype of some elements involved in that future.) Other questions might be: How many people switch from platform 3 to 4 at this time? How many people are on-board the next bus? And so on.

There are issues around how to scale up the data to an urban population. As Anne Galloway and others remind us, not everyone has a mobile phone, never mind a smart-phone. So although we’re investigating a mode of sensing mobility that would be far more wide-spread and real-time than current methods (leaving aside floating car data) we have to be careful about extrapolating the results. We also have to be careful about ethics and privacy too, and we’ll be investigating that shortly, covering both the visibility of the seams of the system, and the levels of aggregation necessary to preserve anonymity in visualisation. As Richard Sennett has said, the great promise of cities is that they enable both anonymity and community – we want to work with that balancing act, not against it.

All the above assumes a ‘passive’ sensing of what phones/devices are present in a space i.e. no direct intervention into the environment encouraging access. However, if there was a smart transit application built for these environments – say delivering real-time transit information, including arrival/departure times, connection times and possibilities, congestion levels, environmental data etc. – this would give people a reason to turn on Bluetooth and/or wi-fi on in the first place. If transit operators offer a good quality informational amenity to passengers, the passengers’ quality of service is improved, potentially leading to great patronage – but in addition, these users can then also be sensed, offering the kind of strategic data we’ve been discussing to transit operators.

As a side-line, we’re also looking at office environments, and how responsive environments could be enabled by these real-time feeds on presence. Many ideas there, which we’ll pick up in a subsequent post.

David Lowe and Jason McDermott

This update is in three parts: ‘our approach’; ‘the hardware’; and ’sensing’. This entry is continued from ‘our approach’.

CRIN have explored some simple hardware platforms, particularly the Gumstix and Beagleboard ’sawn-off’ PCs (strictly, ‘computers-on-module’). Below, a few shots from a recent session discussing the hardware. Be warned, this will get a little geeky.

Note the core board here is a Gumstix Overo Earth – the smaller component – sitting on top of a larger expansion board, which gives us further connectivity, including an outlet for multiple USB connections amongst others (spec here). This is needed as CRIN are taking the ‘array of dongles’ approach to sensing via four Bluetooth dongles all scanning simultaneously. (You can see a couple of those behind the box in the shot below.)

Note also a 3G dongle is needed to deliver data from the board to the internet (and to enable updates to the software to be received on the board too).

There is also a wi-fi dongle, ready for the next stage of scanning (notes on that to follow).

The power adaptor, or battery pack, as seen here, is by far the biggest component. If the boxes are installed where reliable, secure power is available, then the box can be rationalised heavily, down to not much larger than the augmented Gumstix itself. In many cases – most urban bus-stops, public transport vehicles themselves, offices etc. – this power will be available. In far-flung suburban bus-stops, it may not be. So the battery approach isn’t ideal, but may be necessary in some environments. (Also, CRIN (David Lowe, Alex Gibson) reckon the program code is running at about 7% CPU at the moment. By rationalising other aspects of the software, the power load can come down even more. However, Alex is exploring running a background task to keep the 3G connection open (those service plans are not particularly designed for this, of course.)

CRIN can also wirelessly update the software on the boards, when required, by SSH-ing onto the card via their IP address (using Dynamic DNS, which avoids the issue of IP addresses changing regularly due to DHCP, usually used when connecting through an ISP like Dodo. Dodo have been chosen as the 3G connectivity as they’re one of the few to offer a long term pre-paid plans. Again, it’s interesting how these ancillary services can inadvertently shape the research. Though bandwidth not an issue here, due to the tiny packets of data being transferred.)

The data is being updated to Pachube. The problem here is that Pachube only currently supports 15 minute updates, and we also require a broader longitudinal history than it enables. Both of these aspects are being addressed by Pachube though, so we see great value in continuing to patronise that platform with our data (and here it is, for what it’s worth at this pre-installation point). The memory card on the board – a basic micro-SD card – has more than enough room for years worth of data stored locally, but getting the data into ‘the cloud’ via Pachube makes it far more malleable.

CRIN are going to test how scalable this approach is – say, by putting seven Bluetooth dongles on a Gumstix board, which are then scanning at slightly different start times. Results across all seven could be aggregated, and with duplicates removed, give a significantly better return in terms of phone detection.

The total cost of the box (all internals, connectivity etc.) is looking like it’s around $400 at this point. Note, at this stage, the boxes are being chosen for their robustness and unobtrusiveness. At a later date we will consider the visual design and affordances of such boxes, as the need to convey the existance of this system might figure for ethical and adaptive design reasons. Besides, why not make a nice box?

We’ll consider next steps, and the other sensing approaches in the ’stack’ in the next post.

Mobile phone user on CityRail, Sydney

This update is in three parts: ‘our approach’; ‘the hardware’; and ’sensing’.

A quick technical update on our mobile phone sensing project with UTS (see earlier post for context). This project is exploring technical approaches to sensing the presence of mobile phones in transit environments (bus, train, ferry etc.) as well as pedestrians, in order to provide real-time data on such activity, potentially informing urban planning and transport planning decisions. Such approaches might reveal how the city is being used, in real-time. This write-up will get a little geeky in places, but we share it in the hope you’ll find something interesting in the overall idea or the particular approach, and do feel free to contribute via the comments form at the bottom of each post. We’re interested in your feedback.

Our colleagues at the Centre for Real-Time Information Networks (CRIN) at UTS have made significant progress in terms of both the sensing process and the hardware prototypes.

Dealing with the first part, we’ve been exploring a ’stack’ approach to sensing phones, starting with scanning for Bluetooth, then wi-fi, then GSM, and so on. This is partly due to ease of sensing, and partly exploring ethical issues i.e. if people have Bluetooth turned on, or wi-fi connecting to routers automatically, can we assume they are more likely to be happy to be sensed? (Probably not, due to poor design on the part of mobile phone software meaning many may leave it on by default without paying much attention to it thereafter, but part of the point of the research is to explore these issues of privacy and security as well as technical approaches.)

And dealing with the first of those wireless technologies, CRIN have made particular progress in terms of sensing Bluetooth. Using the basic Bluetooth scanning functionality in a PC or Mac Mini, say, we can sense people with Bluetooth turned on and visible if they’re walking past slowly, due to the relatively slow default scan rate i.e. it takes a while for the scanners to detect and observe the phones in the vicinity (the scan rate takes over a second, and is dependent on the number of devices. In essence the scanning uses multiples of 1.28 seconds, with the number of multiples increasing the liklihood of finding all devices. A good quick summary can be found in this PDF.)

As we’re trying to spot a couple of things – for example, both passengers in transit or waiting at a bus-stop (more static) and also pedestrians (moving at around 1-5m/s) – and given the likelihood of groups in these scenarios and the low numbers of people scannable, we needed to increase the Bluetooth scan time.

There are legal and illegal ways to do this. Choosing the former route, CRIN have made great progress in terms of speeding up the scan time, and the detection rate. Software is being written in Python, on the Linux operating system – rather than say Processing on Mac OSX, where the need to parse higher-level languages with limited direct interfaces between Bluetooth drivers and Java would slow things down a little – and several hardware approaches have also been explored, with the current solution considering using multiple Bluetooth dongles in an array, staggering scan times

The range of Bluetooth (class one) effectively turns out to be around 5-20m (depending on the particular dongles employed, the structures in that environment, and so on. Wi-fi is much broader). Of course, in transit, on a bus, train, or tram, or relatively stationery at a bus-stop/platform, the captive audience is much easier to spot.

(NB: the RTA assumes people walk about 1.2 m/s on average, according to their transport planning regulations.)

Essentially, the array of Bluetooth dongles is now able to scan phones much faster, and certainly within our intended environments of buses, trains, bus-stops, platforms, stations etc. Recall that the original rationale for this project is to generate real-time feeds on transit activity in urban areas, as most current transit data is not real-time, not particularly scalable, doesn’t uncover individual ‘multi-modal’ trips where someone might walk to a bus-stop and then switch to a train, say.

Given this impetus, the scan-rate from the Bluetooth array achieved above is certainly good-enough as a start. The next requirement is to wirelessly communicate this data in real-time to ‘the cloud’, via a small robust ‘box’ that could be installed in such environments.

In the next post, we’ll discuss the emerging hardware prototype.

iPhone user on CityRail train

Without being aware of it, most people are walking around with sensors in their pockets, also known as mobile phones. A handful of research projects worldwide are now using data derived from sensing the presence of mobile phone activity to learn about patterns of movement and behaviour in cities.

The Real-Time Rome project by MIT’s SENSEable City Lab is the best-known so far, using aggregate data from mobile phone activity over the three days around the World Cup Final in 2006, plotted onto a map of Rome. As France’s Zidane headbutts Italian defender Materazzi and is shown the red card, Rome erupts in a flurry of phone calls and texts, surpassed only by the final whistle indicating Italy’s triumph. The mobile phone data then shows the supporters following the Italian team parading the cup through the streets the following day.

Real Time Rome visualisation by MIT SENSEable City Lab

At Arup, Dan Hill (Sydney) has used research funding to help secure a UTS Partnership Grant, for a project to be led by David Lowe of the UTS Centre for Real-Time Information Networks, with Dan leading Arup’s involvement as sole ‘industry partner’. The project will explore the use of mobile phone data as a way of sensing patterns of movement across Sydney’s transport networks, including feasible platforms for this kind of data collection, information visualisation, and ethical issues.

The huge promise of this approach is in the detail and real-time nature of the results, and the potential benefits to transport networks and overall urban performance as well as urban planning. Feel free to contact Dan at dan.hill@arup.com for more information about this or other Arup Informatics projects.

NB. Here’s a technical update on the project, some months later.