An initial autonomous Pong ball

Group members participating:
Morten, Lars og Thomas.


Duration of activity:
28 hours.


Goal:
To figure out a way to construct the ball for the Pong Game, matching the original Pong as closely as possible and still being functional according to the goals of the end project.


Plan:

1. Test whether it is possible to use the RCX touch sensors to determine what side of the ball is colliding with the wall.
2. Create a program, using sensor input from a CompassSensor and three RCX touch sensors, to compute a new direction to travel, depending on the previous course travelled and on which of the touch sensors was colliding with the barrier, ie. an algorithm to compute the angle of reflection.
   
3. Determine the tone of the sound effect, from the original Atari Pong game, of when the ball hits a bat or the game barrier.

Activities:

1. Here we encounter a perfect example of the problems that arise when moving from something known to be attainable in theory to something that actually works in practice.
   
   We ended up with three different Lego constructions, built upon the same basic frame. Of the three, only the last construction seem to functions satisfactorily.
   
   
   
   • For a first approach the Lego rubber springs was used. Testing showed that these was not flexible enough. The motors and wheels was not able to transfer enough power (torque) to press in the strong springs, holding the RCX-touch sensors in place.
     
     
     
   • Another approach inspired by EoCB-aITW was tested, attaching plastic tubes between the robot-frame and the bumper. Testing indicated that this solution was to rigid and also unstable. When the robot collided with the barrier, the bumper would get banged out of place.
   • As a last attempt, ordinary household elastic bands was used. - This simple solution actually seems to work.
     
   
   While test driving ball construction, with the three RCX touch sensors attached on the left and right side and on the front, we found that often the hits on the right side would not be detected correctly. We investigated the problem and found that allthough the right sensor was fitted with a fixed resistor, activation of the sensor would still output different readings.
   We were not able to find another better functioning sensor. Intead a new ball construction was made, this time with only two RCX touch sensors mounted on the front corners of the ball frame. The idea is that we are still able to detect collision on the front, by detecting hit on both the left and right side simultaneously.
   
   Two RCX touch sensors mounted on corners of the ball
   
   
   
   
2. By simplifying the number of states the robot-ball can take on, we have managed to construct a fairly simple program.
   The traveled course is measured by the Compass, it is in the integer range [0,359] and its unit vector can be in one of four quadrants { (+x,+y), (+x,-y), (-x,+y), (-x,-y) }.
   The internal coordinate system of the ball is set to match the square of the playing field - on game-startup the ball is placed in parallel with the walls of the playing field, and upon initialization of the software a call is made to the method resetCartesianZero() of the CompassSensor.
   The balls collision is detected by the two RCX touch sensors on the two front corners. Because these are mounted in parallel on the same input port, we get three possible detectable hits { (R_left), (R_right), (R_front = R_left || R_right) }.
   By knowing in which quadrant the unit vector of the current course is together with the knowledge of which side was collided with, we can calculate the angle of reflection.
   
   
   Example of calculating the new heading
   
   The equations used in each case is presented in the table below.
   

   quadrant	detect collision
   (x,y)	right	left	front
   (-x,y)	left	right
   (-x,-y)	right	left
   (x,-y)	left	right
   equations	180 - d	- d	d - 180

   
   
   The implemented software can be seen here.
   
   
3. Background-research on the old Pong sound came up short and gave very little to work with. The goal is still to find a metallic, retro-computer-like sound.
   
   In order to test the capabilities of the NXT internal tone generator we created a small testprogram with two for-loops, - an outer loop iterating the frequency band and a inner loop iterating time of the sound length. This was done in order to find an appropriate sound effect for when the Pong ball hits objects. We ended up with a frequency range around 320 Hz - 640 Hz and a sound length around 100 msec.
   
   With the attained sound, we placed a call to the native method playTone(int freq, int length, int vol); of the class Sound, whenever it is realized on which side of the bumper the collision was.
   
   It seems however that the internal tone generator of the NXT is not able to be heard above the noise of the motors.
   

Conclusion:
The main focus in these lab experiments was to solve the problems regarding making the RCX-touch sensors distinguishable and to define an algorithm to mirror the course in the x and y axis of the NXTs coordinate system. This has been done.
The tests showed however that we need to experiment further with the Lego construction to help the movement of the ball to be more precise. This most probably concern the placement of the compass (removing interference with wires, motors and the like of the NXT), and maybe also the wheels of the ball, which should be replaced with smaller, wider ones giving more road-grip.
We chose the bigger wheels to begin with in the hope that the ball here by would be able to gain more speed, keeping the difficult levels of the Pong game in mind.

About the sound effect. We still have not given up on finding the original sound of the game, and hope maybe to find a mp3- or a wav-file to experiment with.
It was mentioned before that the volume of the internal tone generator might not be adequate, this might be solved using an external speaker connected to a port maybe amplified via power op-amp.