Archive for November, 2010

MoodyJULIO: Investigating My Physiological and Emotional States

Friday, November 19th, 2010

For the last few months I have been working on designing a system that enables me to gain insights regarding my moods and emotions. As I outlined in my previous journal entries, this system needs to enable me to monitor my physiological and psychological behavior, and enable me to cross-reference this data with contextual information about my activities. This past week, after a long testing and preparation phase, I finally launched this project and gave it an appropriate title: MoodyJulio.

Today I will share the completed project proposal that I presented to my colleagues earlier this week, followed by detailed information about the final design of the methodology for my data capture and monitoring system. I will also provide an overview of the next step in this project, comprised primarily of data analysis and visualization work. Lastly, I will share some interesting questions that have been raised by the work that I have done so far (several of which are not directly addressed by this project). Enough preamble, let’s get started with my final project proposal:

MoodyJULIO Project Proposal

Tracking and Measurement Methodology The design goal for the methodology that I created was to devise a system that supports “objective subjectivity”. In other words, I wanted to create an objective way to capture my subjective experience of moods and emotions. At the same time, I had no desire to apply the same level of rigor that medical or scientific studies. The system that I created has 3 core components, and 2 fun components. Let’s start with an overview of the core components:

  1. Biofeedback Component: the first component encompasses the processes and tools for measuring my physiological response to the world. My focus here is on collecting heart rate and galvanic skin response data, two variables that correlate strongly with physiological levels of excitement. To collect this data I use two small devices that I wear throughout the day: a Polar heart rate transmitter and a home made device (dubbed MyMoody) that captures gsr readings and logs that data along with the heart rate information and a timestamp.
  2. Self-Analysis Component: the second component is comprised of the processes and tools for measuring my emotional state. This is the main area where subjectivity comes into play, so I spent a good amount of time thinking about and testing different approaches. The solution I devised leverages the MyMoody device and a smartphone to enable objective-subjective tracking of my emotional states. The MyMoody device prompts me every 40 to 80 minutes, or whenever my heart rate exceeds 95 beats per minute, to log my emotional state. When prompted I submit a short post about my emotional state using my smartphone.
  3. Contextual Component: the last core component is focused on enabling me to capture information about the context associated to my physiological and emotional states. The tools associated to this component are a smartphone and/or a computer. When posting updates about my emotional state via my smartphone I will also record my current activity and note who I am with at that moment. At the end of every day I will update my calendar with a detailed overview of my activities during that day.

Now here is a brief description of the two fun components:

  1. Social-Analysis Component: this component includes process and tools for capturing other people’s perspective regarding my moods and emotions. The process for capturing this input is supported by an old school paper business card (pictured in the presentation above), and posterous.com blog, and a twitter feed. Here is how the process works: when I talk to someone I request that they submit a report regarding my mood. I give them a card that reminds them of this request and provides an email address where they should submit this information. When an entry is received it is added to the posterous blog and the twitter feed.
  2. Picture-Analysis Component: this component aims to provide insights into my moods by capturing images of me when I am using my computer. The process is quite simple, whenever I am using my computer it takes a picture of me every minute using the webcam. These pictures are then stored using sequential files names.

Framework for Describing Emotions In order achieve my goal of objective subjectivity it was important to leverage a framework that enables me to communicate about my emotions in a consistent manner. Rather than attempt to re-invent the wheel, I decided to look for an existing framework that I could leverage. For a while I was leaning towards using Robert Plutchik’s wheel of emotion. However, I ended up deciding to use the HUMAINE project’s Emotion Annotation and Representation Language (EARL) because I find its structure aligns better with my data collection approach and the way I think about emotions. Interestingly, this framework was developed to support emotion-oriented computing. Interesting Questions During this initial process of data collection several questions have been percolating in my mind. These questions are not directly related to my current project but are definitely worth further thought and investigation – who knows, one of these questions may serve as a seed for my thesis project.

  • How does the process of categorizing (or rationalizing) our body’s physiological responses into emotion categories impact our experience of life and the world around us. In some ways this is a process of mediation. How does this process affect our relationship with our own mind and body.
  • How can we experience the world more directly without the interference of this mediation process? Is it desirable to seeks this more direct experience of the world?
  • How does this type of research affect how we experience our emotions. Since emotions are constructs that are largely determined by the stories that we create to rationalize the physiological responses of our body, how does this focus on emotions impact this process (for better or worse).

Methods of Emotions Research

Friday, November 19th, 2010

In order to inform the design of my mood tracking and bio feedback project, MoodyJulio, I did an online investigation into methods for tracking and measuring emotions in scientific and medical studies. My main focus was finding studies that investigate the link between physiological responses and emotions.

After many hours of searching I put together a presentation that provides a high-level overview of the most common approaches for tracking emotions in general. This shift in focus was partially due to the realization that any research into emotions needs to incorporate contextual data to augment physiological data. After all emotions are constructs to cannot be reduced physiology.

Here is the presentation that I developed. Below is a short overview of the most useful and interesting sources that I encountered in my investigations.

Main Source Materials


ITP WC: Building the Installation and Fixing the Code

Tuesday, November 9th, 2010

During this past week we continued to make good progress on the ITP WC project. Our main objectives were to continue working on building the physical structure for the aquaponic installation and to fix issues with the sensors to ensure that we are able to get valid readings from the bathroom.

The Physical Build
After working on developing detailed plans for the bathroom installation, Adib, Marko and Macaulay set out to construct the structure for the aquaponic system. The final design leverages the large Poland Springs bottles that are common to the bathroom as the containers for the living system. To create an appropriate structure, Adib designed a set of clear plexi stands that will serve as displays for the repurposed bottles. Here are a few design sketches:

The Bathroom Layout – Overhead View

ITP WC Design - Bathroom Layout

The Aquaponic System – Close-Up View

Now here are a few pictures of Adib, Marko and Macaulay working on building the installation earlier today.

Air Quality Sensors
On the air quality sensing front we continued to encounter some issues. For our Carbon Monoxide and Methane sensors to work properly we had to re-write the Arduino code. While for our Pachube feed to work continuously we had to upgrade our account to Pro level (luckily, for students the pro membership level is free).

Here is a brief overview of the changes that we incorporated into the code for the Methane and Carbon Monoxide sensors. Working with gas sensors is usually tough. One of the main reasons is that gas sensors need to run for several days before they are able to provide accurate readings (usually they need to run for 4 to 5 days). Since we set-up our sensors we had been encountering problems with the readings readings and the feed.

Based on information that I found out from conversations with Melissa Clarke last week I became aware that we needed to set-up our sensors differently. Carbon Monoxide and Methane sensors require that their heating element receive alternating amounts of voltage every 20 seconds. Furthermore, in order to get accurate readings it is crucial that the microprocessor capture data during a very small timeframe that lasts approximately 5 milliseconds.

This data was not clearly spelled out in the short datasheet that I received along with the sensors. It was only after finding the the detailed documentation online that I was able to accurately understand how to write the code. Here is a link to the code I wrote, available on github.


AMUP original [Research & Testing]

Monday, November 8th, 2010

Over the past two weeks I have made a lot progress on the project Air Mashup. First off, the project name has evolved (or devolved) into AM-UP – ok, this is really minor news. The real progress has been made in testing and setting-up the proximity sensors, which will make up a core part of the interaction experience.

In this journal entry I will first discuss the process I used to select and test different types of sensors. Then I will write a post about the development of my first and second generation prototypes, and discuss some of the main challenges I encountered.

Selecting the Right Sensor
I found three different types of range finders that I looked into. The main considerations that I had in mind with these sensors were: (1) resolution and range; (2) beam width and interference; and (3) price and value.

The first sensors to be considered were the Maxbotix Ultrasonic Range Finders LV and XL range. Though these sensors tend to be very reliable and easy to use, they did not offer the right resolution and value. The LV range has a resolution of 1-inch, which is just not enough, while the XL range has a resolution that is twice that but they cost $60 a piece. I also had some concerns regarding interference between range finders, since I am planning to space them out by 10- to 12-inches only.

The next sensors on my list were from Sharp’s Family of Infrared Proximity Sensors. These sensors feature the shortest range in the bunch but they also provide the best resolution. I looked at two models: the long range model that can measure from 15 to 150 cm, and the mid range model that can measure between 8 to 80 cm. These sensors also provide a narrow beam width and they offer a good price to value ratio.

The last sensor that I looked into was the Parallax Ping Range Finders. These range finders are much more complex to use than the previous two. They require that the sensor send out a signal and then listen for a “ping” to come back in order to measure distances. These range finders are similar in price and technology to the Maxboxtix. Therefore, they suffer from the same value and beam width issues.

After running these initial tests I decided that Sharp’s proximity sensors were the best solution for AM-UP. I went ahead and purchased seven of these sensors and shifted my efforts to developing prototypes.

Prototype One: Testing Dynamic Range

My first prototype was little more than a wooden board with three separate proximity sensors attached a varying distances. The purpose of this first test was to identify interference issues and to out the dynamic range of the sensor. Here are some of the key findings from this initial prototype:

  1. the sensor’s beam width is very narrow. This means that each sensor only needs to be separated by about 11-inches to avoid interference. This also means that there is a small sweet spot where a user’s hand must be placed for the sensor to work.
  2. the dynamic range of the sensor is sufficient but there are some important characteristics that need to be addressed in the code. First, if the user’s hand gets too close to the sensor (within 15cm) then the readings become unstable and unreliable. Second, noise occasionally creeps into the data and needs to be filtered out.

Local Sensing, Worldwide Sharing

Tuesday, November 2nd, 2010

Over the past week we have been making a lot of progress on our bathroom intervention project, ITP WC. Macaulay and Adib have been taking the lead on the physical design and planning for our installation, including the aquaponic system. They have completed some initial prototyping work and have begun to procure the materials for the final build. More updates to come on that front from the two of them.

Marko and I have been focusing our efforts on creating the circuits that feature the gas sensors, and writing the code to share the data using Pachube. I’m happy to report that we have come a long way. We have installed our two first sensors in the ITP men’s room and we have started to feed data to Pachube (feed 11193).

Our first step was to set up the sensors on a breadboard and hook them up to an Arduino with an Ethernet shield. We started with a sensor the captures Methane and Carbon Monoxide (TGS 3870), and a second one that captures solvent vapors (TGS 2600). For building the simple circuits we got some help from an instructable article, since the datasheets from Figaro left much to be desired. We also looked at some tutorials on the arduino site to get up and running with the ethernet shield.

Getting started on Pachube required a good bit of learning. We had to get up to speed on Pachube’s API, which is not very complex but does require some time and effort. We used one of their tutorials as the basis for our code.

The last step was getting the sensors installed in the bathroom and tweaking the code to make sure we were getting reliable readings. The main change we incorporated into the code was to add functionality that takes several readings from the bathroom during a one minute period and averages those readings together uploading data to Pachube (which is done once a minute).