Construction of the human controlled bat

Goal:
To make a simple human controlled Pong bat resembling the computer controlled bat, but controlled via bluetooth.

Plan:

• To copy the computer controlled bat-construction omitting the sensors.
• To adapt the lejos bluetooth example code to make a simple controller for the bat.
  

Activities:

Already satisfied with the stability of the autonomus bat, constructing the human controlled bat was just a matter of copying the already existing bat-construction. Except for all the sensors, a perfect copy of the autonomous bat of was constructed in less than half an hour.

For enabling bluetooth control we needed two programs, one on the NXT receiving signals and converting it to a proper engine response, and one located on a laptop sending signals to the NXT.

The program on the NXT will wait for an incoming bluetooth connection, when this is established, it will continuously check the input stream for integers. The program reads an integer in the range 1-4 and perform the corresponding action such as moving the bat forwards or backwards.

The program sending signals to the NXT is also responsible for providing a simple user interface. The program uses itself as a keylistener and switches on the input A,C and Q for connecting and disconnecting and W, S for moving the bat.

Conclusion of end course project

In the beginning of the project we estimated some requirements that had to be met in order for our project to be a success. In the initial post these requirements were divided into groups concerning the ball, the autonomous bat, the human controlled bat and the environment. In this post we will for each group describe how and if the requirements were met.

About the ball:
We wanted the ball to be somewhat aware of its environment, in order to support a Pong-ball-like maneuverability. We feel that we have accomplished this on a satisfactory level. However in the original game, a movement of the bat while hitting the ball would also influence the new speed and direction of the ball. Implementing this would require the ball to be aware of the speed of the two bats and we would lose the beautiful simplicity of our current architecture.

In our evaluation of the project presentation we discussed the cosmetics of the ball. A spectator commented that he could not recognize the ball. There are several causes for this: The big, slow and clumsy NXT ball does not really resemble the small and fast ball from the old Atari game. The NXT center of rotation is far from the center of the Lego construction, upon collision it backs up before turning to a new angle and it does not change its speed. So the spectator is easily excused. We see that there is room for much improvement on the physical construction of the ball and have a few ideas for future work on the project.

If we had more time to develop we would work on making the ball smaller and faster in order to make it more similar to the original, this at the same time might also help to increase the difficult level of the game and make the game more fun.

On the Lego technology used in the ball:
In the end the compass worked out well, all though a deviation of as little as 5 degrees would cause strange things to happen.
The nice calculation of the angle of reflection is possible because we know at which angle the ball is colliding with the wall. In theory this may be done using several touch sensors on the perimeter of the ball. For us it is only possible to calculate the angle of reflection because we make the initial assumption about the environment being a quadratic box, on which the ball can align itself.

About the human controlled bat:
The human controlled bat proved to be the simplest of our three components. It generally fits the requirements mentioned in the initial post(a construction controllable by a human via bluetooth), although we chose a two-engine design for improved stability.
Even though the bats are both directionally stable on a non-slippery surface, we have noticed that the construction tends to slide out of direction during rapid direction changes on a more slippery surface. We have narrowed the reasons for this imprecision down to a simple matter of the weight not being distributed equally on both sides of the construction.

The current graphical user interface is very simple, and could indeed benefit from a reworking.

About the autonomous bat:
We are generally satisfied with the autonomous bat. It works well even though it is a simple construction with simple software. The requirements fits well with the behavior based architecture, which made it possible to implement it in a simple and elegant fashion. The bat works entirely based on the sensor readings measured on the surrounding environment.

It has been funny to see that the robots have insect-like behavior and are entirely unaware of each others presence, yet for the outsider they still seem to interact.

The autonomous bat suffers from the same weight distribution issue of the Lego construction as the human controlled bat. The unbalanced construction have a tendency to pull the bat away from its intended axis of movement. There are several possible solutions, one being a new construction with the weight redistributed to balance the movement and keep the robot aligned to its course.

About the platform:
Having worked with the Lejos system for the development of this project, we find that it hasn't limited our development in any way. We were very impressed with the overall completeness of the system, keeping in mind that it is an opensource project. One thing we have missed though, is the presence of some PC simulation/debugging software, this could have drastically shortened our write-compile-debug cycle. For some reason we used a lot of time trying to establish bluetooth connection between NXT and PC. Had we been successful much sooner this would have been a great support to gain debugging / logging information in the development cycle.

Future work summary:

• Rebuild of the ball, to get a more ball-like behavior.
• Rebuild of the graphical user interface for the human controlled bat.
• Adjust the center of gravity for the bats.

In conclusion: The game works, but it is too easy. Some of the future work would help relieve this problem, but short of making the human controlled bat move very slowly, which wouldn't be fun for the player, there doesn't seem to be a easy solution for this.

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.

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

Uge 12; Initial description of end course project

Deltagere: Lars, Thomas og Morten

Goal:
At tage en begrundet beslutning med hensyn til udformningen af vores slutprojekt, herunder at vurdere flere forskellige alternativer udfra de kriterier der står beskrevet i opgaveformuleringen.

Plan:
Analysearbejdet tager udgangspunkt i Capranis liste med forslag, samt gruppens egne ønsker og interesser for indholdet af slutprojektet.

1. I første omgang skal der udføres en brainstorm. Dette gøres for at få listet egne ideer og ønsker.
   
2. For hvert muligt emne skal der:
• Udformes en kort beskrivelse.
  
• Diskuteres hw / sw; antallet a NXT'er, kommunikation, hvilke sensorer og aktuatorer, sw arkitektur med argumentation.
  
• Diskuteres muligheder for at konstruere et 'kunstigt miljø', bedre passende for den givne NXT.
  
• Påpeges det sværreste at løse i projektet, med argumentation.
  
• Listes hvad vi forventer at kunne fremvise til slut.
  
3. Efter listen er gennemgået, skal der argumenteres for gruppens valg af slutprojekt.
4. Herunder skal der laves en dyberegående beskrivelse af projektet, evt. i samarbejde med Caprani.
5. Sidste punkt er, at udforme en realistisk tidsplan for projekt-processen

Activities:

Liste med projektforslag:

• Legovej navigation.
• Evolution.
• Legway.
• Interactive Robot Games.

• Autonom robot med kortopbygning, inspireret af bl.a. Maja J Mataric.
• Robot som interaktiv legetøj.

Analyser:
Legovej navigation og/eller autonom robot med kortopbygning, inspireret af bl.a. Maja J Mataric.

• Her kan man i første omgang starte med een NXT, som om nødvendigt kan kommunikere med en stationær PC via bluetooth.
• Omkring miljø, har gruppens erfaringer vist, at et almindeligt kontormiljø med stole- og bordben er meget besværligt for robotten at manøvrere i. En mulighed for at afhjælpe dette problem vil være at konstruere et kunstigt miljø, f.eks. Legovej elementer, eller et rum kun med klare og tydelige flader, f.eks. større kasser hvor der er mulighed for tydelige ekkoer for UltrasonicSensoren.
• Der skal bruges flere slags atenuatorer og aktuatorer;
• CompassSensor - vil kunne gøre navigationen mere præcis, idet kørselsretningen kan korigeres.
• UltrasonicSensor - kan have flere formål, det primære vil være at måle afstande til større objecter. De målte afstande koblet med vinkler fra kompasset, kan måske vise sig at hjælpe til at korigere navigationen, sammen med en form for virtuel mapbuilding, ie. korektion af cartesisk position.
• LightSensor - kan bruges til at genkende kunstige pejlemærker eller referencepunkter, f.eks. et grønt farvet stykke karton på gulvet.
• TouchSensor - en failsafe, hvis der køres ind i stoleben eller andet der kan være for småt til at reflektere ekko tilbage til UltrasonicSensor.
• 2 eller 3 motorer - minimum 2 motorer med tachomålere til fremdrift, og evt. en motorer for at dreje UltrasonicSensor i flere retninger og tage målinger.
• Det største problem vil blive at udvikle en abstraktion på og mulig vedligeholdelse af et kort over NXT'ens miljø. En abstraktion der er tilstrækkelig og ikke samtidig bliver uanvendelig, fordi det bliver i et menneskeligt symbolsprog som robotten ikke kan forholde sig til fysisk.
• Omkring hvad der er muligt at fremvise til slut;
• 1) En mulighed der har været på tale er en slags 'sentry' eller vagtrobot, der kunne have til opgave at køre rundt og holde øje med om forskellige tilstande i miljøet ændrer sig, f.eks. gennemsnitlig støj- / lys-niveau for forskellige kendte positioner, evt med en form for bevægelses sensor.
• 2) Der har også været snak om en robot der skal kunne finde en optimal rute gennem en labyrint, via en form for kortopbygning og planlægning.

Evolution manipulation og distribuering af robotgener:

• Man kan starte med at eksperimentere med 2 NXT-blokke, siden kan man låne sig frem, når/hvis der skal eksperimenteres med større flokke.
• Omkring miljø, vil det optimale, som nævnt før, være at lave et kunstigt miljø der ikke er besværligt for robotter at manøvrere i. I artiklen fra Embodied Evolutions bruges der jo f.eks. et lys, der hjælper som dommer for hvilke gener der skal overleve og hvilke der ikke skal. I artiklen af striegel er der også en dommer, ie. robotterne selv, hvis de ikke kan komme i kontakt med hinanden uddør de.
• Der skal bruges flere slags atenuatorer og aktuatorer. I første omgang kan der til hver NXT-blok anvendes to RCX lyssensorer, til at lave fysikken tilsvarende en Braidenberg vehicle, dvs. der også skal bruges 2 uafhængige motorer til at manøvrerer rundt med. Hvis Braidenbergs-behaviour kan komme til at fungere relativ hurtigt kan man udvide antallet af sensorer og ligeledes opførslen.
• Muligheden forligger at man bare anvender talværdier til at repræsentere gener, ligesom i eksperimenterne fra Embodied Evolution, men det kunne måske være mere interessant at anvende noget lignende reflection, ie. istedet at overføre metoder som gener. Det vil i alle fald forøge spektret af mulige genkonstruktioner. - Er det så et problem at vi bruger Java? - Det ser ikke umiddelbart ud som om, at pakken java.lang.reflect er en del af lejos-API'en.Hvis vi vil bruge noget lignende reflection, vil det så placere projektets indhold udenfor kurset?
• Produktet kunne ende op i en flok "dumme" NXT'er der starter med køre ind i vægge, men efter et stykke tid, lærer at manøvrere og opfylde nogle mål, gennem distribution af "god" viden, NXT'erne imellem.

Legway / Segway

• Segway projektet ville hardware-mæssigt komme til at minde meget om det projekt vi lavede under øvelserne, en nxt med to motorer, samt en lyssensor.
  
• Selve segway-ideen lægger ikke op til noget specifikt miljø, idet der først og fremmest skal arbejdes på at få en stabil robot. Hvis dette opnåes, kan man dog eksperimentere med at lade robottoen bevæge sig rundt i forskellige miljøer, evt. kunne man kombinere segway-robotten med legovej-findingsprojektet.
• Den største hurdle i forbindelse med et segwayprojekt ville, som under øvelserne, være at få bygget en robot der ved hjælp af en pid-controller og de tilgængelige sensorer, ville være så stabil, at den faktisk kunne anvendes til andet end at stå og rokke frem og tilbage.

Atari's 'Pong' fra 1972 som interaktiv robot legetøj (Interactive Robot Games):

• Der skal bruges 3 NXT'er: En NXT til at repræsentere bolden, og to til ketcherne, henholdsvis den til den menneskelige spiller og til 'ai'-spilleren.
• Miljøet skal være et afgrænset område, omkranset af en barriere til at holde bolden inde. Barrieren kan repræsenteres af fysiske vægge eller kanter, evt. kan de repræsenters ved striber af farve-/nuance-skift på gulvet. Til at hjælpe de to ketcherer i at 'holde kursen', kan der anvendes en skinneanordning, men dette kan give et problem for bolden, hvis den ikke bliver fanget af en ketcheren på vej ud, da bolden ikke nødvendigvis er terrænkørende kan den have svært ved at køre over skinner.
• Til ketcheren, der skal styres menneskeligt, skal der være mulighed for kommunikation, f.eks. via bluetooth til en laptop eller mobiltelefon.
• Om det er tilstrækkeligt med to lyssensorer til ai-ketcheren og en tilsvarende lysafgiver på bolden, for at ai-ketcheren kan placere sig korrekt i forhold til bolden, kræver lidt eksperimentation. En anden mulighed kan evt. være et kamera (NXTCam) på ai-ketcheren.
• Hvis der anvendes fysiske barriere til at holde bolden inde, kræver det et antal (evt. parallelt forbundne) touchsensorer. En anden mulighed er, hvis der bruges et andet farvet underlag til at afgrænse banen, kan der bruges lyssensore på bolden, men så opstår der måske problemer med at mærke om en bold bliver fanget af ketcheren.
• I teorien er det nok med én motor per ketcher, idet Ketcherne kun skal køre på en akse. Bolden er nødt til at have to motorer, da den skal køre i flere forskellige vinkler. Til at korrigere NXT-boldens kørende vinkel kan der bruges en CompassSensor.
• Det sværeste vil formentlig være at finde en god måde hvorpå 'ai'-ketcheren skal genkende positionen af 'bold'-robotten. Enten via lyssensor eller kamera.
• Fremvisningen af dette projekt er ligefrem, et interaktivt Pong-spil, med tre robotter, hvoraf den ener - en ketcher - kan styres af en menneskelig spiller, via piletaster på en laptop, mobiltelefon eller en remote.

Valg af end-course-project, og argumentation herfor:
Den autonome navigations robot vil helt sikkert være et spændende projekt, både interesant og lærerigt, men vi ville gerne finde et projekt der også kunne være interaktivt, i form af f.eks. spil.
Vi er en smule tilbageholdende overfor projektet med robotgener, grundene herfor er nævnt i afsnittet der beskriver dette ovenfor.
Valget af slutprojektet er således faldet på computer spillet fra Atari, Pong, som vi vil forsøge at lave i robotform.

A more detailed description
Dette afsnit skal udfyldes efter samtale med Caprani.

A plan for your work with the end course project
Dette afsnit skal udfyldes efter samtale med Caprani.