How We Built Lyt: a Technical View of the Making Process

At Second Story, we all share a passion for making and crafting. Our collaborations have taken lots of different forms, from a robot that prints tattoos to a floor-to-ceiling interactive sculpture to an imaginative birdhouse. We thrive in the vibrant designer community here in Portland, and our local involvement enabled us to meet members of the Intel Labs team who gave us a great opportunity to do some tinkering. They were about to release the Galileo board (see the specs here) and asked us to come up with a demo showing what the board could do. It would then be presented in Rome for the European version of the Maker Faire. After a few weeks of furious designing, prototyping, fabricating, and testing, Lyt, a collaborative, interactive lighting fixture, was born.

Resources

If you’re one of the lucky few who sees through the matrix, source code and build instructions for this project can be found on GitHub; the README over there contains a pretty detailed description of the overall architecture as well as how the various components interact together.

If you’re a more visual person, you can watch the making of Lyt on the creators project website.

Daniel Meyers, Creative Director, Environments, wrote a great blog post back in October about his thoughts on the project, but I wanted to provide some additional information about our process from a technical perspective. Here we go!

 Ideation

lit_sketches_Page_1

The Galileo board is an interesting mix: it’s both Linux-based and Arduino-compatible, offering developers the opportunity to play with advanced tools created by the Linux community and electronics components and shields from the Maker community. We tried to pick the best from both worlds for our prototype.

In terms of concept, we found inspiration in a couple of previous lab projects: Aurora, which incorporated LED mesh, and Real Fast Draw, a collaborative drawing application. After a couple of iterations, we knew what we wanted to make: an LED mesh from scratch that you could draw on.

Picking out the hardware

_MG_8302_sm

Once we decided to make an LED wall “display,” we had to find the right LEDs. Nowadays, you can buy strips by the meter, where the pitch (the distance between two LEDs) varies between 32 LED/m and 64 LED/m. Another factor to consider is the type of microcontroller driving the LED. The predominant ones are called LPD8806 and WS2801. These nifty controllers enable you to address independently every single LED on your strip. Thanks to the wonderful world of Arduino, you can buy these on Adafruit or SparkFun, and they both give you Arduino libraries to drive them.

After some experimentation, we decided to go for a 32 LED/m running on the WS2801. A smaller pitch would have been a bigger power draw and a more precise data signal would have been required (some people were successful running a 64 LED/m strip on a Netduino, but we didn’t want to lose too much time figuring this out, as the other one was working right out of the box).

Daisy chaining

_MG_8506_sm

After picking the strips we wanted, we had to see how many of them we would be able to plug together. These strips work with four wires: one 5V power, a ground wire, one SPI clock, and one DATA (“master out, slave in,” in the SPI lingo). The full-fledged SPI bus has two more wires, one “master in, slave out” to receive information from a slave device, and a slave select to tell which device is connected on the bus you’re talking to. Obviously the LED strip was not going to give us feedback, so there was no need for a master-in wire, but the lack of slave select was pretty annoying; it was harder to get multiple strips listening on the same bus and decide which one to talk to. So, instead of running them in parallel, we went for a series circuit where the maximum number of strips would be daisy-chained together. Experimentation taught us that we could go up to 12 meters before getting a nasty flickering effect. This was around 380 LEDs per fixture with an estimated power consumption of 70W.

We decided we would make 3 modular panels of 12m LED strips, each with its own Galileo board. This is clearly overkill–one Galileo board might have been enough to drive our three columns with a mux-demux controller to select which strip we wanted to talk to. However, from a demo perspective, it was safer to run 3 independent boards, so, if we accidentally fried one, we would still have a working prototype.

We’re happy to report that no Galileo board was harmed in the making of this demo.

Starting the development

_MG_8256_sm

We wanted to be able to control the light fixture using mobile devices and still have a board per fixture. We obviously needed some means of inter-board communication to notify them of the phone interaction, and having a self-contained system was our ideal. We ended up with a four-Galileo-board set-up, using one, which I’ll call the Lyt board, as the server. It dispatched relevant information to the three other boards driving the fixture.

The Adafruit library we used was taking a “pixel” buffer in entry and would display it nicely on the strip, but we had to do some slight modifications to make it run smoothly on the Galileo. It’s pretty common on the Arduino board to transfer buffer one bit at a time, by switching on and off a pin. This should work on the Galileo too, but, as a full Linux system is running, things are not that bare-metal. Instead, it’s mostly as if you were writing to file: you have to open a file descriptor, write, and close it. And this process goes through system calls that take a few milliseconds to kick in, which is not good when you have 400 LEDs to drive. Fortunately, the Intel folks were smart and added a function to the SPI library to transfer a buffer in one go, so instead of having to do syscalls for every byte, it’s reduced to one (or a few) for transferring one buffer entirely. These details are hidden in the depths of the SPI library, so, for the regular user, the only thing to know is that you can transfer a buffer quickly on SPI. The curious should investigate and explore the source code available in the Arduino IDE to better understand how all this black magic is working.

Adventures in debugging

5H2A9943_edit_sm

This project was a truly international effort: the fabrication and concepting happened in our studio in Portland, OR, the Galileo boards were fabricated in Ireland (it’s printed on them!), the software development was done in France (the developer was suffering from a serious case of wanderlust), and it was all for an event happening in Italy. One of many obstacles we faced during the development process: how to develop a graphic interface when you don’t have the display. Our solution was to create a small debug application using an awesome library called openFrameworks. Our app receives OSC messages from the board saying, “Hey, I’m going to display this and this on the LED,” the app parses the messages, and displays them on a laptop. In return, we added a communication link from the laptop to the board to tell the LED, “Hey, I’m clicking on this part of my phone, you should really do something.” This was, of course, not the final solution, but worked well as a place-holder–the communication link between phone and board would be developed later.

Networking is the key to success

5H2A9966_edit_sm

You may wonder how all these fancy boards were talking together. The Galileo board has a PCI express port (the kind of thing you can find in your laptop) in which you can put a WiFi card. At the time of this writing, the N-135 Intel wireless card is the only officially supported one. Using a tool called hostapd, we were able to make a Galileo board run as a WiFi access point and have all the others connect on it. Then it was easy to send OSC messages between all of them.

Finally, to get mobile phones to talk to the board, we wanted to provide the most lightweight experience for the user and thought it would be great to do the UI using HTML5 and CSS (i.e. a basic webpage). Part of the new specifications for HTML5, WebSockets enable your browser to talk with a different computer through a direct connection; they were perfect for our purposes. We compiled a WebSockets library for our Galileo board (the libwebsockets one), plugged in our Arduino sketch, and, after some tinkering, VOILA!…phones can talk to the Lyt board.

Conclusion

5H2A9974_edit_sm

In a few words, here’s what’s happening once you’ve plugged everything in:

Our Lyt board creates an access point you can connect to with your phone. Meanwhile, every light fixture connects to this WiFi and sends information to the Lyt board (like what color they’re currently displaying). When you request the Lyt page on your phone, the board sends it back to you, and, once the page is loaded, your phone opens a WebSocket to the Lyt board. This way, the phone can be updated by the board, telling it the color currently displayed on each fixture, and, in return, when you interact with the UI, the phone sends the information to the Lyt board which relays it to the appropriate fixture. Finally, the fixture triggers the touch animation.

After a few whirlwind weeks and with a successful demo in hand, we got to spend some time in Rome with Intel and the European Maker community. Once more, we were reminded that technology can be the seed for great collaboration and wonder.

— Philippe Laulheret, Interactive Developer

About

Second Story creates enchanting, informative, and entertaining media experiences with innovative technologies that empower connections to ideas.

Tagged with: , , , , , , ,
Posted in Design, Technology