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.