A few weeks ago I was skimming one of the bulletin boards at the university for any interesting lectures and a poster for “Hacking Eating Tracking” caught my attention. The idea of attending a hackathon has always intrigued me, but I was always too intimidated to attend. As an introvert it was the anxieties of forming a good team, not being able do anything of value, and not having the requisite skills that built up the barrier to entry. Still, after reading through the website and mulling it over a few days I decided to apply. My motivation for doing so came from my recent attentiveness to healthy living, the emphasis on hardware skills for this hackathon, and some wish to combine the two. Having now made it through the hackathon I can say that my earlier anxieties just didn’t make sense. In a way my experience has been about making those kinds of anxieties easy to conquer. Think of a hackathon as a place to meet interesting people, build things that aren’t perfect and an opportunity to learn new skills. Just don’t be afraid to go to a hackathon for the wrong reasons.
Prior to the hackathon, there was Slack setup for people to meet and discuss projects and logistics. I commented on a few ideas and proposed my own for tracking grocery ingress/egress by scanning bar codes but nothing really came of it. It wasn’t until I read Anandh and Arjun’s proposal to continuously track the weight of serving vessels in a buffet style restaurant that I saw an interesting project to work on. It was possible to carry out, the solution was non-obtrusive to the participants being tracked, and the data had a lot potential. After making contact with them, all that was left was to wait it out until September 18th rolled by.
The event started with a kickoff talk where I first met all the other hackers. What surprised me was the breadth of different backgrounds everyone came from. In terms of age I found underclassmen in undergrad up to working professionals, though admittedly the skew is towards university students. More unexpected was everyone’s point of origin. There was an entire bus of hackers that came from McMaster in Canada, a handful of people were flying in from western Europe and people came from all around the northeastern states. Technical backgrounds included health, computer hardware/software, and data science but the overwhelming majority were computer science students. I honestly felt like the minority being the computer generalist working in Boston.
Team forming took place the following morning where I had my first glimpse at all the projects being attempted. We weren’t able to permanently recruit anyone to join our team which was a bit disappointing at first, but it worked in our favor to have much lower synchronization costs. After the teams coalesced we started to get some work down and fully develop our idea for “Buffet Tracker”. The premise was to track eating behavior in a buffet style restaurant because it’s case where people are financially incentivized to over consume. To do this we wanted to link a change in weight of a serving vessel and link it to a specific plate when a person goes to take food. The result would be a dataset that has all the food procured from the restaurant’s serving area and proportion of food on plates throughout the day. With that kind of data you are able to start looking into research questions such as “What foods occur together with the highest probability?”, “What restaurant layouts result in the least(or most) consumption?”, “What is the nutritional content of the average plate?”, or “What time of day are people most likely to eat a certain type of food?”. Too many of the other projects focused on tracking at the individual level which tends to need some voluntary action or increased overhead/complexity. Our project’s strength was to avoid that completely by trading off granularity for a completely invisible solution to the problem.
In order to get this all to actually work we settled on tracking plates via RFID tags hotglued. At each serving station there will be a microcontroller responsible for measuring a change in weight and an RFID reader for detecting the plate. When it detects a procurement event it compiles the plate ID and the change of weight and reports it to a local computer which parses the data and adds it to the database. A web server then presents a front-end for querying the database and presenting graphs or tables. My part of this project was to design the hardware to do all this. All we got from the hackathon was an Arduino, a force sensitive resistor, and a USB cable so I had to rely heavily on my stash of parts and tools which wasn’t too bad. We would’ve been doomed though had I not had a bunch of RFID tags and a reader. Since we only had a day to do this I settled on using the Arduino and the force sensitive resistor to measure the weight. What I didn’t know was how bad it was at doing that, the granularity was basically enough to tell if there was an object on top of it or not. It also required that force be applied evenly over the surface area of a small disk. To solve this we wrapped it in a rubber band and hot glued a plate over it to serve as a demo serving vessel. The food also needed to maintain a centroid about the middle of the plate. Since the sensor was a passive resistive type, I created a voltage divider to sample the weight and calibrated it using some melon and a food scale I had lying around. Unfortunately I found that the voltage/weight relationship was also nonlinear and very imprecise, but I went ahead and made a linear approximation of it anyway just to have something to present. To clean up the noise from the data I took the mean of eight samples (Power of 2 for quick division hehe) and reported that. For communications I used the onboard USB UART chip to communicate with the host computer which is not the most elegant or scalable solution, but it’s what I had available to me. This created a problem for the ID-12 RFID reader I had which depended on UART to report the ID of the tag, but I found a nice Arduino library that bit banged a UART at the correct baud rate. For simplicity I used the RFID tag to frame the sample event so I sample the weight when the plate is first detected and again when the plate is removed. As a hack to figure out when the customer takes away their plate , I had to periodically toggle the reset pin on the ID-12 reader to trigger a new read. The moment it failed to read the plate has been removed. With that, I had all the necessary pieces to link a plate to a change in weight. All that was left was to craft a packet and dump it over the bus where a python script picks it up and pushes it up to the database on the cloud.
I managed to finish up the hardware sometime around 2AM and decided to go home for some sleep. The next morning we did integration and documentation which was admittedly very rushed, but I guess that’s the spirit of the hackathon. To my surprise, everything just worked after integration thanks to our well-defined hardware/software interface. We just replaced their test unit with the unit I completed last night and the entire stack worked perfectly. It was just incredibly satisfying to see the tables and graphs update immediately after we transfer food from the serving vessel to our demo plate. After that, we developed our presentation materials and pitch. Of course when it came to demo the product we had technical issues moving from the development environment to production, something about the wi-fi in the room failing and we couldn’t connect to the database on the cloud. In hindsight we probably should have just ran this all locally, but oh well the judges ended up loving the idea. It just met the requirements of the hackathon really well in that our solution provided clean quantitative data, representative of a population, and completely non-obtrusive.
By the time we’d presented to the audience and it was time to announce the winners we were teeming with anticipation as they kept announcing teams that weren’t ours. I really didn’t expect us take first place at all given that I really had no idea what I was doing at a hackathon, but I was obviously thrilled about the outcome. We ended up with $1500 split three ways, which was a nice little bonus. Would I do it again? Probably not. It’s pretty exhausting and stressful while the per-hour value for the prize money was pretty low. I’m just glad I can finally cross this off the bucket list and ended up with an overall positive experience. I met some great people (Big thanks to Anandh and Arjun!), developed a novel idea, won some cash, and got a neat story out of it. Hackathons are pretty cool, but not for me at this point in my life.