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.

Working on sketch 2

Friday, March 1:

Working on creating an equalizer-like effect to track Andrea's body:

Sketch 2 Research

I really like the realism and interaction with the windows on this video:

http://m.youtube.com/watch?v=rPr0CgvmBM4

It was projected on the Ralph Lauren Bond Street Store.

I enjoyed the fact that there were human figures on the building. I also enjoyed the "pretend" lighting up of the building from the inside. The light moving through the building lit up the windows as if it were really inside.

Sketch One Reflections

Reflections on the Dancing Egg
====

There were several postive aspects to our performance and also a few negatives:

Positives:
Scene setup
   - Andrea's costume, the lighting, and the aesthetics surrounding the egg all turned out very nicely.
   - We were aiming for a mysterious, earthy atmosphere and I feel like we acheived it.

Sound production
   - I feel like this was the best part of our production.
   - We created meaningful sounds that helped the audience understand what the egg was feeling even though it wasn't moving :(

Choreography
   - Andrea's dancing was very believable and it added to the performance quite a bit


Negatives
No motion :(
   - The egg's battery was high enough to run the Arduino board, but too low to actual move the motors..
(Lessons -- 1. Always check the battery and test the full range of operability before the performance
                   2. Make the battery easily replacable)

Lack of Responsiveness
   - Although Andrea did a good job of learning the system, the proximity detection method we implemented just wasn't fully robust.

Limited performance space
   - Andrea was limited to the view-area of the webcam we used, which turned out to be about an 8 ft square

All in all, I was proud of what we accomplished, but wished we would have been able to demonstrate our product flawlessly.

-Jonathan