RoboSumo Tournament semester 1 2017-2018 – 2pm Wed 29/11/2017

This semester’s RoboSumo tournament
takes place at 2pm tomorrow,
Wednesday 29th November 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 29th November 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. Weigh-in and robot validation will take place from 2-3pm. The first bouts will commence at 3pm. During the initial “sorting” phase of the tournament, two competition arenas (sumo tables) will operate in parallel in room KEG-036.

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 – 2:00pm in KEG-036

Before your robot can compete in any sumo bouts, it must weigh-in and be measured 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). The size limit will be strictly applied.

Teams should present their robots for the weigh-in at 2:00pm in room KEG-036. One of the tutors will act as compliance officer, managing the weigh-in. He/she will run through a checklist with each team. He/she will also provide Q6a feedback forms for you to complete and return with your robot after the tournament.

Sumo Bouts – 3:00pm in KEG-036

From 3:00pm onwards, teams should 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. The compliance officer (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. Optional: have you attached a 1-page feature guide to your robot? This sheet can be used to highlighting interesting design features that might not be immediately obvious to the assessment panel during the design assessment. There is no special format for this page – if you’re including one, just make it clear, fold it up, and attach it securely to your robot.
  3. 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.
  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 Arduino 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), depending on the time available.
  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. In general, the referees do not 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 pool. A variation on the so-called bubble sort will be used 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 during the tournament

  • 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.
  • 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).
  • Room KEG-036 will be open from 2pm onwards. However, space may be limited due to re-organisation of tables for the tournament.
  • 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.

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 can still 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!

Advertisements
Posted in Uncategorized | 1 Comment

RoboSumo Troubleshooting Clinic: 3:30pm – 5:00pm, Friday 24th Nov

To facilitate teams who are having problems with their final preparations for next week’s RoboSumo tournament, I (Ted) will be holding a “troubleshooting clinic” from 3:30pm to 5:00pm tomorrow (Friday 24th Nov) in room KEG-036. That’s the same room that Shannon, Catherine and I normally have our RoboSumo lab, down one of the small side corridors off the main ground floor corridor of the main building in Kevin St.

One or both of the practice RoboSumo arenas will be available in the room for testing. I will be there to assist teams who are having major problems getting their robot working, but depending on the level of demand I may or may not have time to help every team that attends.

Another class is scheduled in KEG-036 until 3:30pm, so please do not go into the room until that class is finished.

Posted in Uncategorized | Leave a comment

Day 11 Tutorial

Info on the bubble ranking system and also the assessment scheme for RoboSlam:

Instructions about what you need to do and submit on tournament day, just after the competition:

Posted in Uncategorized | Leave a comment

Day 10 Tutorial

Hand dryer coding example to help you program your robot. Similar rationale needed….

Info on the RoboSlam arena and set up:

Today’s main lecture on code for a hand dryer:

Posted in Uncategorized | Leave a comment

State Machine, version 2

This was the second example from today’s class. In this structure, each state is given its own while loop with the Arduino loop function. Once the flow of control enters one of these loops, it continues within that loop until the state changes.

Note that each state’s loop must include statements to update the relevant sensor variables.

//
// State machine example 2: loops inside loop
//

int state = 1;
unsigned long start_time;

void setup()
{
  // Green LEDs on D2, D3, D4
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  
  // Red LEDs on D5, D6, D7
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);

  // White LED on D8
  pinMode(8, OUTPUT);
}

void loop()
{
  int colour;

  while (state == 1) // WAITING
  {
    // Read sensors
    colour = analogRead(0);
  
    // Actuators
    green(0);
    red(1);
    white(0);

    // Change state?
    if (colour > 200) gotoState(2);
  }
  
  while (state == 2) // FAN ON
  {
    // Read sensors
    colour = analogRead(0);
  
    // Actuators
    green(1);
    red(0);
    white(1);

    // Change state?
    if (colour < 200) gotoState(3);
  }
  
  while (state == 3) // FAN ON WITH TIMEOUT
  {
    // Read sensors
    colour = analogRead(0);
  
    // Actuators
    green(1);
    red(1);
    white(1);

    // Change state?
    if (colour > 200) gotoState(2);
    if (millis() - start_time > 2000) gotoState(1);
  }
}

void gotoState(int new_state)
{
  state = new_state;
  start_time = millis();
}

void green(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(2, LOW);
    digitalWrite(3, LOW);
    digitalWrite(4, LOW);
  }
  else
  {
    digitalWrite(2, HIGH);
    digitalWrite(3, HIGH);
    digitalWrite(4, HIGH);
  }
}

void red(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(5, LOW);
    digitalWrite(6, LOW);
    digitalWrite(7, LOW);
  }
  else
  {
    digitalWrite(5, HIGH);
    digitalWrite(6, HIGH);
    digitalWrite(7, HIGH);
  }
}

void white(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(8, LOW);
  }
  else
  {
    digitalWrite(8, HIGH);
  }
}
Posted in Uncategorized | Leave a comment

State Machine, version 1

This was the first version of the state machine example we looked at in today’s lecture. This structure uses an extended if-else-if statement in the loop function to select the code for the current state each time the function repeats.

//
// State machine example 1: if-else-if inside loop
//

int state = 1;
unsigned long start_time;

void setup()
{
  // Green LEDs on D2, D3, D4
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  
  // Red LEDs on D5, D6, D7
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);

  // White LED on D8
  pinMode(8, OUTPUT);
}

void loop()
{
  int colour;
  colour = analogRead(0);
  
  if (state == 1) // WAITING
  {
    // Actuators
    green(0);
    red(1);
    white(0);

    // Change state?
    if (colour > 200) gotoState(2);
  }
  else if (state == 2) // FAN ON
  {
    // Actuators
    green(1);
    red(0);
    white(1);

    // Change state?
    if (colour < 200) gotoState(3);
  }
  else if (state == 3) // FAN ON WITH TIMEOUT
  {
    // Actuators
    green(1);
    red(1);
    white(1);

    // Change state?
    if (colour > 200) gotoState(2);
    if (millis() - start_time > 2000) gotoState(1);
  }
}

void gotoState(int new_state)
{
  state = new_state;
  start_time = millis();
}

void green(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(2, LOW);
    digitalWrite(3, LOW);
    digitalWrite(4, LOW);
  }
  else
  {
    digitalWrite(2, HIGH);
    digitalWrite(3, HIGH);
    digitalWrite(4, HIGH);
  }
}

void red(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(5, LOW);
    digitalWrite(6, LOW);
    digitalWrite(7, LOW);
  }
  else
  {
    digitalWrite(5, HIGH);
    digitalWrite(6, HIGH);
    digitalWrite(7, HIGH);
  }
}

void white(int on_off)
{
  if (on_off == 0)
  {
    digitalWrite(8, LOW);
  }
  else
  {
    digitalWrite(8, HIGH);
  }
}
Posted in Uncategorized | Leave a comment

Code is a mass noun

THIS IS A PUBLIC INFORMATION MESSAGE CONCERNING THE CORRECT USE OF THE WORD “CODE”.

I’ve read many RoboSumo blog posts over the last couple of days that use the word “code” incorrectly. When speaking about programming, “code” is generally used as a mass noun rather than a count noun. To see the difference between mass nouns and count nouns, let’s look at examples of each.

A count noun is a noun (the name of a person, place or thing) that you can put a number in front of to specify a certain quantity. Words like “a” or “an” might also precede a count noun if there’s only one object.

Count noun Example sentence
Apple I ate three apples.
Bicycle I bought a new bicycle yesterday.
Book I own hundreds of books.
Robot At the end of the semester each robot competes in a sumo tournament.

A mass noun is a noun that you don’t put a number in front of to specify a quantity.

Mass noun Something you can say Something you can’t say
Water I drank a glass of water. The jug contained a water.
Sunshine We enjoyed the sunshine yesterday. There were many sunshines yesterday.
Petrol I put some petrol in my car. There are few petrols in my car.
Code I wrote the code for my team’s robot. I downloaded a code onto my team’s robot.

Some important points:

  • In programming, the word “code” is used as a mass noun, which means you don’t say “a code” or “codes”.
  • In the English language, “code” can certainly be used as a count noun in other contexts. For example, spies might communicate using a secret code.
  • Frequently, I see “code” written where the word “program” would be more appropriate. For example, I might see “I wrote a code for my team’s robot” when it should say “I wrote a program for my team’s robot”.
  • The word “program” can be used as a count noun or as a verb, but never as a mass noun. For example, you can say “I wrote a program” or “I program the robot”, but not “I wrote a lot of program for our robot.”

Quiz

Finally, to test your understanding of the use of the word “code”, here are ten example sentences. Five are right and five are wrong. Can you tell which are which? (Scroll down for the answers.)

  1. I enjoy writing code for the robot.
  2. There were problems with the robot because of errors in the codes.
  3. Over the course of the semester, we wrote a lot of program.
  4. Whenever I rewire the circuit, I write a new code for the robot too.
  5. Poorly commented code is difficult to understand.
  6. I enjoyed programming the robot.
  7. In order to try out different strategies for our robot, we wrote three different codes.
  8. There are over 100 lines of code in our final program.
  9. We all worked together to write a new code for the robot.
  10. C code is terse.

Answers

1. I enjoy writing code for the robot. Correct …because “code” is used as a mass noun.
2. There were problems with the robot because of errors in the codes. Incorrect …because “codes” is used as a count noun (due to the “s” on the end).
3. Over the course of the semester, we wrote a lot of program. Incorrect …because “program” is used as a mass noun.
4. Whenever I rewire the circuit, I write a new code for the robot too. Incorrect …because “code” is used as a count noun – “a new code”.
5. Poorly commented code is difficult to understand. Correct …because “code” is used as a mass noun.
6. I enjoyed programming the robot. Correct …because “programming” is used as a verb.
7. In order to try out different strategies for our robot, we wrote three different codes. Incorrect …because “codes” is used as a count noun – “three different codes”.
8. There are over 100 lines of code in our final program. Correct …because “code” is used as a mass noun. Note that the number 100 applies to the word “lines” rather than “code”.
9. We all worked together to write a new code for the robot. Incorrect …because “code” is used as a count noun – “a new code”.
10. C code is terse. Correct …because “code” is used as a mass noun. Also, C code really can be terse!
Posted in Uncategorized | Leave a comment