Universal LED Animator #1 - Intro

Waiting for my board and components to arrive, I would like to present an intro to my project – the Universal LED Animator. It is a combination of a hardware kit (a base station and some beefed-up LED strips) and a web application that together allow their user to endlessly customize animation patterns on their lighting setup. My Hero board is the RedBear, and I'm also using a BeagleBone Wireless. I already have addressable LEDs in satisfactory quantities so I can start working on the project as soon as the RedBear arrives.

The problem

The advent of cheap addressable RGB LED strips enabled plenty of smart and fun lighting systems that were previously very difficult to realize, to the point that a WS2812 LED strip became a staple of every maker's equipment. They offer a full RGB spectrum with plenty of power, come in several sizes and LED densities per length, and various degrees of environmental protection. They light up thousands of storefronts, smart homes and 3D printers. More elaborate designs have also been realised with these components – examples include LED strip clocks and TV ambilights. Obviously there is also plenty of less common and location-specific projects implementing them as well.

The low cost strips sometimes implement some basic control systems, using a controller plugged directly into the strip, or a radio receiver for a simple remote. These already provide plenty of functionality, but for the real potential of the addressable LEDs to be realized, a custom digital control system is required. The immense popularity of Arduinos and Raspberry Pis made them quite common as well due to the ease of programming and plugging them into a LED strip. Recently that last step has become easier to omit, as some lighting products featuring a LED strip and a built-in Bluetooth-enabled controller came to market. With this new kind of hardware it is possible to design even better lighting systems, for example ones that are centrally controlled, e.g. via a Linux board presenting a web interface to an end user, without being physically connected to the LED strips it controls. With a plenty of powerful Li-Ion batteries on the market, we can expect entirely wireless lighting solutions sprouting up relatively soon.

As a person interested in lighting design and architecture, I closely follow any developments related to those technologies. I see a lot of potential for addressable LED strips in applications like temporary architecture (pop up stores and the like), lighting system for events and parties and installations with moving parts. One great feature of LED strips that could be used in those settings is their mechanical flexibility and ease of attaching them to various surfaces – they're very light compared to incandecent bulb solutions of yesteryear (like your oldschool Christmas tree lights) and rarely require anything more elaborate than some clear tape or zipties. One can easily imagine a system of animated lights that can easily be rearranged as the designer wishes, manually or even automatically, if there are moving parts involved (e.g. on a stage backdrop, or as a part of an art installation). The limitations to develop such a system are:

1. Connecting to a controlling wire – already solved by the aforementioned Bluetooth-enabled products. It is also very easy to develop your own, using a Bluetooth-based board like the Redbear, connecting to a centralized controller wirelessly. A custom controller will be a part of this project.

2. Powering it up – can be done with a pack of 18650 lithium cells, they should provide enough power for the time of operation of a temporary installation (i.e. 24 hours), or longer if used with caution. For the purposes of the contest, I consider battery power to be a nice-to-have feature.

3. Creating animations – up to this point, there was little to be achieved in the field of dynamically created animations – they had to be copied into the controllers' memory, and could be changed manually, responded to some signals (button presses, the sound of music etc.) but it was still difficult to achieve an animated sequence that changes with position of particular pixels.

I have identified solutions to two of the above problems and I want to develop a solution to the third – a Bluetooth controller for LED strips working together with a web app, enabling dynamic animation design for a lighting installation where the pixels are moving, or will be often rearranged manually. By putting the installation in a special config mode, allowing identification of each LED strip, and taking a photo with a smartphone, the user will be able to change each LED strip's pattern dynamically, to create a synchronous or asynchronous animation made up of any number of pixels.

The solution

Hardware overview

The Universal LED animator consists of a central computer and LED strips with custom controllers. The central computer is running Linux (Beagle Bone Wireless) and connecting with each LED strip over Bluetooth, as well as presenting the user with a web interface over WiFi for uploading their photo and then working on the animation patterns. Custom LED controllers with Bluetooth functionality will be created based on RedBears.

Proposed workflow

1. User connects to the central controller's web interface with a smartphone and asks the system to enter config mode.

2. The Beagle Bone discovers BT devices in its vicinity, then connects to those of them that are LED strip controllers, and color-codes them.

3. The interface prompts the user for a photo of the system. The user takes a photo with their smartphone and upload it for the system to analyze.

4. The photo is analyzed using OpenCV and available LED strands are identified and numbered. Each config-ready strip color is unique, and the start and end of each strip are color coded, so OpenCV will find and identify each of the strands.

5. User sets up each pattern in an editor provided by the web interface, and can arrange patterns relative to each other. A nice-to-have here is a timeline view. Patterns are updated in real time.

6. A set of patterns is saved and user can decide if they want to run this set once or many times, i.e. indefinitely, or can leave them in system memory and proceed to creating a new pattern.

A word of explanation about the config mode of the LED strips. After entering config mode, the controller tries to find any new LED strip controllers asks each of them to use a specific pattern. Because of this, the shape of each strip is visible (they're all on, with full brightness), each has an unique color and the first and last two pixels are colored differently, so that a computer vision algorithm can uniquely identify them and find their starts and ends so that it knows which way the pixels should go. This image is then processed into a simple responsive vector interface for altering the color of each strip. Light intensity and individual pixels' properties can also be controlled with the tools provided by the interface.

Pattern editor

I'll illustrate my idea with the following mockup (thanks to lovely Ninjamock that I have just discovered):

This mockup assumes that I have hung my LEDs in this arbitrary pattern consisting of 4 strips. Then I used my smartphone to access the Beagle Bone's web interface, asked to reconfigure the system, took a photo of what it looked like in config mode (color-coded strips, see above) and uploaded the photo for OpenCV to chew on it and spit out the simplified version that is there in the mockup. Now I select one of the strips and choose a predefined pattern to get a screen that looks like this:

The editor allows us to set up all parameters that a particular pattern needs - here it's quite self-explanatory, as we chose a striped pattern with the stripes moving downwards over time, 15 times the default speed. Naturally, the LED controller doesn't have any idea of 'up' or 'down' (and we could easily make the strip into a coil or something), but it knows where it starts and ends, giving us control over the pattern's direction - hence the tiny arrow on the mockup.

The patterns are meant to be dynamically updated as we play with them, so that we can see them in the lighting system. After we're done tweaking, we just exit the website, as the patterns are dynamically saved in the system. This is just the tip of the iceberg - my aim is to provide at least several fully customizable patterns to choose from, each with its own host of settings. Another tempting option is to provide the possibility to break up a strip into sections of different patterns and to switch patterns over time. One feature that I consider a must-have is working with strips of different lengths - the length will probably be stored at EEPROM of the Arduino in the strip controller.

Possible difficulties

1. I expect difficulties at several stages of creating the web interface for the LED Animator - I demand quite a lot from my interface. If this becomes a major obstacle I might switch to an Android app, or take away a few features and come back to them later.

2. OpenCV may have difficulty recognising shapes in nontrivial surroundings. Simpler ones will have to be used then for the first version of the system. This will be enough to hold a demo.

Questions, nice-to-haves, expansion capabilities

1. What if the lighting system can't be captured with a single photo? - The basic version of Universal LED Animator will only support a single picture capturing the whole scene, but it could be easily expanded in the future to include analysis of more photos in config mode.

2. How do I store the animation patterns after the user creates them? I have several concepts for that, and practical tests over the next few weeks should bring the answers.

3. Timeline view for the pattern editor.

4. More patterns!

5. Splitting strips into sections in the editor.

6. Freehand mode (i.e. creating custom patterns) in the editor.

7. Powering the LED strip off batteries.

That's all in this short intro. I assume that more feature ideas will cross my mind as I develop this project, and some must-haves might not turn out to be so very neccessary... As it often happens in development hell. Anyway, let's hope for the best!