RoboSumo Tournament semester 1 2022-2023 – 2pm Wed 14-Dec-2022

This semester’s RoboSumo tournament takes place at 2pm, Wednesday 14th Dec 2022.

LINK TO LIVE SPREADSHEET

(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 14th Dec 2022 in Central Quad (rooms CQ-343 and CQ-345). Weigh-in and robot validation will take place from 14:00-14:30. The first bouts are expected to begin at roughly 14:30. During the initial “sorting” phase of the tournament, competitors will be divided into two pools, each of which will be assigned to one of the two competition arenas. Within each pool, sorting will proceed based on the bubble sort process previously described in class. The initial ranking will be determined by the results of the Track TT competition (based on the average of the team members’ individual Track TT rankings).

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 – 14:00

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 referee’s electronic scales. This weight includes every part of the competing robot, including batteries.
  • The size limit is 15 cm x 15 cm x 15 cm (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 14:00. One of the module lecturers (or their nominated proxy) will act as compliance officer, managing the weigh-in. He/she will run through a checklist with each team.

Sumo Bouts – 14:30

From 14:30 onwards, teams should be continuously available to compete without delay whenever summoned to one of the arenas. When a referee summons two robots to the arena for a bout, if one robot is ready to compete but the other is not (e.g. the team fails to present themselves at the arena, or the robot is non-compliant, or the robot is non-functioning) the first robot will be granted a walkover victory in that bout. In that case, the losing team remains eligible to compete in subsequent bouts (until they are eliminated from the tournament).

TU Dublin tournament rules

The beginning of each bout:

  1. The referee positions each robot before the bout begins (or instructs the competitor where to position it). Ordinarily, the referee will place the robots in opposite quadrants of the arena, each robot facing along a line parallel to that of the other robot, but not in the direction of the opponent. However, the starting position and orientation of each robot within the arena is entirely at the discretion of the referee.
  2. Each team nominates a single team member as the designated starter for the bout. The designated starter manually activates the robot at beginning of each bout, as instructed by the referee. The specific method of starting the robot is left up to each team – flicking a switch, pressing a button, inserting a wire, inserting a battery, etc. – but whatever method is used, the robot must remain stationary until the referee says “Go”.
  3. It is permitted for a robot to be powered on while waiting for the referee to say “Go”, provided that it does not move.
  4. When the referee says “Go” each team’s designated starter starts his/her robot.
  5. The designated starter is only allowed to start the robot – he/she may not change the position or orientation of the robot in the arena.
  6. Once the robot begins moving, no one is permitted to touch the robot again until the bout has ended. He/she must withdraw from the arena and have no further contact with the robot until the bout ends.
  7. No one is permitted to touch a robot after it has begun moving (or has moved from its initial position).
  8. No one is permitted to touch a robot after the opponent robot has made physical contact with it.
  9. No competitor is permitted to touch the opponent robot at any time.

The end of each bout:

  1. The bout ends when one robot leaves the arena, meaning that it is no longer in contact with (or directly above) the upper surface of the arena. If one robot leaves the arena while the other remains inside it, them the second robot will be deemed the winner of that bout.
  2. If a robot is partly outside the arena but remains in physical contact with the upper surface of the arena, then it will be left to the referee to judge whether it stands a realistic chance of re-entering the arena.
  3. The duration of each bout is limited to 30 seconds.
  4. 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.

Other rules:

  1. When a bout fails to produce a clear winner, the referee may, at his/her own discretion, order the bout to be replayed.
  2. During the sorting phase 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 increases (best of 3 or best of 5).
  3. 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.
  4. 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.
  5. 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 competitive bouts and can therefore only move down in the tournament ranking. 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 to the knockout phase of 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.
  • At every moment during a bout, it should be possible to enclose the entire robot (including all parts) inside a cube 15 cm on each side (i.e. 15 cm by 15 cm by 15 cm).
  • The only permitted power supply for competing robots is a 4xAA battery pack, using regular AA batteries. The nominal combined voltage of the batteries must not exceed 6V. No other form of stored energy (e.g. chemical, elastic, potential, kinetic) is permitted.

Following validation (the “weigh-in”), if a team makes any change to their robot which increases its size or mass, or if they switch to a different robot, they must repeat the validation process prior to competing in any bout.

Sorting phase

The initial ranking will be determined primarily by the results of the Track TT challenge. Each team will be assigned an initial ranking based on the team members’ average individual Track TT ranking. The objective of the sorting phase is to select the top 8 (or 16) teams. A variation on the so-called bubble sort will be used for the majority of the sorting phase. However, the referee(s) may deviate from this pattern at his/her/their own discretion to resolve any unforeseen ranking issues or anomalies.

In each of the two pools (odd and even), the sorting phase will continue until the referee is satisfied that he/she has identified which 4 (or 8) teams should progress from that pool to the knockout phase of the tournament.

Knockout phase

The 8 (or 16) top-ranked teams 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 (ordinarily best of 3 bouts, apart from the final which is best of 5 bouts).

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, 151mm 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 getting your robot moving around and responding to its sensor(s).
  4. 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.
  5. Make sure you bring 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.

Best of luck to all of you!

Advertisement
Posted in Uncategorized | Leave a comment

State machine example

//
// State machine example
// Written by Ted Burke - last updated 30-Nov-2022
//
 
void setup()
{
  pinMode(3, OUTPUT); // trigger pin
  pinMode(4, INPUT);  // echo pin
 
  pinMode(6, OUTPUT); // LED

  pinMode(7, OUTPUT); // left motor forward
  pinMode(8, OUTPUT); // left motor reverse
  pinMode(9, OUTPUT); // right motor forward
  pinMode(10, OUTPUT); // right motor reverse
 
  Serial.begin(9600); // open serial connection to PC
}

int state = 1;

void loop()
{
  float distance; // rangefinder reading
  int flc, frc; // colour sensor readings
  
  if (state == 1) // FORWARD
  {
    // Set outputs
    setMotorDirections(1, 1); // both motors forward

    // Read inputs
    distance = getDistance();
    flc = analogRead(0);
    frc = analogRead(1);

    // Transition to a different state?
    if (distance < 0.5) state = 2;
    if (flc > 512) state = 5;
    if (frc > 512) state = 5;
  }
  else if (state == 2) // SPIN LEFT
  {
    // Set outputs
    setMotorDirections(-1, 1); // spin left

    // Read inputs
    distance = getDistance();

    // Transition to a different state?
    if (distance > 0.6) state = 3;
  }
  else if (state == 3) // FORWARD
  {
    // Set outputs
    setMotorDirections(1, 1); // both motors forward

    // Read inputs
    distance = getDistance();
    flc = analogRead(0);
    frc = analogRead(1);

    // Transition to a different state?
    if (distance < 0.5) state = 4;
    if (flc > 512) state = 5;
    if (frc > 512) state = 5;
  }
  else if (state == 4) // SPIN RIGHT
  {
    // Set outputs
    setMotorDirections(1, -1); // spin right

    // Read inputs
    distance = getDistance();

    // Transition to a different state?
    if (distance > 0.6) state = 1;
  }
  else if (state == 5) // REVERSE
  {
    // Set outputs
    setMotorDirections(-1, -1); // both motors reverse

    // Transition to a different state?
    delay(2000);
    state = 1;
  }  
}

void setMotorDirections(int l, int r)
{
  digitalWrite(7, l > 0);
  digitalWrite(8, l < 0);
  digitalWrite(9, r > 0);
  digitalWrite(10, r < 0);
}

float getDistance()
{
  // Allow ultrasound echoes to dissipate before measurement
  delay(50);
 
  // Declare variables
  long echo_duration_us; // echo duration in microseconds
  float distance_m;     // distance in metres
   
  // Send 20 microsecond trigger pulse to HC-SR04
  digitalWrite(3, HIGH); // begin pulse
  delayMicroseconds(20); // 20 us delay
  digitalWrite(3, LOW);  // end pulse
 
  // Measure the duration in microseconds of the echo pulse
  echo_duration_us = pulseIn(4, HIGH);
 
  // Convert echo pulse duration to distance
  // Note: speed of sound in air is 340 micrometres per microsecond
  distance_m = 0.5 * 340e-6 * echo_duration_us;
 
  return distance_m;
}

Same state machine with while loops instead of if-else-if-else…

//
// State machine example
// Written by Ted Burke - last updated 30-Nov-2022
//
 
void setup()
{
  pinMode(3, OUTPUT); // trigger pin
  pinMode(4, INPUT);  // echo pin
 
  pinMode(6, OUTPUT); // LED

  pinMode(7, OUTPUT); // left motor forward
  pinMode(8, OUTPUT); // left motor reverse
  pinMode(9, OUTPUT); // right motor forward
  pinMode(10, OUTPUT); // right motor reverse
 
  Serial.begin(9600); // open serial connection to PC
}

int state = 1;

void loop()
{
  float distance; // rangefinder reading
  int flc, frc; // colour sensor readings
  
  while (state == 1) // FORWARD
  {
    // Set outputs
    setMotorDirections(1, 1); // both motors forward

    // Read inputs
    distance = getDistance();
    flc = analogRead(0);
    frc = analogRead(1);

    // Transition to a different state?
    if (distance < 0.5) state = 2;
    if (flc > 512) state = 5;
    if (frc > 512) state = 5;
  }
  
  while (state == 2) // SPIN LEFT
  {
    // Set outputs
    setMotorDirections(-1, 1); // spin left

    // Read inputs
    distance = getDistance();

    // Transition to a different state?
    if (distance > 0.6) state = 3;
  }
  
  while (state == 3) // FORWARD
  {
    // Set outputs
    setMotorDirections(1, 1); // both motors forward

    // Read inputs
    distance = getDistance();
    flc = analogRead(0);
    frc = analogRead(1);

    // Transition to a different state?
    if (distance < 0.5) state = 4;
    if (flc > 512) state = 5;
    if (frc > 512) state = 5;
  }
  
  while (state == 4) // SPIN RIGHT
  {
    // Set outputs
    setMotorDirections(1, -1); // spin right

    // Read inputs
    distance = getDistance();

    // Transition to a different state?
    if (distance > 0.6) state = 1;
  }
  
  while (state == 5) // REVERSE
  {
    // Set outputs
    setMotorDirections(-1, -1); // both motors reverse

    // Transition to a different state?
    delay(2000);
    state = 1;
  }  
}

void setMotorDirections(int l, int r)
{
  digitalWrite(7, l > 0);
  digitalWrite(8, l < 0);
  digitalWrite(9, r > 0);
  digitalWrite(10, r < 0);
}

float getDistance()
{
  // Allow ultrasound echoes to dissipate before measurement
  delay(50);
 
  // Declare variables
  long echo_duration_us; // echo duration in microseconds
  float distance_m;     // distance in metres
   
  // Send 20 microsecond trigger pulse to HC-SR04
  digitalWrite(3, HIGH); // begin pulse
  delayMicroseconds(20); // 20 us delay
  digitalWrite(3, LOW);  // end pulse
 
  // Measure the duration in microseconds of the echo pulse
  echo_duration_us = pulseIn(4, HIGH);
 
  // Convert echo pulse duration to distance
  // Note: speed of sound in air is 340 micrometres per microsecond
  distance_m = 0.5 * 340e-6 * echo_duration_us;
 
  return distance_m;
}
Posted in Uncategorized | Leave a comment

RoboSlam wheels and spacers SVG file

https://robosumo.eu/D12345678/uploads/roboslam_wheels_and_spacers.svg

Posted in Uncategorized | Leave a comment

Example motor control function

This is an example of a motor control function that you could use in your Arduino program to encapsulate the process of setting all four motor control pins. The first argument (input value) to the function sets the direction of the left motor. The second argument sets the direction of the right motor. It is assumed that the motor control pins are:

  • D7 : left motor forward
  • D8 : left motor reverse
  • D9 : right motor forward
  • D10: right motor reverse

Here’s how you would use the function:

// Both motors forward
setMotorDirections(1, 1);

// Left motor forward, right motor reverse
setMotorDirections(1, -1);

// Left motor reverse, right motor stop
setMotorDirections(-1, 0);

// Both motors reverse
setMotorDirections(-1, -1);

// Both motors stop
setMotorDirections(0, 0);

This is the actual definition of the function:

void setMotorDirections(int left_motor_direction, int right_motor_direction)
{
  if (left_motor_direction < 0)
  {
    digitalWrite(7, LOW);
    digitalWrite(8, HIGH);
  }
  else if (left_motor_direction > 0)
  {
    digitalWrite(7, HIGH);
    digitalWrite(8, LOW);
  }
  else
  {
    digitalWrite(7, LOW);
    digitalWrite(8, LOW);
  }
  
  if (right_motor_direction < 0)
  {
    digitalWrite(9, LOW);
    digitalWrite(10, HIGH);
  }
  else if (right_motor_direction > 0)
  {
    digitalWrite(9, HIGH);
    digitalWrite(10, LOW);
  }
  else
  {
    digitalWrite(9, LOW);
    digitalWrite(10, LOW);
  }  
}

The version above is written to be more understandable for beginner C/C++ programmers, but the following functionally equivalent but more concise version is how I would probably write this if I was building a robot myself:

void setMotorDirections(int l, int r)
{
  digitalWrite(7, l > 0);
  digitalWrite(8, l < 0);
  digitalWrite(9, r > 0);
  digitalWrite(10, r < 0);
}
Posted in Uncategorized | Leave a comment

Basic HC-SR04 example

A basic example using the HC-SR04 ultrasonic rangefinder to measure a distance is provided below.

Circuit diagram

Principle of operation

This sensor emits a short pulse of ultrasound which reflects off objects that it meets. The ultrasonic pulse is quite directional and travels at the speed of sound (approximately 340 m/s in air). The sensor measures how much time elapses before the first reflection is detected. This will be the reflection from the nearest object in front of the sensor. The total distance traveled by the ultrasound is twice the distance from the sensor to the nearest object.

T = \frac{2d}{c}

where T is the time taken for the ultrasound to make the round trip to the nearest object (in seconds), d is the distance from the sensor to the nearest object (in metres), and c is the speed of sound in air (approximately 340 m/s). What the sensor actually measures is the time T, which can be used to calculate d by rearranging the above formula:

d = \frac{T}{2c}

Using the HC-SR04 sensor with an Arduino

The process followed by the Arduino to measure the distance to the nearest object is as follows:

  • The Arduino sends a short 5V pulse (at least 10 μs) from one of its digital output pins D3 in the example below) to the “trig” pin of the HC-SR04 sensor. This triggers the emission of an ultrasonic pulse.
  • The HC-SR04 responds by sending a pulse from its “echo” pin to one of the Arduino’s digital input pins (D4 in the example below). The echo pulse begins when the ultrasonic pulse is emitted.
  • The echo pulse stays high (5V) until the first ultrasonic reflection is detected. Once the first reflection is detected, the pulse ends (i.e. returns to 0V).
  • Hence, the duration of the echo pulse tells the Arduino how long it took the ultrasound to travel to the nearest object and back.
  • The Arduino uses the “pulseIn” function to measure the duration of the echo pulse (in microseconds).
  • The formula above is then used to convert from pulse duration (in seconds) to distance (in metres).

An example program for using the HC-SR04 with an Arduino Nano is shown below.

  • The distance measurement process described above is encapsulated in a separate function called “getDistance” so that distance can be measured easily with a single line of code in the loop function.
  • The Arduino has an LED connected to pin D6. It switches it on or off depending on whether the measured distance is less than 40 cm (0.4 m). Of course, you will probably want to use the measured distance to make decisions about the robot motors.
  • The example code also prints out the measured distance over the serial connection, so that you can use the Serial Monitor (under the Tools menu in the Arduino development environment) to check that the sensor is working correctly.
//
// HC-SR04 ultrasonic rangefinder basic example
// Written by Ted Burke - last updated 30-Nov-2022
//

void setup()
{
  pinMode(3, OUTPUT); // trigger pin
  pinMode(4, INPUT);  // echo pin

  pinMode(6, OUTPUT); // LED

  Serial.begin(9600); // open serial connection to PC
}

void loop()
{
  // Declare variable to store distance in metres
  float d;

  // Call function to measure distance and store returned value in d
  d = getDistance();

  // Display the distance in the Serial Monitor
  Serial.print(d);
  Serial.println(" metres");

  // Make a decision based on the current distance
  if (d < 0.4)
  {
    digitalWrite(6, HIGH); // LED on
  }
  else
  {
    digitalWrite(6, LOW); // LED off
  }
}

float getDistance()
{
  // Allow ultrasound echoes to dissipate before measurement
  delay(50);

  // Declare variables
  long echo_duration_us; // echo duration in microseconds
  float distance_m;     // distance in metres
  
  // Send 20 microsecond trigger pulse to HC-SR04
  digitalWrite(3, HIGH); // begin pulse
  delayMicroseconds(20); // 20 us delay
  digitalWrite(3, LOW);  // end pulse

  // Measure the duration in microseconds of the echo pulse
  echo_duration_us = pulseIn(4, HIGH);

  // Convert echo pulse duration to distance
  // Note: speed of sound in air is 340 micrometres per microsecond
  distance_m = 0.5 * 340e-6 * echo_duration_us;

  return distance_m;
}

Posted in Uncategorized | Leave a comment

Assembly instructions for TCRT5000 printed circuit board

Martin Sorohan, who designed the printed circuit board adapter for the TCRT5000 infrared reflective sensor, has kindly supplied the following assembly instructions for soldering it:

Colour Sensor Assembly on PCB Board — Robo Sumo

Posted in Uncategorized | Leave a comment

Sensor controlling motor example

//
// Sensor controlling motor example
// Written by Ted Burke - 19-Oct-2022
//

void setup()
{
  pinMode(4, OUTPUT); // make pin D4 a digital output
  pinMode(5, OUTPUT); // make pin D5 a digital output
}

void loop()
{
  int colour; // declare an integer variable

  // Read the voltage from pin A3
  // Values between 0 and 1023 represent voltages
  // between 0V and 5V.
  colour = analogRead(3);

  // If sensor voltage is greater than 2.5V, then
  // motor drives forward. Otherwise motor reverses.
  if (colour > 512)
  {
    digitalWrite(4, HIGH); // set voltage on pin D4 to 5V
    digitalWrite(5, LOW);  // set voltage on pin D5 to 0V
  }
  else
  {
    digitalWrite(4, LOW);  // set voltage on pin D4 to 0V
    digitalWrite(5, HIGH); // set voltage on pin D5 to 5V
  }
}

Posted in Uncategorized | Leave a comment

Basic motor control example

//
// Basic motor control example
// Motor forward for 2 seconds, reverse for 2 seconds
// and stop for 4 seconds. Repeats indefinitely.
// Written by Ted Burke - 19-Oct-2022
//

void setup()
{
  pinMode(4, OUTPUT); // make pin D4 a digital output
  pinMode(5, OUTPUT); // make pin D5 a digital output
}

void loop()
{
  // Motor forward for 2 seconds
  digitalWrite(4, HIGH); // set voltage on pin D4 to 5V
  digitalWrite(5, LOW);  // set voltage on pin D5 to 0V
  delay(2000);

  // Motor reverse for 2 seconds
  digitalWrite(4, LOW);  // set voltage on pin D4 to 0V
  digitalWrite(5, HIGH); // set voltage on pin D5 to 5V
  delay(2000);
  
  // Motor stop for 4 seconds
  digitalWrite(4, LOW);  // set voltage on pin D4 to 0V
  digitalWrite(5, LOW);  // set voltage on pin D5 to 0V
  delay(4000);  
}

Posted in Uncategorized | Leave a comment

Track TT Competition – Semester 1 2022-23

Live spreadsheet of Track TT results

This competition is a robot track time trial (TT). You will build an autonomous (self-guiding) robot to drive from one end of a marked track to the other end in the shortest possible time. You will each build your own individual robot for this competition. Your robot should be ready to perform the task under the observation of a referee (probably your lab supervisor) during the lab session on Wednesday 9th November 2022.

Results will be ranked based on the time taken by each robot to complete the task (as measured by the referee), as well as compliance with the rules set out below. Robots that do not complete the challenge on 9-Nov-2022 will have a second opportunity to record a time the following week, but their results will be ranked below all robots that successfully complete the challenge in the first week of the competition.

Competitors are permitted (at the discretion of the referee) to attempt the task multiple times, whether to complete the task for the first time, or to improve upon a previously recorded attempt. Priority should be given to competitors who have not yet recorded a successful attempt.

The colour of the track will be decided by the referee. It will either be a light-coloured track on a dark background or vice versa.

At the beginning of a time trial attempt, the competitor places their robot over the start end of the stripe. Some part of the robot must be directly above the end of the track when the referee starts the clock.

The robot follows the track from the start to the finish end of the stripe, keeping some part of itself directly above the stripe at all times. Competitors are forbidden from touching or otherwise influencing the robot during the time trial – the robot must be complete the task autonomously.

The clock stops as soon as any part of the robot is directly above the finish end of the stripe. The robot does not need to come to a halt.

If the robot leaves the track at any point (i.e. no part of the robot is directly above the track), that attempt at the time trial is null and void.

The Track

  • The track will be marked with a clearly visible stripe on a horizontal surface.
  • The track can be either a dark stripe on a light background or a light stripe on a dark background, as decided by the referee(s).
  • The width of the stripe will be no less than 4cm and no greater than 6cm.
  • The track consists of five straight sections, each at least 50cm in length.
  • At every meeting point between two straight sections, the track turns a right-angled corner (i.e. 90 degrees). At each corner, the inner and outer edges of the track will each form a 90 degree angle (i.e. neither edge of the track is rounded at the corner).
  • As the robot travels along the track from beginning to end, the corners are as follows: left turn, left turn, right turn, right turn.
  • The recorded result for the time trial will be the time elapsed between the last moment when the robot was above the start end of the stripe and the first moment when the robot is above the finishing end of the stripe.
  • The robot must remain in contact with the horizontal surface throughout the time trial.
  • It is not permitted to touch, influence or otherwise interfere with the robot during the time trial – it must operate completely autonomously.
  • If the robot leaves the track at any point during the time trial, that attempt is null and void. The robot does not need to be in physical contact with the track throughout the attempt, but some part of the robot must always be directly above some part of the track.

Robot specification

  • The maximum permitted size of the robot is a cube 150 mm on all sides (i.e. 150 mm × 150 mm × 150 mm). At every moment during an attempt, every single part of the robot (including loose wires, etc.) must fit within an upright 150 x 150 x 150 mm cube. Upright means that two sides of the cube are horizontal and four sides are vertical. Note that this size limit is very strictly enforced.
  • The maximum permitted mass of the robot is 500 g. This weight limit is strictly enforced.
  • The only permitted power source for the robot is 4 × AA batteries (e.g. the battery pack provided in the RoboSumo kit).
  • Competitors are permitted to source additional components and materials for use in their robot, at their own expense. However, the maximum permitted budget for parts used in a robot during the time trial is €70 (of the competitor’s own money). This excludes the cost of parts supplied by the college and materials that were obtained for free (provided that similar materials could easily be obtained for free by other competitors). Note that you do not need to spend any money to complete this challenge. Also, please note that any money you choose to spend will not be reimbursed by the college.
  • Please keep in mind when purchasing components or materials that your sumo robot will be submitted for assessment at the end of the project (after the sumo tournament) and, although we do aim to return most robots to the competitors/teams who built them, there is no guarantee that you will get your robot back. Competitors will not be reimbursed for parts included in the robot they submit for assessment, even if the robot is not returned to them.

Non-compliant robots and late entries

  • Robots that fail to complete the challenge in the first week will be permitted to record a time the following week, but all results after the first week will be ranked below those recorded in the first week, irrespective of the times recorded.
  • Robots that fail to comply with the above specifications may still be permitted to record a ranked time, at the discretion of the referee. However, their results will be ranked below those of compliant robots that completed the task in the same week, irrespective of the time recorded.

Documenting your Track TT work in a WordPress blog post

  • Every student writes an individual blog post about their work on the Track TT challenge.
  • Record a video of your robot completing the Track TT. Upload your video to YouTube and make it publicly visible. (You may select to make it “unlisted” which will prevent it from appearing in search results.)
  • Embed the YouTube video of your Track TT attempt (and optionally other attempts) in your blog post.
  • Include photos of your robot, highlighting any noteworthy design features.
  • Include a circuit diagram using the conventional circuit symbols (i.e. not a drawing of your breadboard layout).
  • Include one or more clear photos of your breadboard and any other wiring you completed (e.g. TCRT5000 colour-sensing modules).
  • Include your complete Arduino code for the working robot. Ensure that the code includes clear accurate comments, is easy to read, and is neatly indented.
  • Include a flow chart / state table / logic diagram or something similar to explain how your code works.
  • Include photos of any design sketches or schematics you have drawn.
  • Include a brief reflection on what you learned while working on the Track TT challenge.

Example TrackTT video

Summary of ranking criteria:

Ranking of results will be according to the following criteria, in order of decreasing precedence:

  1. Robots that complete the task in week 1 will be ranked above those that complete it in week 2.
  2. Robots that are fully compliant with the above robot specification during their ranked attempt will rank above robots that are non-compliant during their ranked attempt.
  3. Robots will be ranked according to the time taken to complete the task. Robots that complete it quicker will be ranked higher.

Referees and conduct of competitors

  • Every RoboSumo module lecturer is a competition referee. The module lecturers may also nominate additional referees.
  • Competitors must follow the referee’s instructions during an attempt.
  • Competitors who repeatedly fail to follow the referee’s instructions, or who engage in rude or offensive behaviour during the competition may be suspended or disqualified at the discretion of the referee(s).
  • The referees will aim to treat all competitors fairly. Where a difference of opinion arises, competitors must always respect the decision of the referee. Once the referee makes a decision, competitors must refrain from further argument on the matter.
  • The referees reserve the right to amend the competition rules or ranking criteria in individual cases, should the need arise (e.g. where a student is absent for medical reasons). Amendments may be applied at the time of the competition or subsequently, which may affect the competition ranking.

Posted in Uncategorized | Leave a comment

Provisional RoboSumo Schedule for semester 1 2022-23

Posted in Uncategorized | Leave a comment