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.

End course project description

Goal:
We want to construct a interactive robot game, inpired by the Atari Pong from 1972.

Plan:
The goal of the project is to present a interactive Pong game consisting of three NXTs. One NXT should model the Pong ball, the other two should represent the bats on either side of the playing field.
One bat should be controlable by a human player, the other bat and the ball should be autonomous.

Requirements:

• Environment:
  1. We want to control the environment of the robots in the sense that the playing field should be delimitted by a outer boundary consisting of walls or other horisontal surfaces.
• Human controlled bat:
  1. It must be possible for a human player to control one of the bats. This should be enabled by bluetooth either via laptop or cellphone.
  2. It should be adequate to use a single engine to control the movement of the bat, as it will only move along one axis.
• Ball:
  1. It should be able to calculate an angle of reflection upon collision with a barrier or a bat. This implies an awareness on the balls part about the present course and on which side it collided with the barrier.
     • Awareness of present course should be established by mounting a compass.
     • Collision detection might be established by use of touch sensors on the chassis of the ball.
     • If it is not possible using touch sensors to detect the barrier, it might be using lightsensors to measure color variations on the floor.
  2. The ball should be mounted with two engines, given that the it should be able to make changes to its course.
• Autonomus bat:
  1. The autonomus bat must be able to place itself relative to the ball.
     • Test must be made to see if this is possible using light sensors and a form of Braitenberg vehicles.
     • If it is not possible using light sensors, instead it might be using a camera.
  2. It should be adequate to use a single engine to control the movement of the bat, as it will only move along one axis.

Resistors in RCX touch sensor

Group members participating:
Lars, Morten and Thomas.


Duration of activity:
In total; 6 hours. The actual practical testing took about 2 hours, while the remaining 4 hours was used on finding relevant references and documenting the process.


Goal:
For future work of our project we want to investigate the possibility of using several touch sensors. In order not to consume all input ports of the NXT, we want to understand how the old RCX touch sensor functions, and to see whether it is possible to connect sensors in parallel using only one NXT input port.

Plan:

1. Investigate the physical construction of the RCX touch sensor.
2. Determine the measured limit integer value corresponding to a return value true from a call to readBooleanValue on the SensorPort.
3. Create a graph of the working range of the input port, ie. measured integer value versus resistor load over pin1 and pin2 of the input port.

Activities and Results:

1. We borrowed 9 defect RCX touch sensors and 1 working see-through RCX touch sensor to experiment with.
   
   • A working sensor; Looking inside the see-through sensor showed that it has a fixed resistor mounted between the two wires. Using a multi tester gave resistance reading of around 15k ohm when the the touch sensor was not pressed, and a reading of 1.4k when the sensor was pressed. The explanation is that the rubber elastic (its function is to push the plastic button out) is actually also conductive. This means that if the touch sensor is pressed current will flow through both the rubber elastic and the fixed resistor, lessening the total resistance through the sensor (see figure2).
     
     
     
     Figure1; a picture of an open RCX touch sensor
     
     
     
     Figure2 shows resistor diagram of an original working RCX touch sensor
     
     
     Measuring the resistance of several touch sensor blocks in their different states gave the results presented in the table below:
     

     num\state	unpressed	light press	hard press	comments
     0	15.0 k Ω	14.6 k Ω	1.4 k Ω	works | with pull-up
     1	∞ Ω	199.0 k Ω	17.0 k Ω	≥ 14.26k Ω| never true
     2	∞ Ω	70.0 k Ω	3.9 k Ω	works | no pull-up
     3	∞ Ω	10.0 M Ω	160.0 k Ω	≥ 14.26k Ω| never true
     4	∞ Ω	5.0 M Ω	2.6 k Ω	works | no pull-up
     5	∞ Ω	12.0 M Ω	4.0 k Ω	works | no pull-up
     6	∞ Ω	8.0 M Ω	0.7 M Ω	≥ 14.26k Ω | never true
     7	∞ Ω	15.0 M Ω	7.0 M Ω	≥ 14.26k Ω | never true

     From the table it can be seen that the touch sensors does not only work as switches, ie. they are not strictly on/off, it can potentially work on a variable proportional input / output. - If the sensor is pressed hard, it will give a different readout then if the sensor is only pressed lightly, ie. the rubber elastic acts as a variable resistor.
     
   
   
   
   • Tampered sensors: 2 of the touch sensors had already been 'tampered' with. The back side of the two is labeled 222 and 119, disassembling one of them showed that a small SMD resistor had been glued on the rubber elastic spring, while the original fixed resistor had been removed.
     The two tampered sensors function by letting pin1 of the input port float in mid air (well actually, internally in the NXT, it is connected to 10k ohm pull up resistor) when not pressed, meaning the value measured by the NXT ADC is the max value (in this case 1023).
     When the sensor is pressed, pin1 is pulled to ground via the SMD resistor, inside the sensor, giving us a voltage divider to let the ADC measure on (see page 6 in HDK).
     
     
   
   
   • Defect sensors: Opening one of the 9 defect sensors given to us gave an explanation to the dysfunction. The fixed resistor had been removed, no SMD resistor had been attached and some of the rubber elastics had lost most of their liveness properties, meaning that when pressed only a minimal current (close to zero) went through the rubber elastic, ie. the output of the voltage divider inside the touch sensor, is still close to 5V.
     Using a multi tester on the rubber elastic which had lost some liveness showed a reading of about 7M ohm. This means even if the sensor button is fully pressed, the total resistor value is still larger than the 600 integer limit of the corresponding 'isPressed' true/false limit.
     
     


2. Using a test program and bridging pin1 and pin2 with different resistor values, it was possible to establish the true/false limit similar to the integer values 600 = false, and 599 = true. The corresponding ohm value looks to be between 14.16k ohm and 14.26k ohm.



3. Investigation shows the ADC has a resolution of 10 bit, with a pull-up resistor of 10k ohm, giving the SensorPort a integer range from 0 to 1023.
   The measured integer values from point (2) above, and their corresponding resistor loads was logged, and a graph of the logging can be seen in the figures below.
   
   Figure3: a plot of measured input of the SensorPort / input-load, with only the resistor axis in logarithmic scale.
   
   Figure4: a plot of measured SensorPort input / input load, with both axis' in logarithmic scale.

Conclusion:
From the graphs (figure 3 and 4) and the measurement of resistor values, we saw that for a RCX touch sensor to function in a proper fashion (maybe also backward compatible), it should have a fixed pull down resistor (Rfix) of 15k ohm or above. The 15k value gives the NXT a possibility of knowing that something is connected. The measured value on the analog input port of the NXT pin1 is lowered from floating 1023, to a value around 615 for the 15k example.
Given the of the rubber elastic (Rrub) is within the range 1.4k - 12M, and that the 599 integer limit has a similar ohm value of approximately 14.16k ohm, the two resistors inside the sensor housing (Rtot = Rfix || Rrub) should be in the range:

Unfortunately this approach is not applicable for several reasons:

• Some sensors have lost conductive properties. In the case of (Rfix = 15k) and a defect rubber elastic (Rrubmin = 0.7M), the parallel resistor value of the two will not be below the 600 limit: 14.26k ohm:
  
  
• If we want to connect N sensors with fixed 15k ohm resistors in parallel to the same input port, the parallel resistors will lower the collected resistance to around (15k / N), which for (N=2) already is below the 14.16k-limit, ie. the measured value is less then the 600 integer pressed/un-pressed limit.
• Further more the nature of the variable elastic rubber resistor makes it impossible to distinguish the different sensors apart.

The final solution should enable the sensor to work in the usual way, ie. that calling SensorPort.S1.readBooleanValue() will still return respectively true/false if an equivalent call to SensorPort.S1.readRawValue() returns a integer value less then 600/greater then 600.

A way to do this is by cheating; as mentioned in point [Tampered sensors] above, gluing a SMD resistor directly on the back of the elastic rubber spring, and letting the input pin float when not pressed, - when pressed - the SMD resistor will act as a pull down resistor. Then from the graphs above (figure3 and 4) it can be seen that, the SMD resistor value then should simply be less then 14.16k ohm and above 50 ohm. This yields a working resistor range, where the individual touch sensors are distinguishable.

Using the aquired results we see, that it is possible to connect several RCX touch sensors in parallel to just one SensorPort.


References:
Page 527 at91sam7s series datasheet http://www.atmel.com/dyn/resources/prod_documents/doc6175.pdf

Page 6 in HDK http://cache.lego.com/upload/contentTemplating/MindstormsOverview/otherfiles/2057/LEGO%20MINDSTORMS%20NXT%20Hardware%20Developer%20Kit(3)_7A0CF630-CCE5-4AAF-91FA-D1E7C911817C.zip