PComp Final – Fridgebot

The Fridgebot represents the culmination of my introduction to the world of Physical Computing.  Working with Arielle Hein and Allison Ye, we set out to examine the complex, but rarely discussed, topic of food waste.  Our biggest problem to conquer was scale.  We needed to effectively communicate an enormous problem to a specific audience, and have the idea stick.  For that to happen, the idea needed to address the problem in terms that our classmates at ITP could relate to.  After witnessing the infamous Monday morning refrigerator cleanouts, where expired food and leftovers are cleared from the fridge and thrown out, we decided to put our focus there.

The posted refrigerator rules dictate that students will use a sharpie to label their food with their name and date.  After 4 days, any food is liable to be eaten by someone else, or thrown out.  Similar to your refrigerator at home, sometimes things get forgotten.  Unlike your refrigerator at home, there are over 200 students on the floor, with a large number of them using the refrigerator.  Even with a self-policing population, most of whom are living on very tight budgets, lots of food gets forgotten and spoils.  We volunteered to take over the Monday cleanouts, and have found an average of nearly 16 lbs of food wasted per week.  Admittedly, that data is only from just over a month, but also doesn’t include anything thrown out midweek.  We set out to redefine this process for students in hopes of reducing waste and saving students money.


Preliminary Drawings

Our main objective was to make the process as easy as possible for students.  It should not take any longer than writing your name and date in marker, and should be extremely painless.  The project would fail if these requirements were not met.  We settled on using the NYU student ID as the centerpiece of our interaction.  Students bump their NYU ID on an RFID card reader (HUGE thank you to Surya Mattu for all of his help with that).  This only provides us with the card’s RFID number, no NYU information.  When a student bumps their card, a MYSQL database will be checked for existing records in their name.  So on first use, a student must enter their name and netID (NYU email address) using the touchscreen display.  We also created a google doc in hopes of getting people to sign up at their leisure, so their first Fridgebot experience can skip the entry process.  This entry creates a record in the database through PHP with the students card number, name, and netID.   Once they are in, a signal is sent to Processing, and a barcode label is created and printed with an Adafruit thermal printer.  Students put this label on their food, and their database record is updated with a timestamp.  When students want to eat their food, just use the barcode scanner to scan your label.  This puts a second timestamp in the database.  The database will be scanned multiple times per day looking for entries that are 48 hours old, with no checkout timestamp.  When it finds one, it sends a reminder to their NYU email telling them to eat their food.



Design change!  After Rob Ryan informed us that our plans to hang it on the wall would not work, we scrambled for a redesign.  We chose a retro computer look, which would function like a kiosk standing near the refrigerator.



Evidence of how much the monitor dictated our design choices.


Piecing together the front panels.  They are removable to allow access to the components.



Based on preliminary evidence and user testing, students are excited about the Fridgebot.  We are in an environment where gadgets and tech solutions are embraced, and the Fridgebot heavily plays to that.  A Mac mini powers the Fridgebot, connecting to a touchscreen display and barcode scanner.  An RFID card reader runs through the Arduino Yun.  Processing acts as our communications hub between all devices, and controls the display.  PHP scripts are triggered and run through Processing to update the SQL database, with PHPMailer being used to send the reminder emails.

Rob has given us permission to leave the Fridgebot up for the coming semester.  We want to test the validity of our project, and see if we can truly help lower the level of food waste on the floor.  The idea that my first final class project could be something that is left on the floor to help the student body is, to say the least, extremely exciting.  Big thanks to my partners Arielle and Allison, and all those that helped along the way including Rob Ryan, Surya Mattu, Tom Igoe, Matt Richardson, and Shawn van Every.

PComp Final update

Progress report on my PComp Final.  After collecting all the necessary hardware, we began setting up our system.  Show below is our Arduino Yun, connecting the RFID card reader and Adafruit thermal printer.


The card reader reads an NYU ID on bump, sending the card number to Arduino.  Arduino then generates a barcode receipt with that card number printed below.  For our final product, the student email (Or name, if we get that information) will print below the barcode for easier identification, and the barcode itself will print on a sticker, not receipt.

PComp Final update #1 from John Farrell on Vimeo.



First successful receipt & number printout.

At the moment, the project stands like this: The card reader gets the RFID number from a scanned card.  A Processing sketch, acting as our communication hub, displays confirmation or error messages based on the scans.  Taking the card number from Arduino, Processing saves a .csv file of the number from each scan, and automatically uploads it through FTP.

PComp Final update #2 from John Farrell on Vimeo.

The screenshot below shows the next step: Processing will signal a PHP file to run, which will read the .csv file, and check it against a column for Card Numbers in the database.  A file is sent back to Processing showing whether the number was present or not.  Depending on the answer, Processing will offer different prompts to the user.

Screen Shot 2013-11-23 at 5.28.20 PM


What remains is a lot of PHP work (Which I am learning on the go), refining our Processing order of operations, and visuals (Not to mention fabrication of a casing to mount on the wall).  Ideally, we could even have a real-time display of students with food in the refrigerator.  With 10 days left until the project is due, I think we are on track.

PComp Final

After a lot of discussion, both in class and out, Arielle, Allison and I have decided on our PComp final project (also qualifying as my CommLab Web final).  We will be wiring up the floor refrigerator to track leftovers, with the goal of preventing food waste on the floor.  As Sam said to me, “a very high-tech solution to a very low-tech problem.”  Every Monday morning, the fridge is cleaned out and old food is thrown out.  We have volunteered to handle theses cleanouts going forward to track the waste and get some exposure to what’s going on in the fridge.  This past week, our first week doing the cleanout, 23lbs of food were wasted.  For a group of college kids who are supposed to broke, it seems like a lot of money down the drain.



The basic system diagram above shows our plan.  Currently, students just write their name and date on the food packaging when they put it in the fridge.  In our system, the user will first tap their NYU ID on a card reader.  The card will trigger a printer to print a QR code label, which the user will put on their food.  This creates a record in a database of the student, with a unique ID for the QR code, as well as a time entered.  When the student eats their food, they simply scan the QR code on a webcam, which will mark the food as “eaten” in the database.  A cron will scan the database two or three times a day.  If it sees that a food was entered 2 days ago, without being eaten, it will send a reminder email to the student.  Hopefully, at the end of the week, will have a fridge free of leftovers, or (more likely), we can identify who is leaving leftovers in the fridge to spoil.

We already have our card reader, adafruit thermal printer, and touchscreen display.  Our Arduino Yun is in the mail.  Some things to note: A one-time only interaction will be needed the first time a student taps their ID.  They will have to enter their netID, which we will use in our database for the email notification.  While not ideal, the fact that it only needs to be done once is very important.  Disrupting such a casual, ingrained system is delicate, and we need our interaction to be no more complicated or time-consuming than writing your name and date.   Our real issues will be on the technical side.  Processing will act as our communication hub for the card reader, Yun, webcam and printer.  It will also have a display function for our touchscreen.  It will be outputting information to a PHP script, which will create (or modify in the case of a checkout) a record in our database.  It will need to communicate to both a QR generation software as well as our automated email service.  We will need to be checking the database for existing records at every card tap, as well as throughout the day.  With all of the hardware in place, it’s time for us to start working.  Getting up and running ASAP is a priority, as we will need all the time we can get for user testing to ensure a successful implementation.


Click Here for an updated and more detailed system diagram.

PComp Midterm




PComp Midterm from John Farrell on Vimeo.


Jay and I presented our midterm today.  Even though a couple sensors weren’t working, everything turned out pretty ok.  I was pleased with the design of the instrument itself, the fact that we had a mostly working prototype, and that we got sounds to play from Max (which turned out to be the most frustrating part).  It wasn’t perfect by any means, and there is a lot we could fix if we wanted to refine it.  Obviously, have all the sensors working, toggling the fill sound, spending more time with someone who knows music on how to construct our range and combination of notes, as well as some fabrication changes.  But considering 2 months ago I had never touched an Arduino before, I’m feeling satisfied.

PComp Midterm

With midterm projects due in one week, a progress update is in order.  Looking back to my last post, we decided to stay on track with our infrared instrument.  We went a little off-course by ditching our breadboards (mostly) and soldering everything to perfboard.  The decision will give us a little more flexibility and space in design.  It’s safe to say my soldering technique is up to snuff now.



IMG_2131   Soldering details

 IMG_2136 Set up and soldered.  As you can see, we are using a breadboard only to link some power and ground connections.

After the soldering was complete, the moment of truth came – plugging in and trying to run our program.  Of course, didn’t work.  When plugging the power and ground in to the Arduino, the “on” light on the board immediately turned off, signaling a short.  After a lot of looking, poking, prodding, de-soldering, and rewiring (and a lot of systematic debugging by Jay) our issues were resolved, and the sensors are fully functional.  An incorrect solder or two, and a misplaced wire on the breadboard threw us off.  With the functionality set, we’re on to fabrication.  Wood is our material of choice, and we decided on a wave-based curve for the top housing, reflecting the deterioration of the notes that will be played.  I drew up some simple diagrams, and hope to laser cut the wood in the next day or two, however a decision on the LEDs is still yet to be made.  They were used for testing the sensors, but could be useful to keep around.  We also need to leave time to program the sounds using MIDI in Max.



The box below the curved structure will be used to conceal wires and the Arduino itself.  Only the USB cord will show.



Something that began to slip our minds – where to put speakers?  Currently, thinking cutting an area out on the sides of the housing seen in the pictures above.

PComp Catch Up (Pt. 2)

Decided to split things up to avoid a mega-long post.  More recent developments in Physical Computing.  Jay and I have continued to work on/troubleshoot our musical instrument.  Troubles have included use of digital pins 1,2 and 13, which Ben Light explained to us can be troublesome to use as standard inputs due to their additional functionality, as well as light noise affecting the IR readings.  We’re hoping a physical case would solve those issues by keeping the bulbs set back in a piece of wood to shield them from extra light.  We also have some unknown problems on the board that are causing issues with a couple of the IR sensors which need investigation.  Jay and I are currently debating pursuing this as our midterm project, which would involve developing a more robust physical housing, mapping sounds (maybe piano?) from Max/MSP, and working on some visualizations to be triggered in Processing.  We’ve spent a fair amount of time on it and want to see it through, but project fatigue is also setting it.



Overall setup


Breadboard detail


Arduino detail

Speaking of using Processing sketches – we just learned how to do that!  Here’s proof.  Mapping values from a potentiometer in a Processing graph.

Graphing Arduino values in Processing from John Farrell on Vimeo.


Controlling an ellipse using an accelerometer.

Controlling Processing through Arduino from John Farrell on Vimeo.


PComp Catch Up (Pt. 1)

Haven’t kept on top of my blogging for the past week – here’s some of the latest things happening in Physical Computing.


First up: Mouse lab.  I’ve been working with Jay as my partner for the past couple weeks.  After making a mouse work using photoresistors programmed through Arduino, we were working towards using an accelerometer as our mouse.  We had the LEDs mapped to the X,Y, and Z axes to give a corresponding brightness, but had a little trouble with our safety and clicker buttons.  We figured them out, but ran out of time for full testing.  Something to come back to, as I would like to have a good understanding of how to use the accelerometer.



Here, I had the Servo motor set up to pivot when light was blocked to the photoresistor.  I taped my drawing pen to it quickly, and made a little doodle by rapidly covering/uncovering the sensor.  Each little dash is the plastic arm on the servo rotating back and forth, while I moved the servo motor itself in my hand.



First tonal output through Arduino!  After mapping a pitch library to the photoresistors, I was able to play simple notes by covering each sensor.  Pretty basic stuff.


Vertical Video WOOOOO!

Tonal Output through Photoresistors from John Farrell on Vimeo.


I also did a quick exercise from the Arduino book using a temperature sensor.  The idea is that the LEDs each have a different temperature range, and will light up depending on how hot your hand is when you squeeze the sensor.  I didn’t spend a lot of time doing calibration so it doesn’t work perfectly, but interesting to try nonetheless.

LED control with temperature sensor from John Farrell on Vimeo.



Public Interactive Design

Like many ITPers, I live in Brooklyn.  Therefore, I have gotten to spend quite a lot of time riding the subway to and from school.  There are few interactions as equalizing as riding the subway; the homeless and the very wealthy all have to buy the same card from the same machine, wander the same tunnels, wait for the same train, and sit or stand in a cramped car .  With an estimated 5 million rides per day, the subway is as public as an interaction can be.  It’s goal is to provide efficient mass transportation to as many people as possible, on time, to every major part of the city, in as simple a way as possible.  And yet it’s very intimidating to visitors, and confusing still for residents.

I want to focus on the ticket machines.  The only way to get on the subway is to buy a ticket, almost always from an automated machine.  The machines will seemingly always be unoccupied whenever you already have a ticket, but backed up with customers when you’re in a rush.  People struggle to find the right options within the menus – I want a new card, right?  Do I just need a SingleRide?  Why do all of these say “+1” on them?  The credit card readers are often very problematic as well.  There isn’t time to have to try your card 10 times when there is a growing line forming behind you.  This is not completely the machines fault; it is still a struggle to understand why the US refuses to adopt the chip technology prevalent throughout the rest of the world.  If a single ride is $2.50, why isn’t there an option to purchase based on number of rides, so that you don’t invariably end up with leftover money on your card?  As an aside, looking into this led me to MetroChange, a fantastic idea where you can donate your leftover card change to charity.

So you finally end up deciding you need a $25 card.  You spent a few minutes navigating the touch screens, which, for all our technological advancement, feel as antiquated as an automated phone system.  Maybe you got your card to work, maybe you paid with cash because the reader was malfunctioning.  You’re then dispensed a thin paper ticket.  For a rare user, this may make sense.  But for purchasing unlimited monthly passes, something a little more substantial would be nice.  In my opinion, there should be an option for a more substantial plastic or composite card, less susceptible to wear and loss, offering more encouragement to be refilled.  Your whole transaction probably took 3-4 minutes, which doesn’t sound long but can feel eternal with a lot of anxious travelers behind you.  After your purchase is completed, you then enter the confusing tunnels to find your train – but that is a different discussion.  Something as large and complex as the subway system will produce inherent difficulties and confusion.  But simply getting a ticket to get into the subway should be an easier process.  It may be simple to someone who has lived in the city for a while, but, more importantly, it needs to be equally as simple for a first-time user, a tourist.