So this year I helped out a bit with a performance that was part of Brisbane’s Anywhere Theatre Festival. The awesome Sandra Carluccio found me lurking around at The Edge and pitched her concept for a site specific performance titled “This is Kansas City”. It sounded like an interesting project, that would give me a chance to refine some android bluetooth tracking technology I had developed with Luke Atherton.
The concept we hammered out with Sandra was that audience members would walk around the cultural precinct and depending on their location, they would receive a phone call and a piece of narrative would play down the line. A little like that infamous scene in the Matrix, where Morpheus calls Neo and starts to give him instructions on how to escape the office building.
- Photo by Lynette Letic
The kicker of the concept being, we wanted people to receive phone calls on their own phone. You wouldn’t need to install any application, all you would need is a phone that supported bluetooth. However we quickly ran into a problem with our existing bluetooth tracking technology, it appeared as though somewhere around iOS 5.0 Apple had changed the way Bluetooth behaved on the iPhone and broke all our tracking code.
So after a night of hacking, we switched to a new design that was the final that powered the performance. We purchased up a bunch of cheap Android phones (The Huawei x3 is a really awesome budget handset), and installed a custom created Android application that I developed called “TriggerTracker”. This application would poll the GPS unit on the phone, and match it against a list of locations, and when the phone was within 15 metres of a specific location for the performance TriggerTracker would ping a URL on a custom server application.
The custom server application (a variant of our bluetooth tracking technology - TeethTracker) was written in ruby on rails and ran on Heroku. It would receive tracking messages from the handsets “Hey, I am this device, and I am at this location” and our server application would match this with the phone to call and the MP3 to play to the audience member. The server application then used Twilio to make the phone call to the correct audience member.
Finally we set up the phones with caller ID, so that phone calls would appear to be coming from the two different characters ‘the monster’ and ‘the authorities’. Each identified by a different ring tone.
We also had a nifty little status page to help us keep track of where everyone was up to in the performance, and Sandra set up a help line where people could call in if they got lost, or in event of technical calamity. I am fairly happy with how the technology played out in the end, naturally it could be better and below is a list of things that caused problems and can be done differently next time around:
What went wrong.
-
Our Bluetooth tracking technology didn’t work with the latest iOS versions on iPhone (need to go back and repair that).
-
We dove in and purchased a bunch of handsets before doing a full walk through and test of the performance. Some of these handsets were just plain terrible, the x3 performed much better.
-
The vast majority of the testing we did was short - did we trigger the correct call at the correct location? We did very little testing of the whole performance until a few days before the opening night.
-
Network woes, we had terrible time with the cheap handsets being locked to a particular network. This network had a huge dropout problem, signal strength was OK. But we were getting disconnected frequently. However we didn’t find that out till we did our whole performance testing. It was a late and frantic switch of handsets and network provider sorted out the majority of these problems but didn’t alleviate it completely.
-
Had no way of programmatically figuring out if a call had been dropped or ended early. More frequent and shorter phone calls would have helped.
-
GPS is inaccurate! It made positioning of the locations fairly difficult, the further apart the target locations were, the less chance of accidentally triggering the wrong location. Conservatively we started out with some locations being about 30 metres apart. In reality we should have had them separated by 50 or 60 metres.
What went right.
-
The iterative development process we used for testing the performance sorted out many of the issues with problem locations early on, and provided a nice framework for testing the performance.
-
The Android Application was able to easily contact the server, and get twilio to trigger the call.
-
Having all the MP3’s in one place made it very easy to update the performance as the content changed. Having the MP3’s on the server also meant that the handsets didn’t need a huge data allowance. Just simple little URL triggers made everything happen.
-
Twilio made it very easy to play an MP3 down the line of a phone call.
Comments:
You can join the conversation on Twitter or Instagram
Become a Patreon to get early and behind-the-scenes access along with email notifications for each new post.
Hi! Subconsciously you already know this, but let's make it obvious. Hopefully this article was helpful. You might also find yourself following a link to Amazon to learn more about parts or equipment. If you end up placing an order, I make a couple of dollarydoos. We aren't talking a rapper lifestyle of supercars and yachts, but it does help pay for the stuff you see here. So to everyone that supports this place - thank you.