Final Pong Ball

Group members participating:
Morten, Lars and Thomas.


Duration of activity:
15 hours.


Goal:
To improve the Lego construction and the SW, in order to make the Ball move more precise.


Plan:

1. To improve the Lego construction by substituting with smaller wheels and raise the CompassSensor further up and away from the NXT-brick, wires and motors.
2. To construct a P-controller for when rotating to a new angle.
3. To find a way to distinguish between being hit on the front alone, or on either side.

Activities:

1. Initially we constructed the Ball with the big 8.16 cm diameter wheels, this together with a dusty linoleum floor gave problems with spinning upon acceleration. Because of this, we instead constructed the ball with the small 5.6 cm diameter wheels. This seem to reduce the spinning, but choosing the small wheels over the bigger wheels meant we also had to content our selfs with lesser speed.
   With the previous construction, the CompassSensor received errors of the magnetic interference from the NXT electronics. A solution could be to make a table of deviation, but this can only be done for a specific Lego construction, then for every small modification to the Lego one would have to make a new table. Instead the compass was raised further up and away from the NXT. We found that if the compass was in a distance of about 20 cm away from the rest of the NXT, the compass measurements would be trustworthy.
   
   
   Raised compass
   
   
   The ball is based on a construction of two main wheels connected to two separate motors, and a third wheel, that can rotate around its own axis, to balance the weight of the ball. The problem of compensating for the third wheel being in different positions upon rotating to a new direction initially gave a lot of headache. The problem was solved with the new CompassPilot described in the next subsection.



2. Our experience convinced us that the rotateTo method of lejos.navigation.CompassPilot was useless. In preceding tests, use of the navigation.CompassPilot.rotateTo made the rotating movement of the NXT overshoot the target direction several times - bouncing back and forth - never finding the correct angle.
   This of cause might have been due to a misunderstanding of the original CompassPilot on our part, nonetheless we chose to construct our own version of the CompassPilot.rotateTo(int i).
   We felt the need for a more controlled rotation and implemented a sort of P-controlled rotational movement. The closer the actual heading is to the target heading, the less power is supplied to the motors.
   
   power = (int)(60F - (((float)delta-180F)*40F)/(-180F));
   
   This normalization was inpired by Tom Deans notes on constructing Braitenberg vehicles. We changed it to use our own constants. 180 is the maximum angle to turn and we want a power in the range between 20 and 60. A power value below 20 is not enough to turn the wheels around and a value above 60 makes the wheels spin.
   When the power is calculated we make a test to see which is the smaller angle distance to turn - left or right - making the coresponding calls to MotorPort.controlMotor() for a left turn or right turn respectively.



3. With only two RCX touch sensors attached on either side of the ball, it was impossible to detect a collision with the boundary wall on the front. The idea here was that if both sensors was activated simultaneously, this would imply a collision directly on the front of the ball. When running tests, we never managed to see this state being detected.
   One solution, might be to include a time delay when checking the state of the touch sensors. It was estimated to require some debugging before some magic constant could be established. Instead we chose to attach a third NXT touch sensor on the front, on one of the still available input ports, and then adapt the program to account for the new sensor.

Explicit front collision detection with third touch sensor (NXT)

Conclusion:
The implementation of a new rotateTo method and the P-controlled rotation in our own CompassPilot was of great help in increasing the precision of the rotational movement of the ball.

Moving the compass further away removed interference from the electronics. In some initial testing we made the error of using metal shelves as boundary for the ball, which of cause sometimes gave rise to some unexpected behavior. One could argue that a form of average on the compass readings may resolve this issue, but since we are able to decide on the working environment of the ball this is unnecessary.
At the moment when the ball hits a wall it backs up, then change to the new course and resumes driving forward ( see diagram below).

Reversing before finding angle of reflection

In theory this makes the ball imprecise, at least comparing it with a natural round ball. Our estimation on this is that it is possible via software to make the ball find a more correct angle of reflection, but what this adds to the deviation in the long term would have no greater effect, because of the nature of the Lego construction. There is a further discussion on this issue in the final conclusion.

Controlling the autonomus bat

Group members participating:
Morten, Lars and Thomas.

Goal:
To create a control program for the autonomous bat, using a behavior based architecture with a suitable array of behaviors whose interaction will mimic the overall behavior of an autonomous Pong bat.

Plan:
To make use of our previously developed arbitrator and develop the needed behaviors.

As a minimum we will need the following behaviors:

• a light following behavior
• an idle behavior
• an exit switch
  

Activity:
Earlier in the course we developed an improved arbitrator. This arbitrator works on objects implementing the behavior-interface, but we do not use the suppress-method. Instead we start the behaviors in threads, and let it be the behaviors responsibility to check if the thread has been interrupted. The arbitrator interrupts the current thread when a new behavior will get control. The arbitrator starts a new thread when it switches behavior, and when the current behaviors thread dies.

Developing the light following behavior proved to be very simple, as we had already developed the basic behavior while testing the construction. We did however need to add some normalization of the input values, to make the robot less sensitive to the background lighting conditions. The Light following behavior also utilizes the Proportional part of a PID-controller, as the one mentioned on wikipedia, meaning that the robot should move faster proportional to the difference between the readings of the light sensors. Even with the normalization and proportional control of the behavior, it still captures the simple, stateless operation of the autonomous Braitenberg vehicles.

The inspiration for developing the idle behavior is the observation that the bat will not be able to detect the light source for at least half of the actual time played. With this in mind, it makes sense to try to position the bat where it's most likely to detect the light again. By centering the bat in the middle of the playing field, we optimize the chance of detecting the light when the ball returns. The centering mechanism is actually very similar the light following behavior. This behavior uses input from the ultrasonic sensors pointing in the direction of the playing field walls. Where the light follower seeks to minimize the difference between the light sensors, the idle behavior will minimize the difference between the two distance-readings, thus centering the robot in the middle of the field. The only assumption the behavior needs to achieve this, is that there is a playing field with parallel walls within the range of the ultrasonic sensors, which is not really a devastating assumption for a game of Pong.

Experiments
The experimenting during this phase mainly consisted of tuning the thresholds of the light-following behavior and then testing whether the new setup posed an improvement to the behavior. Through this testing we came up with a threshold of 25 meaning that the bat should only move when the normalized difference between the readings is larger than 25, this ensures that we only move when actually spots the ball.

References:
Rodney Brooks, a robust layered control system for mobile robots
Tom Dean, Introduction to Machina Speculatrix and Braitenberg Vehicles
Tom Dean, Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book

Construction of the autonomus bat

Present: Thomas, Lars and Morten.

Goal:
To determine the basic design of the autonomus(in other words the computer player bat) . Subgoals include gaining knowledge about the effective range of the sensors in play, thus helping us to determine the length and width of our playing field.

Plan:

• To construct a simple robot, similar to one of the Braitenberg vehicles, equipped with two lightsensors.
• To experiment with the robot, to determine wether we can construct it in a way that it is able to center itself relative to a lightsource.
• To experiment with the robot to determine the range at which it is able to center itself.

Activities:

Construction of the robot:
While brainstorming about the physical construction of the bat robots, we opted for a two engine, four wheels design due to the natural stability of this platform. To ensure directional stability we fixed the shafts between the two engines. At the one side of the vehicle we mounted a bat-like construction and on top of the bat we mounted 2x2 lightsensors in a 40 degree angel. To complete the design we added to ultrasonic sensors, one at each end of the vehicle.



After the initial construction, we wrote a simple test program, much like the code used in the Braitenberg vehicles. Using a table lamp as light source, we concluded that our vehichle was able position itself relative to this lightsource. But this simple test also showed us the importance of mounting the weels the same way all the way around and making sure that the tires are properly fitted on the rims, neglecting this will cause the bat to change direction inspite of the locked shafts.

Knowing that our ball would hardly be able to carry the tablelamp, we realised the need for a smaller lightsource and thus carried out the following experiment, to determine wether the light sensors we fitted would be able to recognize the small lego-lights at a distance.

Experiment with the lego-lights and the RCX light sensors:
The setup for this experiment consists of two RCX light sensors and one lego-light. We then marked distances from 0 to 150 cm with a 15 cm interval on the wall and lined the light up with the wall at the 0-marker. The next step was to measure the raw values produced by the lightsensors at the different distance markers. For this purpose we used a simple program for the NXT. We repeated the experiment with one light sensor, two light sensors and with one light sensor with minimal light in the room.



The following table shows the data obtained during the experiment:

Distance	1 sensor	2 sensors	1 sensor, dark
15	37	72	70
30	30	59	57
45	27	52	49
60	24	49	46
75	23	45	41
90	22	44	38
105	21	41	35
120	21	39	34
135	20	38	34
150	20	38	33

The raw values of the background lighting was measured to 17 with one sensor and 32 with two sensors. From the collected data we conclude that we will be able to recognize the light at distances of up to 150 cm, which is more than we expected and actually makes the lego-light a possible light source for our game. Using two sensors instead of one more or less just doubled the values, but we chose to use two because this gives us a clearer distinction between our lightsource and the background lighting. The experiment also shows us that there is no reason to darken the playingfield to better recognize the lightsource.

One thing we noticed during the experiment is that the light seem to be concentrated in a rather narrow cone shape. This suggest that we will need multiple lightsources on the ball to make sure that our bat will be able to detect it when approaching in different angles.