It's working!!

I finally figured out the error in the sample circuit in the large pillow. The + and - leads for the vibrator were both touching the vibrator housing, thus short circuiting and diverting the current around the vibrator.

Simple fix -- tape the leads down.

Yay!

*Old Post* Final Presentation - Concepts

***Old Post for Final Project. We eventually went to a new idea***

Yesterday, our team ( - Federico and + Katherine) started working on hashing out ideas for our final piece. We began by making a list of things we thought were fun and embodied play. Our list included things from bouncy castles to throwing paint.

At the end, our current idea (which still needs to be readjusted and fleshed out) is to make a two-room piece in which actions the audience performs in one room affect the dance performed in the next room. The audience will think that the first room is self-contained, and will be moderately entertained by playing around with things

Work Day 4.21

Work Day on Sunday Night 4.21

Debugging the electronics of the pillow creatures...

6:00-7:15
Started by talking to Catherine about what's currently wrong with each creature. I think the list is as follows:

Large Pillow:
      - None of the vibrators are working
      - Voltage connection to XBee is shaky
      - The voltages on the transistors are not very intuitive

Medium Pillow
      - Flex sensor data coming from pillow is not intuitive (We have no idea why it's sending what it's sending)
      - LEDs are not mapped to the correct flex sensors

Small Pillow
      - Unknown... Wait on this one

7:15-
Catherine has to go home, started working on understanding one isolated circuit of the Large pillow.

7:30 --taped down conductive thread connections, stopped flickering of power to circuit.

7:45 -- I think the voltages going into the vibrator are reversed...

8:00 -- No they're correct

--Break from 8:15-11--

11:13 -- The battery is dead. And the low battery has been causing a problem. It can't supply enough voltage for the Arduino to properly send out 5 volts on 5 pins. With the USB cable attached, the proper voltages are sent out.

     

Project Meeting 4/12/13

Project Meeting 4/12/13

Today's goals:
- Get two XBees connected.
- Get Pillow Creature 1 to talk to Touch Designer
- Get Touch Designer to receive data from Kinect

Find-a-conference/festival!!

While searching around the internet, I found a conference called SPLASH (Systems, Programming, Languages and Applications: Software for Humanity). The home page is here:

http://splashcon.org/2013/

This conference discusses how to use different systems and/or computing techniques to better integrate software with humanity. I thought our project would fit nicely here because our project deals with two different types of human/software integration: the Kinect, and a physical computing sensor blob.

Here is the website for the Student Research Competition:
http://splashcon.org/2013/cfp/due-june-28-2013/664-acm-student-research-competition

And here are the details involving submission:

Submission Summary
Due on:	June 28, 2013
Notifications:	July 28, 2013
Camera-ready copy due:	August 28, 2013
Format:	ACM Proceedings format
Contact:	Isil Dillig and Sam Guyer (chair)

Sketch 2 - Final Product

See my groupmate's blog to get a picture of the final product:

http://thomasrussellstorey.wordpress.com/2013/03/05/sketch-two-recap/

-Jonathan

Technical Side of Sketch 2

Sketch 2 involves a dancer, a Wii remote, and a visualization. Andrea is our dancer, Thomas and Federico took care of the visuals, and I took care of the Wii remote interaction.

We decided to use a Wiimote for this sketch for numerous reasons:
1) It can communicate over Bluetooth (meaning Andrea could dance where ever she wanted)
2) It has a clean interface for accessing the accelerometer, buttons, and infrared data.
3) The Visualization Department had them on site.

After deciding on the Wiimote technology, my job became how to use the wiimote to gather interesting information about a dancer's movements. I played around with the wiimote and a little wiimote pairing tool called DarwiinRemote that provided a nice graphical representation of the acceleration data (on all 3 axes) versus time. My discovery was the accelerometer reliably captured both human-made accelerations and acceleration due to gravity. So I decided to try an utilize both in our performance.

Acceleration due to gravity:
The acceleration due to gravity enabled me to characterize the orientation of the Wiimote. Based on which axes were experiencing gravitational force, I was able to figure out which way the Wiimote was leaning. I created the "equalizer" visual after brainstorming with Thomas and Federico about how best to show off this data. The equalizer visual plays off the building because of the horizontal beams between the windows.

The code for the equalizer is seen below:
int convertFromRange(int target, int oldmin, int oldmax, int newmin, int newmax){
  float newRange = newmax - newmin;
  float oldRange = oldmax - oldmin;
  float newValue = (((target - oldmin) / oldRange) * newRange) + newmin;
  return (int) newValue;
}
void draw(){
  gradientRect(0,0,width/3-10,height,light,dark);
  gradientRect(width/3,0,width/3-10,height,light,dark);
  gradientRect(2*width/3,0,width/3-10,height,light,dark);
  fill(0,0,0);
  int left = convertFromRange((int)wiiController.acc.x, 300, 200, 0, height);
  rect(0,0,width/3,height-left);
 
  int mid = convertFromRange((int)wiiController.acc.y, 0, 350, 0, height);
  rect(width/3,0,width/3,height-mid);
 
  int right = convertFromRange((int)wiiController.acc.x, 200, 300, 0, height);
  rect(2*width/3,0,width/3,height-right);
}

This code draws dynamically sized rectangles based on the values given for the x and y axes.

Human-acceleration:
The next piece of information I wanted to grab from the wiimote was the action of flick (or slash). I figured this would be a useful piece of information because of the nature of sketch 2's dance requirements (Laban's "A scale"). The visualization our team thought of to demonstrate this data was spheres floating in a 3D space.

The procedure I followed in capturing the flick data was to observe the different waveforms related to the 3 axes of the accelerometer, recognizing a pattern for when the Wiimote was "flicked", and capture the occurrence of the pattern in code. I noticed that in a flick, there is an initial change in acceleration in the flick direction, and then an spike in the other direction immediately following. This is the waveform that I wanted to try and recognize:

  (Right flick)

The algorithm to determine a (right) flick turned out to be something like this:

if the x_val < minThreshold && x_val < previous x_val
increment spike_up
if the x_val > maxThreshold && x_val > previous x_val
increment spike_down

depending on the order of the incrementation of spike_up and spike_down, either a flick left or a flick right has occurred.


Final Implementation
We changed a few things for our final implementation. Most notably, I coded the flick recognition to consider all 3 axes and we changed the floating spheres to floating cubes.