The Bitble | Final Project Documentation

How I Came Up With The Bitble?

For the final project, I started off by experimenting with digitally blowing bubbles using a sensor that can detect wind coming off from user’s mouth. However, as I realized that was not enough to call it a good project, I began my journey to find a narrative for it. 

One day, I came across the news of Bitcoin and how its associated bubble has already burst. In a moment of great realization, I decided that I could combine the two idea together into an interactive installation, which was later named as: The Bitble 

What Exactly is The Bitble?

There is a physical structure similar to the bubble blower that uses soap. A sound sensor is mount to the blower to detect wind coming from the user (including the intensity and duration). The sensor is connected to Arduino and Arduino will then send data to Processing, which will start to draw bubbles on the screen when the user starts blowing.

There is a line graph representing the “price” on the screen, if the user keeps on blowing to the blower, the graph will keep increasing. If the user stops, it will start to decrease. The catch is that if the “price” reaches 0, all of the bubbles will burst which means that the user goes bankrupt. The higher the price, the harder it is for the user to increase the price further, also the higher the rate at which the price will decrease.

How it should look like from my conceptualization

How The Bitble was Put Together

For the visual part, The Bitble primarily consists of 3 main components: 

  • Bubble class: has some properties such as size, color, lifespan, speed (in x-axis and y-axis)…
  • Game class: controls everything else in the game, draws the main screen, draws the story line, stores the bubbles themselves, as well as keeps track of scores and displays them
  • The price graph: displays a line chart of the history of the price of the coin, with the current price displayed in number above the line chart

Implementing the bubble class was straight-forward as I already did something quite similar for a previous example.

The early stage of The Bitble

However, I wanted to use real images to make the bubble look as nice as possible. Also, I wanted to have the animation of bubble bursting. Therefore, I searched the Internet and got a series of bubble-bursting image and played them back-to-back to create the animated effect. However, as the images are more complex and there are so many of them floating on the screen, the performance did suffer a lot.

What it looks like when the default render is used. One word: laggy

I had to come up with a solution!

Later, I stumbled upon the P2D render, which would draw everything on an off-screen buffer and then display it on the screen, which would supposedly sacrifice some quality in favor of better performance. Luckily, when I changed everything to the P2D render, the quality did not decrease by a lot but the performance did receive a HUGE boost.

I then also added a changing color background to illustrate the state of coin: green for increasing and red for decreasing.

The drawing of the line chart was a little bit trickier. I had to draw it using another canvas (that is different from the canvas used to draw the bubbles, the horizontal bars, the background, and the price value – everything that had to be updated every single frame). I did not clear the background of this canvas so as to leverage the fact that if I constantly map the value of the price on the y-axis by using individual points (the x-axis is time, which increases throughout the game), I could replicate the effect of drawing the entire line chart, without having to store the historical data of the price to re-draw them every time the background is wiped.

The result can be seen as below:

So this is what it looks like in the end! Pretty smooth and aesthetic

Below is the Processing code:

 

The hardware of this installation was the simpler component: it consisted of only a sound detector mounted to a physical structure that resembles a bubble blower. The Arduino was then placed in an enclosed to ensure structural stability and general anesthetics.

The schematics
The Arduino and the prototyping shield as seen inside the enclosed case
The bubble blower was designed by using TinkerCAD and then 3D-printed: I learned a new skill making this project, yay!

Before settling down on the sound detector, I used to fiddle with the barometric sensor and the humidity sensor, which relied on the Bernoulli effect of moving air and the higher relative humidity coming from user’s mouths, respectively. However, neither of them proved to be fast and responsive enough to capture the exact moment the user start and stop blowing.

Below is the Arduino code, whose job is to measure the intensity of the sound coming from the sound detector and write it into the Serial from which Processing reads data: 

 

Final Thoughts

All in all, I was satisfied with the project, its technical details and complexity, its final look, and most importantly, how people interacted with it. A lot of people were amused by the “revelation moment” when they found out about the connection between the bubbles and Bitcoin of the project. Making the installation into some sorts of a game also enhanced people’s interaction and engagement with it. I saw some people who kept returning to try to beat the high score (but failed :l) (and clearly, people can get really competitive). 

Some were distracted during the introduction narrative of the project, which I had anticipated before due to the high-energy atmosphere and presence of other projects at the showcase. Though I tried to shorten it up, I still had to keep the core ideas that served to inform people of the purpose and context of the project. Maybe, in the future, I can try to re-position the narrative so that it will be at the end of the game as a de-brief to retain people attention and interest.

Below are some more pictures of the project at the IM Show:

User Testing – The Bitble

I had three classmates (Estelle, Jungsoo, and Manas) test my project:

https://drive.google.com/open?id=1JyDDYHRWsTNZtVYXHl2pOIuiBq4bsZAQ

They gave me some valuable feedback on how I can potentially improve my project:

  • The storyline about the Bitcoin should be made shorter as it was too long
  • The animation overall also should be made shorter
  • The difficulty of the game should be raised so that it can be more challenging as well as to make sure that the graph won’t jump out of the screen boundary
  • Maybe I should have a reward for those who achieve a highscore?

On Computer Vision

Reading the paper actually reminded me of the tracking project I did last year which used the Kinect to find the outline of the person in the frame. Reading the paper helped me understand more about the mechanism of it and shed light on how complicated and resource-intensive it would have been if we had been in the 1950s. Since then, we have come a long way on image processing and computer vision to easily reproduced it with little engineering/computer science background.

The paper also made a definitive assertion of the trickle-down effect that results in the passing down of computer vision technology often used in highly-expensive and prioritized environments to that of the interactive media domain. Interestingly enough, this phenomenon can also be broadly applied to most of the technology we see in interactive media nowadays. As a result, from the case of computer vision, we can expect to see more applications of high-end technology into our daily, artistic lives in the future.

Bitble | Update

Brief Summary

There will be a physical structure similar to the bubble blower. Bubbles will be drawn on the screen when the user starts blowing into the blower. There will be a line graph representing the “price” on the screen, if the user keeps on blowing to the blower (keep on producing more bubbles), the graph will keep increasing. If the user stops, it will start to decrease. The catch is that if the “price” reaches 0, all of the bubbles will burst, game over!

I can also consider adding another player to the game to increase the competitiveness; but I have to perfect the project for one person first.

Technical Details

  • I have worked with the barometric sensor to detect the wind from user blowing; however, when connecting it to the Processing sketch, the delay is rather noticeable.
  • For the Processing sketch, I have created a bubble class to draw the bubbles. However, as the number of bubble increases, the sketch slows down considerably (which is no surprise to me as I already anticipated this before). I have to come up with a better way to develop the code.
  • Below is the Arduino code, which is pretty straight-forward:

  •  

Some More Challenging Steps

  • Finding out another way to display the bubbles so that the performance won’t suffer as well as find images of real bubbles to put in the sketch.
  • Animation and sound for the popping bubbles!
  • Maybe try another approach to the barometric sensor (which is quite delayed)? Maybe I should use a microphone instead? I will try to prototype this first. Last time I asked Jack, he showed me a microphone but it was too big/ugly for this project. I went on the Internet and did some research and came upon this, which I think I have seen it around in the lab:Image result for arduino microphone amplifier
  • I still haven’t designed the physical bubble blower as I haven’t settled on the sensor yet. I will try to get the design done well and work well. It shouldn’t be too big, just enough space to mount the sensor on and to hide the wires. I haven’t come up with a material for the handle of the blower yet, but I’m pretty sure that I will use the laser-cut acrylic to mount the sensor on.

Bitble | Final Project Idea

Prelude

Yes, if you’re reading this, I have already failed my previous final project idea.

It was a tad too ambitious I admit, which wouldn’t have been a problem if I didn’t have a ton of projects and finals for the other classes. I was late to realize that. However, it’s still not to late for me to come up with another simpler idea for my final project. And here it is: introducing the Bitble.

In case it’s not yet clear, Bitble is a combination of Bitcoin and Bubble. As I was tinkering with the idea of making a digital bubble blower, I came across the news of bitcoin bubble busting all over places, “Why don’t I combine the two together?”, I asked myself. Bitble was born that way.

How it works

There will be a physical structure similar to the bubble blower that uses soap; however, no soap will be used in this project. Instead, a sensor will be mount to the blower to detect wind coming from the user (including the intensity and duration). The sensor is connected to Arduino and Arduino will then send data to Processing, which will start to draw bubbles on the screen when the user starts blowing.

There will be a line graph representing the “price” on the screen, if the user keeps on blowing to the blower, the graph will keep increasing. If the user stops, it will start to decrease. The catch is that if the “price” reaches 0, all of the bubbles will burst, representing the situation of the Bitcoin right now (although its price has not reached 0 quite yet, but let’s make it more dramatic that way). The higher the price, the faster the price will decrease, thus making it harder for the user to keep the bubbles from busting.

Challenges

  • How to make a functional bubble blower with a sensor mounted on it. It will probably be made out of acrylic by using the laser-cutter. It also has to be durable so that it won’t break in the middle of the installation. I have tried using the barometric sensor to detect the wind and it works! (Based on the Bernoulli effect)
  • How to draw the bubbles so that they looks beautiful and real as the same time (Aesthetic things work better!) as well as the effect of winds and gravity! Also, how to create the effect of bubble bursting is also one of the difficult challenge.
  • How to develop an algorithm that uses the data from the sensor as an input to calculate the size of the bubbles and how many of them should move out of the blower in a second
  • How to optimize the drawing so that performance won’t suffer. As the bubbles are probably much more complicated to draw than plain particles, I expect them (and the increasing number of them) to affect the performance of Processing at some point. I have to make a sacrifice between performance and aesthetics.

 

On Digitize Everything

After reading the piece, I realize that although it is easy to digitize and replicate information on the Internet, not everyone succeeds at combing those data together in a meaningful way that delivers users with new way of interacting with and using information. Those who succeed, like Waze, Google Maps, and Wikipedia, are continuously showing the world their gargantuan impact on how we use use our data and how we decide to share our digitized self to the world.
The Internet is not only a place to collect, share, and make use of digitized information to make a profit but also a place for people to express their thoughts, interests and share their ideas without any anticipation to receive money from digitizing their brainchild. However, much as we want to separate these two motives from collapsing onto each other, more and more big corporations are exploiting our shared data to maximize their profit by re-selling them to other companies or targeting a specific group of people for advertisements and price discrimination. Therefore, as the new dawn of digital era is unveiling itself, we should always think twice before digitizing our own personal self on the Internet where everyone can replicate or re-purpose our information.

Response to “Design Meets Disability”

I especially love his juxtaposition between design and disability: mainstream design can have a trickle-down effect and thus makes advanced technology more readily-available for the disabled while at the same time design made for the disabled can potentially influence the mainstream design culture itself. This is further backed by his example of the glasses that we know of today: being both a prescribed medical tool and a fashion icon. Thus, we need not to separate general design and design that is specific to a certain group of people as both of them can interact and influence one another, often time result in a fusion between the two.

It is interesting, however, to see the opposite trend happens to hearing-aid devices which has become smaller and smaller overtime. This is intended to hide, or to conceal, the presence of such device worn by disabled people. Perhaps, fewer people need hearing-aid devices and thus have not created enough attention and change of attitude from the manufactures, the designers, the public, and the influencers to normalize it as being just another garment like glasses. Therefore, we can also see that it is necessary for integration and collaboration among different fields to create such design that simultaneously cater to the needs of the public as well as disabled people.

Arms-Waving Robot with Potentiometers

By using 2 potentimeters as seen in the photo and the arms-waving robots examples in Processing, I was able to combine them together to use the potentiometers to control the waving animation of the robot. For the communication between Arduino and Processing, this time, I choose to implement the Comma Separated Values method mentioned in the previous class. This proved to be very straight-forward to use; furthermore, more potentiometers can be easily added to the code in the future (if we also want to control the legs of the robot)

Below is the Arduino and Processing codes of the Arms-Waving Robot controlled by 2 potentiometers:

 

Let’s Tile It Up

Image result for piano tiles

Inspired by the smartphone game “Piano Tiles” where players have to quickly and accurately touch constantly-moving piano tiles to win, I tried to re-create the game using Processing and Arduino. To implement a new way of playing the game, I use 4 different photoresistor sensors to detect whether or not the hands of the players hover above the sensors (as an alternative way to touching the screen/button).

How the Game Actually Looks Like

Tile can be played in 2 different modes: with keyboard or with hover sensor (my fancier way to call the photoresistor sensors).

  • With keyboard (chosen by pressing LEFT ARROW at the main screen): by pressing A, S, D, or F on the keyboard, which from left to right respectively correspond to the 4 column of tiles on the game screen
  • With hover sensor (RIGHT ARROW): by hovering around 5cm above the four sensors, which also correspond to the 4 column of tiles on the game screen

As the tiles start to traverse down the screen, players have to quickly and accurately  destroy the tiles by pressing/hovering above the tile that it currently closest to the bottom of the screen. This will changes the color of the tile into red which indicate that this is the right tile to destroy. The amount of time the player have to hold on for each tile until it is destroyed (and only then can the players destroy the next tile) depends on how long the tile is (a tile can be anywhere between 1 or 5 length units).

If the players can’t successfully destroy a tile, after it has disappeared beyond the bottom of the screen, the players can then attempt to destroy the next one still on the game screen.

Each game has a limited amount of time. After the time runs out, Tile will display how many points the player have earned, accompanied by a high score list. By pressing Enter at the Game Over screen, the players can replay another round to try to beat their old scores.

Here is a video of Tile:

 

 

Here is how the array of the 4 photoresistor sensors look like. 

Here is the schematic of the project, consisting of 1 Arduino Uno, 4 photoresistor sensors, 4 10kΩ-resistors, and some jump wires

Code

Processing Code

Arduino Code

 

Difficulties

I did not use the ultrasonic distance sensor because using 4 of them (facing the same direction) proved to be troublesome as one’s echo sound beam would interfere with others’ echo reading. It took me a while to realize this.

Tile was probably the most difficult project I have ever done so far apart from the midterm project. The code for the actual game and the checking of winning/losing conditions proved to be very complicated when I actually tried to implement them. I realized that having the right mental model when developing a project is crucial to timely and successfully complete the project as Michael mentioned in class. As I progressed along the project, I had to change my mental model several times as well as re-think and re-develop how some of the elements of the game would be implemented without sacrificing the main value/characteristics of the game.

Along the way, I also learned that in order for Processing to recognize key input, the window has to be focus first (by mouse clicking on the windows when initializing) or else it will not register any key press coming from the user. Besides, ArrayList is very good at storing, assessing, adding, and removing information (different object in this case).

When some of my friends tried playing the game, I also realized one more limitation of the game which is that it does not allow the input of more than one press/hover at the same time. However, getting that to work in the code would be much harder than the code I already developed here. This could potentially be an idea for future improvement.

Rotating and Traversing Lines

Inspired by the harmonious alteration of the “wave” in this piece, I decided to create a artwork that involves lines that can not only rotate about an imaginary point on their own but can also traverse from one place to another.

I decided to randomize the gradient of the different lines but to keep them on the gray-scale to recreate the old black-and-white look to the artwork.

The number of lines onscreen can be easily adjusted as the code is made for object-oriented programming language.

Below is the code of the artwork: