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...

Helmet Concussion Sensor Design/Application

For our project this week in PComp, we were asked to get a little creative and use the knowledge we have gained from the first month of class to come up with a Stupid Pet Trick. This project had a few parameters, mainly that we gather information from the analog world and do something with it via our Arduino Microcontroller and some programming language. I had several ideas, but fell back on something that "hits" close to home for me.


Head trauma and concussions in the world of football.

As a long time athlete, I witnessed many head trauma incidents in the world of football. I have also witnessed the arbitrary testing that goes on to diagnose concussions as well as player avoidance of medical staff after a concussive event has occurred. Recently, there has been new information brought forward on head trauma and dementia in the world of sports. The New York Times broke a story recently that former NFL players ages 30-49 suffer dementia at 19 times the national average. This is alarming to say the least and only heightens the need to further understand these traumatic events and seek to protect players immediately.

Briefly, the head trauma that is incurred on the football field is due to acceleration (also think deceleration) events. The brain sits suspended in a liquid medium, Cerebral Spinal Fluid (CSF). As the head and helmet are quickly accelerated, the brain has no where to go as the CSF can only minimally slow the brain down in these events. The greater the acceleration, the greater the force and impact the brain will incur inside the skull both linearly and rotationally...Force=Mass x Acceleration in linear systems and (Mass x V^2)/R in rotational systems...(Video).

We can think of accelerations in terms of "G's". G's are normally spoken of as G-Force, this is somewhat of a misnomer as G's are actually accelerations, but are easily understood as force through F=ma. 1 G is equivalent to gravity here on earth, 9.8 m/s/s. For a number of years, it has been common convention to assume that concussive events are correlated with accelerations of ~75 G's or more. Once recent North Carolina study had this to say:

"In football, a hit can easily jerk the head, for milliseconds, at 50g, and hits above 100g are common. One player in the study experienced 168g. It was previously suggested that a forces above 75g would likely result in a concussion, but these new results call into question that finding.

The UNC studies showed that some players suffered concussions at little more than 60g, while others sustained hits creating more than 90g and showed no signs of concussions; less than .35 percent (only one-third of one percent) of impacts greater than 80g resulted in concussions."

Given this and other studies/data, it is clear the sports world must urgently seek to find out more about the mechanisms of head trauma in football and to protect the millions of grade school, jr high, high school, college, and professional athletes who play full contact football on a weekly basis.


What I have come to hope for is a device that would signal coaches, medical staff and game officials that a potentially traumatic event has occurred with a player's head. To this end, I took the liberty of heading in the general project direction of Mom, I want to play football but don't want to suffer undo brain trauma Pet Trick. This is what I came up with:

I designed a system that would utilize an accelerometer (or an array of accelerometers in future versions) to detect linear and rotational accelerations due to activity on the football field. If a threshold level of acceleration was reached, a conductive sticker or other outward display would change from white to red on the back of the players helmet. This would immediately signal to medical staff, coaches, and officials that the player needs to come out of the game to be examined. The sticker, depending on its construction, could either be reset or discarded and another sticker could be placed in the system for further use. My number one design principle while looking at this problem was to communicate a potentially concussive event with a minimal amount of resources (cost).

For my prototype, I used a 3-axis accelerometer that can sense up to 3G's. This is obviously a lower G threshold than almost all concussive events, but this accelerometer was an extremely low cost option for the prototype. If an event of 3G's (or whatever level I set in my code) is detected in the prototype, 5V is sent to a red LED on the back of the helmet (emulating the sticker).


And here is the system in action. The LED will light up and stay lit up for 3 seconds every time a threshold acceleration (2.5G's in this video) or greater is sensed.







Currently, there is a system in limited production that is being tested by several major college teams. This system is very robust and signals to a computer on the sideline when a concussive event has occurred. This is fantastic. The technology used is the HIT system developed by Symbex. This technology was acquired by helmet maker Ridell costs $80,000 per team to implement (about $1000/player).



I hope to continue to develop this technology in the coming weeks and months. More than this, I hope that the sports world will focus itself on solving this problem and protecting the young and professional athletes who play all contact sports.

CODE

/*This program allows for the detection of accelerations using a three axis
accelerometer (ADXL 3xx)..Originally referenced Tom Igoe/David A. Mellis code
http://www.arduino.cc/en/Tutorial/ADXL3xx

created 2 Oct 2009
by Chris Anthony

*/

const int groundpin = 19; //Setting groundpin to Analog pin 5
const int xpin = 4; //x axis readings of accelerometer
const int ypin = 3; //y axis readings of accelerometer
const int zpin = 2; //z axis readings of accelerometer
int ledPin = 6; //digital pin that turns on our LED
int a = 0; //x axis
int b = 0; //x axis
int c = 0; //y axis
int d = 0; //y axis
int e = 0; //z axis
int f = 0; //z axis
long lastPulse = 0; //for millis fx
int refreshTime = 5; //for millis fx


void setup()
{
// initialize the serial communications:
Serial.begin(9600);

pinMode(groundpin, OUTPUT); //This code turns the groundpin
digitalWrite(groundpin, LOW); //into a voltage sink=ground.
pinMode(ledPin, OUTPUT); //tell our ledPin to output voltage when commanded
a = (float)analogRead(xpin); //this is for the x axis
c = (float)analogRead(ypin); //this is for the y axis
e = (float)analogRead(zpin); //this is for the z axis
delay(5); //I use this delay just in void setup to attempt to mimick millis, this is used just once
}

void loop()
{
if (millis() - lastPulse >= refreshTime) {
b = (float)analogRead(xpin);
d = (float)analogRead(ypin);
f = (float)analogRead(zpin);
//Code below is coming up with a final vector that takes into account the
//vectors of all three axes. If this final vector is greater than 200, which is
//equivalent to 2.5G's with 3.3V input to acclerometer, we turn on the LED
//note that with this setup 1 G will be equivalent to a change in ~70
//on your serial monitor. This is where we get 175 in below math
if (sqrt(sq(a-b) + sq(c-d) + sq(e-f)) > 175) {
digitalWrite(ledPin, HIGH);
delay(3000); //this code keeps LED on for 3 seconds just for interaction purposes
}
else digitalWrite(ledPin, LOW);
a = b; //we swith our variables so we can now look at the 3 set of readings
c = d; //compared to the second set.
e = f;

Serial.print(analogRead(xpin));
// print a tab between values:
Serial.print("\t");
Serial.print(analogRead(ypin));
// print a tab between values:
Serial.print("\t");
Serial.print(analogRead(zpin));
Serial.println();

lastPulse = millis();
}
}

Servo Lab/Lab 4

This week we learned about pulse width modulation (PWM). This is where we use a digital signal to act like an analog signal. This happens by changing the frequency of digital pulse's through our system (which obviously corresponds to width of pulse). To learn more about PWM, duty cycle, and extended information about using digital signals to communicate in an analog world, check out this article.

This lab was really exciting for me as it was the first time we used a transduced input and used it in such a way as to immediately affect our world in a physical manner. This was really fun and I am excited about using multiple arrays of servos + motors + gears to create mechanically robust entities.

/*
Servo control from an analog input

The minimum (minPulse) and maxiumum (maxPulse) values
will be different depending on your specific servo motor.
Ideally, it should be between 1 and 2 milliseconds, but in practice,
0.5 - 2.5 milliseconds works well for me.
Try different values to see what numbers are best for you.

This program uses the millis() function to keep track of when the servo was
last pulsed. millis() produces an overflow error (i.e. generates a number
that's too big to fit in a long variable) after about 5 days. if you're
making a program that has to run for more than 5 days, you may need to
account for this.

by Tom Igoe
additions by Carlyn Maw & Rob Faludi
Created 28 Jan. 2006
Updated 10 Jun. 2008
*/

int servoPin = 2; // Control pin for servo motor
int minPulse = 500; // Minimum servo position
int maxPulse = 2500; // Maximum servo position
int pulse = 0; // Amount to pulse the servo

long lastPulse = 0; // the time in milliseconds of the last pulse
int refreshTime = 20; // the time needed in between pulses

int analogValue = 0; // the value returned from the analog sensor
int analogPin = 0; // the analog pin that the sensor's on

void setup() {
pinMode(servoPin, OUTPUT); // Set servo pin as an output pin
pulse = minPulse; // Set the motor position value to the minimum
Serial.begin(9600);
}

void loop() {
analogValue = analogRead(analogPin); // read the analog input
pulse = map(analogValue,0,1023,minPulse,maxPulse); // convert the analog value
// to a range between minPulse
// and maxPulse.

// pulse the servo again if rhe refresh time (20 ms) have passed:
if (millis() - lastPulse >= refreshTime) {
digitalWrite(servoPin, HIGH); // Turn the motor on
delayMicroseconds(pulse); // Length of the pulse sets the motor position
digitalWrite(servoPin, LOW); // Turn the motor off
lastPulse = millis(); // save the time of the last pulse
}
}

Electronics Lab/ Lab 3

This week we dove deeper into what is actually going on with our circuits and the theory behind our applications. We also learned how to solder and use a voltage restrictor in order to take power in from alternative resources. This was a fun lecture for me as I am interested in knowing what is going on behind the scenes.

Here are some good resources for information on electricity and how it relates to what is actually going on in a circuit or project build-out:

Read about electricity.

Good video to visualize what electricity is actually doing.

And some formulas that will prove helpful.

Physical Prototype Personal Medical Diagnostic Tool

I created several prototypes of my previously proposed Personal Medical Diagnostic Tool. I used the prototypes to gain an understanding of common every day usage and how this would be relevant for personal and community health. My most interesting discovery was that I commonly was pressing the "Mark" button to record an event of when I had a pain, slight headache, or stomach discomfort.

In my testing, it seems that this device would open up a new area of health care evaluation and treatment. In recording the diagnostics at the time of my "Mark" event, this information could be evaluated by my device or by a physician in order to correlate the data with known pathology etc. or with previously marked events.

It also was comforting to know that if anything went wrong, or started to go wrong but would go unnoticed by me, the Personal Health Diagnostic Tool would alert me to this information.

I also prototyped a system of interconnected proteins or nano-structures that would communicate to the device.

I will continue to conduct more studies and play around with the prototype. Will report back soon...

Dream Device/Personal Health Diagnostic Tool

This week we were asked to design our "dream device". This could be anything we want, though, it had to be something we couldn't readily build, something that stretched our imaginations.

I knew immediately what I wanted to design. For a while I have been thinking about the state of our health care system and what the future of medicine and health care holds for me, my family, and friends.

A confluence of thoughts for me in this area has been the idea of "personalizing" medicine and health care. We are on the brink of being able to implement technology that will allow us to track our health in a minute by minute fashion. I believe this technology will empower individuals to learn more about their bodies and ultimately receive better and more comprehensive care. The following is my vision for one of the ways this might manifest in a device.





The links below will help to give a better understanding of the technologies that will be deployed inside the human body in order to enable the Personal Human Diagnostic Tool. There are also several animations that show the scale and level on which this device will gather information.


Wikipedia on Carbon nanotubes and applications
http://en.wikipedia.org/wiki/Carbon_nanotube


Article on using Y shaped carbon nanotubes as transistors (switches)
http://www.scienceagogo.com/news/20050715001807data_trunc_sys.shtml

Animation of inter-workings of cell. This gives an idea of the scale on which this device would gather information.Animation

Animation of how cells and proteins communicate. This allows us to see and envision the proteins and structures we could build that would detect various phenomena in the body and signal to an outside device what is happening.Animation

Animation of how we can engineer and build proteins into structures of our choosing.Animation

Playing with IF statements

Had a lot of fun today with IF statements and derivatives...Here is some code and video from my experimentation today.

This code turns on and off 3 LED's depending on the amount of force sensed by a Force Sensitive Resistor.

////////////////////
///////////////////
int potPin = 0;
int ledPin = 3;
int ledPinA = 5;
int ledPinB = 6;
int potValue = 0;

void setup()
{
Serial.begin(9600);
pinMode(ledPin, OUTPUT);
pinMode(ledPinA, OUTPUT);
pinMode(ledPinB, OUTPUT);
}

void loop()
{
potValue = analogRead(potPin);

Serial.println(potValue);


if (potValue >= 600) {
analogWrite(ledPin, potValue / 4);
}
else analogWrite(ledPin, 0);

if (potValue < 600 && potValue > 500) {
analogWrite(ledPinA, potValue / 4);
}
else analogWrite(ledPinA, 0);

if (potValue <= 500 && potValue > 200) {
analogWrite(ledPinB, potValue / 4);
}
else analogWrite(ledPinB, 0);

delay(10);
}



_______________________________________________

The following code allowed for the use of two sensors and included some OR (||) statements.
////////////////////////////
///////////////////////////
int potPin = 0;
int potFlex = 1;
int ledPin = 3;
int ledPinA = 5;
int ledPinB = 6;
int potValue = 0;
int potFlexValue = 0;

void setup()
{
Serial.begin(9600);
pinMode(ledPin, OUTPUT);
pinMode(ledPinA, OUTPUT);
pinMode(ledPinB, OUTPUT);
}

void loop()
{
potValue = analogRead(potPin);
potFlexValue = analogRead(potFlex);

Serial.println(potFlexValue);


if (potValue >= 600 || potFlexValue < 450) {
analogWrite(ledPin, potValue / 4);
analogWrite(ledPin, potFlexValue / 4);
}
else analogWrite(ledPin, 0);

if (potValue < 600 && potValue > 500) {
analogWrite(ledPinA, potValue / 4);
}
else analogWrite(ledPinA, 0);

if (potValue <= 500 && potValue > 200) {
analogWrite(ledPinB, potValue / 4);
}
else analogWrite(ledPinB, 0);

delay(10);

}



_____________________________________________________

In this last snippet of code is a simple application of the "Hello World!" program using a sensor to tell a user if they are "strong" or not.

/////////////////////////////////
////////////////////////////////
int potPin = 0;
int potValue = 0;

void setup()
{
Serial.begin(9600);
}

void loop()
{
potValue = analogRead(potPin);


if (potValue >= 800) {
Serial.println("You are Strong");
}
else Serial.println("You are weak");

delay(10);
}



________________________________________________________

A lot of fun with this stuff. Really starting to see the giant world of possibility when combining the physical world with instructions.

Lab 2/Hello Analog World, meet my Arduino

I just finished lab 2. This lab allows us to start interfacing the analog (variable) world with the digital world of computation. I was primarily interested in using the variable resistors at our disposal to measure force and flexion. As I changed the resistance in the variable resistors with physical force, the LED in my circuit had a proportional voltage applied to it. This lab really started to open my eyes to the possibility we have to connect our physical world to the power of a computational device. Lots of ideas running around my head. Will keep you all updated.

Lab 1/Switch and LED's

I just completed my first lab. This was my first time building a circuti...ever. New experience from cutting wires to figuring out schematic of breadboard to figuring out the anode and cathode ends of a LED. Great to move from theory to application...Switch works great. One note for anyone programming Arduino->Save your file before you tried to upload it to Arduino...Side note= I now have lots of tools and electronic components, heh heh heh.

Sensor Walk

I just completed my "Sensor Walk" and had an interesting experience. Similar to my "mental sensor walk", I started at my apartment in Park Slope and walked to the subway at Atlantic Ave. I noticed many things along the way from ATM's, to street signals/lights, to apartment buzzer systems. I found my "gold mine" to be underground in the subway system. I found touch screens, magnetic(?) card readers (swipe and go), turnstiles, and subway doors. What struck me most about all of the sensors I encountered was what was required of me to get them to actuate. I found myself much more drawn to sensors that required more "dynamic" movement or force from me. For instance, I became fascinated with the subway turnstiles that allow you into the subway. I had never stopped to think about it before, but, these turnstiles require a force to be exerted on them in order for you to enter the subway. I decided I wanted to measure this force and so went home and got a scale (see pics below). I found that waist height turnstiles require approximately 3 pounds of force when operated as far as possible from the fulcrum (pivot or rotation point of turnstile). I also tested full-height turnstiles and found that these require approximately 5 pounds of force when measured from the middle of the "cage".

I found it interesting that I was much more drawn to interactions with sensors that required more of me (in terms of force) than interactions that were fairly easy, like the touch screen. This brings to my mind the different ways of interacting with subway turnstiles->

1) Lets say I'm in the mood to exert a larger amount of force over a shorter distance..I should try walking as close to the pivot point as possible. My torque is minimized here so I must personally produce a larger amount of force to get myself through the turnstile.

2) If I want to output less force but am willing to give this force over a longer range of motion, I should walk as far away from the pivot point as possible. This will maximize my torque but will require me to output a smaller amount of force (than 1) over a longer range of motion.

I think this exercise has made me aware of what is a personally rewarding experience with a sensor for me. I will trying to keep an account for interactions with sensors in the coming days and weeks that speak to these and other observations.

"Mental" Sensor Walk

One of my first assignments is to do a "sensor walk". This requires observing sensor applications in the every day world. Prior to this, I thought I would do a "mental" sensor walk...To do this, I will just imagine myself heading out from my apartment to my Physical Computing class in lower Manhattan. These are the things that come to mind:

Phone->Push Buttons, Voice Dial, Video Camera, Lens

ATM->Push Buttons

Subway Turnstile->slide card=GO

Subway Doors->Shut but will re-open if opposable force is applied.

Subway Temperature Controls->This might potentially work by having some type of temperature sensor that provides feedback to the heating/cooling system thus regulating overall T of each individual car. I think this might be true as I remember the air conditioning units seem to vary their output.

Subway door sound as doors close->Their is an automatic "ding ding" as doors are closing, sometimes automated voice as well "Stand clear of the closing doors"..I am assuming the conductor presses a button which closes the doors and that this button also triggers the "ding ding" and automated voice.

Horn->People in cars push rather large "buttons" on their steering wheel that results in a loud honk..Lots of this on Houston and Broadway.

Bathroom urinal at NYU Tisch->Sensor that detects my presence at the urinal. This seems to operate such that once I am close an "event" is started. Once I leave the urinal it flushes automatically...This could be interesting...Will probably check this out further.

Elevator Button->I press "^" to go to the fourth floor.

What is this?

This is my blog and record for the projects and discoveries I will encounter in my Intro to Physical Computing course at NYU. This course is part of the Interactive Telecommunications Program (ITP) at NYU and is an elective toward my masters degree program in Biological Engineering. I look forward to gaining an ability to create useful applications for the sports and medical worlds with the knowledge and insights gained in this course.