#masportfolio

[sidlamaute]

Thermal Alarm/Scheduling Sessions -- July 2019 to Jan 2020

Summary: When I joined Embr Labs, I had ample latitude to pick my research topics, and I was and still am interested in technological interventions for mental maladies. I read numerous papers on temperature and depression, narrowed to seasonal affective disorder (SAD), which then led to studying and prototyping a thermal alarm and scheduling thermal sessions to bring regular relief for when people know they need it most. This initially involved modifying the firmware (in C) on the wearable device to design a gradual awakening session. I then ran internal alpha tests for both technical and user experience reasons: 1. I had to check if the wearable experienced any time drift when programmed to start 8 hours after the session was set

2. I had to check if people actually woke up as a result of the thermal stimulus. The results showed that time drift was minimal, but my initial stimulation design was flawed. As it turns out, instead of having 12 minutes of getting colder and colder (the longest the device could handle without getting dangerously hot), having 30 minutes of "waves" of cooling from room temperature to a fixed colder temperature was much more effective. The company became interested in using my feature for more than just the population affected by SAD, given that other users might find that they need sessions at predictable times and thus would want to schedule them. Therefore, I moved on to phase two of this project, which involved designing features in the wearable's companion Android app to enable users to program thermal sessions for any time they wanted (as opposed to the fixed 8 hours I used for testing) and to schedule up to 10 sessions. To support multiple sessions, I also had to modify the firmware to support a table of timers with the parameters of each desired session. However, given that sessions could be scheduled up to 24 hours in advance, I decided not to rely on the lack of time drift I observed in the previous experiment. Instead, I designed a syncing system from the phone to the wearable that would check and correct the remaining time until the session started any time the app was opened. I then ran another alpha user experience study, checking if the interface and options were logical and sufficient for users, and if there were any time drift issues in the longer-term scale. I omitted the pictures of the session setup process because they're quite boring, but as you can see, there's room for a list of sessions, and each entry shows the relevant details of the session, which can also be edited or deleted. As a result of my supportive findings, this project was added to the roadmap. What I Learned: more complexities of C, the newer features of Android programming at the time, user study design, and key human thermal perception paradigms.

[sidlamaute]

Reachability -- Summer 2015

Summary: While I interned on the Hotels team at Google, I worked independently on a project to allow users to visually determine what they could “reach” starting from a given location. The idea was to be able to pick a hotel and see places one could reach from there, to better help choose hotels. The metrics for “reachability” involved how many minutes away one wanted to travel at maximum, and mode of transportation. Based on that, a map overlay would be drawn. Google had made a version that never made it to production a while back, but as shown below, when a mode of transportation with distinct stops (eg, a rapid transit system) is selected, distinct dots around the farther stops are shown rather than a contiguous area because the “reachability time” is taken quite literally.

Even for walking directions, the pattern of small circles from radii around different points was inelegant, and actually less informative that one contiguous region, because now the high level of the map looked so bumpy that the sense of absolute precision required zooming in to see which adjoining blocks were “out of range”.  Therefore, I decided to redesign the aesthetics in addition to writing new code so that my version looked like the second picture in the header of this post. In fact, one of the most fun parts of this project was that I had to meet with many people, from UI/UX designers to the person who assembled the raw data, in order to create this entire system over the course of one summer. Nobody actually thought an Engineering Practicum intern could do it by themselves until I presented it at the end of the summer. Unfortunately, all the code and the final presentation is Google’s. However, Google’s “Nearby” feature in maps reflects an evolution of my design, in that there are smooth curves connecting the reachable area (but better drawn, likely by someone who already knew JavaScript) rather than having those distinct regions that are a result of a precise, literal definition of the reachability time. Here’s an example (in NYC with walking distance because they don’t seem to have complete data for this feature yet):

What I Learned: How to use Protocol Buffers and Javascript with Closures, as well as Google’s specialized Java APIs (all of which I learned in my first three weeks), as well as how to structure a more intuitive UI.

[sidlamaute]

Mind Media -- February 2015

Summary: I was accepted to the Stanford hackathon, TreeHacks, and over the course of 24 hours, my team of four constructed the MediaMind system.  The idea was to take the Internet of Things to a futuristic extreme to get rid of the question “what do I feel like listening to?”, instead producing a curated list of songs before you even necessarily know what you feel.  We used the Emotiv (left), a device that can read brain waves to determine emotions. From there, we connected the Emotiv’s reading through the cloud (using Microsoft Azure), which picked a selection of songs through the Spotify API (and ideally in the future, tv shows and movies, etc.) and sent that list to the Pebble (through the user’s phone). Then, one could select the media with the Pebble and, with wireless speakers for example, play the song immediately. I personally worked on sending the Emotiv’s readings to the cloud, which was actually one of the major difficulties since at the time the Emotiv only had one working API and could not send data wirelessly.  However, I was able to complete this task. We were not able to get the full pipeline working in time, but were my team not split between me at MIT and the rest at Stanford, we would have really liked to continue the work. What I Learned: using cloud services (in this case, Microsoft Azure), working with competing teams to get the Emotiv to work, creating multi-element Internet of Things systems, and project managing (as a sudden headfirst dive). Documentation: code, hackathon submission

[sidlamaute]

Digital Synesthesia -- Spring 2014

Summary: This was my first research project, under Santiago Alfaro in the MIT Media Lab’s Object-Based Media Group.  The goal was to learn if it was possible to augment human senses by creating devices such as the distance-sensing glove (bottom left) and temperature-sensing headband (middle left, bottom right) which gave vibrotactile feedback proportional to the information sensed. I was in charge of building the headband, which required an Android app, designing PCBs in Eagle and fabricating them, and integrating temperature sensors within the headband. I also assisted with user testing of the glove. This project solidified my decision to jointly major in Electrical Engineering and Computer Science, and inspired me to keep taking whatever classes were available to undergraduates at the Media Lab. What I Learned: programming for Android, designing and fabricating printed circuit boards, using various sensors in wearable devices. Documentation:  headband, glove