Final Project

For my final project in Physical Computing, I was able to get the Personal Health Diagnostic Tool working. This was a great culmination to a great semester. The system consists of a Polar Heart rate module from Sparkfun, some Processing code to interpret and graphically display the heart rate data, a Polar Heart Rate monitor setup, and web php scripts that strip data from POST calls from Processing. I also use TextMarks so users can text in "symptoms" that will be associated with their heart rate data.

Here is my presentation (pdf).

Also, for more background on this project see these two previous posts:
Final Project Proposal
Dream Device

As previously stated, my vision for this device is that it would allow a user/patient to gather health data that could be utilized by a physician or health care professional in treatment of disease or symptoms. In addition, through testing of this project I saw the very real effect that a more full understanding of my body and even one data point (heart rate) can have on my ability to control various physiological states. I saw over the course of several weeks that I was able to control my heart rate and respiratory rate simply by being more aware of what was actually happening.

As in any "conversation", feedback is usually good. I am excited to further investigate the potential for feedback, both on the user/patient side and on the medical professional side, in an effort to better understand the human body and the treatment of human disease states.

Final Project//Personal Health Diagnostic Tool

For my final project in Physical Computing I will attempt to bring together a limited prototype of my dream device that was conceived earlier in the semester, the Personal Health Diagnostic Tool. I envision this device allowing a patient/user to collect a number of different diagnostic data points in a continuous fashion. I also envision this device allowing a patient/user to associate symptoms with multiple data points in an effort to better understand their body and disease/malfunction. I see this tool as a way to add to the conversation and practice of evidence based medicine that will allow for more well informed decision making for medical professionals and better understanding and greater ownership of one's own personal health.


For my final project are several areas I would like to look at more in depth:

1) New programming frameworks. I would like to look at some new frameworks in an attempt to continue to synthesize my knowledge and understanding of overarching programming concepts.

2) Gathering of personal health/medical data. I would like to begin to understand the ramifications and implications of gathering personal health data and its display and cataloging for later use.

3) Interface and data presentation implications for both patients/users and medical professionals.

Robotic Arm/Hand

For my midterm project in Physical Computing I decided to get, well, a little physical. In collaboration with my partners Chris and Marie, I made a robotic hand and arm that responded to the movement of an operator's hand, finger, and arm movements.

This was easily the largest mechanical (see moving parts) project that I have ever worked on and presented a number of design challenges.

My responsibility was the design and build out of the mechanism that would control the hand and arm. On numerous occasions this project resulted in me starting endlessly at my hand as it grasped something or my arm as it rotated. This turned into a full fledged study of the mechanics of the hand and arm of the human body.

I started out prototyping the servo motors we used in an isolated finger system.

It was important to me that our entire system, especially the hand and fingers, were as realistic and representative as possible. I knew the prototype was not going to cut it and so started looking for alternative solutions for the fingers and hand. I knew the key would be creating an antagonistic system (similar to the one that exists in your arm) to control the fingers. Below is a video that documents a bit of the journey from one wooden finger to a system that contained 4 moveable fingers (thumb and index interacted together) and a moveable "forearm" with 2 degrees of freedom.



We eventually settled on a design that would utilize the flexibility of plastic to "passively" restore the fingers to their locked out position. The servomotors would shorten the string attached to the tip of the finger when we wanted a flexion out of a particular finger. This is extremely similar to the system and operation of the human fingers. Below is our finished product. As can be seen, we control the hand with a glove that utilizes 4 flex sensors to move the fingers and a stretch sensor to sense when the forearm is moved and Processing to sense when the entire arm is moved on the X axis.

"Finger" prototype w/servo

Below is my work from the evening of 10/16/2009...My initial effort was to understand and reverse engineer the human hand, specifically a finger. Here is a video that illustrates my final design of the evening that attempts to mimic the functionality of a human finger. This is the first layer of what will hopefully be a part of my group's midterm project in Physical Computing.

My process was to consider what I know about the human hand and attempt to engineer this functionality (or a small percentage of) in the form of an automated finger. As can be seen, I started with a double jointed finger design. This was relatively hard to control and lead to my second iteration which was a single jointed finger that gives the ability to grasp and object when added to an opposable "thumb".

Moving Box Arduino/Serial

I was just messing around this afternoon trying to learn processing and came up with this sketch. It allows you to use a variable sensor to move a box or other object in processing.

/*
Sensor Graphing Sketch

This sketch takes raw bytes from the serial port at 9600 baud and graphs them.

Created 20 April 2005
Updated 5 August 2008
by Tom Igoe
Modified 14 October 2009
by Chris Anthony
*/

import processing.serial.*;
int xpos = 0;
int xpos2 = 0;
int smallByte = 0;

Serial myPort; // The serial port
int graphXPos = 1; // the horizontal position of the graph:

void setup () {
size(600, 500); // window size

// List all the available serial ports
println(Serial.list());
// I know that the fisrt port in the serial list on my mac
// is usually my Arduino module, so I open Serial.list()[0].
// Open whatever port is the one you're using.
myPort = new Serial(this, Serial.list()[0], 9600);

// set inital background:
background(48,31,65);
}
void draw () {
// nothing happens in draw. It all happens in SerialEvent()

}

void serialEvent (Serial myPort) {
// get the byte:

int inByte = myPort.read();
// print it:
println(inByte);

smallByte = inByte/10; //divide by 10 so that it goes slower

xpos = xpos2 + smallByte;
background(48,31,65); //important this goes here
rect(xpos, 20, 75, 75);
if (xpos > width) {
xpos = 0;
}
xpos2 = xpos; //swap variables

}

Here is product in action...

Interactivity Observations

We were given an assignment this week in Physical Computing that required the following:

Observation. Pick a piece of interactive technology in public, used by multiple people. Write down your assumptions as to how it's used, and describe the context in which it's being used. Watch people use it, preferably without them knowing they're being observed. Take notes on how they use it, what they do differently, what appear to be the difficulties, what appear to be the easiest parts. Record what takes the longest, what takes the least amount of time, and how long the whole transaction takes. Consider how the readings from Norman and Crawford reflect on what you see.

For this assignment, I decided to use both my extended experience with and observations of the NYC subway entrance process.



I have both experienced and observed the NYC subway entrance experience be troublesome in every step of the interaction, from initially deciding which direction the Metro Card should face when being slid, to the anxiety that is felt as you slide your Metro Card if you are unsure how much fare is left on the card. In addition, as exampled by the previous video, making one's way through the vertical or horizontal turnstile with any amount of groceries, gear, or luggage can be a true adventure in spatial awareness. All of these problems can lead to rushing to catch the next available train, and as most New Yorkers can attest, this is usually an act that is done with a certain level of anxiety and disregard for the one's own physical health and the health of those in the way.

What I have noticed in my experience and observations is that the NYC subway entrance experience can easily frustrate the potential rider who is attempting to gain entry through the subway turnstiles and also the potential riders who are waiting in line behind the rider in question. I observed this experience only heighten the anxiety of catching the next train in order to achieve arrival at a rider's destination on time.

Below are the major categories of frustrating user interactions with subway entry I noticed:

Sliding your card
For the first time subway rider, figuring out which way the card faces as it is slid can be confusing. Though it is true the card has the magnetic strip that is actually read on only one side, knowing which way to put this into the card slider can be confusing. There is a diagram on the card slider that indicates the direction the card should be slid but nothing that indicates which way the card should face as it is slid. For an experienced New Yorker this is an afterthought. We all know the card faces us (faces in) as we "swipe" to go through the turnstile. However, an unknowing tourist or preoccupied rider could easily mistake which way the card should face as it is slid causing a quick backup during busy subway conditions.

Card reader
Personally, my most frustrating experience with the subway system is my card not being read properly. When I am in a hurry, my MetroCard can be slid at a rather high velocity that at times does not allow for the card to be properly read. The problem with this system is that by the time I alerted that my card has not been properly read I am usually nearly falling over the turnstile due to its not releasing. I then have to go back to the card slider and attempt to do the whole process again. Fortunate for me, I have experience attempting to run over defensive backs on the football field, for the less physically experienced subway rider, this sudden stop of momentum can be jarring and even painful. Having to redo the whole process also slows the subway line and in my observation creates many a frustrated potential subway rider.

Turnstile operation
If a rider's Metro Card is both held and slid properly, getting through the turnstile can be a physically rewarding feat. The horizontal turnstiles create a nice experience of getting through something that would normally seek to oppose. In my experience, most people like the feeling of accomplishing something physical even if it is an often overlooked experience like physically powering the subway turnstile.

In my observation, one of the problems when navigating the turnstile is when a potential rider has more than one bag or a large object like our NYC surfer from the video above. Multiple bags or large objects can require a user to contort his or her body and use muscles not normally accessed. The vertical turnstile confronted by our surfer in the video is especially notorious for how difficult it is to navigate with multiple bags or even one medium to large bag.

When confronting the vertical turnstile with multiple bags or large items it is necessary to think ahead and not start to turn the turnstile before all of your gear is in with you.

When is the train coming?
If you setup camp near any subway entrance in NYC you will certainly see a great number of potential riders scurrying down the stairs attempting to expediate the subway entrance process. This is logical as it gives a rider the best possible chance for catching the greatest amount of trains. I observed this phenomena start what I would call a "cascade" of feeling rushed which should certainly cause mistakes and lack of clear thinking that could directly lead to problems in the previous three areas.

Conclusion
I observed these four areas both frustrate and consume undo energy from potential NYC subway riders. I think it is possible to address some of these problems with solutions that would make riding the subway a more enjoyable and less stressful (and painful) experience.

I will detail some potential solutions in suggestions in a following post.

Arduino/Serial Communication/Processing

This week we started to learn about serial communication. Serial communication allows us to send (or receive) data from another device. The other device can then use the data if a program on the device is able to access the serial port where my initial data is coming from. This was a fun lab and the implications are also fun. This lab starts to show the possibility of gathering data in the physical world via Arduino and doing something useful with it on a more powerful and robust computational device.

In this example, I am going to gather data with an Arduino microcontroller and an FSR.




I am then going to send this data to my computer via a serial connection and port and allow a fun little program called Processing to play around with it. Specifically, processing is going to be graphing my FSR data. When Processing receives a "high" value from my sensor that corresponds with a strong squeeze of my FSR, the graph will correspondingly go up.

First, the code for the Arduino is as follows:

int analogPin = 0;
int analogValue = 0;

void setup()
{
// start serial port at 9600 bps:
Serial.begin(9600);
}

void loop()
{
// read analog input, divide by 4 to make the range 0-255:
analogValue = analogRead(analogPin);
analogValue = analogValue / 4;
Serial.print(analogValue, BYTE);
// pause for 10 milliseconds:
delay(10);
}


This code is simply reading my FSR and printing the value as a byte in the serial monitor.

As previously mentioned, in order to do something useful with the data, I need to have another program access this data. In this instance I'll use Processing. Processing will take my values and create a graph that has the sensor byte value on the Y axis and time on the X axis.

Here is the Processing code:

/*
Sensor Graphing Sketch

This sketch takes raw bytes from the serial port at 9600 baud and graphs them.

Created 20 April 2005
Updated 5 August 2008
by Tom Igoe
*/

import processing.serial.*;

Serial myPort; // The serial port
int graphXPos = 1; // the horizontal position of the graph:

void setup () {
size(400, 300); // window size

// List all the available serial ports
println(Serial.list());
// I know that the fisrt port in the serial list on my mac
// is usually my Arduino module, so I open Serial.list()[0].
// Open whatever port is the one you're using.
myPort = new Serial(this, Serial.list()[0], 9600);

// set inital background:
background(48,31,65);
}
void draw () {
// nothing happens in draw. It all happens in SerialEvent()
}

void serialEvent (Serial myPort) {
// get the byte:
int inByte = myPort.read();
// print it:
println(inByte);
// set the drawing color. Pick a pretty color:
stroke(123,128,158);
// draw the line:
line(graphXPos, height, graphXPos, height - inByte);

// at the edge of the screen, go back to the beginning:
if (graphXPos >= width) {
graphXPos = 0;
// clear the screen:
background(48,31,65);
}
else {
// increment the horizontal position for the next reading:
graphXPos++;
}
}


ONE NOTE...When you load your Processing sketch, you must have your Arduino plugged in and running the aformentioned program. You need this so that the Processing code that looks at serial ports will capture the correct serial port. ALSO, this code works for Mac's as the first serial port that comes up in Processing is the serial port we want to access:

myPort = new Serial(this, Serial.list()[0], 9600);


This code in our Processing program is telling our program to access the first serial port in the array returned by this code:

println(Serial.list());

It might be slightly different on a PC.

Here is the finished product in action...