Bubble Display
March 2011

Introduction

Bubble Display:
A display utilizing air bubbles rising in fluid as pixels. Control of the bubble streams is used to produce text and simple images. The bubble display is an innovative, interactive artistic display medium for conveying many types of messages.

This group project was completed by the team Jon Bennett, Sahinaz Safari, and Gouting (Jane) Chang. This was our engineering fourth-year design project for electrical engineering at the University of Waterloo. The project was started in our third year (Fall 2008) and demonstrated to the public in March 2010, shortly before our graduation.

Inspiration for this idea came after seeing the Liquid Display project on Hack A Day. I thought it would be fun to have greater control over the bubbles and use them to make patterns.

Modes of operation:
1) Demo Reel - a pattern of bitmap images that is shown on the display
2) Bubble Symphony - midi keyboard input with each note corresponding with a bubble column (a note held creates a large bubble)
3) User Input - user can enter text or draw a pattern and have it shown on the display

Our project used 24 valves spaced 4.7 cm apart. I'm pleased with what we were able to accomplish and it was a big hit at the fourth-year project symposium. Some lessons learned: oil and glycerin are really messy, pneumatics are really expensive, and tanks are very difficult to construct and seal!

We started this project without really knowing what we were getting ourselves into. As electrical engineers, we knew the software and control hardware would be no problem. However, there were many questions that we needed to answer.
- What kind of tank material?
- What kind of liquid?
- What type of valve to use?
- What air pressure to use?
- Can we make the bubbles consistent?
- How do we stop liquid from flowing into the pneumatics?
- Etc.

All of these issues were eventually solved, mostly by trial-and-error.

This is not meant to be a how-to guide. This is meant to be a project description to inspire and share knowledge.

Hardware

Prototyping
Given the number of unknowns with this project, we started prototyping as soon as we had decided on this idea. We built a small test tank and found mouse valves from Clippard that we thought might be a good choice. We later decided against them. We used our small tank to evaluate different valve types, liquid types, and valve spacing. See the sections below for more details on the component selection. This prototyping phase was very important so that we didn't make any decisions that would be hard or expensive to fix later.

With the prototype tank we determined timing between bubble rows, saw how bubbles affected each other, how the viscosity of the liquid affected the bubble rise rate, and other variables that you can't look up on a datasheet. Note how the bubbles are semi-circular using mineral oil (2nd image), but round with glycerin (4th image).

Tank
The tank was the most frustrating and time-consuming part of this project. It was constructed of 1/4" lexan and held about 29 litres of liquid. The thickness of the sheets required is primarily determined by the height of the tank. Various aquarium-building websites recommend 3/4 - 1" for a tank of this height. We used 1/4" and ran in to a lot of problems. Thick lexan is expensive, so we didn't buy it. Also, we figured that since our tank was so skinny, we wouldn't face the same issues that aquarium builders did. Big mistake! The tank was put together using WeldOn 16.

The first time the tank was filled, it was filled to 29 L before a seam burst, dumping 29 L of water in to my basement! After that, all tank-related testing was done in a garage. We spent countless hours trying to stop small leaks with caulking and putting over 80 bolts all around the frame to try and squeeze the tank seams together. Before the project was over, we had completely rebuilt the tank by cutting off the bottom and making a new one, and installing a verticle bar down the center, effectively creating two tanks. After these measures had been taken, the tank was leak-proof and was filled with liquid for months with no problems.

Channels

I had wanted to have the bubbles float freely in the tank. This is a pleasing effect. However, after much testing, the bubbles affected each other far too much with our spacing of 4.7 cm. With spacing this small, bubbles 'pushed' against each other and drifted into voids if there was no bubble beside it. We found that if we used every-other valve, effectively halving our resolution, but then having spacing of 9.4 cm, we didn't have this issue. Our final solution was to construct a set of channels using 1/16" lexan. This prevented the bubbles form affecting each other.

Frame

The frame was constructed of 1" steel tubing and 1/8" angle-iron. The welding and frame construction was done for us by Rob in the engineering machine shop. The frame worked really well and didn't give us any problems. It was later painted gold using metalic spray paint.

Liquid Tests

Our tank required about 29 L to fill. I would like to thank Xenex Labs for donating 40 L of glycerine for our project.

Pneumatics

The pneumatics were an expensive part of this project. Each valve was about $30 (x24), each manifold about $35 (x4), each accumulator $25 (x4), each check-valve $6 (x24), each fitting $1-2 (x196), etc. This isn't including the regulators, gauges, filters, and tubing required! Also, we evaluated 3 sets of valves and each set of valves for evaluation cost about $200 to try out.

System Overview

We had a compressor hooked up to a filter-regulator. That bumped the 115 PSI from the compressor to about 12 PSI used in the rest of the system. The filter-regulator fed 4 manifolds. Each manifold had 6 valves attached. Each manifold also had an accumulator to smooth out the pressure changes when we 'fired' the valves.

Compressor

We used a Campbell Hausfeld (FP209499AV) tool air compressor purchased at Home Depot for $90 on sale. It could store 3 gallons of air at 115 PSI. This would run last our display for about 30 minutes if it was in constant use. It was very noisy when charging! During our public demostration we borrowed an air compressor with more capacity.

Valves

We evaluated three sets of valves as shown below. The parameters we tested were the minimum pressure that we could use the valve at, the minimum timing we could use to use the valve, and how consistent the valves were over time. The Festo and Parker valves performed roughly the same and both out-performed the Clippard valves. If I were to do it over again, I would use even smaller valves than the ones we used. We didn't want to operate them at the absolute edge of their operating capabilities. We ended up operating them at 12 PSI and with pulses around 10-20 ms in length which was above each of the valves' minimum stated response times. Each valve had a power consumption of around 0.6 W, but this was negligable since we were only turning them on for a very short period of time.

The valves were quite inconsistent amongst themselves. For example, we had to turn 1 valve on for 20.5mS and another for 32.5mS to get the bubbles produced from them to be consistent! The software had to be written to allow for per-channel timing configuration to deal with these inconsistencies. These configuration parameters were stored in config.txt and was used by the control software.

I would like to thank Parker for supporting our project by donating 6 (of 24) valves as well as some pneumatic components.

Check Valves

We knew that we had to stop the liquid from flowing out of the tank and into the pneumatics system. This was accomplished with a check-valve. A check-valve is a valve that allows fluid/air only in one direction. So air was allowed to pass through the check-valve, but fluid was not able to return in the other direction. We wanted to screw the check-valves right in to the bottom of the tank. The only check-valves we could find with male threading were MCV-1AB from Clippard. They worked well for us.

List of all Pneumatic Components Used

Control System(s)

We built two control systems for this project. We figured that millisecond control resolution would be sufficient to match the valves (since the valves themselves are inherintly inconsistent). However, after extensive testing we found that 50 microsecond timing resolution was required. Our first control system couldn't perform at that speed, so a second had to be constructed. Both systems were designed in Eagle and the PCB was fabricated by BatchPCB. Power was supplied using the 5 V and 12 V rails of a PC power supply.

First System

The board was built to support up to 64 outputs. Each output had an LED. It was a simple design of several I/O expanders on an I2C bus. Each I/O expander output was connected to a darlington transistor array (ULN2803A IC) The bus would be driven using an Arduino microcontroller. The board was designed and built with millisecond timing resolution in mind. The Arduino wasn't able to drive the I2C bus fast enough for 50 microsecond timing resolution on the outputs that we later required.

Second System

By the time we realized that we needed 50 microsecond timing resolution on the outputs, we had scaled our initial (ambitious) design from 64 valves to 24. With this lower output count, we could use the microcontroller output pins directly. We selected a PIC18F4455 because it had enough outputs and could be clocked at a high frequency. For future reference, a PIC @ 48 MHz is performing 12 MIPS (1 instruction per 4 clock cycles), however an Atmel microcontroller will perform 1 instruction per clock cycle, so an Atmel might be a better choice if performance is an issue.

I was able to simulate the microcontroller code in MPLab and verify that we had less than 50 microsecond timing resolution on the outputs (source code available below).

This board was connected to the computer by a serial port and the system worked quite well. This board has an LED for each output and you can see the outputs being turned on/off as the midi keyboard is being played in the video at the top of this article.

Software

The software is what ties the whole system together and makes it usable. There are 4 pieces of software involved in this project. There is a visual basic GUI program that is used to set which mode of operation the display is in and also to send user-generated text and images to the pixel decoder software. The pixel decoder software decodes bitmap images and also accepts pixel data from the visual baisc GUI. It handles the per-channel timing configuration and sends data to the hardware control system over a serial port. The midi decoder software decodes midi data from an attached midi piano keyboard and sends the data to the hardware control system. Each note is mapped to a bubble column, so that the keyboard can be played and that will create a "bubble sympthony". The last piece of software is the microcontroller firmware that accepts control commands from the PC serial port and turns the microcontroller outputs on for a very specific period of time (with 50 microsecond timing resolution).

This software is only provided as an example so that you can see how the system operated. It would be foolish for anyone to try and duplicate our exact system, so please don't try! The software provided is meant to be educational, but not instructional.

Visual Basic GUI

This software was literally completed at about 2 AM the night before our public design symposium. To communicate between the 3 pieces of software running on the PC (written in VB, C, and C++), I had wanted to use environment variables. However, VB6 has no way to set environment variables, it can only read them. The hack I implemented to make the system work was that the visual basic GUI would create text files and the other software programs would poll, looking for the command data in that text file. It wasn't the prettiest approach, but it worked pretty well as far as the end user was concerned.

With this control software, the use was able to enter text or draw a pattern and send it to the display, or turn it to "Keyboard Input" mode and use the midi piano keyboard to control the bubble display.

Source code: included in zip below

Pixel Decoder

This software decoded a black and white bitmap image file and sent it to the display. It also read data from a text file (generated by the VB software) with pixel data in it that the user had drawn, and sent that to the display using the PC serial port. The image we used for our demo loop is shown below. This software was written in C++ using the Dev-Cpp Windows IDE.

Below are 2 sets of demo images that we ran on the display.

Source code: included in zip below

Midimon (Midi Decoder)

I found an open-source set of midi utilites that were really easy to use and modify. I used the midimon utility and modified it to map each midi note to a bubble column and send the data to the microcontroller using the PC serial port. Open source software is great! Many thanks to Div's Midi Utilities for providing the midi portion of this software.

Source code: included in zip below

Microcontroller Firmware (for PIC18F4455)

This software is written in C using the HI-TECH C compiler. It read in an array of pixel data. Each pixel data value specifies how long the valve should be turned on for (with 50 microsecond resolution). When the next row of data is required, the microcontroller sends an ACK character to request more data. The data is provided by either the midi decoder or the pixel decoder, depending on the mode of operation specified using the VB GUI. A note about efficiency: a significantly higher timing resolution could have been obtained by sorting the pixel data array on the PC before sending it. However, our performance targets were met, so that was not required.

Source code: 4455.c (also included in zip below)

Download All (221 kB)

Project Costs and Conclusion

Between the multiple prototype revisions, expensive pneuamtics, multiple control systems built, and a myriad of other problems, we spent quite a bit of money on this project. The total bill was about $3500 CAD, $1796 of which was reimbursed by our school.

I had wanted to take on an ambitious project that had a large visual impact and I think we succeeded in that. I wouldn't mind building another bubble display sometime in the future, having learned many lessons from this one. It was an interesting project, but I would caution anyone considering to take ona similar project -- there are many unforseen complications that you will face!

If you liked the project or write-up, add a comment below or send me an e-mail at .