RoboSumo Tournament semester 2 2016-2017 – 2pm Wed 26/4/2017

This semester’s RoboSumo tournament
takes place at 2pm tomorrow,
Wednesday 26th April 2017
in room KEG-036, DIT Kevin St

Click here for Live Tournament ranking (Note: All rankings are provisional and subject to change)

Please review the following information carefully from start to finish.

Tournament time and location

The tournament will commence at 2pm on Wednesday 26th April 2017 in room KEG-036, which is located in one of the smaller side corridors on the ground floor of the main building in DIT Kevin St. During the initial “sorting” phase of the tournament, two competition arenas (sumo tables) will operate in parallel in the same room.

The exact duration of the tournament will depend on how quickly things progress, but we aim to be completely finished by 5pm. To ensure that the tournament proceeds efficiently, teams must comply with the instructions of the referee(s) without dispute at all times.

Robot Weigh-in – 1:30pm in KEG-036

Before your robot can compete in any sumo bouts, it must weigh-in to ensure compliance with the competition rules.

  • The weight limit is 500 grams, as measured using the electronic scales in room KEG-036. This includes every part of the competing robot, including batteries.
  • The size limit is 10cm x 10cm when viewed from above (no part of the robot is allowed to be outside this boundary).

Teams should present their robots for the weigh-in at 1:30pm in room KEG-036. Paul Leamy is managing the weigh-in and will run through a checklist with each team. He will also provide Q6a feedback forms for you to complete and return with your robot after the tournament.

Sumo Bouts – 2:00pm in KEG-036

From 2:00pm onwards, teams must be continuously present in room KEG-036 and ready to compete immediately whenever 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. However, that team remains eligible to compete in subsequent bouts (until they are eliminated from the tournament).

Submitting Your Robot for Formal Assessment – KEG-036

Once your team is eliminated from the competition (or has won!), you must submit your robot for assessment. This is critically important for your final grade. Paul Leamy (or another tutor) will be managing the submission of robots and will run through the following checklist with each team:

  1. Have you submitted your robot? A clear label showing the robot’s name should be securely attached. Suitable labels will be available in KEG-036.
  2. Have you provided a completed robot information sheet? This sheet includes: team/robot name, team number, tutor name, name of every team member, blog address of every team member. Blank paper copies of the robot information sheet will be available in KEG-036.
  3. Have you returned your Launchpad?
  4. Have you returned a completed Q6a feedback form for each team member? Blank paper copies of the Q6a form will be provided at weigh-in.

Please do not leave without submitting your robot. Doing so may have a catastrophic effect on your grade.

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 apply 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 should 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. (Note: In the past, we have sometimes reduced the bout duration to 30 seconds to speed things up.)
  3. If both robots remain in the arena when the time limit for the bout expires, 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 (the “weigh-in”), 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 until 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 Tuesday/Wednesday

  • A RoboSumo clinic will take place in room KEG-036 between 5-7pm on Tuesday 25-4-2017. This is to facilitate teams who are having difficulty troubleshooting problems with their robot. Attendance is entirely optional.
  • Access to laboratories other than KEG-036 before 3pm on the day of the tournament will be subject to the limitations of the timetable for each laboratory (other classes may be timetabled in some rooms before 3pm).
  • There will be no RoboSumo lecture from 2-3pm on the day of the tournament. Instead, teams will proceed directly to KEG-036 at 2pm for the tournament weigh-in.
  • The normal lab facilities will be available 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.
  • Room KEG-036 will be available from approximately 1pm onwards. However, space may be limited due to reorganisation of tables for the tournament.

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 weight limits. Yes, 101mm is too much! And yes, 501 grams is too much! To avoid unexpected problems, 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 have a working rangefinder you expect to win some bouts just by staying mobile and staying on the table.
  4. Speaking of which… don’t be too reliant on your rangefinder / proximity sensor (if you’re using one). These sensors 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 it doesn’t 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

Timer A interrupt examples from today’s lecture

Example 1: Use a Timer A0 interrupt to flash some LEDs on and off

In this example, we configure Timer A0 to increment every 8 microseconds and generates an interrupt whenever it reaches 12500, which occurs every 100ms. The resulting interrupt service routine (ISR) either switches on or switches off all three LEDs (red LED on P2.0, white LED on P2.1, green LED on P2.2).

//
// Timer A interrupt example for MSP430G2452
// Written by Ted Burke - last updated 5-4-2017
//
 
#include <msp430.h>

// Timer A0 interrupt service routine (ISR)
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A(void)
{
    // Toggle LEDs
    if (P2OUT == 0) P2OUT = 0b00000111;
    else            P2OUT = 0b00000000;
}

// Main function
void main()
{
    // Disable watchdog timer
    WDTCTL = WDTPW + WDTHOLD;
    
    // Configure inputs and outputs 
    P1DIR = 0b00000000; // P1.0-7 are all inputs
    P2DIR = 0b00000111; // LEDs: P2.2=green, P2.1=white, P2.0=red
    
    // Configure TimerA0 and its interrupt
    TA0CTL = TASSEL_2 + MC_1 + ID_3; // "Up" mode, divide SMCLK by 8
    TA0CCR0 =  12500;                // Set timer period to 100ms
    TA0CCTL0 = CCIE;                 // Compare interrupt enabled    
    _BIS_SR(GIE);                    // Global interrupt enable
    
    while(1)
    {
        // Nothing required here because the ISR does all the work
    }
}

Example 2: Use a Timer A0 interrupt to add a millisecond counter to a state machine

In this example, we configure Timer A0 to increment every 8 microseconds and generate an interrupt whenever it reaches 125, which occurs every 1ms. The resulting interrupt service routine (ISR) increments the variable “milliseconds” which is used to count the number of milliseconds that have elapsed since the program entered the current state. Each state lights a different LED (state 1: red LED on P2.0; state 2: white LED on P2.1; state 3: green LED on P2.2).

//
// Millisecond timer example for MSP430G2452
// Written by Ted Burke - last updated 5-4-2017
//
 
#include <msp430.h>

// Declare variables to stores the current state number
// and counts the number of milliseconds that have
// elapsed in current state.
int state = 1;
int milliseconds = 0;

// This function is used to change states.
// The input value s is the state to switch to.
// The function updates the state variable and resets
// the millisecond counter variable.
void change_state(int s)
{
    state = s;
    milliseconds = 0;
}

// This is the Timer A0 interrupt service routine.
// Once the timer is configured, this function will
// be called every 100ms.
#pragma vector=TIMER0_A0_VECTOR
__interrupt void Timer_A(void)
{
    milliseconds = milliseconds + 1;
}

// This is the main function
void main()
{
    // Disable watchdog timer
    WDTCTL = WDTPW + WDTHOLD;
    
    // Configure inputs and outputs 
    P1DIR = 0b00000000; // P1.0-7 are all inputs
    P2DIR = 0b00000111; // LEDs: P2.2=green, P2.1=white, P2.0=red
    
    // Configure TimerA0 and its interrupt
    TA0CTL = TASSEL_2 + MC_1 + ID_3; // "up" mode, divide SMCLK by 8
    TA0CCR0 =  125;                  // set timer period to 1ms
    TA0CCTL0 = CCIE;                 // compare interrupt enabled    
    _BIS_SR(GIE);                    // global interrupt enable
    
    // State loop
    while(1)
    {
        if (state == 1)
        {
            P2OUT = 0b00000001; // Red
            
            if (milliseconds > 1000) change_state(2);
        }
        else if (state == 2)
        {
            P2OUT = 0b00000010; // White

            if (milliseconds > 2000) change_state(3);
        }
        else if (state == 3)
        {
            P2OUT = 0b00000100; // Green

            if (milliseconds > 3000) change_state(1);
        }
    }
}
Posted in Uncategorized | Leave a comment

State machine example from today’s lecture

In today’s lecture, we worked through a state machine example designed to navigate a RoboSumo bot to the centre of the arena. Please note that the term state machine refers to an algorithm rather than to a physical machine. Obviously, in this case the algorithm controls a physical machine (the robot), but a state machine approach can be used in many applications where there is no physical machine at all.

The circuit diagram for this example is basically the same as the one from last week’s lecture except that I’ve added an additional colour sensor, so that there’s one on each of the front corners of the robot.

First we drew up a state table to describe the behaviour of the robot in unambiguous terms. What defines each “state” the specific activity of each actuator (i.e. what each motor is doing) and a number of conditions which can trigger a transition from that state to another one.

State Description Motors Transitions
1 Initial pause LM stop, RM stop 2 seconds elapsed: goto 2
2 Forward to white LM forward, RM forward FL white: goto 3
FR white: goto 4
3 Straighten right LM stop, RM forward FR white: goto 5
4 Straighten left LM forward, RM stop FL white: goto 5
5 Reverse to centre LM back, RM back 2.3 seconds elapsed: goto 6
6 Spin LM back, RM forward 5 seconds elapsed: goto 2

Notes:

  • LM is left motor, RM is right motor
  • FL is front left colour sensor, FR is front right colour sensor
  • The 2.3 second delay in state 5 is the estimated time taken for my fictional robot to reverse from the table edge into the centre. For a real robot, this value should be determined experimentally.

This is the complete C code for the state machine example from today’s lecture:

//
// Sumo example for MSP430G2553 / MSP430G2452
// Written by Ted Burke - Last modified 29-3-2017
//
// P1.1 = LF colour sensor - low on black, high on white
// P1.2 = RF colour sensor - low on black, high on white
// P2.0 = LED
// P2.1 = LM forward
// P2.2 = LM reverse
// P2.3 = RM forward
// P2.4 = RM reverse
//
 
#include <msp430.h>
   
void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
       
    P1DIR = 0b00000000; // P1.1 is colour sensor
    P2DIR = 0b00011111; // P2.0 is LED, P2.1-4 are motors
     
    // State machine
    int state = 1;
    int FLS, FRS; // front left and right colour sensors
    
    while(1)
    {
        // Read front left colour sensor
        if (P1IN & BIT1) FLS = 1;
        else FLS = 0;
        
        // Read front right colour sensor
        if (P1IN & BIT2) FRS = 1;
        else FRS = 0;
        
        // Implement current state
        if (state == 1)
        {
            P2OUT = 0b00000000; // LM stop, RM stop
            
            __delay_cycles(2000000);
            state = 2; // move to state 2 after 2 seconds
        }
        else if (state == 2)
        {
            P2OUT = 0b00001010; // LM forward, RM forward
            
            if (FLS == 1) state = 3;
            if (FRS == 1) state = 4;
        }
        else if (state == 3)
        {
            P2OUT = 0b00001000; // LM stop, RM forward
            
            if (FRS == 1) state = 5;
        }
        else if (state == 4)
        {
            P2OUT = 0b00000010; // LM forward, RM stop
            
            if (FLS == 1) state = 5;
        }
        else if (state == 5)
        {
            P2OUT = 0b00010100; // LM back, RM back
            
            __delay_cycles(2300000);
            state = 6;
        }
        else if (state == 6)
        {
            P2OUT = 0b00001100; // LM back, RM forward
            
            __delay_cycles(5000000);
            state = 2;
        }
    }
}

The End

Posted in Uncategorized | Leave a comment

Code and circuit from today’s lecture

//
// Stay on Table example for MSP430G2553 / MSP430G2452
// Written by Ted Burke - Last modified 22-3-2017
//
// P1.1 = Colour sensor input - low on black, high on white
// P2.0 = LED
// P2.1 = LM forward
// P2.2 = LM reverse
// P2.3 = RM forward
// P2.4 = RM reverse
//

#include <msp430.h>
  
void main( void )
{
    WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
      
    P1DIR = 0b00000000; // P1.1 is colour sensor
    P2DIR = 0b00011111; // P2.0 is LED, P2.1-4 are motors
    
    // Main loop repeats forever
    while(1)
    {
        if (P1IN & BIT1)
        {
            // white detected
            P2OUT = 0b00010010;
        }
        else
        {
            // black detected
            P2OUT = 0b00001011;
        }
    }
}
Posted in Uncategorized | Leave a comment

Final opportunity to record a Week 6 Race to the Wall time: 13:20-14:00 Friday 3-3-2017

By popular demand, we are providing one final opportunity to record a Week 6 Race to the Wall time tomorrow (Friday, 3-3-2017) between 13:20 and 14:00 in room KEG-036. This is for teams who were close to completing the Race to the Wall on Wednesday and have since ironed out any remaining problems. It is not a workshop session; no materials or equipment will be provided and there will be no technical support! Teams that don’t have a fully working robot should just wait until next week to record a time. We’ll have a whole lab session on Wednesday to get those robots working.

According to the timetable, DT066A groups who are doing RoboSumo this semester have classes scheduled in Bolton St up until 13:00, so there should be adequate time to travel across to Kevin St after class if you wish to avail of this opportunity.

Please note that this is just an opportunity to record a time – there will be no technical support! I’ll basically just be typing results into the spreadsheet for teams who now have a fully functioning robot.

Ted

Posted in Uncategorized | Leave a comment

Race to the Wall, March 2017 – Rules and Information

This semester’s Race to the Wall event will commence at 3pm (or shortly thereafter) on Wednesday 1st March 2017. The event will end on the same day at a time chosen by the RoboSumo tutors, not earlier than 6pm.

Teams who do not complete the Race to the Wall task on Wednesday 1st March 2017 (week 6) will have a second opportunity to complete the task on Wednesday 8th March 2017 (week 7). However, any teams that complete the challenge for the first time in week 7 will be ranked below all teams that complete the challenge in week 6.

The final ranking will be determined as follows:

  1. The highest ranked teams will be those that complete the Race to the Wall task in week 6 and are fully compliant with the weight and size restrictions (see below). These teams will be ranked in ascending order of recorded time, each team’s recorded time being their best time achieved in week 6.
  2. The next ranked set of teams will be those that complete the task in week 6 but are not fully compliant with the size and weight restrictions. These teams will be ranked in ascending order of recorded time, each team’s recorded time being their best time achieved in week 6. Please note, however, that permission to attempt the task with a non-compliant robot will be granted at the discretion of the RoboSumo tutors only. Robots which grossly exceed the limits will be disqualified.
  3. The next ranked set of teams will be those that complete the task in week 7 and are fully compliant with the weight and size restrictions. These teams will be ranked in order of speed.
  4. The next ranked set of teams will be those that complete the task in week 7 and are not fully compliant with the weight and size restrictions. These teams will be ranked in order of speed.
  5. The final ranked set of teams will be those that do not complete the task in either week, but are still be deemed by the tutors to merit ranking on the basis of technical attainment.

Before stating the rules formally, here’s a quick introduction:

(Editable SVG versions of gallery images: 0, 1, 2, 3, 4, 5, 6)

Rules

The Competition

The competition requires each robot to compete in a time-trial race. Robots perform the time trial one at a time and are ranked on a leaderboard. The objective is to complete the race as quickly as possible.

The results of the race will be used to determine your robot’s starting position on the RoboSumo Leaderboard for the final RoboSumo competition. The format of this semester’s RoboSumo tournament is still to be finalised, but in previous DIT RoboSumo tournaments starting higher on the leaderboard was a significant advantage.

In the event of a tie between two or more robots in the Race to the Wall, the position on the leaderboard will be determined by an assessment of the quality of the robot construction.

The Race

The robot begins in a starting position before the start/finish line (see Figure 1). A team member pressed a start button or otherwise switches on the robot’s power, then withdraws. Team members may not physically propel the robot. Once the robot is activated, team members may not intervene or interfere with it in any way for the full duration of the task.

The robot must do the following:

  • Move forward autonomously from the starting position,
  • Break the start/finish laser beam once and only once (the first of two times during the race),
  • Continue moving forward until it touches a block,
  • Move back towards the start/finish line,
  • Stop on the start/finish line within the 20 second time limit, breaking the start/finish laser beam for the second and final time. The beam must remain continuously broken for a minimum of 2 seconds.

When the robot returns to and stops on the start/finish line, if the beam becomes unbroken within 2 seconds the robot is disqualified and the time is not recorded on the leaderboard. Disqualification for this reason does not prevent a robot from attempting the task again.

If the robot successfully completes the task, the time recorded will be the time between the first and second breaking of the beam. Each team can attempt the task an unlimited number of times during the event. However, if others are waiting to attempt the task, a team must return to the back of the queue following each attempt. At the discretion of the tutors, teams who have not yet recorded a time may be given priority over teams who have already recorded a time but wish to improve upon it.

The Robot

The robot must satisfy the criteria for the mini-sumo class in the Robot Challenge robot sumo rules, with the following additional requirements:

  • At every moment during the race, there must exist a cuboid 10cm in horizontal length, 10cm in horizontal width and of unlimited height which encloses every part of the robot. In other words, the dimensions of a robot cannot expand outside its 10cm x 10cm footprint at any time during a race.
  • The sides of the robot must be covered with an opaque material so that the robot reliably breaks the start/finish laser beam once and only once as it passes through it.

The key features are:

  • The robot must be fully autonomous.
  • The footprint of the robot (its shape / area when viewed from above) must fit within a 10cm by 10cm square.
  • The robot’s mass must not exceed 0.5kg.

race_to_wall

Figure 1: The Race to the Wall track. (Click here to download editable SVG version of image)

The Track

The race will take place on a flat horizontal light-coloured surface (probably one or more tables) in room KEG-036. One end of the track is marked with a dark line of tape (the start/finish line). A block stands at the other end of the track. The track is between 1m and 2m in length (from the start/finish line to the block). The start/finish line is parallel to the vertical face of the block.

The Start/Finish Laser Beam

The laser beam is used to start and stop the timer for the race, and is used to accurately measure each robot’s race time. The laser will be in a fixed position at a height of 5cm and will be aimed horizontally across the track, above (and parallel to) the start/finish line.

The Block

The block is a solid object at least 20cm high and 50cm wide. It will be positioned such that its face is perpendicular to the table surface and parallel to the shorter edge of the table, as shown in Figure 1. The position of the block will be otherwise unspecified but will be the same for each competing robot.

Posted in Uncategorized | Leave a comment

Race to the Wall Ideas – images from lecture on 23-2-2017

This gallery contains 15 photos.

Gallery | Leave a comment