RoboSumo Tournament semester 2 2021-2022 – 2pm Wed 27-Apr-2022

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

Live Ranking 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 27th April 2022 in Central Quad (rooms CQ-507 and CQ-508). 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!

Posted in Uncategorized | Leave a comment

Sumo state machine examples

Two-state version: spin and charge when opponent is detected

//
// RoboSumo state machine example
// Two-state version: spin and charge when opponent is detected
// Written by Ted Burke - last updated 6-Apr-2022
//

int state = 1;

// The setup function performs one-time initialisation
// whenever the Arduino is powered on.
void setup()
{
  pinMode(3, OUTPUT); // trigger pin
  pinMode(4, INPUT);  // echo pin

  pinMode(5, OUTPUT); // LM forward
  pinMode(6, OUTPUT); // LM reverse
  pinMode(7, OUTPUT); // RM forward
  pinMode(8, OUTPUT); // RM reverse
 
  Serial.begin(9600); // open serial connection to PC
}

// The loop function gets called repeatedly after the setup
// function has completed. It keeps getting called until
// the Arduino is powered off. This is where most of the
// action happens.
void loop()
{
  // Declare variable to store distance in metres
  float d;
 
  // Call function to measure distance and store returned value in d
  d = getDistance();

  if (state == 1)
  {
    // Motors / outputs
    motors(1, -1); // LM forward, RM reverse

    // State transitions
    if (d < 0.5) state = 2;
  }
  else if (state == 2)
  {
    // Motors / outputs
    motors(1, 1); // LM forward, RM forward

    // State transitions
    if (d >= 0.5) state = 1;
  } 
}

// The motors function is a utility function that allows us to
// conveniently set the state of both motors in a single line
// of code. It sets the four digital output pins that actually
// control the two motors.
void motors(int left_motor_direction, int right_motor_direction)
{
  if (left_motor_direction > 0)
  {
    // LM forward
    digitalWrite(5, HIGH);
    digitalWrite(6, LOW);
  }
  else if (left_motor_direction < 0)
  {
    // LM reverse
    digitalWrite(5, LOW);
    digitalWrite(6, HIGH);    
  }
  else
  {
    // LM stop
    digitalWrite(5, LOW);
    digitalWrite(6, LOW);
  }

  if (right_motor_direction > 0)
  {
    // RM forward
    digitalWrite(7, HIGH);
    digitalWrite(8, LOW);
  }
  else if (right_motor_direction < 0)
  {
    // RM reverse
    digitalWrite(7, LOW);
    digitalWrite(8, HIGH);    
  }
  else
  {
    // RM stop
    digitalWrite(7, LOW);
    digitalWrite(8, LOW);
  }
}

// The getDistance function is a utility function that handles
// the interaction with the HC-SR04 ultrasonic rangefinder.
// Each time this function is called, it takes one distance
// measurement. It returns the distance in metres to the
// nearest object.
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;
}

Four-state version: Alternate spin directions

//
// RoboSumo state machine example for Arduino Nano + HC-SR04
// Four-state version with alternating spin directions
// Written by Ted Burke - last updated 6-Apr-2022
//

int state = 1;

// The setup function performs one-time initialisation
// whenever the Arduino is powered on.
void setup()
{
  pinMode(3, OUTPUT); // trigger pin
  pinMode(4, INPUT);  // echo pin

  pinMode(5, OUTPUT); // LM forward
  pinMode(6, OUTPUT); // LM reverse
  pinMode(7, OUTPUT); // RM forward
  pinMode(8, OUTPUT); // RM reverse
 
  Serial.begin(9600); // open serial connection to PC
}

// The loop function gets called repeatedly after the setup
// function has completed. It keeps getting called until
// the Arduino is powered off. This is where most of the
// action happens.
void loop()
{
  // Declare variable to store distance in metres
  float d;
 
  // Call function to measure distance and store returned value in d
  d = getDistance();

  if (state == 1) // SPIN LEFT
  {
    // Motors / outputs
    motors(-1, 1); // LM reverse, RM forward

    // State transitions
    if (d < 0.5) state = 2;
  }
  else if (state == 2) // FORWARD
  {
    // Motors / outputs
    motors(1, 1); // LM forward, RM forward

    // State transitions
    if (d >= 0.5) state = 3;
  }
  else if (state == 3) // SPIN RIGHT
  {
    // Motors / outputs
    motors(1, -1); // LM forward, RM reverse

    // State transitions
    if (d < 0.5) state = 4;
  } 
  else if (state == 4) // FORWARD
  {
    // Motors / outputs
    motors(1, 1); // LM forward, RM forward

    // State transitions
    if (d >= 0.5) state = 1;
  }
}

// The motors function is a utility function that allows us to
// conveniently set the state of both motors in a single line
// of code. It sets the four digital output pins that actually
// control the two motors.
void motors(int left_motor_direction, int right_motor_direction)
{
  if (left_motor_direction > 0)
  {
    // LM forward
    digitalWrite(5, HIGH);
    digitalWrite(6, LOW);
  }
  else if (left_motor_direction < 0)
  {
    // LM reverse
    digitalWrite(5, LOW);
    digitalWrite(6, HIGH);    
  }
  else
  {
    // LM stop
    digitalWrite(5, LOW);
    digitalWrite(6, LOW);
  }

  if (right_motor_direction > 0)
  {
    // RM forward
    digitalWrite(7, HIGH);
    digitalWrite(8, LOW);
  }
  else if (right_motor_direction < 0)
  {
    // RM reverse
    digitalWrite(7, LOW);
    digitalWrite(8, HIGH);    
  }
  else
  {
    // RM stop
    digitalWrite(7, LOW);
    digitalWrite(8, LOW);
  }
}

// The getDistance function is a utility function that handles
// the interaction with the HC-SR04 ultrasonic rangefinder.
// Each time this function is called, it takes one distance
// measurement. It returns the distance in metres to the
// nearest object.
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

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-Mar-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

Reminder: RoboSumo Schedule for semester 2 2021-22

Same schedule as before – I’m just re-posting it to remind you how close the final tournament is!

Posted in Uncategorized | Leave a comment

Track TT example(s)

//
// Track TT example code
// Written by Ted Burke - 9-Mar-2022
//

void setup()
{
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
}

void loop()
{
  int colour;

  colour = analogRead(0);

  if (colour > 512)
  {
    digitalWrite(2, HIGH); digitalWrite(3, LOW); // LM forward
    digitalWrite(4, LOW);  digitalWrite(5, LOW); // RM stop
  }
  else
  {
    digitalWrite(2, LOW); digitalWrite(3, LOW);  // LM stop
    digitalWrite(4, HIGH); digitalWrite(5, LOW); // RM forward
  }
}

Another version of the Track TT code for the above circuit, this time using a helper function to set the direction of both motors in a single function call.

//
// Track TT example code
// Written by Ted Burke - 9-Mar-2022
//

void setup()
{
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
}

void loop()
{
  int colour;

  colour = analogRead(0);

  if (colour > 512)
  {
    motors(1, 0); // LM forward, RM stop
  }
  else
  {
    motors(0, 1); // LM stop, RM forward
  }
}

void motors(int LMdirection, int RMdirection)
{
  // Set left motor pins
  if (LMdirection < 0)
  {
    digitalWrite(2, LOW);
    digitalWrite(3, HIGH);
  }
  else if (LMdirection > 0)
  {
    digitalWrite(2, HIGH);
    digitalWrite(3, LOW);
  }
  else
  {
    digitalWrite(2, LOW);
    digitalWrite(3, LOW);    
  }
  
  // Set right motor pins
  if (RMdirection < 0)
  {
    digitalWrite(4, LOW);
    digitalWrite(5, HIGH);
  }
  else if (RMdirection > 0)
  {
    digitalWrite(4, HIGH);
    digitalWrite(5, LOW);
  }
  else
  {
    digitalWrite(4, LOW);
    digitalWrite(5, LOW);    
  }
}
//
// Another Track TT example
// Written by Ted Burke - 9-Mar-2022
//

void setup()
{
  pinMode(2, OUTPUT);
}

void loop()
{
  digitalWrite(2, analogRead(0) > 512);
}
Posted in Uncategorized | Leave a comment

Live ranking for Track TT competition

The official track for today’s Track TT competition is located in CQ-507 / CQ-508. Please come to that room to record your official time. The track will be available from 3-6pm. Competitors wishing to record a time after 6pm may be facilitated at the discretion of the referee, but don’t assume that this facility will be available.

The link below provides access to the live ranking spreadsheet for the Track TT competition. Please note that all rankings shown are provisional and will update as new results are added to the spreadsheet.

Live Ranking Spreadsheet

Posted in Uncategorized | Leave a comment

Example blog post

This is a paragraph of text. The motor control subsystem shown in this blog post is based on an earlier example by Ted Burke.

This is another paragraph of text.

This was the code used for testing this sub-system:

//
// Blinking LED example for Arduino Nano
// Written by Ted Burke - 23-Feb-2022
//

void setup()
{
  pinMode(2, OUTPUT); // Make pin D2 a digital output for the LED
}

void loop()
{
  // LED on for 1 second
  digitalWrite(2, HIGH);
  delay(1000);
  
  // LED off for 1 second
  digitalWrite(2, HIGH);
  delay(1000);  
}

Posted in Uncategorized | Leave a comment

Motor control with TCRT5000 sensor input

This was the first example circuit I presented in today’s lecture:

This was the TCRT5000 example circuit from today’s lecture:

This diagram illustrates how the TCRT5000 reflective infrared (IR) sensor works:

This diagram illustrates the physical layout of the pins on the SN754410 integrated circuit:

The following example program from today’s lecture combines sensor input from the TCRT5000 circuit (using the analogRead function from the Arduino library) with motor control using the SN754410. The motor direction and LED state both depend on the voltage reading from the TCRT5000 sensor.

//
// Motor example
// Written by Ted Burke
// Last updated 9-Feb-2022
//

void setup()
{
  pinMode(2, OUTPUT); /// LED pin
  pinMode(3, OUTPUT); /// Motor forward pin
  pinMode(4, OUTPUT); /// Motor reverse pin

  Serial.begin(9600); // Open serial connection to the PC at 9600 bits/s
}

void loop()
{
  int colour; // Declare an integer variable to store the colour sensor reading

  colour = analogRead(0); // Read voltage from pin A0 as a number between 0-1023

  Serial.println(colour); // Print out the sensor reading in the Serial Monitor

  // Decide between two options based on colour sensor reading
  if (colour > 512)
  {
    // Motor forward with LED on
    digitalWrite(2, HIGH); // LED on (D2 set to 5V)
    digitalWrite(3, HIGH); // Motor forward
    digitalWrite(4, LOW);  //  
  }
  else
  {
    // Motor reverse with LED off
    digitalWrite(2, LOW);  // LED off (D2 set to 0V);
    digitalWrite(3, LOW);  // Motor reverse
    digitalWrite(4, HIGH); //  
  }
}

Posted in Uncategorized | Leave a comment

Motor control example

Useful information about the SN754410 integrated circuit (IC) can be found in its datasheet:

The datasheet for an electronic component contains lots of useful information for engineers who want to use the device in their designs. It generally includes basic information about pin layout and upper limits on voltage and current, as well as more detailed information about the electrical behaviour of the device.

//
// motor example program
// Written by Ted Burke
// Last updated 2 Feb 2022
//

void setup()
{
  pinMode(2, OUTPUT); // pin D2 is a digital output

  pinMode(3, OUTPUT); // pin D3: motor forward
  pinMode(4, OUTPUT); // pin D4: motor reverse
}

void loop()
{
  digitalWrite(2, LOW);  // LED off
  digitalWrite(3, HIGH); // motor forward
  digitalWrite(4, LOW);  // motor forward
  delay(3000); // 3 second delay
  
  digitalWrite(2, LOW);  // LED off
  digitalWrite(3, LOW);  // motor reverse
  digitalWrite(4, HIGH); // motor reverse
  delay(2000); // 2 second delay
  
  digitalWrite(2, HIGH); // LED on
  digitalWrite(3, LOW);  // motor stop
  digitalWrite(4, LOW);  // motor stop
  delay(1000); // 1 second delay
}
Posted in Uncategorized | Leave a comment

Track TT Competition – Semester 2 2021-22

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 2nd March 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 2-Mar-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