To fix the motors causing interrupts issue, it has been suggested to use smoothing capacitors to reduce the current spike and resulting voltage dips.  Another solution would be to disable interrupts from being triggered while the robot is driving, or changing the interrupts from falling to rising edge could also solve the problem.

At the moment the PCB has to be removed to change the batteries (which is fairly often with cheap batteries) , this is not an ideal solution.  Large PCB spacers could be mounted in the chassis and drilled through the PCB. so that it is mounted high enough that the batteries can be removed without removing the PCB.  On a similar note, the PCB should be redesigned with the correct size of Molex connectors, so that the connections can be neater and more robust.

As discussed earlier, more work will be done on accessing the serial port through Processing on the Raspberry Pi, this will allow the games master GUI to be run on a much cheaper machine.

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.