The design and production of the Zen Pugilist (by Oscar Klingspor, Andres Taraciuk and Rafael Gross-Brown) is complete (for now).

This sound-based interactive punching bag has been a work in progress over the past months, culminating with a final product that features:

1. Wireless: The first iterations of the bag included communication between modules through wires, which complicates the dynamic and intensely physical interaction required for a punching bag. We furthered the design with a wireless feature, to make the experience more user friendly (we want users to hit the bag freely and without any thoughts/concerns related to the bag’s stability or usability). The wireless feature is operated by Xbees Series 1 ( a pair sufficed).
2. Multiple Sound Modes (“SMs”): Extensive playtesting and thorough feedback from playtesters helped us identify ways to enhance the user experience. One of the most significant feedbacks was that users not only preferred the initially prepared relaxing SM, but also desired other SMs. Among proposed ideas, users suggested fights sounds, the sounds of cracking oysters, sounds of the ocean, among others. Therefore we went back to the sound design table to come up with a broader range of sounds that could not only be relaxing, but also cathartic and entertaining.  We added new SMs, including relaxing synth pads, samples of gunshots and other fire weapons (highly cathartic), fight sounds, and a more humorous SM.
3. Higher Resolution of sensor readings: The Zen Pugilist reads punches through an accelerometer sensor(see Img 1 below). Getting accurate readings that reflect hits to the bag from an accelerometer is tricky in that they are produced through changes in movement. Playtests indicated that users preferred a better resolution of the bag’s reaction to punches, a more accurate output. Thus, Andres went back to the code and improved it to have better and more precise readings from the accelerometer. Changes to the code include removal of the call to the delay() function, because that caused Arduino to hang, which made the bag less reactive. We changed it with a custom millis() function 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 that triggered sounds. Please refer to the code below (see Code 1 below)

Img 2

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

 

Code 1:

 




More on wireless communication, Pure Data and Ableton Live:

Receiving XBee

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

Arduino based toggle button that changes SM based on user input.

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

Code 2 :

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 Live

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

Trial and Error

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 SM, we tried to (instead of having the XBee communicating to Pure Data through the serial adapter)  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).

Future improvements

• Put the Arduino that controls sound channel change and the receiving XBee on a box, so it is not visible 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 use 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.
• We have ideas about designing a game around this concept.

Special thanks to the people that lent us assets:

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