Problems with Design

It was discovered during extensive testing that when motors were turned on i.e. the robot driving, that the interrupts for laser detection were being called.  This was only found when status LEDs were implemented, as otherwise there was no other indication of the laser detection other than on the GUIs.  It is suggested that this is the reason why both robots cannot be controlled simultaneously through the network, as the interrupt is flooding the network with 'games master' packets, and causing the actual control signals to robot 2 to be lost.

The reason for the interrupts being called is that they are triggered on a falling edge, i.e. when the laser is detected, the interrupt pin goes low.  When the motors are started, a high current draw is required, this causes the voltage across the whole robot to dip. This voltage dip is low enough to trigger the interrupt. 

This is undesirable, as it causes the score to increment when the player drives the robot.  It also stops both robots from being simultaneously driven.  A work around for this was achieved by implementing turn by turn play - making the game more strategic.  It also makes the game slightly easier - as hitting a tiny moving target has proven to be difficult through the robot.  

If this problem is fixed in the future, it is suggested to keep the turn by turn play, with the scores staying the same when robots are driven.

After attempting to get Processing to run on the Raspberry Pi, and observing the speed at which that runs, concerns were raised about the ability of the Pi to process two video streams simultaneously.  In addition, other groups findings were that the Pi could only achieve an approximate refresh rate of 1 frame per second at a very low resolution from a wired webcam.  Our project would require this stream to be wireless, and at a high enough resolution to see the laser.

It was decided to move this objective into the future, as time constraints and hardware availability would restrict the development of this further.

Other findings from testing were that each robot had a very short battery life, with the 6V power gradually running out.  In addition the 9V batteries that were powering the Arduino and Xbee were very cheap batteries from a pound shop, and did not provide enough juice to run both.  Higher quality batteries were purchased and this solved the issue, although it is unknown as to how long for.