Become a Zen Pugilist.
December 7, 2012

Testing with a real punching bag

Now we have a real punching bag! Between that and also having tied the wires together, now the project looks much more professional.  

Some stuff that we had to change:

The new bag is harder than the old backpack, so we had to lower the threshold value in the Arduino code.

This led to the sounds being triggered more often, but also on a big punch more sounds were triggered at the same time. That made the sounds to look more random. To solve this, at first we tried increasing the delay() value, but that only made things more inconsistent. Surprisedly, for me at least, completely removing the delay() call solved things. I don’t know why, maybe the delay() was freezing also the sending of data, so it sent it after the delay, causing the sound in pure data to trigger lately? Or maybe it read an old value of the sensor that was buffered?

Results from another play test
Few people considered that the sounds relaxed. At least no one thought they were annoying. I think people don’t want relaxing music when hitting, they are more in the mood for something more energetic or about breaking. Fighting sounds and oyster cracking were the two most popular demands. Also, there is a tendency for asking more responsiveness, that the sounds should be triggered more often. I think we solved that when we lowered the threshold and removed the delay.

[originally posted: 11.30.2012]
December 7, 2012

Getting the first prototype to work.

We have a ‘punching bag’ (right now just a backpack), that when it’s hit it triggers relaxing music.

Workflow

1. Punching bag moves
2. Accelerometer attached in bag detects acceleration
3. Arduino receives accelerometer values
4. Arduino sends serial data
5. Pure data receives serial data
6. Pure data triggers MIDI notes based on data
7. Ableton plays music based on the midi notes received

Arduino code

void setup()
{
  // initialize the serial communications:
  Serial.begin(9600);
  int i;
  for(i = 0; i < 100; i++){
    avgX += analogRead(A0);
    avgY += analogRead(A1);
  }
  avgX = avgX / i;
  avgY = avgY / i;
}

We calibrate the accelerometer in the setup()phase. This way, avgX and avgY end up storing the still values for the speed components.

void loop()
{

  vx = map(analogRead(A0) - avgX, minv, maxv, 0, 255);
  vy = map(analogRead(A1) - avgY, minv, maxv, 0, 255); 

  if(abs(vx - oldx) > threshold || abs(vy - oldy) > threshold) {
    vx = vx != 127 ? vx : 128; //we avoid submitting 127
    vy = vy != 127 ? vy : 128; //we avoid submitting 127
    Serial.write(vx);
    Serial.write(vy);
    oldx = vx;
    oldy = vy;
    delay(200);
  }

}

analogRead() – avg gives the calibrated value.
Then, we scale that value between 0 and 255 to fit in a byte.
maxv and minv are the maximum and minimum values obtained by the accelerometer, after calibration. These values were obtained empirically. For the accelerometer used, they are 550 and -550 respectively.

We only write data into serial if the new values from the accelerometer are different enough from the old values sent (the if condition:
abs(vx – oldx) > threshold || abs(vy – oldy) > threshold). This is to avoid playing music sounds because of oscillation, and also to achieve that each punch should only trigger few times a new sound. If we don’t do this, the noteout command from PD overwrites the previous one. That clearly cannot happen at every loop

We never submit 127 because that is 0 speed, and in our PD patch we need the speeds to be always != 0.

Lastly, we update the old values with the ones just sent.

Pure data (PD)

The comport command listens to serial communication on the port specified on the open command above it.

Then, we unpack the two values (vx and vy), and we substract 127, because a value received is between 0 and 255 but speed can go both ways, so actually the middle value is the no speed (that’s why in arduino we never send 127).

With these values, then, we will generate the 8 possible chords played. The chord played is based on the relation between vx and vy: vx / vy. With this (and based on if they are positive or negative), we divided the plane in 8 regions. All the right part of the sketch is arithmetic to determine which chord to play.

The amount of speed is used to set the velocity of the note (MIME protocol). The amount of speed is determined by sqrt(vxˆ2 + vy^2). We divide this value by 2 to make it fit in a byte.

Lastly, the noteout command sends the note to the channel specified.

CHECK OUT THE VIDEO

[original post: 11.12.12]

December 7, 2012

Accelerometer calibration and play test

Accelerometer calibration and Playtest

Accelerometer

We went the route to start with an accelerometer. B_ shared us a model ADXL3xx (thanks!).

As we were told, an accelerometer needs calibration. In the case of the ADXL3xx, even when it’s still its speed components report values bigger than 100. Also, if the accelerometer is rotated (in any of the 3 axis), its new still position will report different values than the previous still position.

To solve this, we made a calibration by code. In the setup method, we calibrate the accelerometer, that is, we store in variables the initial values for the speed components:

long int avgX = 0;
long int avgY = 0;
long int avgZ = 0;

void setup()
{
  // initialize the serial communications:
  Serial.begin(9600);

  /* beginning of calibration */
  int i;
  for(i = 0; i < 100; i++){
    avgX += analogRead(A0);
    avgY += analogRead(A1);
    avgZ += analogRead(A2);
  }
  avgX = avgX / i;
  avgY = avgY / i;
  avgZ = avgZ / i;
  /* end of calibration */
}

Then, we will use the values avgX, avgY and avgZ later on the loop method:

void loop()
{ 
  ...
  calX = analogRead(A0) - avgX;
  calY = analogRead(A1) - avgY;
  calZ = analogRead(A2) - avgZ;
  ...
}

The accelerometer must be as quiet as possible during the calibration fase, and the still position, like a reference position, must remain always the same in this case.

We assume that, effectively, the accelerometer will always have the same position in relation to the punching bag.

Improvements to do: An improvement for this will be to have the calibration in a routine, and then call this routine in the loop method if some trigger is called. A pushbutton wired to the arduino or some trigger from a notebook through serial communication can do the job.

Playtest

We wanted to find out

  1. The public interest in a product like ours
  2. Which kind of sounds did people find more relaxing

For this, we made a poll for people to complete

The first 3 questions were aimed at point 1

For point 2, Oscar made 7 tracks with sounds. People were asked to listen to them and then answer the last question.

[original post:11.03.2012]

December 7, 2012

Concept: punching bag + relaxing sounds = zen-ness.

Concept:

A punching bag that plays relaxing sounds when you hit it. The sound will change according to the direction of the punch, so the user will be able to play with the music and make different melodies with the punches. Also, the force of the punches will be taken into consideration, there will be a difference between hitting harder or softer. Probably, a change in strength will translate into a change in the sound volume.
Philosophically speaking, the system will take ‘anger’ as an input and throw ‘relaxation’ as an output.

Input:

We discussed several alternatives for detecting the punch.
Putting FSRs in the punching bag doesn’t seem good, because that will limit the hittable area. Also FSRs tend to be fragile, we are afraid they are going to break with use in this case, and we don’t know if they are good for detecting different grades of punches.
If we put the FSRs in the gloves, we avoid the limiting surface problem, but, on the other hand, that would require wiring in the gloves.
The best solution, in our opinion, will be putting an accelerometer in the punching bag. This way, we detect the generated acceleration from the punch. Accelerometers, also, give input of the acceleration in two (or even three) dimensions, so with a single accelerometer we can obtain the direction and intensity of a punch by analyzing the two vectors.
Lastly, a switch so it can be easily turned off.

Output:

Sound.
We want to output MIDI protocol through serial communication. There are programs for faking a MIDI port through USB. Then, a program like GarageBand or Ableton will play the MIDI music.

A quick sketch below.

image

Some links:
https://sites.google.com/site/bharatbhushankonka/home/diy-midi-over-usb-using-arduino-uno


http://spikenzielabs.com/SpikenzieLabs/Serial_MIDI.html


http://lizarum.com/assignments/physical_computing/2012/sound/arduino_garage_band.html

[original post: 10.22.2012]

December 7, 2012
December 4, 2012

Quick documentation of the first prototype.