Smart Trash – Physical Computing Final

Katie and I worked together on this project as our Physical Computing Final.

This project started as an attempt to apply what we had learned in our physical computing class to street furniture. Both Katie and I are fairly urban oriented (natives of Detroit and NYC respectively) and were eager to connect our new ITP knowledge with our prior interests.  The trash can emerged as our point of focus since its probably the most ubiquitous form of street furniture and one of the least interactive. Over the course of this project I think we learned valuable lessons in terms of our approach to interactive work and completing physical projects in general.



Once we had selected the trash can as object of interest we spent some time looking at different types of cans, reccent ideas in this area and doing some field research.


We reached a number of important conclusions about trash behaviors:

  • Many people do not want to hold onto “garbage” for an extended period of time
  • Many people do not want to litter
  • Many people do not want to touch a public trash can and will avoid doing so even if it means littering
  • Many people would like to recycle but are frustrated by the lack of trash differentiation

These user behaviors work together to produce some strange results :

One of the most technological trash cans in wide spread use is the Big Belly solar compactor. The advantage with these cans is that they are self contained (self powered), aware of how full they are,  relatively easy to clean out, and most importantly they compact the garbage as the can fills. This decreases both the number of trash receptacles required for a given area and the frequency at which they need to be cleaned out. This saves a lot of time and money for any agency that is responsible for keeping streets clean. The glaring failure of the Big Belly trash cans in our opinion and (others) is that they require the user to grab a handle to open and close a little door to deposit their trash. As a result in this has become a fairly common scene in NYC neighborhoods where these have been deployed: 

(Thanks to Jordan Frand)

In addition to user behavior we also identified a number of other key points about street trash:

  • Geography is important – E.g. trash receptacles near a fast food restaurant will overflow with trash related to that business while an empty can might be down the street
  • Collection is the primary concern – Getting people to recycle or put their trash in the trash can doesn’t matter if theres no one to pick it up and deal with it.
  • Cost and durability – Street furniture needs to be durable and affordable on a large scale

Based on these findings we came up with a few directions for improvement.  We wanted to have the can open and close as a way to better contain the garbage inside of it, to protect from wind and rain, and to indicate if the can was full. We knew we wanted this opening and closing to be hands free and to be interesting/entertaining for people so that they thought more about their interaction with the garbage can. We wanted to build a system where additional components could be attached easily depending on the needs for that specific geography. One example of this in action was made by Sandra Hoj out of a tube for used coffee cups.

We also wanted this “system” to sit ontop of existing garbage cans in NYC. In reviewing the types of trash cans suitable for street use we discovered that the common light metal mesh cans cost around $100-250 while heavier cans that don’t fall over as easily can cost up to $850. We thought that this gave us an interesting opportunity to create a product that attached to the lighter, more easily moved and cleaned models that would make the total cost less than a heavier model. Lastly in followup conversations with Tom Igoe, our professor, we thought that data collection would be an important goal as well. Measuring the weight and volume of garbage would give us a diagnostic tool that could be used to determine what attachments or design changes worked and didn’t work.



In developing our product we had to repeatedly revise, scale back, and pivot in many areas. Our final product ended up being very different from what we set out to do but going from concept to creation was definitely educational. We initially focused on developing the lid and opening mechanism that we thought would serve as the base for our motor, sensors, and other attachments. As we thought about opening and closing mechanisms we wanted something that was visually interesting but also quick enough to prevent garbage from spilling out if the can was knocked over. Ultimately we landed on trying to produce an iris diaphragm. Our first attempts at building an Iris were promising but as we scaled up we ran into a constant stream of problems.


Our first Iris


We made over four different Iris’ with a ton of help from our classmate Franklin using different materials and designs but each of them failed for one reason or another (sources we used for Iris design 1,2,3) . With certain designs the issue seemed to be materials but then it would be hardware or problems with the gears for the motor. Honestly, I don’t really know why we had so much trouble with the Iris but I suspect that the designs we were using didn’t scale up to the size we needed it to be with our level of precision. Lacking a base to build the rest of our trash system and the time it took to build each Iris sent us scrambling. While we had most of the electronics laid out and programed not having anything to attach them to left us at dead end. (Video of electronics coming)

Using what we had available we built a different type of closure and built a box around our prototype trash can to act as the housing for the electronics.

Due to our time crunch we primarily focused on the opening and closing interaction. We had the lid slide open using a stepper motor, stop, determine if their was still motion happening in the view a motion sensor, and if not close again. In addition to this we used a trio of FSR sensors on the bottom of the can to detect changes in weight. If the can detected that something had been placed inside it would let out a short three tone sound to let the user know that their contribution was welcomed. Lastly we had a trip ball sensor that would disable the opening and closing response if the can was not right side up. Here is a video of the final product in action (SmarTrash).

While I certainly would have preferred to build something closer to our original concept I am grateful for the experience I gained in this attempt and and happy with the final product as a demonstration of the skills I’ve acquired in physical computing and elsewhere at ITP this semester.

Read More

Final Idea Don’t Honk Street Sign – PComp #8

In thinking about my PComp final I’ve come up with an idea for a honk detecting street sign. The goal of this sign would be two fold: to collect data on honking at various intersections, and then to discourage unnecessary honking by providing a visual reaction to individual honks and longer term trends. I came to this idea while listening to the amazing amount of honking that takes place outside my window on the Queensboro bridge. The prototypical bystander reaction to the frustration of incessant honking is to scream obscenities out of your window. I totally get this urge. However as a means of changing the behavior of drivers its almost completely ineffective. I take this as a sign of an unmet need; people want to communicate the frustration of living around a honk ridden intersection to the individual drivers who are presumably just passing through with little awareness to the plight of nearby residents. My hope is that this sign can communicate the collective feeling of neighborhood residents to the individual driver who isn’t aware of the compounding effect of their honking. I believe that such a sign will be effective because in my time spent listening to honking cars (against my will) I have learned that the decision to honk is highly informed by social dynamics.

Often honking will happen in clusters, as one particularly hurried or irritable driver starts the chain reaction by removing the slight stigma that exists. Eventually others will follow suit as if to signal agreement in their displeasure with sitting in traffic. In extreme cases when certain drivers feel their honks are being ignored (something I find insane) they will honk out a tune or simply hold down the horn until their non-verbal demands are met. Since honking operates within some discernible social system, I think this system can be altered by injecting a sign of displeasure to honking. Hopefully the number of “first honkers” can be reduced as they see statistics on honking or a visual representation of how their honks make residents in the area feel. For the “ignored honkers” I hope they will feel some slight shame or guilt when they see how honky of a day its been already, ideally they’ll realize that NYC traffic does not operate according to the whims of the individual and that their attempts to honk their way out of traffic is a tried and failed method.

Screen Shot 2015-10-29 at 4.32.16 AM

Here is my digital mock up of how the physical sign could look and function.


Read More

Midterm – Sword Fight! | Pcomp #7

Ian (Yuan Gao) and I worked together to produce a sword fighting game with foam swords, digital sound effects, and a scoring mechanism for our PComp midterm. We had recently learned how to read the data from an accelerometer and how to serially communicate between the arduino and our laptops such that programming on the arduino can effect programming in p5.js and vica versa. We thought a sword fighting game would be a good application of these skills.

After consulting with Tom about our project he suggested we start out by visualizing the output of our accelerometers and using any patterns we noticed as a jumping off point for detecting sword motions like swings and hits. After a few attempts I put together a program in p5 that would graph the accelerometer data in a readable way, similar to what Tom had shown us. At the time we were hoping to use bluetooth communication so I set up bluetooth and attached the arduino to a battery as I tested my accelerometer graph.


As we studied (mostly played around) with the data output it became clear that acceleration isn’t always what it seems. Conceptually I understand acceleration as the rate of change of velocity. However, in practice I think I was expecting acceleration to act more like velocity or maybe “energy”. In addition, the constant acceleration due to gravity complicates the “movement” view of acceleration further. We looked into how to manage this data input and get it into a more usable state and we realized that in doing so we were entering the world of complicated math and physics lessons. One option in this regard was to calibrate the accelerometer to sense G force accurately. This would have made our measurements more accurate and legible but wouldn’t have necessarily helped us identify swings and hits. The other option we identified, and ultimately used, was to dive deeper into the meaning of acceleration and its derivatives. While we did research we discovered that a lot of people who work with accelerometers also work with the derivatives of the acceleration: Jerk and Jounce. Combining current accelerometer readings with the Jerk and Jounce allows you to determine points of inflection that could indicate the beginning of a swing, the end of a swing, a hit and other events. We ended up using a threshold value for jerk as the primary component of our swing detection, however it became very clear that it is possible to get accurate and distinct readings for a huge variety of motions depending on how much math and pattern recognition you are willing to do with acceleration, jerk and jounce. As a result, we spent a lot of time tweaking and experimenting with different values for each. In the end we included a lot of smoothing algorithms and this kind of threshold test for playing a sound:

function playbackChopSoundEffect(_jerk_vals, _jounce_vals, sample_ind) {
    if ((abs(_jerk_vals.x) >= _jerk_vals.max_x * 0.25 ||
    abs(_jerk_vals.y) >= _jerk_vals.max_y * 0.25 ||
    abs(_jerk_vals.z) >= _jerk_vals.max_z * 0.25) &&
   (abs(_jounce_vals.x) >= _jounce_vals.max_x * 0.33 ||
   abs(_jounce_vals.y) >= _jounce_vals.max_y * 0.33 ||
   abs(_jounce_vals.z) >= _jounce_vals.max_z * 0.33)) {
   if (random(1) > 0.5) swoosh_sounds[sample_ind].play();
   else swoosh_sounds[sample_ind + 2].play();

If we had more time for research we may have been able to rely completely on the accelerometer to detect all of the possible sword events however we settled on having the accelerometer control swing sounds and to use home made switches for hit detection (scoring) and to play a sound when two swords hit each other.

Attaching the accelerometer to the foam swords, building the p5.js sketch to detect and respond to the action and wiring this all up was tricky but took much less time than the calibration of the accelerometer. We wrapped each sword in tin foil and built companion targets (also wrapped in tin foil) to form switches when the opponents word makes contact with your sword or your target. The accelerometer was attached to a mini breadboard which we zip tied to each sword. Unfortunately we didn’t have time to make this wireless so each sword had a long trail of wires connecting them to the arduino. The sketch incorporated some fencing images and sounds that we found online (citation coming) as well as the score count for each player.


Screen Shot 2015-10-29 at 6.54.16 PM

I was happy with how this project turned out. Some problems were the lack of wireless which would have made the game more fun due to the increased freedom of movement and the relatively fragile nature of the swords and electronics we fabricated. I’m confident that with more time, resources, and guidance we could make this game fully wireless, self contained (wouldn’t require a PC connection for the sounds and scoring), and more durable.

Here’s a video of it in action:



Read More

Evil Peeps w/ External Game Controller (Serial Communication) | Pcomp #6

The task for week 6 was to “make a serial application that controls one of the animation projects you’ve done in intro to computational media with analog sensor data from an arduino, sent to the browser serially” so I decided to give my evil peep game I’ve been working on in ICM an external controller.

The evil peep game was relatively easy to adapt for an external controller. Origionally the Evil Peeps would appear at the pointer of the mouse on screen at an increasing rate. The challenge was to continue placing peeps without overlaps even as the time between new peeps and the available space on the screen were shrinking. To adapt it for an external controller I first copied in all of the serial communication set up (listing available ports, error checking, etc…)  that was made available to us in the serial communication Lab. Once I got the arduino and the sketch to communicate I added an if statement so that if the peeps game received a signal for a button press from the arduino it would look for all controls to come from that device and ignore the mouse. This allowed the game to be played either the standard way or with the game controller. The next step was to add the controls.

At this point measuring the output of a sensor and mapping it’s values is something I’ve gotten comfortable with so having the arduino read two potentiometers was straightforward. I assembled my arduino with one button input and two potentiometer inputs and stuffed it into a used milk carton.


I programed the arduino to serial write the value of each potentiometer and the button as a series of values, like this: “125,125,0” – This would indicate that both potentiometers are close to half their maximum resistance and that the button is not pressed. In p5 I read these values, split them up, mapped the range in values to the size of the screen, and stored each in an array. Once I had these values coming in reliably having them control the game was just a matter of replacing mouseX and mouseY as the basis for the peep locations with the mapped potentiometer values stored in the array. Controlling the game with the potentiometers made it significantly more difficult so I spent a lot of time adjusting the score and Peep timers until I got it to a playable format. In the end I was really happy with how it turned out and I think I’ve developed a much deeper appreciation for classic arcade games!


Evil Peeps With Controller


  • one issue I had was that after stuffing my arduino in the box the button became unreliable – the solution would have been to get a better button

Read More

Reading Response | Pcomp #5

The readings this week emphasized sketches and the design process. I was happy to see the repeated suggestion that you don’t have to be “good at drawing” to sketch because I am definitely not good at drawing and that gave me some confidence to do it anyway. It also occurred to me that a non-verbal way of communicating ideas would be helpful in general but paticularly at ITP given the number of international students and group projects. In addition, I really appreciated the concept of local hill climbing at the expense of the “global” maxima. I feel like I’ve already experienced this in some of my ICM work, where a particular problem was wasting a lot of time only to change course and produce similar functionality in a fraction of the time. — The second reading , by Tom Igoe, also dealt with the design process and essentially asked aspiring interactive artists to realize that a truly interactive concept can’t be completely defined or contained by it’s creator. Too explicit an interaction deprives the experience of discovery and a truly two way interaction. This lesson is taught to ITP students in many cases when they walk up to the screens displaying projects in the hallways. Outside of the end of semester shows most of these screens are unlabeled and up to the casual viewer to determine the “purpose” and decide for themselves what they are supposed to “get” from it.  It’s an interesting challenge to see what can be left unsaid and still be heard.


Buxton, Sketching User Experiences: The Workbook

IgoeMaking Interactive Art: Set the Stage, Then Shut Up and Listen

Read More

Sound and Movement | PComp #4

This week in Pcomp we looked into controlling sounds/speakers and servo motors with arduino. The first task in the lab was to control the pitch of a speaker depending on input from a variable resistor. I took the light meter I made last week and after some tweaking installed a speaker on the breadboard to provide an audio indicator along with the succession of lights. The pitch increases as the amount of light hitting the sensor increases. I was very surprised that the addition of the speaker only required a couple lines of code to be functional.

Video: Lightmeter + Audio

Screen Shot 2015-09-29 at 12.53.59 PM

The next task in the audio lab was to have the speaker play a melody. This required a library to be called in the Arduino IDE and the use of some arrays, which I don’t have much experience with. However I followed along with the lab closely and was able to get the melody playing on my arduino. The slight change I made from the lab was to assign different pins because I wanted to keep my light meter operational.

Video: Arduino melody

Screen Shot 2015-09-29 at 1.28.23 PM

And last up for the audio lab was to build an instrument. I had limited success here. I was able to get responsive tones from a few light sensors, however I also had a persistent buzzing tone that I couldn’t eliminate. I realized that part of this may be due to the fact that I am maintaining my light meter on the same board and that I may have unintentionally introduced some interference or error. I plan to attempt this again with a clean breadboard later this week.

Video: Arduino Instrument (Work in progress)


At this point I moved onto the servo lab and ended up successfully including a servo as another responsive element in my light meter.

Video: Arduino light meter + Sound + Servo

Screen Shot 2015-09-29 at 7.54.05 PM

I’ve been having a good time building around this light meter. I realize it’s fairly basic but I find it helpful to work with something thats somewhat familiar and somewhat new at the same time.

Read More

Lab + Photometer | PComp #3

The purpose of this lab was to get a sense for how to program analog and digital input/output with an Arduino.

Examples shown to us in class

I started with the digital input example where I was able to get two different colored LEDS to alternate based on a switch button. I realized halfway through that I had switched the LEDs from what was shown in the lab but it was easy enough to change the code and have it work properly either way.

Screen Shot 2015-09-21 at 6.58.17 PM

Video-Aurdino Alternating LEDs

Next I worked on the analog input lab which uses a potentiometer to effect a variable as the analog input and apply a range of power to an LED via the digital output. (a portion of the previous circuit was left on the board).

Screen Shot 2015-09-21 at 7.15.09 PM

Video – Arduino Variable LED


After completing these labs I decided to try to build a sort of photometer with some LEDs and a photosensor. My goal was to illuminate the LEDs in a sequence as the resistance of the photosensor changed. This meant reading an analog input and providing power to a series of LEDs via the digital out. The schematic I drew at the time looked like this:


I started using a potentiometer rather than the light sensor so that I could test the programming for the lights a series of precise levels.  After some trial and error with the programing I had it working roughly the way I wanted it to.

Screen Shot 2015-09-21 at 8.32.06 PM

Video – Arduino Indicator Light Photometer

The LEDs turn on and off in sequence as the resistance changed and when the range was maxed out they all flickered to indicate that it was as high as possible. Lastly I removed the potentiometer and replaced it with a photosensor and a 10 kohm pull down resistor. I recalibrated some of the levels so that the LEDS would generally represent a range of typical room brightness and felt happy with the results.

Video – Arduino Indicator Light Photometer (2)


Read More

Observation – POS system at The Container store | Pcomp #3


Pick a piece of interactive technology in public, used by multiple people. Write down your assumptions as to how it’s used, and describe the context in which it’s being used. Watch people use it, preferably without them knowing they’re being observed. Take notes on how they use it, what they do differently, what appear to be the difficulties, what appear to be the easiest parts. Record what takes the longest, what takes the least amount of time, and how long the whole transaction takes. Consider how the readings from Norman and Crawford reflect on what you see.


Customers wait in a line to enter a bank of registers. When a cashier is done with their previous customer they call another over (sometimes this requires raised voices and repetition). Once the customer arrives at the cashiers POS they ask the customer if they have a rewards card – most don’t and don’t want one. The costumer then begins to pile mostly large plastic containers onto the counter top as the cashier scans the barcodes with a scanner gun. Each item pops up onto the display facing the cashier and occasionally they require some form of verification or confirmation (I assume this is in the case of sales or other special circumstances). Throughout this process the cashier has to stop scanning and rearrange some of the items and bag them. Once they are done scanning they focus on bagging and let the customer know they can pay. This is the trickiest part because the variety of payment options require varying levels of interaction on both their part and the customers at the same time that the cashier is trying to bag up all of the purchased products (due to the complex and large items this is a more complicated and less repetitive task than at most retailers). Eventually all the products are bagged up and payment has been made.

Some of the cashiers vary this process by being more vocal than others – I saw one of the cashiers asking ahead of time how the customer intended to pay while others waited. Some of them would prepare bags or boxes ahead of time while others just waited between customers.

It makes sense that some of the cashiers started asking these kinds of questions (they may be told to) since a lot of time and attention is lost when things like the amount of bags you want, whether you have a rewards card, and how you intend to pay all effect the speed at which the cashier can check out customers. having to bag the products while transacting the purchases seems to make both tasks less efficient. It was clear that the easiest part of the interaction and the portion of the process that seems to be done with the most confidence is the scanning and product information retrieval.

Based on the readings from Norman and Crawford, on the whole I’d say the POS system is a good design for very general use. The method of inputing information, taps on the screen and the scanner gun, work quickly, accurately and are well suited for the task. The POS system is able to associate the barcodes with a large product database and tabulate the totals with discounts and other modifications. The machine is also fairly good at making its output clear and useful using the tough screen and the payment terminal. However, there is often confusion about when to swipe a credit card and the cashier has to do a lot of verification and reading off the screen to the customer which seems like it could be improved. In addition, these kinds of POS systems are fairly standard so most customers and employees have an idea of what to expect and how to use it. Customers know where to swipe and whether or not the payment went through and most of the points of friction seem related to additional programs the store has imposed such as the rewards card. That being said I think there is a lot of room for improvement, particularly before the customers reach the machines themselves. I think that If customers were sorted before reaching the register cashiers would be able to check people out faster and the interaction with the POS system would be more predictable and intuitive for both the customer and employee. As the customers are online they should be asked if they have a rewards card and what method of payment they intend to use. In addition customers with complaints, pricing questions, and other miscellaneous issues should be sorted out of line so that they don’t have to conduct their non-checkout business with a person and platform that are tailored for checkout. Lastly the kiosks that the POS systems sit on should be rearranged so that a dedicated employee can bag things up while the checkout is happening separately. Basically I think the POS system is very good at checking people out but it is not quite so good when this activity is coupled with bagging and sorting out customer issues.


Read More

First Circuits | PComp #2

This week I did my first work with circuits by reviewing our class work and the labs available on the PComp website.


I started with a simple circuit powered off of the Arduino containing a 220 ohm resistor, an LED, some little wires, and a button that came with my Arduino starter kit.


The next challenge was to add a couple more LED, first in series and then in parallel to get a sense for how voltage and current change when more components are added.

image2 image1

As expected when the three LEDs were arranged in series behind the resistor, none of them lit up when power was connected because the voltage that each was receiving was divided amongst the three and failed to reach the level necessary. When I rearranged them into parallel each of them lit up because the voltage was now high enough since the current is what is divided when the components are arranged in parallel.

Next I soldered and attached a Potentiometer to vary the brightness of the LEDs.


This worked surprisingly well and I had way too much fun dimming a single LED on and off.

Lastly I set out to develop a switch myself to use with this board. I decided I’d like to make a switch that reacts to wind and the process turned out to be fairly simple. I attached a couple of wires to the board ahead of my resistor and LED (roughly where the button had been) and put some aluminum foil on the ends of each of them. When the two leaves of aluminum foil touch it completes the circuit and turns on the LED. I mounted this contraption above my A/C and was eventually able to get the switch to activate the circuit as the air blows and to turn off when it doesn’t.



Read More

Response to Crawford, Victor, and class discussion | PComp #1

I’m not sure how exactly I would have defined interaction prior to our first class and its related assignments, but I’m fairly certain that at this point coming up with a definition is more difficult. I like the Crawford definition, requiring two actors and a cyclical listening/thinking/speaking process, but as Crawford admits (and demonstrates) that framework can be rather squishy. The idea that the “refrigerator door game” can be disqualified as an interaction for being “beneath the intellectual dignity of almost everybody” is funny but also distracting for me. I couldn’t help but think about how disappointed I’d be to open a fridge with a burnt out light bulb, and whether that is a reflection of my intellect. But Victor’s rant made me feel a little better. He noted the feedback a glass of water provides to it’s drinker via weight, and few pursuits are more intellectual than deciding whether a glass is half empty or half full. Though I’m still unclear on whether this glass or the process of using it is a tool, interaction or both. At this point I’m leaning towards interaction as a spectrum that is much more fluid than Crawford’s system of zero, low and high. As for an original  definition I’d say: Interaction is a relationship formed in pursuit of a goal. So to me Crawford’s refrigerator light and Victor’s glass of water are both good examples of successful interaction despite their simplicity. 


Crawford, The Art of Interactive Design, chapters 1 and 2

Victor’s rant (

Read More