Our final project is done! It is an improvement over the previous Relaxing Punching Bag. Reading that link will help understanding objectives and implementation.

Improvements

For this iteration, the improvements added are:

1. Wireless communication from the arduino to the Pure Data patch in the notebook. This was important to achieve because having wires from the punching bag, which moved a lot, was not very robust. When people hit hard, the wires sometimes would get loose, or even the arduino would fall to the ground. Also, it was a bit annoying for the user to have cables going out from the punching bag and getting into his way. This was achieved using a pair of XBees series 1
2. Different types of sounds. After the midterm presentation, lots of people suggested that they would like to have the ability to change between different types of sounds. We made a playtest to know what the users thought about the sounds. Right now, there are 6 families of sounds to choose from. Some are relaxing, some are violent, some are whimsical. Also, we added a 2nd Arduino with a switch to enable the user to change the sounds without having to use Pure Data.
3. In relation to point 2, we improved the detection of punches from the accelerometer readings. For some of the sounds, it was very important that multiple sounds would not be triggered at almost the same time. This was not an issue with the relaxing music, but, for something like a punching sound, if the user punched once and then two successive punch sounds were played and the first punch sound was interrupted very quickly by the second punch sound, that was not good.
4. We have a real punching bag now.

Components

Punch detection

Arduino that reads accelerometer values and sends data via serial port to the first XBee

This is put inside the punching bag. The Arudino code was barely modified. In fact, it was only modified to achieve point 3 of the list above, that is, punching detection. Here is the code:

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

/*
int bigX = 0;
int bigY = 0;
int lowX = 0;
int lowY = 0;
*/

int vx, vy, vz, maxv = 550, minv = -550, oldx = 127, oldy = 127, threshold = 30;
unsigned long int currMillis = 0, lastMillis = 0;

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

void loop()
{

  //bigX = max(bigX, analogRead(A0) - avgX);
  //bigY = max(bigY, analogRead(A1) - avgY);  
  //lowX = min(lowX, analogRead(A0) - avgX);
  //lowY = min(lowY, analogRead(A1) - avgY);
  vx = map(analogRead(A0) - avgX, minv, maxv, 0, 255);
  vy = map(analogRead(A1) - avgY, minv, maxv, 0, 255);

  //Serial.print("bigX: ");Serial.print(bigX);Serial.print("         bigY: ");Serial.println(bigY);
  //Serial.print("lowX: ");Serial.print(lowX);Serial.print("         lowY: ");Serial.println(lowY);

  if(min(abs(vx - 127),abs(vx - oldx)) > threshold || min(abs(vy - 127),abs(vy - oldy)) > threshold) {
    currMillis = millis();
    if(currMillis - lastMillis > 300) {
      vx = vx != 177 ? vx : 178; //we avoid submitting 127
      vy = vy != 177 ? vy : 178; //we avoid submitting 127
      Serial.write(vx);
      Serial.write(vy);
      oldx = vx;
      oldy = vy;
      //delay(500);
      lastMillis = currMillis;
    }
  }
}

void calibrate() {
  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;
}

We removed the call to delay(), because that completely hanged arduino, including sending serial, and that made the punching bag less reactive, and we changed it with a custom millis() calculation. Also, now not only the difference with previous acceleration has to be higher than the threshold, but also the actual acceleration value needs to be higher. This added stability to the punch detection, and avoided false positives.

Receiving XBee

The second XBee receives data wirelessly from the other one, and sends the data through serial communication to Pure Data. The XBee is connected to a XBee explorer module that sends the serial data.

Arduino that changes sound family based on user input

It’s just a single switch that, when pressed, sends serial data to Pure Data to trigger a change in the sound family.

And the code:

boolean pressed = false;

void setup() {
  Serial.begin(9600);
  pinMode(8, INPUT);
}

void loop(){
  if(digitalRead(8)){
    if(!pressed) {
      Serial.write(1);
    }
    pressed = true;
  } else {
    pressed = false;
  }
}

Pure Data Patch

The patch was improved to store the current channel to send to Ableton (or similar), read another serial port and change the current channel based on a receive from the serial.

Ableton

Ableton has 6 channels, Pure Data then triggers one of them

Discarded alternatives

At first, we tried to make an Xbee read directly the analog values directly from the accelerometer, send that to the other XBee, and make the second Xbee send that data to Arduino, where it would be processed. This way, Arduino could be kept next to the computer that has Pure Data, just in case. We could not make this work, it was impossible to successfully read Accelerometer data directly from the XBees. At first we reading directly the Accelerometer Output (values from 0 to 3.3V in this case because the accelerometer was receiving 3.3). Then, we were told that XBees only read as analog input a value from 0 to 1.2V. So, we tried with a voltage divider between Accelerometer output and the Xbees analog inputs, thus reducing the max value to 1.2V, but this didn’t work either, maybe because we could not find adequate resistance values. Alternatively, the XBees may have needed a firmware update.

When we gave up, we came to the current solution, which is way easier. Now, the code in the Arduino could remain the same, instead of having to parse an XBee message, and we avoided the need of having two serial communications through arduino (one from XBee, the other to Pure data). The disadvantage to our solution is that, if any changes need to be done to the arduino in the accelerometer, it is not easily accesible we need to open the punching bag. As en example, the accelerometer cannot be easily recalibrated now, or the arduino reset.

After adding the second Arduino to let the user change the sound channel, we tried to, instead of having the XBee communicating to Pure Data through the serial adapter, to instead send the data through serial to the second Arduino, and this Arduino send the data to Pure Data. For this, we needed to manually parse the XBee message in the Arudino code, and we ran out of time for this (now, the XBee adapter takes care of that). Also, if we did this, instead of having two serial ports open in Pure Data, we would have had only one, so we would have had to add logic in Pure Data to identify one serial read meant data from Accelerometer and when it meant a change in the sound channel, and adjust Pure Data flow accordingly. This would have allowed us to avoid the disadvantage we have now stated above, because the Arduino connected to the notebook would have been able to send data to the Arduino in the bag (via XBees).

Interesting difficulties we had

• As stated above, we could not make the XBees read data directly from a sensor (the Accelerometer in this case)
• At first, we borrowed a pair of XBees series 2. The series 2 allow to set up more complex networks of XBees than the Series 1 do, but they are hard to configure. We could not make them to communicate. For achieving that, we needed to update the firmware via a special program (X-CTU for example) but we didn’t have one. The configuration is much harder on the series 2 than on the series 1. Later, we borrowed a pair of XBees series 1, and it was really easy to make them communicate one with each other. There is lots of documentation around the web.

Future improvements

• Put the Arduino that controls sound channel change and the receiving XBee on a box, so it is invisible to the user. Add a nicer switch that triggers the sound channel. In general, improve aesthetic presentation
• Add a way to send data to the Arduino in the bag, just in case we need to do something there and we don’t want or can’t open the punching bag
• Right now, the Arduino in the punching bag uses a 9V battery, an is all the time on, drawing power from it. In one day, the battery gets completely drained. We should find a way of easily opening the circuit when the punching bag is not in use.

Borrowed parts

Special thanks to the people that lent us parts

• Benedetta Piantella: the accelerometer, a pair of XBees series 2 and the XBee adapter
• William Lindmeier: a pair of Xbees series 1

Now we have a real punching bag! Between that and also having tied the wires together, now the project looks much more professional. Sadly, I don’t have pictures about the new look.

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?

The playtest

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.