Ping Pong Remix Wireless Presentation
Posted on December 15, 2005 at 05:10 PM by sj695
|
Everything’s done and completed…Steve did this incredible paddle sound selector on Processing and we’re all set!
Re-Paddling
Posted on December 15, 2005 at 04:51 PM by sj695
We decided it was best to redo the paddles all together, so we both went to Paragon at Union Square and bought 5 dollar paddles to break apart and Piezo buzzers at Radio Shack. The Rubber on the paddles were stripped open as well as the wood on the handles.
The Peizo buzzers were soldered, red is to power, blue is to analog and black is to ground. Then a hole was cut in the middle of the handles as shown in the pictures in order to place the wires that go from the peizo buzzer to the transmitter boards.
After making the hole, the Piezo Buzzer is placed under the rubber ever so carefully as the wires of the Piezo buzzers are very very sensitive and glued with the gorrila glue. The new buzzered paddles are clamped down and left to dry overnight.
The reciever box was re-designed to be more accessible and to look more prefessional and the transcievers are now placed in a little pouch.
I have to say I was glad we redid the paddles because it gave me a chance to see how the paddles actually worked and what was really used to get data from the paddles to the pic chip. Speaking of pic chips, the pic chips for the transmitter boards were changed from the larger 18F452 to the smaller 18F252 which has 28 pins. It was best to use a smaller Pic chips since we were using a smaller breadboard and we needed more space on the board to fit everything together.
Below are few pictures of our preparations:
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Ping Pong - The Remix
Posted on December 08, 2005 at 04:50 PM by sj695
We finally got the Paddle to work wirelessly, and we have figured out how we will be strapping the paddles. What we have decided so far is to mount the breadboard and having these velcro straps wrap around them We hope to get everything done by this weekend so we will be able to do some userbility testing and be able to video tape the users in action! Below is the code we did.
‘****************************************************************
‘* Name : PP-PADDLE
‘* Author : Steven Jackson / Fazreen Kuhiri
‘* Notice : Copyright (c) 2005
‘* : All Rights Reserved
‘* Date : 12/1/2005
‘* Version : 1.0
‘* Notes : sending serial out (transmitter) from paddle
‘****************************************************************
define osc 4
‘ Define ADCIN parameters
DEFINE ADC_BITS 10 ‘ Set number of bits in result
DEFINE ADC_CLOCK 3 ‘ Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 20 ‘ Set sampling time in uS
PeakValue var word
SensorValue var word
LastSensorValue var word
Threshold var word
Noise var word
Threshold = 50 ‘ set your own value based on your sensors
PeakValue = 0 ‘ initialize peakValue
noise = 5 ‘ set a noise value based on your particular sensor
‘ Set PORTA to all input
TRISA = %11111111
‘ Set up ADCON1
ADCON1 = %10000010
inv2400 con 16780
thisByte var byte
adcVar var word
blink var byte
output portd.1
output portd.2
OUTPUt portd.3
input portb.0
i var byte
pause 500
main:
‘ read sensor on pin RA0:
ADCin 3, sensorValue
‘ check to see that it’s above the threshold:
If sensorValue >= threshold + noise then
‘ if it’s greater than the last reading,
‘ then make it our current peak:
If sensorValue >= lastSensorValue + Noise then
PeakValue = sensorValue
endif
‘ if the sensorValue is not above the threshold,
‘ then the last peak value we got would be the actual peak:
Else
If peakValue >= threshold then
‘ this is the final peak value; take action
thisByte = 1
for i = 0 to 5 step 1
serout2 portd.3, inv2400, [65, dec thisbyte]
next i
’serout2 portd.3, inv2400, [83, DEC thisByte, 10]
high portd.1
pause 200
low portd.1
pause 200
endif
‘ reset peakValue, since we’ve finished with this peak:
peakValue = 0
Endif
‘ store the current sensor value for the next loop:
lastSensorValue = sensorValue
goto main
——————————————————————————-
‘****************************************************************
‘* Name : PP-RECEIVER_BOX
‘* Author : Steven Jackson / Fazreen Kuhiri
‘* Notice : Copyright (c) 2005
‘* : All Rights Reserved
‘* Date : 12/1/2005
‘* Version : 1.0
‘* Notes : sending serial out (transmitter) from paddle
‘*
‘****************************************************************
inbyte var byte ‘ incoming string
inbyte2 VAR BYTE
output portb.1 ‘ status LED
output portc.6 ‘ serial out to PC
input portc.7 ‘ serial in from receiver
n_2400 con 16780 ‘ baud mode for serin2 (2400-8-N-1 inverted)
n_9600 con 16468 ‘ baud mode for serin2 (9600-8-N-1 inverted)
i var byte ‘ loop counter
RFSerialIn var portc.7
PCSerialOut VAR portc.6
StatusLED var portb.1
PingPong VAR WORD
PingPong = 420
‘ flash status LED to start:
high StatusLED
pause 500
low StatusLED
main:
‘ this serial call does nothing until it gets bytes:
serin2 RFserialIn, n_2400, [wait(65), inbyte]
serout2 pcserialout, n_9600, [inbyte]
goto main
Ping Pong - The Remix
Posted on December 01, 2005 at 04:36 PM by sj695
We’ve decided to make the signal digital rather than analog because there was too much data being sent through, so it was much easier to have it digital.
We also have a back up plan….IN CASE the WHOLE WIRELESS thing doesn’t work out, and it’s to combine everything in one big box. Since we are still getting some signal difficulties.
![]() |
![]() |
![]() |
![]() |
![]() |
Ping Pong - The Remix (Preparations)
Posted on November 17, 2005 at 04:28 PM by sj695
In order to make our ping pong to work wirelessly, we have decided to use plain old Radio Frequency (RF) Serial Communication. RF transmitters sends bits on pulses of radio energy, and what attracted us to RF frequency is it’s flexibility. RF unlike Infrared serial is omnidirectional and can go greater distances, even through walls. This makes it great for our ping pong application, because as you saw in last week’s Ping Pong video there were lots of acrobatic movements going on. RF is also much easier to program compared to bluetooth. So hopefully we will be able to save more time.
In order to differentiate the signal from ambient radio or light waves, the data is sent on carrier wave. Actual information is encoded by slightly varying the frequency of the carrier wave (FM) or signal strength (AM). We will be using 315MHz.
What we have so far:
Laipac Transmiter & Reciever
|
The coding that we have so far, but still needs to worked on as we are picking up other signals we don’t want.
inbyte var byte ‘ incoming string
outout portb.1 ‘ status LED
output portc.6 ‘ serial out to PC
input portc.7 ‘ serial in from reciever
n_2400 con 16780 ‘ baud mode for serin2 (2400-8-N-1 inverted)
n_9600 con 16468 ‘ baud mode for serin2 (9600-8-N-1 inverted)
i var byte ‘ loop counter
RFSerialIn var portc.7
PCSerialOut var portc.6
StatusLED var portb.1
‘ flash status LED to start:
high StatusLED
pause 500
lowStatusLED
main:
‘ this serial call does nothing until it gets bytes:
serin2 RFserialIn, n_2400, [DEC inByte]
‘ high statusLED
‘ if the first three bytes are “OBJ”, then
‘ the fourth byte is data. parse it as a number (DEC inbyte (3))
if inbyte > 0 Then
serout2 PCSerialOUT, n-9600, [DEC inbyte, 10, 13]
high StatusLED
‘ PAUSE 500
‘ LOW StatusLED
endif
‘ low StatusLED
goto main
Ping Pong - The Remix
Posted on November 10, 2005 at 05:19 PM by sj695
Here's the link to our presentation of our final project in Physical Computing.
Ping Pong - The Remix (PowerPoint Presentation)
Ping Pong - The Remix
Posted on November 10, 2005 at 04:21 PM by sj695
Our idea is to re-create the ping pong application, and make it wireless this time. As we all know it’s always hard to jump around like an acrobat playing ping pongs with long tangled wires attached to the paddles. So this is our solution, going WIRELESS!!
Ping Pong - The Remix
Posted on November 10, 2005 at 04:21 PM by sj695
Our idea is to re-create the ping pong application, and make it wireless this time. As we all know it’s always hard to jump around like an acrobat playing ping pongs with long tangled wires attached to the paddles. So this is our solution, going WIRELESS!!
Obs Proj TWO, the Final Stretch [um, Prototype]
Posted on October 28, 2005 at 02:19 PM by sj695
Although the drum trigger was working, it was not giving us reliable results. As suggested in class we decided to work in parallel. We ultimately wanted two working paddles, so we decided to have one hooked up to a midi synth box and the other one using the Sonia sound library in Processing.
I am not taking ICM so I had never used Processing before. Dan Shiffman's book draft was invaluable in getting me up to speed, but soon realized that sound was not Processing's forte. At the end of the day I got Daniel to come by and take a look at my code and even he couldn't figure out why it wasn't working!
So I ditched Sonia for the time being and got the midi synth box from the ER. I got some simple tones to play with the paddle. Going back to my days of playing flute I got the paddles to play Salt 'n Peppa's "Push It".

DEFINE OSC 20
DEFINE HSER_RCSTA 90h ' enable the receive register
DEFINE HSER_TXSTA 20h ' enable the transmit register
DEFINE HSER_BAUD 31250 ' set the baud rate
TRISD = %00000000 'Set all of PORTD pins to output mode
paddleVar VAR word 'Create variable to store result
pitch var byte(12)
i var byte
i=0
' ranges for reference
pitch(0) = 60' mid c
pitch(1) = 61' c#
pitch(2) = 62' d
pitch(3) = 63' d#
pitch(4) = 64' e
pitch(5) = 65' f
pitch(6) = 66' f#
pitch(7) = 67' g
pitch(8) = 68' g#
pitch(9) = 69' a
pitch(10) = 70' a#
pitch(11) = 71' b
' a,e,d,c,b,g,g,b,c,b,g - salt n peppa push it!
'69,64,62,60,71,67,67,71,60,71,67
song var byte(11)
song(0)=69
song(1)=64
song(2)=62
song(3)=60
song(4)=71
song(5)=67
song(6)=67
song(7)=71
song(8)=60
song(9)=71
song(10)=67
'light debug sequence
high PORTD.0
pause 200
low PORTD.0
high PORTD.1
PAUSE 200
low PORTD.1
main:
ADCIN 3, paddleVar 'coming in at analog port 3
if paddleVar > 100 THEN 'set to 100 since slight vibrations give off readings
hserout [$90, pitch(i),$40]
if(i>11) then 'loop thru song once its at end reset to 0 o
i=0
ELSE
i=i+1
ENDIF
ENDIF
PAUSE 100
goto main
*One thing to remember, when working with the midi box, you need a 20 hz clock and when you program the chip you have to change the oscillator from XT to HS.
ConstructionWOES
On the sensor/paddle side, Steve ran into Danny Tsang [who had done a similiar project for a class] and he told us a better way to rig the paddles. Steve stripped a piezo speaker and took out the piezo film inside, carefully soldered the connections.
We hollowed out the paddle handle, ran wires through it and glued the pieces back on.

Steve used Gorilla Glue, which takes about 3 hours to dry. BUT the glue expands which fixes the sensor into place. [pic here]
We got some code that handled the sensor peak readings and luckily got Sonia to work at the last minute.
' Define ADCIN parameters
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 20 ' Set sampling time in uS
PeakValue var word
SensorValue var word
LastSensorValue var word
Threshold var word
Noise var word
PingPong VAR WORD
PingPong = 420
' serial pins and data reate:
tx var portc.6
rx var portc.7
n9600 con 16468
Threshold = 50 ' set your own value based on your sensors
PeakValue = 0 ' initialize peakValue
noise = 5 ' set a noise value based on your particular sensor
' Set PORTA to all input
TRISA = %11111111
' Set up ADCON1
ADCON1 = %10000010
Main:
' read sensor on pin RA0:
ADCin 3, sensorValue
' check to see that it's above the threshold:
If sensorValue >= threshold + noise then
' if it's greater than the last reading,
' then make it our current peak:
If sensorValue >= lastSensorValue + Noise then
PeakValue = sensorValue
endif
' if the sensorValue is not above the threshold,
' then the last peak value we got would be the actual peak:
Else
If peakValue >= threshold then
' this is the final peak value; take action
'serout2 tx, n9600, ["peak reading", DEC peakValue, 13,10]
'serout2 tx, n9600, [DEC peakValue]
serout2 tx, n9600, [DEC pingPong]
endif
' reset peakValue, since we've finished with this peak:
peakValue = 0
Endif
' store the current sensor value for the next loop:
lastSensorValue = sensorValue
Goto main
//PROCESSING CODE FOR SOUNDS
import pitaru.sonia_v2_9.*;
import processing.serial.*;
/*avani added, put sounds in array, sounds should reside in same folder as .pde file */
String[] wavArray = {"first.wav", "second.wav","third.wav"};// new String[3];
//end avani additions
int bgcolor; // background color
int fgcolor; // fill color
Serial port; // the serial port
int[] serialInArray = new int[3]; // where we'll put what we receive
int serialPong = 0;
int serialCount = 0; // a count of how many bytes we receive
boolean firstContact = false; // whether we've heard from the microcontroller
int j=0; //wavs index
Sample bounce;
void setup() {
size(256, 256); // stage size
noStroke(); // no border on the next thing drawn
// print a list of the serial ports, for debugging purposes:
println(Serial.list());
port = new Serial(this, Serial.list()[0], 9600);
//port.write(65); // send a capital A to start the microcontroller sending
Sonia.start(this); // Start Sonia engine.
}
void draw() {
background(bgcolor);
fill(fgcolor);
// get any new serial data:
while (port.available() > 0) {
serialEvent();
// note that we heard from the microntroller:
firstContact = true;
}
}
void serialEvent() {
processByte((char)port.read());
}
void processByte(char inByte) {
// add the latest byte from the serial port to array:
serialInArray[serialCount] = inByte;
serialCount++;
// if we have 3 bytes:
if (serialCount > 2 ) {
bounce = new Sample(wavArray[j]);
serialPong = (int)serialInArray[0];
println(serialPong);
if (serialPong == 52) {
bounce.play();
j++;
if (j>2) { j=0;}
} serialCount = 0;
}
}
// Safely close the sound engine upon Browser shutdown.
public void stop(){
Sonia.stop();
super.stop();
}
[processing code here]
We constructed two Radio Shack project boxes in order to keep the components in place when the user swings the paddle.


So without further ado....see the project in action! That's right! Click here
Lots of fun was had.

Paddle with peizo sensor
Posted on October 26, 2005 at 02:21 AM by sj695

Paddle with Pressure sensor
Posted on October 26, 2005 at 02:20 AM by sj695

Paddle with drim trigger.
Posted on October 26, 2005 at 02:18 AM by sj695

If it ain't got that swing...
Posted on October 23, 2005 at 02:05 AM by sj695
As part of our ongoing second project, I built two more prototypes to evaluate different sensors. The two sensor used were Piezo vibration (DigiKey #MSP1007-ND), and Force (DigiKey #102-1214-ND).
The Force sensor seemed to hold a lot of promise, as we were trying to sense when the ball is struck by a paddle. After all, that’s the focus of the project: to get the input of ball hitting paddle to create output as some other signal. For prototyping purposes, I just programmed an LED to light as my output.
Initially I peeled back the rubber pad on one side of the paddle and slipped the Sensor underneath it, and replaced the pad. This would have been a perfect solution because it was clean and tidy, but proved to be insufficient. The rubber pad dampened the collision force, and the readings were weak and sparse. If you didn’t hit the ball exactly where the sensor was or within close proximity, you got not reading at all.
For the second attempt, the sensor was placed on top of the rubber pad, and then covered with a stiff membrane (chipboard). This worked much better; no matter where you hit the ball with the paddle, the force was transferred to the sensor. We got plenty of useful readings from the sensor but the team felt that having to put the covering over it detracted too much from the original look and feel of the paddle.


On to Piezo
I was surprised when the Piezo sensors arrived because they were miniaturized versions of the Flex sensor accelerometer that I built a week ago. Working quickly, I designed a third prototype by taping the Piezo sensor to the paddle. These sensors worked fantastically, giving off tons of data. Too much so, in fact. The sensors are so sensitive that just holding the paddle steady, there’s enough vibration in your hand (time to switch to decaf?) to send a steady stream of data out to the PIC.
The challenge then was to develop a filter in the software that would only pass on a signal when the paddle struck the ball, not merely the slightest vibration or wiggle. The raw numbers coming in from the paddle ranged from 30 to 650. Tapping a ball with the paddle produced numbers from 400 to 600. The next step was to set up a filter that would knock out anything under what we thought a ball/paddle collision would produce. This presented a problem because the force of the ball hitting the paddle is always different, therefore it is never consistent. So if we set the filter to eliminate any numbers under say 350, just holding the paddle wouldn’t produce any signal. This seemed to work fine however once a ball was struck, we would then get multiple signals. After analysis, we determined that the problem was produced by the sensor continuing to reverberate after the paddle struck the ball. For instance, if a collision produced a reading of 425, we would then get a slowly descending string of readings from 425 down, until we hit the filter at 350.
To rectify this problem we introduced a new variable into the software that would represent the initial reading of a collision (the highest). We then used this reading as our cut-off point in the filter. After a set amount of time, the filter would be reset to a lower setting in anticipation of the next swing of the paddle. This produced much better results and only one output signal per collision. Unfortunately, the force of swinging the paddle sometimes was great enough to trigger the sensor as well. Much like the Flex sensor accelerometer I developed for my last prototype!
I felt that this could be interesting in our project, for we could create an event that happens when you swing the paddle and another one when the paddle collides with the ball. Sadly, my teammates were skeptical of the sensor protruding from the backside of the paddle and voted to go with the Drum trigger.


Here's the code:
Spacer = 0
Threshold = 300
main:
High PORTD.1
pause 100
Low PORTD.1
ADCIN 0, ADCvar ' Read channel 0 to adval
If ((ADCvar/2) > Threshold) then
serout2 PORTC.6, 16468, [DEC ADCvar/2, 13, 10] ' print it to serial out,
pause 250 ' with linefeed and carriage return (10, 13)
Spacer = 1
endif
IF (Spacer = 1) then
High PORTD.2
Pause 100
Low PORTD.2
Spacer = 0
Threshold = ADCvar
ENDIF
if (ADCvar/2 < 200) then
Threshold = 300
endif
Observation Project TWO, it's Analog, it's digital....it ANALOG!
Posted on October 22, 2005 at 02:00 AM by sj695
Steven decided to strip the drum trigger to see what was inside. He found piezo film which basically senses vibration. We rigged the paddle so that the film was placed inside a groove cut for it near the bottom of the paddle. It picked up the vibration and so we figured out YES the drum trigger is analog. Oh and when the vibration was sensed, the LED in Santa's mouth lit up! "Ping Pong, Santa's ON."
Observation Project TWO, Phase II
Posted on October 16, 2005 at 02:02 AM by sj695
We convened and decided to each take a paddle and try out different sensors. We all ended up in the lab at the same time and worked from one board, each testing after another.
Conclusions and findings:
- Drum trigger is digital NOT analog. Had to be hit at a specific pt and not big enough to cover surface area of paddle.
- Flex sensor. Idea was to attach multiple flex sensors to a paddle. Only flex sensor detects when a tennis ball hits it but the range of values is small, very similiar to values when just moving paddle. We tried a various of resistors but this just dropped the values from 900 to 200, but the overall number range stayed the same. After three different flex sensors and no consistent results we decided to try some Piezos.


Observation Project Questions about Ping Pong
Posted on October 06, 2005 at 11:47 PM by sj695
What tool or device is the action taken on?
Ping pong paddle, table and ball
What is the goal of the activity?
To hit the ping pong ball across the table with the paddle and repeat as the other player does the same actions
What are the physical parameters of the activity?
Seeing the ball, swing the paddle, positioning the body.
What does the person engaged in it do with their arms, their legs, their hands or feet, their head?
Move arms to swing and reach ball as it enters their side of table. The person may also have to jump or move from different sides of the table to reach or hit the ball.
How do they change their posture?
Sometimes the person may have to bend to reach balls that land closer to the center of the table (the net)
Where do they need to focus their attention?
The ball, speed, direction, angle of approach and anticipated bounce.
Is there a secondary focus of attention (for example, if two limbs are used independently)?
Angle of their paddle and body position
What physical elements of the activity make it engaging?
Sound, returning the ball to your opponent.
What elements make it difficult, painful, or boring?
Repetitive, anticipating ball landing, speed and bounce
Observation Project Video of Ping Pong
Posted on October 06, 2005 at 06:59 PM by sj695
Observation Project Video of Ping Pong

0 Comments
















