Implementation

The year is 2067. Health and Safety regulations have gone too far. Sport has been outlawed . To satisfy the entertainment needs of the people, robots have been created to fight one another. They have been built with family-friendly lasers. They hunt out the opponent and blast them away with their laser. Skill is everything. Failure is not an option. LaserBots - be entertained. 

(Rated PG. Ages 8+). 

The objective of LaserBots is to shoot the opponent robot and be the first to get to a score of 50. 

Currently, LaserBots is for two players. However, in the future, targets could be made and sold with the game so that the game could be for one player. To increase the number of players in the future, more XBees will need to be setup and added to the circle network. 

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.

In this post is all the Arduino source code for each robot, and the games master Processing code.  See the individual posts for a walk-through of each section and it's function.

#include <Servo.h>
#include "avr/interrupt.h"

char instruction [10]; //instruction sent to arduino
int i = 0; //index for instruction array
int j = 0; //index for for loop

String stringXCoord = "";
int intXCoord; //x coordinate for servo
String stringYCoord = "";
int intYCoord; //y coordinate for servo

Servo servoX; //servo x
Servo servoY; //servo y

The Games Master GUI was designed using Processing. In Processing, there are quite a few examples on how to draw different things. Firstly,it was figured out how to draw text by looking at the Processing example "Words". The screen was to be split into two halves, one the left hand side would be LaserBot one's score, and on the right LaserBot two's score.