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.
Thinking:
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.
Making:
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.
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.
Here is my digital mock up of how the physical sign could look and function.
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:
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.
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.
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!
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
Igoe, Making Interactive Art: Set the Stage, Then Shut Up and Listen
