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.