What I am looking to do is build a wooden box about 3ft high with a pulley system inside that will tilt an accelerometer when the ropes are pulled. This will in effect send data through the Arduino to Processing and work with my program.

I spent a day or so constructing this box that will be large and durable enough to with stand people pulling and tugging at it.

The difficult part was figuring out a way to have the accelerometer tilt to a side when a rope is pulled then retract in it's orginal position. I wasn't aware of any hinge that did this and wasn't exactly sure how to do it.

After a lengthy conversation with my father, he recommended this bungee system inside the box. Which actually works rather well. The bungee does a nice job of making the user pull and stretch the rope giving the feeling really pulling something. Then when released it will immediately go back to the orginal position.

As you see here.

The Basic Idea:
A winter glove that will control your iPod through touching your fingers and shaking your wrist to control the volume, switching tracks and turning it on and off. Here are some sketches drawn up by Hatti who is one of the other people I am working with on this project:

I also found some websites of other people who have hacked iPod remote controls along with a guy who did something very similar:

iPod Remote Control Protocol
Controll an iPod with gestures

I already turned an LED on so I thought it would be fun to try something involving the programming side of the Arduino. Luckly I was working with Yasmin, who was a Programmer in her previous life. We decided to try a combo lock.

IDEA :: Combo Lock
Our idea was to create a combination lock that requires 2 switches to be on, and the 3rd switch needed to be clicked 3 times consecutively to open the lock. We signified this w/ 2 yellow LEDs lighting up. Any wrong combo would result w/ a 3rd green LED emiting light. The difficulty of this combo lock was:
1. Our switch was the "state" switch (for lack of the tech-term), in which you do not know the state of it - hrigh or low. So we needed a way to consider 3 clicks, or rather 3 toggled state changes in sequence.
2. The Arduino's main function is the loop function wich iterates in the range of milliseconds. So in order to sample the state of our switch in time, and click it before the loop iterates, we need to force a delay.

So the main algorithm behind the program was having 3 state variables for the three switches, plus an additional previous state (prevState) variable which will save the last state of the 3rd switch., so we can check for the 3 toggled state changes. Also I added a delay of 500 ms.

This algorithm worked, but when the combo was "unlocked" the LEDs would blink very briefly, b/c of the new loop iteration. But it wasn't a good design b/c of the speed of sampling and coinciding it with the clicks.

Bottom line: We decided that using a regular on/off or toggle switch for a combo lock isn't the best idea. We just didn't have any other resources.

Here is the Code we used

//************VARIABLES****************
int input = 12; // DIGITAL INPUT TO THE MUX
int d= 5; // SELECT PIN D GOING INTO PIN 5
int c= 4; // SELECT PIN C GOING INTO PIN 4
int b= 3; // SELECT PIN B GOING INTO PIN 3
int a= 2; // SELECT PIN A GOING INTO PIN 2
int pin9 = 9; // OUTPUT FOR THE RED LED INTO PIN 9
int pin8 = 8; // OUTPUT FOR THE WHITE LED INTO PIN 8
int pin10 = 10; // OUTPUT FOR THE GREEN LED INTO PIN 10
int pin11 = 11; // OUTPUT FOR THE YELLOW LED INTO PIN 11
int time;

//***********ARRAY TO STORE THE VALUES FROM THE MUX*********************
int val[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
//************DIGITAL VALUES TO CONTROL OUR 16 INPUTS*******************
int d_bin[]={LOW,LOW,LOW,LOW,LOW,LOW,LOW,LOW,HIGH,HIGH,HIGH,HIGH,HIGH,HIGH,HIGH,HIGH};
int c_bin[]={LOW,LOW,LOW,LOW,HIGH,HIGH,HIGH,HIGH,LOW,LOW,LOW,LOW,HIGH,HIGH,HIGH,HIGH};
int b_bin[]={LOW,LOW,HIGH,HIGH,LOW,LOW,HIGH,HIGH,LOW,LOW,HIGH,HIGH,LOW,LOW,HIGH,HIGH};
int a_bin[]={LOW,HIGH,LOW,HIGH,LOW,HIGH,LOW,HIGH,LOW,HIGH,LOW,HIGH,LOW,HIGH,LOW,HIGH};

//aux
int close=0;
int open=0;
int a_val=0;
int b_val=0;
int c_val=0;
int d_val=0;

//**************OPENS SERIAL***************
void setup()
{
beginSerial(9600);
pinMode(input, INPUT);
pinMode(c, OUTPUT);
pinMode(b, OUTPUT);
pinMode(a, OUTPUT);
pinMode(d, OUTPUT);
pinMode(pin11, OUTPUT);
pinMode(pin10, OUTPUT);
pinMode(pin9, OUTPUT);
pinMode(pin8, OUTPUT);
}
void loop() {
for(open=0;open<=15;open++)
{
//************SELECT MUX INPUT*************
a_val=a_bin[open];
b_val=b_bin[open];
c_val=c_bin[open];
d_val=d_bin[open];

digitalWrite(a,a_val);
digitalWrite(b,b_val);
digitalWrite(c,c_val);
digitalWrite(d,d_val);
delay(1);

//***************READ VALUE*******************
val[open] = digitalRead(input); // read input value

Serial.print("For pin ");
Serial.print(open,DEC);
Serial.print(" we are getting ");
Serial.println(val[open]);
delay(300);
}
//*******************IF STATEMENT****************
int greencount = 0;
for (int jj=0;jj<16;jj++)
greencount = greencount + val[jj];
if(greencount == 0)
{
digitalWrite(pin10,HIGH);
}
else
{
if(greencount != 0)
{
digitalWrite(pin10,LOW);
}
}

if ((val[0] == 0) && (val[1] == 0) && (val[2] == 1) && (val[3] == 0) && (val[4] == 0) &&
(val[5] == 0) && (val[6] == 1) && (val[7] == 1) && (val[8] == 0) && (val[9] == 1) &&
(val[10] == 1) && (val[11] == 0) && (val[12] == 0) && (val[13] == 1) && (val[14] == 1) &&
(val[15] == 1))
{
digitalWrite(pin8, HIGH);
digitalWrite(pin9, LOW);
digitalWrite(pin10,LOW);
Serial.println("WINNER!!!!!!!!!!!!!!!!!!!!!!!!!");
}
else
{
int ii;
int total_count = 0;
for (ii = 0; ii < 16; ii++)
{
total_count = total_count + val[ii];
}
if ( total_count == 4 )
{
digitalWrite(pin8, LOW);
digitalWrite(pin9, HIGH);
digitalWrite(pin10,LOW);
Serial.println("THERE IS FOUR ON!!!!!!!!!!!!!!!!!!!!!!!!!");
}
if (total_count == 7 )
{
digitalWrite(pin11, HIGH);
digitalWrite(pin9, LOW);
digitalWrite(pin8, LOW);
digitalWrite(pin10, LOW);
Serial.println("YOUR GETTING CLOSE!!!!!!!!!!!");
}
if ((val[0] == 0) && (val[1] == 0) && (val[2] == 1) && (val[3] == 0) && (val[4] == 0) &&
(val[5] == 0) && (val[6] == 1) && (val[7] == 1) && (val[8] == 0) && (val[9] == 1) &&
(val[10] == 1) && (val[11] == 0) && (val[12] == 0) && (val[13] == 1) && (val[14] == 1) &&
(val[15] == 1))
{
digitalWrite(pin8, HIGH);
digitalWrite(pin9, LOW);
digitalWrite(pin10,LOW);
Serial.println("WINNER!!!!!!!!!!!!!!!!!!!!!!!!!");
}

for ( ii = 0; ii < 16; ii++ )
{
serialWrite(val[ii]);
}
}
delay(10);
printNewline();
Serial.println("Time: ");
time = millis();
Serial.println(time);
}

The Following Day:
We did find some code from the Arduino website to start with, but we weren't even sure if the Multiplexer worked. We we started working with the Serial to see what kind of outputs we were getting. This led to hours of watching different varations of 0's and 1's run through the Serial for various reasons. Unfortunately none of the reasons made much sense to us. We were convinced the problem was within our code so that is where we spent most of our troubleshooting.

It wasn't until Ben Chao looked at our code, rewrote some of it and then troubleshooted our breadboard that we realized some of our mistakes. As you see below, we forgot to run power to all our switches on the left side. But our big problem was the face we weren't grounding our switches before running them into our Multiplexer. This caused an incomplete circuit making it impossible for the Arduino to read anything.

It was really helpful to have someone with a programming background help us out because instead of thinking the code was the problem, he helped us realized it was actually the wiring.

Now using the Multiplexer's datasheet we filled in the array from the orginal code and we are now able to see each switch through Serial. Yipee!!!

Here is our code at this point. [Code]

Liz and Allister discovered a way of coding the 16 switches using something called Row-Column Scanning. Allister also purchased a Multiplexer for another possible solution. Here is what we discovered:

We didn't want to use the Multiplexer at first because we have never used a Multiplexer and from what we gathered there is no documentation on using a Multiplexer with an Arduino. So Row-Column Scanning was our first choice.

We were able to wire the board with the 16 switches allowing each row to turn on a corresponding LED.

This is where we ran into our first issue with our 16 switches. The way Row-Column Scanning works is that you have to have a pin for every row and column. Which in our case is a total of 8 pins considering we have 4 rows and 4 columns. That means we have 8 pins for the rows and columns in addition to our 4 LEDs coming out of our Arduino as outputs. We realized we don't have enough pins. So Row-Column Scanning will not work.

On to the Multiplexer...

Allister took a picture of the Multiplexer's datasheet at the store he bought it at. We then spent most of the night trying to figure out what it all meant. After getting a pretty good idea of how the Multiplexer is setup we asked a friend who has used Multiplexer's before if she could help. This is where we discovered the problem with the Multiplexer. Apparently the way a Multiplexer works is managing 16 inputs with only 4 switches. This will not work for our idea since we need each of the 16 switches to work independently of each other. So now we are under the impression the Multiplexer will not work.

Here is some info on Multiplexers that was helpful:
Wiki - Multiplexer
Thread on using an Analog Mux with the arduino

After brainstorming other solutions the same friends who said it wouldn't work said if we use the Multiplexer is a different way we could have the result we are looking for. She explained if we used the Multiplexer to scan all 16 inputs then using the 4 selects (data inputs) in the Multiplexer we can write a loop that will constantly scan the 16 inputs to see which combination is turned on. So we went with it.

Allister than cut a board so we could keep everything together:

Everything is wired and now ready for the coding.....we hope:

By the way we are using a 16:1 Digital Multiplexer and the datasheet Allister found is here.

We then wired a paper matt we made using tin foil for our switches.

Tuesday, Oct. 10th: We had our third meeting. It seemed like we were worried about creating an idea based on our observations. However, settled on something very quickly and become working out the technical problems.

Our Idea:

Twister is a game that is familiar to all of us. It has alot to do with motion but what if it had more to do with dancing? What would that game be like? We decided to try and create a musical version of Twister. This game would be played by two people who might like to dance together. Here's what it would look like.

The people playing will step on the circles. If they get the wrong combination the red light and a buzz will go off. If they get the right combination then the blue light will go off and a song with play. The goal is to get the right combination.

Problems with the Idea

We thought we should use pressure sensors to communicate with the arduino. These sensors would tell the arduino when someone stepped on the circle. However, we soon discovered that these sensors are expensive and hard to find. The computer store did have touch sensors but these too were expensive.

Allistar and Liz talked to Dan Shiffman and he gave us some helpful advice. We realized we didn't need a sensor we just needed to create a switch that people would step on. These could be made easily out of foil. It was amazing to realize that we just needed to think about things differently to make it work!

The group decided on dancing for our motion but I don't see any significant way of using technology to re-invent dance moves so my approach has more to do with the social interaction while dancing. A common thread we all seem to share is the approach or denial of dancing with someone while at a club or bar.

Dancing is such a non-verbal action that even if one person is not interested in dancing with another person they typically won't verbally express it. It can take multiply hints of dancing away from the person or turning their back to them in order to discourage them from dancing with you. It is very rare that it will be verbally expressed.

So I thought if there was a way of communicating with each other while dancing without having to verball say anything that could help engage people or disengage people from dancing with each other.

Right now, I feel the best way would be some kind of lighting system that could be worn which could have three positions, Red, Yellow, Green. So if you had a Red light on, that means you are perfectly content in dancing alone or with the people you currently have around you. If the light is Green, you are open to people approaching you to dance. And if you have the light on Yellow, then you can send mixed signals which can be neither stay away or I'm open to anyone.

I would have to be obvious enough that other people could see it but suttle enough that it won't be terrible distracting.

We all agreed in having similar situations of indirectly and directly observing people dance. I personally wasn't sure where we would be able to go with this idea until I left the group and sat down to start my ICM homework. Then I remembered Allister and Liz talking about the situation when a guy or girl has trouble communicating with a dance partner. Since dancing is typically a non-verbal action, the communication between partners is usually non-verbal, so could there be a non-evasive device that could be used to communicate with dance partners????

The user will always keep the controller in their hands even when the game is on pause. The more experienced the user the more fluid their movements. A user just learning will occasionally look down at the controller to see which buttons they are pushing, while an experienced user will know exactly which buttons they are pushing at all times.

The worse the person is doing in the game the more movements using their entire body. As though if they use more of their body they will get more response from the remote control. The closer the game is between the users the closer each user will lean in to see the screen.

The most strenuous part of playing the game would be the use of the user's thumbs. If the user does well in the game or loses there is typically a vocal response.