PennApps Post-Mortem: Too Hot - Day One

January 28th, 2017

Last weekend I had the privilege of attending and participating in the University of Pennsylvania's biannual PennApps hackathon. The following is my recollection of the event and discussion of our project.

To begin, I will note that I was not the only person from Blair who applied to PennApps. However, I was the only who got in. This put me in a difficult position, as after scrolling through the -- admittedly incomplete -- list of attendees on Devpost, I could not find anyone I knew. I had a minor breakdown the weekend before, staying up until 3am, paralyzed by the lack of a team or good idea. This is the point where I inform you dear reader, that I had never been to a hackathon before and had no idea what to expect, especially on my own.

With all of this anxiety in mind, you can only begin to imagine my relief when I arrived at the University of Maryland PennApps bus stop and saw four Montgomery Blair alumni standing in front of me. I was even more relieved when I discovered that two of them (namely Ji Hyuk Bae and Anthony Li) were on a team with another UMD CS student (Ethan Farkas), and as their fourth member had not been able to make it had a free spot on their team.

During the course of the multi-hour bus ride to UPenn several ideas were discussed. Most of them amounted to personal finance apps that integrated the two APIs which there were prizes for: Capital One's "Nessie" -- which effectively gave you the tools to simulate transactions and all the internal operations of a commercial bank -- and the new kid on the block known simply as "Button". The latter's rather generic name made googling a tad difficult, but eventually we found out that it was essentially a generalization of the Uber API to allow for other "merchants" to offer their services through an integrated access point in other apps, with both Button and the app creator taking a commission off of the purchase. One early idea that Ethan proposed in this vein was an app which would allow the user to order Uber, flowers, and a pizza to their location, while paying for it with their Capital One account.

After arriving on campus, negotiating the registration lines, and finding a spot to work on the second floor of the Towne building, we set to creating an idea in earnest. I threw my hat into the ring with several of ideas that I had come up with in my delirium the week before: A device which could go through and automatically redact physical documents, an AR app that would let you identify a product using Google Glass and then find the best deal on it, a platform for setting up charitable fundraisers through Button merchants, or an integrated entertainment system which would sense the mood in a room and then amplify it with appropriate lighting and music.

These ideas, along with several others, were let go of in favor of something proposed by Anthony: during the swine flu outbreak airports in China had mounted thermal imaging cameras at security checks, and those who were observed to have a raised temperature were pulled aside an check further for symptoms. However, these cameras were expensive and required supervision. Thus, we could create a system that would be mounted in other public places and used to automatically check and report if passersby had a fever.

We encountered challenges straight away. The hardware people didn't have a thermal camera, or even a directional thermometer. It was 6:30PM, the kickoff ceremony was about to start, and we were searching for infrared thermometers online. Several decent looking thermometers were found on amazon, but we would be receiving them around 8 in the morning at the earliest, and this would put us a full twelve hours behind (hacking began at 8PM). Thankfully, it was soon found that RadioShack (a) still existed, (b) carried infrared thermometers, and (c) had a location on Chestnut street, a mere mile and a half walk from our location. A quick phone call confirmed that they had a device similar to what we needed, so instead of going down to Irvine auditorium we threw on our jackets and headed across town. In order to make sure that we didn't miss out on anything important, Anthony streamed the kickoff on his phone.

By the time we got back, dinner, hardware checkout, and hacking had begun. Ji, acting on experiences with food shortages at previous hackathons, urged us to get dinner first. This was a good decision, as we were all hungry and the line was ever growing, but as soon as we got back to our table I went to acquire a Raspberry Pi to run our device. Unfortunately, they were all long gone by the time I came around, but the hardware people were overflowing in Arduinos. Having taken one, a wifi shield, and the appropriate cable, I set to work dismantling the thermometer with electronics pliers, twisting off the plastic. Inside I found the device and its board. The next several hours consisted of trying to understand how to programmatically get output from the sensor, with little success. I referenced the very few attempts I found documented on the internet of people attempting to do the same. While the only source I found using the same model had failed, a different person had managed to read serial output from a similar board on Arduino. This code was copied over onto Ethan's computer, and modified to suit, but seemingly to no avail. Eventually, I decided to firmly solder the wires we were using to the contacts on the thermometer, just in case that was the issue. After the 1AM pizza run my suspicions were confirmed: the program worked and we were able to read the temperature from the thermometer every tenth of a second. For those of you wondering, "how did it take you five hours to read serial output from a thermometer?", I will remind you that none of us had ever used an Arduino before, that the thermometer was practically undocumented for our purposes, and that as a result we did go down several red-herrings and multiple sanity checks using a multi-meter were required.

All this while Anthony and Ji had been working creating a RESTful API on an Amazon AWS server to accept the data from the Arduino. Ethan and began the adventure of connecting the Arduino to WiFi and sending HTTP packets with the data. By the time 4AM rolled around we had a device that took readings and sent them off to our server which then mad a judgement on whether the subject had a fever and served a basic webpage to that effect. Quite happy with our first bit of work we went to sleep.

< Newer PostOlder Post >