Main Page
|
Course Admin
|
Contest Rules
|
Project Resources
|
Team Info
|
Picture Gallery
|
Contact Info
 
  You are here: RoboTag Main Page > Contest Rules


  Contest Rules

The following list of rules and regulations are intended to ensure that all robots compete on a level playing field, and that the robots are compliant enough to play with each other. All robots that compete in the final competition must observe the rules and regulations or be subject to scoring penalties at the discretion of the judge(s).

In all matters of interpreting these rules before and during the contest, and in any issues not covered by these rules, the decisions of the official contest coordinator (Will Sitch) will be final. These rules were based on previous competitions coordinated by Prof. John Knight, and the Trinity College Fire Fighting competition.

The RoboTag rules and regulations - which will be dynamic for a while to allow contestants to point out loopholes (point them out to me!) - were last updated on Jan. 7, 2001 and are as follows:

  1. Contest Objective
  2. The Playing Field (Arena)
  3. Ambient Lighting
  4. Robot Operation
  5. Robot Size, Weight & Materials
  6. Sensors
  7. Electricity
  8. Cables
  9. Robot Identification and Marking
  10. Beacons and Detectors
  11. Tagging Specifications
  12. Tagging Implement Specifications
  13. Tag Detector Specifications
  14. RF Communication Specifications
  15. Bus Controller
  16. Running Order
  17. Scoring
  18. Types of Games
  19. Penalties
  20. Safety
  21. Interpreting the Rules
  22. Updated Rules and Regulations
  23. Location and Dates



1. Contest Objective

To build two (2) autonomous computer-controlled mobile robots that can play a revolving game of flashlight tag. The robots must conform to the tagging specifications in order to play with other robots. Both robots must be able to switch roles (predator/prey) upon a successful tag, handle the confusion of false tags, communicate with other robots, and exhibit aggressive movement algorithms.

The tagging games are meant to develop competing pursue/flee algorithms in a static environment, while focusing on robotic cooperation and communication to ensure both robots can appropriately handle both successful and false tags. The final goal of the project is to have a large number of robots play several different types of games together in the same arena.

Note that the main thrust of the competition is to develop a pair of robots that will compete with each other. Your team will be judged on how well your robots can play the game. A secondary goal is the round-robin 'Eliminator' game where one of your robots will play another robot from another team. Other games are being planned, but will just be for fun. (ie: they will not affect the competition score)



2. The Playing Field (Arena)

There is no official floor plan for the RoboTag event - robots will play in an arena that will be changed before each match. At the request of the contestants, robots will be allowed to wander around before the match begins in order to map the arena. A 5-minute time limit will be placed on the mapping attempt.

The floor of the arena will be either be several sheets of pressure-treated plywood, without laminate, or standard Carleton University floor tile. The arena may or may not be rectangular in shape, and will be limited by available floor space in the competition area. A good size would be 12' by 12'. Any seams in the floor will not be taped over, and robots must be able to handle both a height and width discontinuity of up to 1/8", if necessary. All attempts will be made to ensure the floor is flat, even, and clean. 1/4" dowel holes, used to anchor the floating wall segments, may be present in the floor material.

The walls of the structure will be made of wood and will be approximately 14" high. The walls will not be painted or laminated, but may be treated to dampen reflections. All attempts will be made to ensure the same wall material is used throughout the arena. Seams in the wall structure will be minimized wherever possible, and any cracks or holes will be filled in.

All passageways and corners will be at least 18" wide. There will be no moving parts within the arena. The arena will not be orthogonal, although the walls and obstacles will be planar (no curved surfaces). There will be no "dead ends" in the arena, so robots can always be approached from more than one direction.

The insertion points will be changed for each game, and will be assigned almost anywhere inside the arena. Robots attempting to map the arena before a game will be allowed to start mapping from the assigned insertion point. Starting positions will not be within line-of-sight of each other.

A preliminary location for the final contest is the Architecture Pit. An example of a possible floorplan is shown below. As further details regarding the arena location and materials become available, updates will be made to this section.


The arena will be changed for each game as follows:

  • Each team will consecutively play the "tag" game in each new arena
    • ie: team #1, #2 .. #6 plays in arena #1, then team #1, #2 .. plays in arena #2
    • As detailed in the scoring, teams will play three games of tag
  • All "eliminator" games will occur in the same arena



3. Ambient Lighting

The ambient lighting in the contest arena will obviously be difficult to predict until the location of the competition area has been determined. Contestants will be given time on the contest day to make ambient light level readings, if necessary, to calibrate their robots. The room will be lit with standard overhead flourescent lights.

Robots should be able to adapt rapidly to different lighting conditions, as there may be lights associated with video cameras (IR and visible light), flash bulbs (high intensity visible light), or other auxiliary incandescent or natural light.



4. Robot Operation

Once turned on, the robots must be self-controlled without any human intervention, that is, these are to be autonomous robots that operate without any remote control. No power or signal tether lines will be allowed.

The robots can bump into or touch the walls of the arena as they move about, but they are not allowed to mark or damage the walls in doing so. The robots cannot leave anything behind as they travel through the arena, and cannot make any marks on the floor of the arena that aid in navigation. Any robots that deliberately damages the contest arena will be disqualified. (this doesn't include accidental scratches or marks made while moving around)

Robots are not allowed to split into multiple robots, drop traps or snares, drag materials, or otherwise affect the competition arena or other robots in any way. Robots are NOT allowed to come into contact with other robots (low-speed accidents are anticipated and forgivable, but will be penalized if a culprit can be identified). Apart from standard tagging procedures, robots should not interfere with each other in ANY way, and therefore must not:

  • Use any form of physical contact to hinder another robot
  • Use any form of electromagnetic radiation to hinder another robot
  • Flood the communications channel in order to avoid being tagged
  • Alter the beacon in order to avoid being detected
  • Attempt to tag other robots when not "it"
  • Avoid correctly reporting a "tag"



5. Robot Size, Weight & Materials

The maximum size of each robot is 12" by 12" by 12" (30.5cm x 30.5cm x 30.5cm). Robots may not look over the walls of the arena, and must never extend themselves beyond 12" in any direction. All robots will be carefully measured and larger robots will be disqualified. If the contestants wish to add a flag, hat, or other purely decorative, non-functional items to their robot, they may exceed the height limitation. The item must have absolutely no effect on the operation of the robot.

If the robot has sensors or feelers, they will be counted as part of the robot and must not exceed the 12" width or height limitation. If tagging devices are mounted on movable platforms, they will be counted as part of the robot and must not extend past the 12" width or height maximum for the robot.

There are no restrictions on the weight of the robot. Please don't design a tank, as a high-speed collision with a wall or another robot will definitely cause damage, and the robot would definitely be disqualified.

There are no restrictions on the type of materials used in the construction of the robot, except in regards to safety, and that the robot must be designed and constructed by the contestants and cannot consist of a commercially available product or kit. Robots cannot be based around the modification of a commercially available product or kit. Robots CAN use commercially available products or kits if they are used as construction material. ie: don't use the Acme Robot Kit, but feel free to use some lego or meccano.

Carleton University will be providing equipment to the teams. Any parts which are surplus to the Universities other needs, or which can be legitimately borrowed from the labs or workshops, may be used. Some items will be available on a first-come first-served basis. Do not assume that you will be reimbursed for ANY costs you incur during the course of the project.



6. Sensors

There are no restrictions on the type of sensors that can be used as long as they do not violate any of the other rules and regulations. Specifically, they must not interfere with other robots. Using an agressive sonar sensor may confuse other robots using sonar ranging. Use of sonar sensors will be strongly discouraged due to the small size of the arena and the possible confusion of having multiple sonar-using robots playing the same game.

Contestants are not allowed to place any markers, beacons or reflectors on or around the arena. Robots are not allowed to use navigation cues external to the arena. Robots must conform to the IR beacon specifications, however.

While many film and video cameras use infared light as part of their automatic focusing system, all attempts will be made for cameras to use manual focusing and natural lighting in order to limit the exposure to external IR and intense light sources. Competitors should arrange to have an adjustable ambient level for sensor use.



7. Electricity

Robots must run from self-contained batteries. The batteries must not leak toxic chemicals if tipped over. Unsealed lead-acid batteries used in cars and motorcycles are not allowed.



8. Cables

There shall be no external power, control cables, or hoses attached to the robots.



9. Robot Identification and Marking

Each robot will have several identification numbers and should be appropriately marked. The identification numbers are as follows:

  • A "robot ID" number, which is unique for each robot and doesn't change
    (your robot will be identified with this number, and you will be called to participate in games based on this number)
  • An 8-bit "address", which is unique for each robot and doesn't change
    (this will be the address the bus controller will communicate with when sending your robot a message - set your receiver motherboard DIP switch to this 8-bit binary value)
  • A 3-bit "game ID" number, identifying each robot in a game
    (this number will be used to identify your robot to the bus controller, and will change for each game - use the hardware DIP switch on the MING motherboard)

Your robot must be clearly marked with the "robot ID" number. This 2-digit marking must consist of black numbers on a white background, with each character in a 1" by 1" space. The marking must be visible from above the robot.

The robot identification numbers are as follows:

Game Controller:
RobotID: 00; address: 0001 1010

Team SCUD:
RobotID: 01; beacon#: 3; address: 0000 1010
RobotID: 02; beacon#: 7; address: 0011 0101

The Gingerbread Man:
RobotID: 03; beacon#: 8; address: 0001 1001
RobotID: 04; beacon#: 3; address: 0010 0110

Team Gemini:
RobotID: 05; beacon#: 1; address: 0010 1000
RobotID: 06; beacon#: 6; address: 0001 0111

The Pharaohs:
RobotID: 07; beacon#: 4; address: 0000 0101
RobotID: 08; beacon#: 8; address: 0011 1010

Gizmo ART:
RobotID: 09; beacon#: 6; address: 0001 0100
RobotID: 10; beacon#: 2; address: 0010 1011

System F:
RobotID: 11; beacon#: 5; address: 0000 0010
RobotID: 12; beacon#: 1; address: 0011 1101

The "A" Team (Waterloo):
RobotID: 13; beacon#: 2; address: 0001 0001
RobotID: 14; beacon#: 5; address: 0010 1110

The Strange Brewbots (IEP):
RobotID: 15; beacon#: 7; address: 0010 0000
RobotID: 16; beacon#: 4; address: 0001 1111

WillBot:
RobotID: 17; beacon#: 8; address: 0010 1001



10. Beacons and Detectors

Each robot must have a fully compliant beacon, centrally mounted at the highest point of the robot. The beacon must not be obstructed. The beacon must adhere to the requirements outlined below:

  • emits ~940nm infrared light, projected in 360-degrees
  • detectable from 12'+ (approx. 60mA/LED required)
  • 56.8kHz square wave signal (as illustrated below)
  • beacon pulses meet the timing spec outlined below

Timing
Consecutively, each beacon must:

  • emit 6.25ms of modulated infrared light
    • 940nm light modulated at ~56.8kHz (55.5kHz is okay)
    • emitted 360-degrees around the robot
    • (minimum of 50% beam power in any direction)
    • must be detectable at 12+ feet with a standard device (50+mA/LED)
  • looks for infrared light from another robot
    • (for N blocks of 6.25ms each, N is assigned by course coordinator)
  • emit 6.25ms of modulated infrared light (as spec'd above)
  • looks for infrared light from another robot
    • (for 14-N blocks of 6.25ms each)
  • repeat the process
This process is further detailed
here. An example of the timing is shown below.

This can be shown in a chart form as follows:


The coloured blocks indicate when the particular robot is transmitting, and the white blocks indicate when the robot is 'looking'.

The above chart shows each robot transmitting from 0 to 6.25ms, then 'looking' for a differing amount of time before transmitting another 6.25ms pulse. This allows us to have eight robots in the same area that will ALWAYS detect each other within 100ms.



11. Tagging Specifications

Strict tagging specifications are used to ensure that a teams robots cannot only compete with each other, but also with other robots. If teams wish to use a different tagging specification, it may be permissable, but the group will not be able to fully participate in the final competition. Please consult the contest organizer for more information.

The tagging specifications involve the tagging implement (a focused flashlight or a small spotlight), the tag detectors (a number of phototransistors), and the RF communications (a 300MHz AM transmit/receive package). A bus controller will be used to maintain the communication channel and organize games.



12. Tagging Implement Specifications

As part of the tagging specifications, robots will attempt to tag each other using a focused beam of light. While the selection of light source and the beam tightening is left up to the individual groups, there are a number of specifications in regards to the size of the beam, the intensity of the light, the duration of pulse when firing, and the time between "shots".

The tagging implement specifications are as follows:

  • The device must project a white beam of light (a filter may be added later)
  • The beam of light has the following maximum diameters at these distances:
    • 3" wide at the source, 12" wide at 6', 24" wide at 12' (see diag. below)
  • All light outside the allowed area must be minimized as much as possible
  • The light must have less than 10000 candlepower intensity at 1 foot

The above illustration details the maximum robot sizes compared with the maximum beam width size at the source, 6 feet, and 12 feet.

Each pulse of light must adhere to the following specifications:

  • Each pulse of light can be generated for a maximum of 500 milliseconds
  • The beam cannot move more than 5 degrees in the x-y plane while on (see diag. below)
  • There are no beam movement restrictions in the z plane while on
  • The SHOT signal must be transmitted during the first XXX2 milliseconds of the pulse
  • There must be 3000 milliseconds inbetween each pulse of light (reloading)
  • Robots are not required to stop moving after firing a pulse of light

The above illustration details the maximum x-y beam swing while the beam is on, compared with the maximum robot sizes at the source, 6 feet, and 12 feet.



13. Tag Detector Specifications

As part of the tagging specifications, robots must be able to detect a burst of light from all different directions. While it might seem advantagous to design a tag detector that doesn't function especially well, making your robot harder to tag, remember that non-reported tags will draw a scoring penalty. Also try to keep in mind that while it may be competatively advantageous to ignore a successful tag, the contest objective is to correctly simulate a complete game.

The tag detector specifications are as follows:

  • Each robot must have a total of five detectors: (see diag. below)
    • Four detectors around the periphery, and one at the highest point of the robot
    • Each periphery detector must have a 180-degree unobstructed view
    • The top detector must have a 360-degree unobstructed view
  • Detectors should adapt to ambient light conditions
  • A possible "tag" consists of any one detector measuring light at twice the ambient intensity
  • Robots must immediately transmit a HIT! signal when detecting a possible tag
    • The signal must immediately follow the detection of a possible tag
    • The signal must be transmitted for XXX1 milliseconds
  • Robots are not required to stop moving if a possible tag is detected

The above illustration details the five tag detector placements on a robot. The size of the detectors are not to scale.



14. RF Communication Specifications

As part of the tagging specifications, robots will communicate using MING 300MHz serial-input AM Transmitters and Receivers. These parts are available from DigiKey, part numbers TX-99V3-ND and RE-99V3-ND, respectively. The transmitter and receiver will communicate with the MING encoder/decoder motherboards, DigiKey part numbers RE-01-ND and TX-01-ND, respectively. Information regarding these devices is available from Ming Microsystems. Note that you will need a 9-12V source for the RE-01 and TX-01 motherboards.

Use of the AM transmitters must be strictly regulated to ensure that a fair game is conducted. Robots that are not playing must NOT transmit on the shared 300MHz band, and competitors are warned that electronic warfare will result in disqualification. You should design a radio transmission "off" switch to avoid accidentally transmitting when not involved in a game.

The strict transmission specifications must be observed. A "bus controller" will transmit start/stop/other orders to the playing robots, and there are strict rules about which robot will be allowed to transmit what message at what time.

The encoder and decoder motherboards use an 8-bit address (set by a dip-switch) to deliver 4-bits of latched data. Each robot will have an individual 8-bit address which will be assigned by the course coordinator. The bus controller will have a fixed address.

What this means is that the robot's encoder motherboard (connected to the HandyBoard and the transmitter to send the data) will be fixed with the bus controller's address. The decoder motherboard (connected to the receiver and the HandyBoard to receive the data) will have a unique address.

The bus controller will have a receiver and decoder motherboard fixed to the bus controller's address. The bus controller will have an encoder and transmitter that can be changed for each transmission. This means that all competing robots communicate to the bus controller on one channel, and the bus controller will communicate with each robot directly.

Each robot will be assigned a three-bit game ID. This ID will be used to identify the robot to the bus controller, and will change for each game. This game ID would best be realized by a 3-position DIP switch that connects to the digital input pins of the transmitter.

The list of transmission codes are as follows:

  • from any robot to bus controller
    • b'xxx0' - HIT! - indicates that robot xxx (gameID) was tagged
      • this command also acts as an acknowledgement signal when STOP'd
    • b'xxx1' - SHOT - indicates that robot xxx (gameID) has fired a shot


  • from bus controller to a particular robot
    • b'0000' - STOP - tells the robot to immediately stop
    • b'0001' - STRT - tells the robot to start
    • b'0010' - PRED - indicates the robot is now a predator
    • b'0011' - PREY - indicates the robot is now a prey

It is important to note that two output bits are required from the microprocessor to the TX motherboard, and two input bits are required from the RE motherboard to the microprocessor. While powered, the TX motherboard transmits continuously, so an enable signal is required to enable/disable the transmitter.

You will need to somehow get the active-low enable signal onto the TX motherboard ~TE line. Check it out in the Holtek 12E datasheet. Because the transmitter would otherwise be transmitting all the time, we need to turn it on and off when transmitting to avoid flooding the communication channel.

The HIT! and SHOT signals must be transmitted for exact times. The SHOT signal must be transmitted for the first 250ms that the tagging implement is activated (detailed here). The HIT! signal must be transmitted for 250ms, exactly 250ms after being detected (detailed here).

The following is a list of states and allowed signals:

"predator" state

  • Controller (received) codes:
    • STRT - allows the robot to begin hunting for prey
    • STOP - indicates the robot should immediately stop
    • PRED - indicates the robot should immediately change state
    • PREY - indicates the robot should immediately change state
  • Self-originated (transmitted) codes:
    • when "started" and playing the game
      • HIT! - indicates the predator detected what it thinks is a tag
      • SHOT - indicates the predator fired a shot
    • when "stopped" and waiting to start
      • HIT! - acknowledges a command from the bus controller
"prey" state
  • Controller (received) codes:
    • STRT - allows the robot to begin evading the predator
    • STOP - indicates the robot should immediately stop
    • PRED - indicates the robot should immediately change state
    • PREY - indicates the robot should immediately change state
  • Self-originated (transmitted) codes:
    • when "started" and playing the game
      • HIT! - indicates the prey detected what it thinks is a tag
    • when "stopped" and waiting to start
      • HIT! - acknowledges a command from the bus controller

The communications protocol and specifications are designed to reduce the amount of radio traffic, allow for games with more than two robots, reduce the possibility of "false tags" caused by a camera's flash, and keep the game moving quickly.

An example of a scenario involving two robots and a bus controller is listed in the bus controller section.



15. Bus Controller

As detailed in the tagging specifications and the RF communication specifications, a bus controller will be implemented to assist the gameplay. The controller will be built with the same style MIT HandyBoard and RF communication boards that the contestants will use, and will be made available in the design lab at Carleton University for testing purposes.

An example of events involving the bus controller are as follows:

  • two robots are placed in the arena: robot #3 (id: 0), robot #14 (id: 1)
  • bus controller transmits a PRED command (0010) to robot #3
  • robot #3 transmits a HIT! (0000) command to acknowledge
  • bus controller transmits a PREY command (0011) to robot #14
  • robot #14 transmits a HIT! (0010) command to acknowledge
  • bus controller transmits a STRT command (0001) to robot #14
  • robot #14 transmits a HIT! (0010) command to acknowledge
  • bus controller pauses to give the prey a headstart
  • bus controller transmits a STRT command (0001) to robot #3
  • robot #3 transmits a HIT! (0000) command to acknowledge
  • ** gameplay starts **
  • robot #3 sees another robot (#14) and fires a short burst of light
  • robot #3 transmits SHOT (0001) to bus controller
  • robot #14 didn't detect a hit, and keeps running
  • robot #3 keeps chasing
  • robot #3 sees robot #14 again, fires, transmits SHOT (0001)
  • robot #14 was hit, and transmits HIT! (0010)
  • bus controller transmits a STOP command (0000) to robot #3
  • robot #3 transmits a HIT! (0000) command to acknowledge
  • bus controller transmits a STOP command (0000) to robot #14
  • robot #14 transmits a HIT! (0010) command to acknowledge
  • ...

Without communication to ensure that tags hit or missed, and without the ability to check/change the state of robots playing, the game would quickly degenerate. While the implementation of a bus controller may seem excessive, more complicated games would not be possible without an arbitrator to ensure robots remain in the correct states.



16. Running Order

Each team will compete consecutively in the competition, and while teams are encouraged to attempt minor tweaks to enhance their score, it is important to note that the arena will be changed for each round.



17. Scoring

Due to the complexity of the final events, a detailed scoring method has not yet been decided upon. There are a number of penalties that will be observed in the final score, however.

The preliminary scoring will work as follows:

  • The final score will consist of:
    • 10% Aesthetics
    • 30% Technical (difficulty of design/construction)
    • 60% Performance (competition score from the games)
  • The competition score will consist of:
    • 60% Team Performance (score from the Tag game, 20% per game)
    • 40% Competative Performance (score from the Eliminator game)
18. Types of Games

Several different types of games, all based around the tagging idea, will be played during the final competition. Only two game types will be judged for points, however, due to the complexity of judging a multi-robot game. The games are as follows:

  • Tag (60% of competition score)
    • Robot #1 from team A plays tag with robot #2 from team A
    • "tag" is the standard, revolving game played in schoolyards
    • Scoring is based on the quality of the game, minus any penalties
    • Three seperate games will be played in three different arenas
  • Round-robin Eliminator (40% of competition score)
    • Robot #1 from team A plays eliminator with robot #1 from team B
    • "eliminator" is where both robots act as predator/prey
    • The match winner is the robot that successfully tags the other robot first
    • The game winner is the robot that wins two matches (best-out-of-3)
    • The winners advance, round-robin style, to face other challengers
    • Scoring is based on the final ranking of the teams, minus any penalties
    • Penalties will be summed from each match! (ie: no cheating)
  • Group Tag (not scored)
    • One robot from teams A, B, C, and D play a game of "tag" together
    • "tag" is the standard, revolving game played in schoolyards
    • One robot will act as the predator, all three others will be prey
    • There is no scoring for these games, just bragging rights
  • Group Eliminator (not scored)
    • One robot from teams A, B, C, and D play a game of "eliminator" together
    • "eliminator" is where both robots act as predator/prey
    • Once robots have been tagged, they will be removed from the arena
    • The object of the game is to be the only remaining robot
    • There is no scoring for these games, just bragging rights
  • Group Hunt (not scored)
    • One robot from teams A, B, C, and D play a game of "hunt" together
    • "hunt" is where one robot remains the predator, and hunts the others
    • Once robots have been tagged, they will be removed from the arena
    • The object of the game is to "hunt" the prey as quickly as possible
    • There is no scoring for these games, just bragging rights



19. Penalties

The goal of the project is to design a pair of robots that will compete in a game of flashlight tag, and while there are several actions that are not completely illegal, they do have penalties associated with them. These penalties are usually a small price to pay for a pair of robots that successfully demonstrate an exciting game of tag.

The penalties are as follows:

  • Firing Anomolies
  • Non-reported Tags
    • If a judge verifies that a robot does not comply with the detector specifications, a penalty will be assessed against the team.
    • The penalty will be moderate (approx. 20% of the game points)
  • Low-velocity Robot Collisions
    • If a judge identifies a robot was primarily responsible for a low-velocity collision with another robot, a penalty will be assessed against both teams.
    • The penalty will be minor for the instigating robot (approx. 5% of the game points)
    • The penalty will be inconsequential for the other robot (approx. 2% of the game points)
  • High-velocity Robot Collisions
    • If a judge identifies a robot was primarily responsible for a high-velocity collision with another robot, a penalty will be assessed against both teams.
    • A high-velocity collision would be a collision that would cause the judge to wince
    • The penalty will be severe for the instigating robot (approx. 50% of the game points)
    • There will be no penalty for the other robot (& hopefully nothing is broken)
    • The instigating robot may be removed from the competition
  • Damaging the Arena
    • If a judge rules that a robot was responsible for wanton damage and destruction, and that the arena was solidly made, a penalty will be assessed against the team.
    • The penalty will be moderate (approx. 15% of the game points)



20. Safety

Contest judges or the contest coordinator may stop any robot at any time if they feel that it is performing, or is about to perform, any action that is dangerous or hazardous to people or equipment. No robot is allowed to use flammable, combustable, corrosive or radioactive process. Robots must not be programmed to hurt, maim, or kill innocent bystanders, project supervisors, or Jan Huissoon.



21. Interpreting the Rules

In all matters of interpreting these rules before and during the contest, and in any issues not covered by these rules, the decisions of the official contest coordinator (Will Sitch) will be final.



22. Updated Rules or Regulations

All registered contestants will be kept updated as to any rule changes and/or modifications that should arise between now and the contest. Updates will be immediately posted to the webpage.



23. Location and Dates

The contest will be held at Carleton University in Ottawa, Ontario, Canada on March 31, 2001. There will be time available on Friday March 30 for contestants to test their robots on the official arenas. As more specific information about the time and location of the contest is finalized, registered contestants will be notified and details will be posted to the webpage.


 
 
Main Page
|
Course Admin
|
Contest Rules
|
Project Resources
|
Team Info
|
Picture Gallery
|
Contact Info