Code examples from today’s class

Example 1: Spin Search

//
// Spin search sumo example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    while(1)
    {
        if (P1IN & BIT0) // Proximity sensor
        {
            P2OUT = 0b00010101; // Forward with LED on
        }
        else
        {
            P2OUT = 0b00001100; // LM forward, RM reverse, LED off
        }       
    }
}

Example 2: Bounce Around Table

//
// Bounce around sumo robot example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    while(1)
    {
        P2OUT = 0b00010100; // Forward with LED off
        
        if (P1IN & BIT1) // Colour sensor white?
        {
            P2OUT = 0b00001101;     // LM forward, RM reverse, LED on
            __delay_cycles(750000); // 0.75 seconds
        }
    }
}

Example 3: Spin Search and Move

//
// Sumo robot example MSP430G2553
// Written by Ted Burke - Last modified 30-11-2016
//
// P1.0 is proximity detector
// P1.1 is colour sensor
// P2.0 is green LED
// P2.1 and P2.2 are left motor
// P2.3 and P2.4 are right motor
// 

#include <msp430.h>

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00000000; // Sensors: P1.0 is proximity, P1.1 is colour
    P2DIR = 0b00011111; // Motors and LED
    
    int counter;
    
    while(1)
    {
        // Search for opponent
        counter = 0;
        while(counter < 2000)
        {
            P2OUT = 0b00001100;     // LM forward, RM reverse, LED off
            
            if (P1IN & BIT0) break; // Proximity sensor detects object?
            
            counter = counter + 1;  // increment counter
            __delay_cycles(1000);   // 1 ms delay
        }
        
        // Driving to white line
        while ((P1IN & BIT1) == 0) // While colour sensor stays black
        {
            P2OUT = 0b00010101;     // LM forward, RM reverse, LED on
        }
        
        // Turn and drive back into the centre of table
        P2OUT = 0b00010010;     // turn
        __delay_cycles(500000); // 500 ms delay
        P2OUT = 0b00010100;     // forward
        __delay_cycles(1000000);
    }
}
Posted in Uncategorized | Leave a comment

Using the TCRT5000 as a proximity detector

//
// IR proximity detector MSP430G2553
// Written by Ted Burke - Last modified 23-11-2016
//
// P1.0 is used as A0 the analog input for the potentiometer
// P1.1 is used as A1 the analog input for the proximity detector
// P1.2 is used as TXD the UART transmit pin - connect this to Launchpad
// P1.3 is green LED
// P1.4 and P1.5 are joined together to drive the IR LED
// 

#include <msp430.h>
#include <stdio.h>

int read_analog_channel(unsigned int);
int proximity();

void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
    
    // Digital i/o
    P1DIR = 0b00111000; // P1.3 is green LED, P1.4+P1.5 is IR LED
    P2DIR = 0b00000000; // P2.0-7 are inputs
    
    // Analog inputs
    ADC10AE0 = 0b00000011; // A0 is proximity sensor, A1 is threshold input
    ADC10CTL0 = ADC10ON;   // Turn on the ADC

    // Basic Clock Module (set to 1MHz)
    DCOCTL = CALDCO_1MHZ;
    BCSCTL1 = CALBC1_1MHZ;
     
    // UART
    // Baudrate = 1MHz / (256 * UCA0BR1 + UCA0BR0)
    UCA0BR1 = 0; UCA0BR0 = 104;  // Set baudrate = 9600
    UCA0CTL1 |= UCSSEL_2;        // Set USCI clock to SMCLK
    UCA0MCTL = UCBRS0;           // Modulation UCBRSx = 1    
    P1SEL = BIT2; P1SEL2 = BIT2; // Set P1.2 as TXD
    UCA0CTL1 &= ~UCSWRST;        // Start USCI (release from reset)
    
    // Variables to store voltage readings
    int v_pot, v_off, v_on, v_prox;
    
    while(1)
    {
        // Read the proximity sensor
        v_off = read_analog_channel(0);    // Take baseline reading
        P1OUT |= BIT4 + BIT5;              // IR LED on (i.e. set P1.4 and P1.5 high)
        __delay_cycles(1000);              // 1ms Settling time
        v_on = read_analog_channel(0);     // Take IR reflection reading
        P1OUT &= ~(BIT4 + BIT5);           // IR LED off (i.e. set P1.4 and P1.5 low)
        v_prox = v_on - v_off;             // Subtract out baseline to get v_prox
        
        v_pot = read_analog_channel(1) / 4; // Read threshold voltage from pot (and scale down)
        
        if (v_prox > v_pot) P1OUT |= BIT3; // green LED on when reflection detected
        else P1OUT &= ~BIT3;               // green LED off when no reflection deteceted
        
        printf("v_off=%04d v_on=%04d v_prox=%04d v_pot=%04d\n", v_off, v_on, v_prox, v_pot);
        
        __delay_cycles(250000);
    }
}

//
// For the printf function (from stdio.h) to work, we need to provide
// a putchar function which transmits a single character via the UART.
//
int putchar(int c)
{
    UCA0TXBUF = c;
    while((IFG2 & UCA0TXIFG) == 0); 
}

//
// This function performs a single analog to digital conversion,
// converting the voltage on analog input pin ANx into a 10-bit
// unsigned integer. Execution time for this function is of the
// order of 100us.
//
int read_analog_channel(unsigned int x)
{
    ADC10CTL0 &= ~ENC;            // disable conversion
    ADC10CTL1 = x << 12;          // select channel
    ADC10CTL0 |= ENC;             // enable conversion
    ADC10CTL0 |= ADC10SC;         // start conversion
    while(ADC10CTL1 & ADC10BUSY); // wait until complete
    return ADC10MEM;              // return digital value
}
Posted in Uncategorized | Leave a comment

Live Race to the Wall Results – October 2016

The results so far for the Race to the Wall can be viewed on the following Google spreadsheet:

Live Race to the Wall results

Posted in Uncategorized | Leave a comment

Motor example from today’s lecture

Please note the colour-coded wiring on my breadboard:

  • Black is 0V. Never use black for any wire that isn’t always 0V! This is the conventional meaning of black wires throughout the electrical engineering world.
  • Red is 6V. Red is always the positive supply voltage (6V from the battery pack in this case). This is the conventional meaning of red wires throughout the electrical engineering world.
  • Orange is 3.3V. This is just my own personal convention. It’s similar to red which reminds me that it’s a positive supply voltage, but also different enough from red that I don’t get them mixed up which could result in damage to the MSP430.

Remember, neat wiring with consistent colour-coding is the secret to fast fault finding in your circuit. It’s probably the single most important element to successful breadboard prototyping of circuits.

20161005_145740

20161005_145744

20161005_145754

20161005_154735

20161005_154741

20161005_154754

20161005_154802

20161005_154818

20161005_154838

20161005_154912

//
// Motor Control example for MSP430G2553
// Written by Ted Burke - Last modified 5-10-2016
//
  
#include <msp430.h>
  
void main()
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
      
    P1DIR = 0b00000000; // All port 1 pins are unused (set as inputs)
    P2DIR = 0b00011001; // P2.0 is LED, P2.3 and P2.4 are motor
    
    // Main loop repeats forever
    while(1)
    {
        // Decide what to do with motor and LED based on
        // the voltage on pin P2.5 (the switch input)
        if (P2IN & BIT5)
        {
            // If the boolean condition is true do this
            P2OUT = 0b00010001; // LED on, motor forward
        }
        else
        {
            // If the boolean condition is false do this
            P2OUT = 0b00001000; // LED on, motor reverse
        }
    }
}
Posted in Uncategorized | Leave a comment

LED Flash Challenge – Semester 1, 2016/2017

We’re beginning the RoboSumo project with a little competitive puzzle called the LED Flash Challenge. We’re not attaching a formal assessment weighting to this challenge, but we’ll be keeping a close eye on which teams finish in what order.

It’s a race.

In today’s lab (and for many of you part of the next lab) you’ll be working with your team to complete two tasks:

  1. Build a simple breadboard circuit for the MSP430 microcontroller and program it to blink an LED on and off.
  2. Add a second LED to the circuit and reprogram the MSP430 to transmit a specific binary sequence as a series of flashes from the two LEDs.

The first task is very prescriptive, which means that we’ll basically tell you exactly what to do, but to complete the second task you’ll need to think for yourselves.

You’ll need a team number to complete this challenge. Your tutor will assign your team a unique number within the range shown below:

  • Teams 1-6: Group C1 with David Dorran in room KEG-012
  • Teams 7-12: Group C2 with [Someone TBA] in room KE4-024
  • Teams 13-24: Groups D1 & D2 with Ted Burke & Shannon Chance in room KEG-036
  • Teams 25-30: Group E1 with John McGrory in room KEG-004
  • Teams 31-36: Group E2 with Damon Berry in room KEG-014

Part 1: Blinking LED

This task is relatively straightforward and shouldn’t take you too long to get working. You’ll find complete instructions here:

Instructions for Blinking LED example

Once your LED is blinking, there are four things you need to understand before moving on:

  1. How one of the pins (P1.0) was turned into a digital output.
  2. How the LED is turned on
  3. How the LED is turned off
  4. How to delay the program for a specified number of microseconds, so that the rate of the LED blinking can be controlled

Once you understand these four things, you have finished this part of the task (the easy part) and it’s time to move on to the LED Flash Challenge.

Part 2: LED Flash Challenge

In this part, you’re going to modify your circuit to create a simple optical transmitter, which transmits a digital message (a sequence of 1s and 0s) as a series of LED flashes. I’ll demonstrate this to you in the lecture.

The message that you’ll transmit will be 2 bytes long (a byte is 8 bits, or 8 ones and zeros) and it will contain your team number (byte 1) followed by a second number calculated by subtracting your team number from 255 (byte 2).

For example, if your team number is 101…

  • byte1 = 101
  • byte2 = 255 – 101 = 154
  • byte1 + byte2 = 255
You and your teammates should take a few
minutes to read about binary numbers and
digital i/o on the MSP430 here.

Specifically, you need to do the following:

  1. Modify the code to create a second digital output pin.
  2. Extend the circuit by adding a second LED (with current limiting resistor) to that digital output pin.
  3. Convert your team number into 8-bit binary. This is byte 1 of your message.
  4. Calculate the required value of byte 2 (so that byte1+byte2 = 255).
  5. Each byte will be transmitted as a sequence of ones and zeros, preceded by a start bit (1) and followed by a stop bit (0). That means your complete transmission will be 20 bits long. You need to calculate this sequence on paper first.
  6. To transmit a 1, turn LED1 off and LED2 on for 500ms.
  7. To transmit a 0, turn LED2 off and LED1 on for 500ms.
  8. To ensure the sequence is read correctly, transmit a long sequence of zeros (for about 5 seconds) before you transmit your message.

Let’s consider that example team number 101 again. As explained above, byte 1 is 101 and byte 2 is 154.

  • Before transmitting the sequence, send a “0” for about 5 seconds.
  • The first bit of the sequence is the start bit for byte 1 which is “1”.
  • Written as a binary number, 101 (one hundred and one) is 0b01100101. The “0b” prefix indicates that it is a binary number and is not part of the number value. The byte is transmitted least significant bit first, i.e. in the following order: “1,0,1,0,0,1,1,0”.
  • The next bit is the stop bit for byte 1, which is “0”.
  • The next bit is the start bit for byte 2, which is “1”.
  • Written as a binary number, 154 is 0b10011010, so the next 8 bits are “0,1,0,1,1,0,0,1”.
  • The final bit is the stop bit for byte 2, which is “0”.
  • To summarise, the complete 20-bit sequence for team 101 would be as follows (data bits for each byte are highlighted in bold):

    “1,1,0,1,0,0,1,1,0,0,1,0,1,0,1,1,0,0,1,0″

    The validator for checking your transmission is a web application which I have posted at the following location:

    I will set up an official validation station in KEG-036 where you can record your result once your circuit is working. Other tutors may set up validation stations in the other rooms, but that will depend on available cameras and light levels.

    You are welcome to try the validator on your own laptop / PC. In principle, it should work on any modern PC with a webcam and up-to-date browser. However, since video capture is relatively new in HTML, I recommend using the current release of Google Chrome which is what I tested it in.

    Your tutor will be able to clarify anything you don’t understand about this.

Posted in Uncategorized | Leave a comment

RoboSumo Tournament Live Ranking Spreadsheet

Live Ranking Tables

Posted in Uncategorized | 1 Comment

RoboSumo Tournament semester 2 2015-2016 – 2pm Wed 4/5/2016

This semester’s RoboSumo
tournament will take place
at 2pm on Wed 4th May 2016
in the Gleeson Hall, DIT Kevin St

Please review the following information carefully from start to finish. In addition to reading it yourself, if possible you should arrange to sit down with your team mates to go through it together. We are aware that many teams are putting in an awful lot of hard work in the lead up to the competition, so we’re anxious that teams shouldn’t get any nasty surprises on the big day!

Tournament time and location

The tournament will take place at 2pm on Wednesday 4th May 2016 in the Gleeson Hall, just inside the main entrance to DIT Kevin St. Two competition arenas (sumo tables) will operate in parallel in the same room.

The exact duration will depend on how things progress on the day, but we aim finish by 5pm. To ensure that the tournament proceeds efficiently, teams must comply with the instructions of the referee(s) without dispute at all times. From 2pm onwards, teams should be present and ready to compete immediately when summoned to one of the arenas. If a team is not ready when they are called to compete in a bout, their opponent will be granted a walkover in that bout.

DIT tournament rules

The RoboSumo tournament rules are those of the Robot Challenge “Mini” class, mostly as described in the Robot Challenge rules PDF document. However, those rules make provision for tournament organisers to introduce local rule changes as appropriate.

The following rule variations are followed in the DIT RoboSumo tournament:

  1. No infrared starting devices are used. Instead, teams position and start their robots manually at the beginning of each bout, as instructed by the referee. Following manual starting, each robot must remain still for at least 2 seconds. (In most cases, this will simply require the inclusion of a 2-second delay in the robot’s microcontroller program.) Robots which do not observe the 2 second delay at the start may still be allowed to compete at the discretion of the referee, but may be penalised by being placed in a disadvantageous starting position.
  2. The duration of each bout is limited to 60 seconds. At the discretion of the referee(s), the bout duration may be reduced further to speed the progress of the tournament.
  3. If both robots remain in the arena at the conclusion of a bout, the referee will decide the winner based on each robot’s distance from the centre of the table (the closer the better), robot activity/behaviour during the bout, attitude/behaviour of each team during the bout, and/or other criteria at his/her own discretion. The referee may explain the criteria upon which the winner of a bout was chosen, but is not required to do so.
  4. When a bout fails to produce a clear winner, the referee may, at his/her own discretion, order the bout to be replayed.
  5. During most phases of the competition, matches will consist of a single bout. However, in the latter (knockout) stages of the competition the number of bouts in each match may be increased (e.g. best of 3 or best of 5).
  6. The dimensions of each arena will be similar to those described in the Robot Challenge rules (77cm diameter with a 2.5cm white border), but may deviate slightly from them. However, the white border will not be less than 2.5cm in width.
  7. A robot which displays no responsiveness to its opponent or its surroundings for a significant period of time may, at the referee’s discretion, be disqualified from a bout. In particular, please note that robots which simply spin on the spot will be viewed very unfavourably by the referees unless they exhibit other behaviour which provides evidence that the spinning forms part of a meaningful control strategy.
  8. Each team’s robot spending limit is €70. This figure must include the cost of all components included in the final robot, as it is presented for the tournament validation process, with the following specific exceptions. The €70 budget does not include the cost of components or materials purchased but not used in the final robot. It does not include any cost incurred for postage and packing. Most recycled materials which are obtained free of charge do not need to be accounted for in the robot budget, but specialised components which would not be available to other teams through normal scavenging (e.g. remote control servos) may need to be represented by an indicative cost. The referees do not in general systematically verify the cost of every robot, but where a specific dispute arises or it is suspected that a robot may be in breach of this rule, a team may be asked to provide evidence of their total spending (e.g. by providing receipts or showing where each component used can be purchased for the claimed price). Where a team is suspected to be in breach of this rule and cannot prove otherwise, the referees may apply a penalty of some kind or even disqualify a robot from the tournament.

Important note: Every effort has been made to compose the rules of each bout and the structure of the tournament as a whole in a way that is fair and consistent, but since it is impossible to anticipate every eventuality, the referee(s) must have ultimate discretion to overrule any regulation or introduce a rule change at any time.

Tournament structure

The tournament is divided into two main phases – a sorting phase and a knockout phase. Each team must also complete a validation process prior to competing in their first match.

Validation process

The validation process ensures that each robot complies with the restrictions on size and mass imposed by the Mini class rules. Teams who do not successfully complete the validation process are not eligible to compete in the RoboSumo tournament. Teams who are unable to field a compliant robot may still be asked to compete in one or more exhibition bouts for assessment purposes, but they cannot progress in the tournament.

  • The mass of the robot, including batteries and all parts which will be attached to the robot during a bout, must not exceed 500 grams.
  • The footprint of the robot must not exceed 10cm by 10cm. Specifically, the entire robot and all parts attached to it, must fit within a cuboid (with vertical sides) of 10cm width and 10cm depth. Height is not specifically restricted. Note that robots are permitted to expand beyond their 10cm by 10cm footprint after the start of a bout, as described in the Robot Challenge rules.
  • All ground contact points that bear the weight of the main body of the robot must fit within the 10cm x 10cm footprint throughout the entire bout. It is permissible for parts of the robot to touch the ground outside the 10cm x 10cm footprint once the bout is underway, but the weight of the main body of the robot must not rest on them.

Following validation, if a team makes any change to their robot which increases its size or mass, they must repeat the validation process prior to competing in a match.

Sorting phase

The referees will divide the competing teams into two pools. The initial ranking in each group will be determined primarily by the results of the Race to the Wall challenge. The objective of the sorting phase is to select the top 8 teams from each group. A variation on the so-called bubble sort will be followed for the majority of the sorting phase. However, the referee in charge of each arena may deviate from this pattern at his/her own discretion to resolve any unforeseen ranking issues or anomalies.

In each group, the sorting phase will conclude when the referee is satisfied that he/she has identified which 8 teams should progress to the knockout phase of the tournament.

Knockout phase

The 8 top-ranked teams from each group (A1, A2, A3…A8 and B1, B2, B3…B8) will proceed to the knockout phase of the tournament. When a team loses a match in this phase, they are eliminated from the tournament. The referees will decide the number of bouts per match in each stage of the knockout phase.

The matches in this phase of the tournament are as follows:

  • 8 Last-16 Matches: A1 v B8, A2 v B7, A3 v B6, A4 v B5, A5 v B4, A6 v B3, A7 v B2, A8 v B1
  • 4 Quarter Finals: A1/B8 v A5/B4, A2/B7 v A6/B3, A3/B6 v A7/B2, A4/B5 v A8/B1
  • 2 Semi Finals: A1/B8/A5/B4 v A3/B6/A7/B2, A2/B7/A6/B3 v A4/B5/A8/B1
  • 1 Final: A1/B8/A5/B4/A3/B6/A7/B2 v A2/B7/A6/B3/A4/B5/A8/B1

Laboratory access on Wednesday

  • Laboratory access will be provided prior to the normal scheduled RoboSumo class time on Wednesday, subject to the limitations of the timetable for each ground floor laboratory. One or more of the RoboSumo tutors may also be available during the morning, but bear in mind that they are likely to be in high demand, so if you know in advance that you will have major difficulties getting your robot working it may be wise to contact your group’s tutor earlier rather than later.
  • There will be no RoboSumo lecture from 2-3pm on the day of the tournament. Instead, teams will proceed directly to the Gleeson Hall at 2pm.
  • The normal lab facilities will remain open from 3pm onwards, to facilitate teams who wish to carry out repairs or adjustments to their robots. However, bear in mind that if the referee summons you to a match and you are not present, your opponent will be granted a walkover victory.

Competitor check list

Inevitably, many teams will face technical issues on the day of the tournament, and it’s impossible to foresee every problem. However, there are certain issues which we see every year:

  1. PLEASE PLEASE PLEASE ensure that your robot is compliant with the size and mass restrictions. Yes, 101mm is too much! And yes, 501 grams is too much! To avoid problems on the day, please leave some margin for error. We need to be absolutely strict about these limits and butchering your carefully crafted robot at the last minute to reduce its size or weight can be a heartbreaking experience.
  2. If you haven’t already tested your robot actually driving around, please do so BEFORE the tournament. Bizarrely, every year we see teams who leave it until the very last minute to attach the wheels to their motors for the first time. Unfortunately, many of them discover at that point that their gearing is totally inappropriate and the robot cannot actually move.
  3. Focus on the basics. This means moving around and responding to the white border of the arena so that you don’t accidentally drive out of it. Even if you don’t get the rangefinder working properly, with luck you can win a few bouts just by staying mobile and staying on the table.
  4. Speaking of which… don’t be too reliant on the rangefinder. It’s far from a perfect sensor and can sometimes completely fail to detect an opponent, depending on its shape and material. Design your code so that the robot will still do something intelligent if the rangefinder fails to detect the opponent.
  5. Make sure your robot doesn’t simply spin around the spot for the entire bout. This behaviour will be viewed very unfavourably by the referee.
  6. Make sure you bring plenty of spare batteries.

Finally, remember to get plenty of photos and videos of your robot (and team) in the run up to and during the tournament. Of all the evidence you will provide on your blog, photos and videos are some of the easiest to create, and they can really help to tell the story of your project.

Finally, best of luck to all of you!

Posted in Uncategorized | Leave a comment