Home > January 2013

January 2013

Welcome!

Friday, 18 January 2013 0

This site documents our embedded systems project 'LaserBots' from design right through to implementation and testing.

For this project we proposed two Arduino powered robots controlled through iPads, with a 'Games Master' running on another machine (initially a Raspberry Pi).  The players could then fire lasers at the other's robot, with that robot detecting and updating scores accordingly.


See the technical manual below for how we designed and implemented the project within the time-frame  and the user manual for how to play the game.

LaserBots: User Manual

Category : , , , 1

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+). 

OBJECTIVE OF THE GAME

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

PLAYERS

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. 

Read more »

Technical Manual

Category : 0

This page contains links to all technical information about the system, along with problems encountered with the original design and future improvements to the system.

Firing Device and Detection

Aiming

Communications

Human Computer Interfaces

Conclusion

Future Work

Category : , 0

A specific Raspberry Pi camera has been developed which interfaces directly with the GPU, which would improve it's performance, however these have not been put into production yet.  It has been suggested that using the VoIP service Skype for the video streaming would work as a simple solution.  Each robot would have a mobile device attached to it, and the user would run a video call from it.

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.

Problems with Design

Category : , 0

Motor Current Spikes Triggering Interrupts


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.

On-board Video on Raspberry Pi


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.

Power Consumption


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.

Project Management

Category : 0

Project Timeline 
Due to certain parts of the project taking less and some parts being considerably more difficult than was initially thought, along with delay in obtaining particular components the project timeline was updated to reflect the plan for the remainder of the project. Initial timing is on the top line and the revised timing is on the second line in red.

Updated Project Timeline

Read more »

Final Demonstration Code

Category : , 0

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.

Final Arduino Code for Robot 1

#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

Read more »

Final Build Pictures

Thursday, 17 January 2013 Category : , 0

The PCBs were mounted using double sided tape on top of cardboard to protect connections on the bottom.  This was mounted on top of the 6V battery pack, which was in turn stuck to the chassis.  This type of mounting is not ideal, as while it is secure, it makes changing the batteries underneath awkward, as the robot essentially has to be dismantled to do so.  This can be improved in future iterations of the design.


Bullseye targets were created and mounted on the LDRs, during testing it was found that these were particularly useful when the player has just missed the target, and can adjust accordingly. 

Read more »

Games Master GUI

Wednesday, 16 January 2013 Category : , , , 0

The Games Master GUI is the graphical user interface that is displayed on a laptop that is connected to the Games Master Arduino. Its purpose is to display the scores of each LaserBot for everyone to see.

DESIGN

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. 

Read more »

Testing Multiple Controllers

Sunday, 13 January 2013 Category : , , 0

In order for the two robots to be controlled effectively, it is necessary to receive and differentiate between messages sent from two controllers.  The TouchOSC app allows for the IP address of the host to be configured, along with the port of the application to send messages to.  The port of received messages on the iPad can also be configured, this is generally left as default.  At the bottom is the iPads IP address, which is required to send messages back to the controller to control LEDs and labels on screen. The configuration screen is shown below.
TouchOSC configuration screen

Sending Messages

Using some of the examples on the OscP5 library's website it was possible to create some prototype code to send OSC messages back to the controller, to update labels and turn on LEDs etc. The processing code below updates the player's score label.

Read more »

Improving iPad Interface

Saturday, 12 January 2013 Category : , 0

The original touch interface constructed here was improved using the TouchOSC editor to include labels and LEDs to show the robot's status, and player's score.  When a robot is hit, the plan is to disable it's movement for a set amount of time. These LEDs will show where the robot was hit, and whether the robot can be moved or not.  This is important feedback to the player. A screenshot of the new interface design can be seen below.
Improved Interface
Two sets of this interface were designed and tested on two iPads, with slight differences in labelling to show which iPad is controlling which robot.  The names of components on the second interfaces were named '/2/control' so that the games master can differentiate between messages sent from each.

Read more »

PCB Design and Manufacture

Friday, 11 January 2013 Category : , 1

In order to make the robot implementation more robust and neater, a PCB was designed.  The software used was the EAGLE design suite.  The tested prototype circuits were analysed and transferred to a schematic with connectors to interface the PCB with the Arduino and the rest of the robot.  This schematic can be seen below.
PCB Schematic
Each subsystem can be seen; the connector for the Arduino control signals is on the left, the motor chip middle centre, four LEDs for robot status to the right of the motor chip, three LDR detector transistor circuits, and then finally the Molex connectors on the far right.  At the bottom are two connectors to allow the two power supplies to be connected to the board.

Read more »

Building a Full Robot

Tuesday, 8 January 2013 Category : , 0

Before designing a PCB for the robot, it was necessary to test all the prototype circuits when put together.  This was important, as if the circuits are not correct, it is much easier to fix at design stage than after it is set in copper on a PCB.  The completed prototype robot can be seen below.
Completed Prototype
Each group member constructed their own subsystem on a breadboard that fit the size of the robot.  The Arduino and Xbee was mounted towards the rear of the robot.  The complete robot was then tested with communications through a USB cable, and no issues were encountered.  The hit notification was tested by using another laser to trigger the sensor, and then Processing was monitored to see the notification packet come through.  These tests can be seen in the video below.

Read more »

Circle Network: Controlling each robot

Monday, 7 January 2013 Category : , , 0

In this post, it was explained that the LaserBots are now connected in a circle network as shown below. The Games Master talks to LaserBot 1, LaserBot 1 talks to LaserBot 2 and LaserBot 2 talks back to the Games Master. 
Circle Network Setup

NEW PACKET STRUCTURE

To implement this correctly, the packet that is being sent round needs to be modified so that the instruction is sent to the correct LaserBot. Therefore, the new packet format is as follows:
< - character to signify start of message
1 or 2 - robot ID 
F or f - turn laser on or off
XX - numbers to control servo x
XX - numbers to control servo y
F, B or S - left motor controls (forward, back or stop)
F, B or S - right motor controls (forward, back or stop)
> - character to signify end of message

 Also, to send the scores back to the Games Master, another packet needs to be introduced:
[ - character to signify start of message
G - intended for Games Master
1 or 2 - robot ID
XX - number representing how much score should be incremented
] - character to signify end of message

LASERBOT ONE CODE 

INSTRUCTION PACKET CODE

The code in each robot needs to be modified to accept this new packet structure. Firstly, the array used to store the instruction needs to be made bigger to accommodate the extra characters being sent. 
char instruction [10]; //instruction sent to arduino
Next, a String needs to be introduced so that a message can be resent on to robot 2.

//message to send on to Robot 2
String resendMessage = "";
Inspecting the previous code for the robot, the first part of void loop() stays the same - while there is serial data available, read the data and store in the instruction array. Next, check to see if the instruction starts and ends with the characters '<' and '>' (remembering to change the index by one for the ending character). 

 Next, another if statement needs to be added to check whether or not the instruction received is for robot 1. 
//check that message is for robot 1 <1....>
        if (instruction[j+1] == '1')
        {
If the message is for the robot, the normal parsing takes place (parse the rest of the message to deal with lasers, servos and motors). Else, if the message is for robot 2, robot 1 needs to resend the message. The message is concatenated together and then printed out. Before being printed, however, the serial port is flushed. 
//else check is message is for robot 2 <2...>
        else if (instruction[j+1] == '2')
        {
          //reset resend message to blank
          resendMessage = "";
          int k = 0;
          //loop around the instruction message
          for (k = j; k<(j+10); k++)
          {
            //concatenate all characters of message
            resendMessage += instruction[k];
          }
          Serial.print(0); //flush the serial port
          Serial.print(resendMessage); //send the message onto Robot 2
        }
That is all the code that needs to be added/changed for robot 1 to parse the instruction message.

SCORE PACKET CODE

To update the score, a score packet needs to be sent on to robot 2, who will then send it on to the Games Master, which keeps track of all scores. Therefore, when the robot is hit, it needs to send a score packet. Firstly, the variables need to be stated.
//string to print to contact games master - in the following form:
//G (games master) 2 (robot 2's score) 10 (how much to increment score)
String GMscoreLR = "[G210]";
String GMscoreB = "[G215]";

As can be seen, the robot ID has been stated has 2, even though this code is on robot 1. This is because robot 1 has been hit, but it has been hit by robot 2 and so it is robot 2's score that needs to be updated. 

 The reason for two different score packets is for the two interrupts that are used to detect when the robot is hit. This allows for two different scores to be implemented. Therefore, in interrupt one the following code needs to be added
    Serial.print(0);//flush the serial port
    //print message to GM to increment Robot 2's score
    Serial.println(GMscoreLR);
In the other interrupt, this code needs to be added:
    Serial.print(0);//flush the serial port
    //print message to GM to increment Robot 2's score
    Serial.println(GMscoreB);
These interrupts print the correct string which will then be sent on to robot 2. 

LASERBOT TWO CODE

INSTRUCTION PACKET CODE

Again, the array used to store the instruction needs to be made bigger to accommodate the extra characters being sent. 
char instruction [10]; //instruction sent to arduino
Next, a String needs to be introduced so that a message can be resent on to the Games Master.
//message to send on to Games Master
String resendMessage = "";
Again, inspecting the previous code for the robot, the first part of void loop() stays the same - while there is serial data available, read the data and store in the instruction array. Next, check to see if the instruction starts and ends with the characters '<' and '>' (remembering to change the index by one for the ending character). 

Next, another if statement needs to be added to check whether or not the instruction received is for robot 2. This is not really needed as anything that is sent to robot 2 will be for it, but it is extra error checking.
//check the message is for  robot 2 <2...>
        if (instruction[j+1] == '2')
        {
If the message is for robot 2, the normal parsing takes place (parse the rest of the message to deal with lasers, servos and motors). That is all the code needed for the instruction packet. 

SCORE PACKET CODE

For the score packet, as well as sending its own score packet, robot 2 needs to process robot 1's score packet. Let's deal with that first. 

In void loop(), there is an if statement to check for the characters '<' and '>.' After this statement and else if statement needs to be included to check for the characters '[' and ']'. 
//if message is score packet for the Games Master
      else if ((instruction[j] == '[') &&  (instruction[j+5] == ']'))
      {
        //reset resend message to blank
          resendMessage = "";
          int k = 0;
          //loop around the instruction message
          for (k = j; k<(j+6); k++)
          {
            //concatenate all characters of message
            resendMessage += instruction[k];
          }
          Serial.print(0); //flush the serial port
          Serial.print(resendMessage); //send the message onto games master
      }
In this else-if statement, the message is concatenated together and then sent on to the Games Master. 

 For robot 2's own score, the same code as robot 1 needs to be included in the interrupts.
    Serial.print(0);//flush the serial port
    //print message to GM to increment Robot 2's score
    Serial.println(GMscoreLR);
And in the other interrupt, this code needs to be added:
    Serial.print(0);//flush the serial port
    //print message to GM to increment Robot 2's score
    Serial.println(GMscoreB);
That concludes all the code that needs to be updated on the robots. Please see post BLAH for the parsing of the Games Master packets in Processing.

XBee Configuration: Coordinator and Router (Circle Network)

Category : , , 1

After trying a point to point network, and a point to multipoint network, it was decided that a circle network would be implemented. 

Circle network
For this, one XBee needed to be set up as a coordinator and two XBees needed to be set up as routers. 

WHICH ONE TO BE THE COORDINATOR?

For this circle network, the XBees were configured several times until the network worked. Trial and error was used, changing which robot or games master should be a coordinator or router. In order to test the system, a simple test was done by sending integers around the circle, which were read and retransmitted by the correct XBees. Eventually, the setup that worked was:
Coordinater - Robot 2
Router 1 - Games Master
Router 2 - Robot 1
Coordinator and Router Setup for Circle Network

Read more »

Running Processing on the Raspberry Pi

Category : , 0

Having encountered difficulties installing processing on the raspberry pi it was discovered that the problem was due to the default Java JDK'Sun 6 JDK'  not being able to run on ARM. In order to overcome this an alternative ARM compatible JDK was downloaded and installed.
sudo apt-get install openjdk-6-jdk librxtx-java

Processing linux 32 ( in this case 1.5.1) was then downloaded and unzipped.
http://processing.org/download/

This linux verion of Processing assumes a Intel architecture so we need to remove the link to java directory from within the unzipped files. To do this the command rf is used. a side effect of this is that the director will most likely be deleted.  This is described in more detail here. http://www.linuxjournal.com/article/50
rm -rf java

Read more »

Point to Multipoint - Broadcast Network Design

Category : , , 0

This method for configuring Xbees ended up being too slow for this projects requirements, due to the Zigbee protocol's requirement for delays to be in place to allow packets to propogate through the whole network.

A simple solution could be to simply use another Xbee, and have a separate channel for each robot, however this would require another shield and Arduino as an interface.  The budget and hardware is not available for this.  Instead a 'circle' network configuration was devised to allow all devices to communicate at rate that was suitable.

In a broadcast network, one module is set as the 'master'.  This sends out all it's messages to all devices on the network.  The devices can then check an ID that is sent as part of the message, and then decide whether they need to act upon it or not.  This sounded suitable for this project, as both robots could then receive all messages, and only carry out the instructions if the ID matched the number of the robot.  They can then reply to the master if they are hit, or as required through a uni-cast connection which is configured in their modules. This configuration is illustrated below.
Broadcast configuration for an Xbee network
This is not as simple as the standard uni-cast point to point network with two modules that is often employed with Xbees so direct configuration of the Xbee's firmware was required.

Read more »

Point to Point Xbee Network Testing

Friday, 4 January 2013 Category : , , 2

Xbees are wireless modules which interface radio transmissions with standard serial input output.  All transmission issues are taken care of by the Zigbee protocol (which is the protocol that Xbee Series 2 modules use).  This ease of use means Xbees are often used as drop in replacements for a serial cable as can be seen in the diagram below.  In this configuration the module's default settings mean that a link can be set up quickly and easily.
Xbees in Unicast mode
This is called 'uni-cast', when a module knows the address of it's recipient, and sends data directly to it.  In this example, the second module also knows the address of the first Xbee, and therefore can reply back to it.

Xbee Shields

In this project, shields are used to interface the Xbee module with the Arduino Uno on the robots.  The main component on these shields is a voltage regulator to convert the Arduino's 5V logic to the Xbee's 3.3V. Without this the Xbee module could be damaged.

Read more »
Theme MXS. Powered by Blogger.