I’ve been working on getting serial data to an Arduino behind the scenes and on the fly to drive the ambient display for the Boris Bikes. Naturally, a simple script seemed suitable, but sending serial data from a bash script is not a trivial task, so a little helper tool in C, python, or ruby were looming high on my list. However, as with such things, there is no need to re-invent the wheel. Fortunately, Ben (over here), has written a nice little python script to handle just such events, which aslo has a nice step-by-step guide for those who are unfamiliar. So, I’m now snagging cycle data from a open-source API and sending the proper string via a similarly open script. Trending the data is also in the pipe.
Updating the data on a regular basis is also going to be key. The final version will operate stand-alone, as an appliance (e.g., ethernet Arduino), but for the prototype, I’m using a computer and sending the data via plain old Serial over USB. As I’m using a Mac, the scheduling bit will be handled via a Launch Agent, which has replaced the deprecated launchd. There’s a handy little guide to using Launch Agents here. It uses scheduled backups as an example, but it works for any regularly launched event (such as a shell script). A nice primer for one of those rarer requirements. I use launch agents and plists to firing off my scripts for backing up as well as syncing data and now, piping stuff over serial.
99% of the time pie charts suck (see my rant). However, there is a situation where it can be useful: when you are trying to convey a general idea of part-to-whole relationships among 3-5 entities which are meaningful parts of a whole unit. There’s an excellent breakdown of how this works, why it works, and dos and don’ts here.
This image has to be the best use of a pie chart I’ve ever seen.
In trying to push the limits of how precisely you can actually position a small induction motor, I ran into a lot of calibration problems – as expected. This is a definitely a job for a stepper. However, I then stepped back a moment to think about the information task. What do I really want to know from my ambient display? In fact, the crucial information is not exactly how many cycles are available until the number starts to get low – too low for me to race out to the station and get a bike! Say…anything under 10 bikes and I should start thinking about leaving. By changing the scale to display only 13 positions (0-10,11-20,20+), I can get a general idea of the number of bikes when it’s not really critical, and gradually provide more precision when it’s really needed. This allows for the needle to be positioned more crudely and still provide a useful display. The needle now indicates a number accurately, even after over 1000 test cycles.
It’s a nice reminder that it is important to ask “What is the communication objective?” when designing information displays (whether ambient, on screen, or on paper), and design accordingly.
I’ve been working on the physical side of my ambient display for a Barclay’s Cycle Scheme docking station on Theobald’s road – one that I use pretty often. The challenge for this display is that it uses a motor and drive assembly harvested from an obsolete HP printer. Properly, anything requiring precise positioning should use a stepper motor, but that’s not what I found inside the printer. It uses a simple cheapie induction motor. So, I’m considering it a design challenge/constraint.
There was a plastic optical calibration strip somewhere in the assembly but that’s long gone. So precise positioning will be rudimentary, as the vagaries of induction drive do not always yield reliable results. My tradeoff for the display is to zero-out the motor for every display cycle instead of skipping directly from one number to the next. Each number will have its own drive time and the motor supply is regulated to keep it as constant as possible to minimise the likelihood that the motor will be slower or faster depending on supply voltage.
This test is just to make sure the drive times for digits and the serial communication are all working properly. Next steps are connecting it to the web API and making it look pretty!
I use quick prototyping tools quite often and my definition of prototyping is quite broad. Usually I start with paper sketches, as they are cheap, quick, and easy (There are a number of other good reasons for paper and pencil sketching, see Bill Buxton or my dissertation.) For paper and pencil works well for both hardware and software prototyping, but there are some other useful tools out there. If I’m prototyping in hardware, I usually use Arduino (over, mBed, PIC, etc). For software, and screen-based work, the list of useful tools keeps growing.
On the LDSE project, I used Omnigraffle to produce the wireframes for the user interface, which were very useful as paper prototyping and user feedback, before we coded in Java and JavaFX. For moving to a higher fidelity and for wireframes, there are a couple of handy web-based tools out there, which allow you to model interactions as well – also without cutting new code. This has the benefit of testing interactions where the transition is hard to model easily in paper (e.g., zooming, dynamic representations, etc.). I’ve tried Mockingbird, which is very good for quick and dirty mockups, and which uses a “sketchy” look for UI elements. This is great for making sure stakeholders don’t get hung up on trivial things like button colours, etc. JustInMind moves up the fidelity scale a bit, with benefits and drawbacks. Both have free-use modes for quickly sketching up something and sharing it, but for any serious work, you’d need to pay a nominal amount for the services to be useful – for example, sharing with clients. I’ll be trying out both of these further for an upcoming iPhone app I’m working on with the People’s Trust for Endangered Species. I expect the trend in web-based tools will continue to grow until a couple of players win out.
I like London’s new Cycle Hire scheme (Boris Bikes) but don’t always want to hunt down the Barclay’s website to find out how many (if any) bicycles are available at the docking station near my office. So, I’ve been working on a little project to make a physical bar graph to illustrate the current situation. At a glance, I’ll be able to see if I can use a bike to grab some lunch. An Arduino+a harvested printer head transport mechanism will do, I think.
You have to apply to TFL to get a feed from them and I didn’t want to bother. I figured I’d use CURL to screenscrape it. However, using curl with no parameters returned a page-not-available result from the page which displays the map content using Javascript. Crunch! Not very helpful. It turns out you need to specify a user-agent to get a valid result from the cycle hire site, which returns the expected page nicely:
curl -A “Mozilla/4.0″ https://web.barclayscyclehire.tfl.gov.uk/maps
After fiddling about parsing this I got the data for the terminal I am interested in. However, I also poked around and found this very nice API, which allows me to simply sent an HTTP request for the the relevant information in XML, JSON, CSV or YAML, formats. Very handy indeed, and updated every minute! Now I’ll be spinning along with my project pretty quickly, I think…
I’m really pleased that after a few months of planning, we are able to announce that Tinker London is working with Planet Money of National Public Radio to develop a t-shirt using QRCodes (see the podcast on their blog). We’ve been prepping this since May. Way back then, I was listening to the PlanetMoney podcast, when they announced that they were working on a new t-shirt design, which has to tell a story. It’s hard to get very much “story” content onto a t-shirt (much less, to make it appealing), so I figured using QRCodes to link to a website (as has been used at Internet of Things events and other conferences, like SxSW) would be a good way to resolve the real estate problem on a t-shirt. Our team has been refining this inspiration for a while now.
We’re moving onto refining the design ideas and getting the details right, so that the final t-shirt can do what it’s supposed to do. Check us out on twitter (@tinkerlondon) or by scanning the QRCode at the left…
Comments (0) 
I’ve been working on getting serial data to an Arduino behind the scenes and on the fly to drive the ambient display for the Boris Bikes. Naturally, a simple script seemed suitable, but sending serial data from a bash script is not a trivial task, so a little helper tool in C, python, or ruby were looming high on my list. However, as with such things, there is no need to re-invent the wheel. Fortunately, Ben (over here), has written a nice little python script to handle just such events, which aslo has a nice step-by-step guide for those who are unfamiliar. So, I’m now snagging cycle data from a open-source API and sending the proper string via a similarly open script. Trending the data is also in the pipe.
Themocracy