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".
Sunday, October 18, 2009
Thursday, October 15, 2009
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...
/*
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:
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.
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...
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...
Thursday, October 8, 2009
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();
}
}
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();
}
}
Saturday, October 3, 2009
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
}
}
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.
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.
Thursday, October 1, 2009
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...
Subscribe to:
Posts (Atom)