RoboTag^TM

• Of specific note is the possibility of using an inverse IRDA like encoding for the laser beam bullet packet.  If this method is chosen, target hardware built for IRDA encoding most likely won't have a chance of working.  It would require circuit changes to handle the different encoding over the dynamic range of the input.
• This file is under constant revision.  New versions may show up at any time.

• The wavelength bands I chose for both the Laser and the Target LEDs were chosen due to the availability of inexpensive parts, and the availability of commonly available optical filters.  Specifically the green band's end points were chosen to conform to standard green pas filters.  The red laser band was chosen based on available red laser diodes, and it's ability to be band limited by a red pass filter combined with an IR cutoff filter.
• Laser output minimums and maximums were chosen based on a survey of many different laser modules minimum / maximum outputs.
• The data rate was chosen after looking at what modulation frequencies available inexpensive modulatable laser modules could produce.  Of specific note, quantity one from one manufacturer is only $48.00 US, $32.00 US from another.  While I realize that the data rate for the laser modulation is beyond most laser pointers ability to produce.  It was chosen based more on reliability of transmission than on cost of parts, or ease of hack ability.

• Competitive game for autonomous robots to play against each other and as teams.
• Scoring is based on how many hits your robot achieves on other robots, and how many times the your robot is hit by other robots and it's self.
• Specification of minimum sensor levels.
• Specification of minimum abilities to withstand external noise like ambient light from many different types of sources like incandescent lights, sunlight, fluorescent lights, IR distance sensors on robots, etc.
• Specification of laser properties such as minimum and maximum optical output power, maximum beam diameter and divergence.
• Specification of robot size and shape properties.
• Specification of data transfer format and method between robot and scoring computer / device.
• Specification of data retention needed by the robot for scoring.

My visions on how each part of the game plays.

1. Opto-Mechanical aspects of game play.
1. Each robot has a set of target sensors arranged around the diameter of the robot.
2. Each robot has a laser.
3. The robot is in charge of aiming the laser at a target and firing it.
4. The target senses a data stream modulated on the laser beam.
5. That data stream identifies the robot that is shooting the laser.
2. Game Setup.
1. Game setup is done by using a PDA to assign each robot it's ID# and configure the game parameters into it.
2. The time clock on the robot is synchronized at this time, with the one on the PDA, and start and end times are assigned for the game.
3. Score tracking.
1. Each robot records what hits it receives on it's target sensors.
2. If it can't identify the source of the hit, it tallies one hit up to the unknown counter.
4. Score tallying.
1. At the end of play, the PDA is again used for collecting the counts from each robot, and to make a score sheet.

Contest Environment Specifications

1. Rules shall be interpreted by the spirit of the rule, not by rules layering.
2. Contests will take place in a Xm by Ym playing field.
1. X and Y will be at least 3 meters and less than 10 meters.)
3. Expert Level playing fields are unlimited in size with the exception of practicality.
4. Walls of at least 25 cm high will surround the playing field.
5. There will be randomly placed walls and obstructions in the interior of the playing field for robots to maneuver and shoot around.  These walls and obstructions will be the same height as the perimeter walls. Intermediate and Expert levels of play will allow there to be low (sub 25 cm) walls and obstructions.
1. For Beginner and Intermediate playing levels, walls of at least 25 cm high will be considered infinitely high and not allowed to be shot over.
6. Expert play levels allow for an increasing more complex play environment.  I envision multiple floor levels, ramps, steps, conveyer belts, pits, cliffs, doors, etc.

---

Contest Specifications

1. The object is to score as many hits as possible on opponent robots, and have as few hits as possible scored against one's self.
2. In Team play games, robots are not allowed to hit other members on their team.  Points will be deducted for hitting your own team players.
3. In both the Intermediate and Expert levels there is the possibility of adding in neutral players that are not allowed to be hit.  Hitting a neutral player will deduct points from your score.
4. Shooting over the walls and obstructions is not allowed at the beginner levels of play.  Intermediate and expert levels allow shooting over sub 25 cm walls and obstructions.

---

Robot Specifications (Limitations)

1. I'm considering a requirement that robots be as non-reflective as possible of th 625 nm to 680 nm light as possible.  This is a safedy issue related to laser reflection striking spectators.  (It looks like the other possibility is restricting laser output to Class II lasers with a maximum of 1 mW output.)  Safety to me is an important issue.
1. A few methods could be emploied to meet this requirement.
1. Absorbtion of light stricking surface.
2. Broad dispersion.  Light stricking surface is relected off in a wide dispersion patern.
2. The reason I'me considering this is due to my interpritations of CDRH regulations for Class II and Class IIIa laser devices, as well as thos governing laser light shows.
2. Robots playing the game must fit within a 20 cm cube with all appendages spread out to maximum.
1. There may be provision for different classes of robots.
1. One sugestion is to have a Wheeled versus walking class distinction.
2. Another class distinction sugested is to have an analog circuit only class.
1. Needless to say, the RoboTag game sircuits would have to be digital to be able to do their job.  It is possible to make a "backpack" type sensor circuit with laser firing circuit that would allow the rest of the robott to be analog. It would need a simple on/off set of status indicator lines to talk to the robot.
1. My first draft circuit was basicaly what ould be needed.
1. One output line per sensor to interupt on hits to that sensor.
2. A input line to tell when to put the laser into aiming mode.
3. A trigger input for firing the laser.
4. An output line to tell when the game is on.
5. An output line to tell when it is permissible to explore the mase to learn it before game play begins.
3. I've had one responce requesting a "Transformer" glass.
2. Currently there is no class distinction, just a max size limit.
3. In the Beginner and Intermediate levels of play robots shall behave as if there is a ceiling 25 cm off the ground.  For the Expert level there are no ceilings except for those formed by hard surfaces.
4. The exit point where the laser leaves the robot may not go outside a vertical box with it's corners bounded by the sensor target's photo diodes.
1. This is to prevent someone from making an arm that can be moved around a corner and shoot another robot without exposing at least one sensor to the robot being shot at.
2. Note: if you wish to place your laser on an arm, you may, but the arm must have a target sensor on it that can be targeted by a robot that can be hit by that laser.
1. Rules for placement of the sensors on the arm need to be worked out.
2. I personally feel that in a situation like this that the laser output port should be within a box bounded by targets.
5. Targets shall be placed such that no part of the robot eclipses them.
1. There may be an exception for an arm properly covered with target sensors.
2. This is not to be counted on.
6. At this time arms are not allowed unless that have target sensors on the top, bottom, left, right, and front faces of the farthest out segment.
1. Arms are not allowed at the beginner levels of play.
7. Robots in all levels of play shall not have any constructions on their exterior that are designed to confuse the location of the Target.

Robot to Scoring Computer

1. The device that is responsible for setting up all the Robots before the game, and collecting the scores after shall be referred to as the Game Programmer.
2. The physical layer protocol shall be IRDA.
1. IRDA was chosen because it allows for easy hookup without the problems of ESD, ground mismatches, etc.  It is also a relatively mature computer standard.
2. Hardware that implements the physical layer is readily available.
3. Software has been written that is available in the public domain to handle the software part of IRDA.  It can be used as a model for implementing the IRDA code on the Robot.
3. To simplify data communication, data transferred after IRDA link has established communication, will be simplified into a common byte structure.
1. Control / Header information will have bit 7 set, while data information will not have bit 7 set.
2. In all packets, bit 6 will be used to signify the first byte, bit 5 will signify the last.
3. Control Codes, Data, and Addresses will be transferred in bits 4 through 0.
4. The twelve bit counters will be broken into three 4 bit nibbles. Most significant nibble will be transferred first.  Before each counter the ID # associated with the counter will be transferred.
5. When downloading data, the controller on the robot will stream the full set of scores starting with Robot ID #0 and finishing with #30.
1. No optimization for smaller numbers of robots playing at one time.
2. Again, this is to simplify coding.
6. Types of packets will include:
1. Clear Hit Counters - This tells the robot to set all counters to 0.
2. Clear Game Parameters - This tells the robot to forget game parameters.
3. Setup Robot ID - Configures the Robot ID.
4. Setup Timing - Configures the Start and Ending times for a game.
5. Synchronize Timing - Synchronizes the onboard clock to the clock in the Game Programmer.
6. Setup Game Parameters - Configures the game parameters telling the robot what type of game it will be.
7. Transfer Hit Counters - Tells the robot to transfer the full set of hit counter values to the Game Programmer.
8. Tell data protocol level. - Tells the Robot to tell the Game Programmer what version of the data transfer protocol it is using.
1. Note it is the responsibility of the Game Programmer to be able to deal with all versions of the data transfer protocol.
9. {Plus others as necessary}

---

Data Tracking Specifications

1. Robots will be given a Robot ID of 1 to 30.  This will be the number they transmit over the modulated laser beam as part of the "bullet".
2. There must be data storage for at least 30 12 bit counters.
1. One for each robot.
2. One generic catch all for hits from unknown robot.
3. This allows for 30 robots to play against each other.
3. The robot shall be able to have it's Sender ID assigned at the time of play by the Game Programmer.
4. The robot shall have an internal clock for timing the game.  It shall be capable of being synchronized with the configuration device for start and end time of the round.

---

Laser Specifications

1. The Laser device shall be referred to as the "Laser Gun".
2. The beam of laser light will be referred to as the "Laser Beam".
3. The Laser Beam has two non off excitation states.  The "Aiming State" is used for allowing the user to target in on the subject.  The "Bullet State" is a state where the laser beam is modulated to send the ID of the robot shooting the Laser Gun.
4. The optical output of the laser shall confrom to CDRH regulations covering Class II or Class IIIa lasers, with the following additional restrictions.
1. Maximum optical output of 5.0 mW.
2. Minimum optical power output of 0.5 mW.
3. Optical output wavelength centered in the 625 nm to 675 nm range. (red light wavelength band).
4. Laser beam diameter shall be no larger than 10 mm when it leaves the robot.
5. Laser beam divergence is allow to be no greater than ?%. (Beam dot size smaller than ?mm at ?m.)
5. Sender ID will be transmitted at a 115000 baud, ±5%. Same as a standard high baud rate serial port.
6. There are two proposed methods of encoding the data into the laser light.
1. Proposal one is to use an IRDA compatiple pulse stream.
1. Data would be coded as a 3 of 16 clock width light pulse, with position determining logic "0" or "1" state.
2. In order to switch from aiming to pulsed data stream, the laser would have to go off for a preset time to allow the sensor circutry to adjust to ambient light levels.
1. I've tentatively set the guard period to 5ms.
3. The circuit needed to pick out the laser data stream is a relatively standard one.  Roughly equivalent to the one used for IRDA, but easier to make due to not needing such low frequency responce.  An OP-AMP filter/amplifyer circuit with output compairator is all that is needed.  Tune the circuit to ignore anything below 100kHz or so.  This will get rid of ambient light interference from most lights, and robot sensors.
2. Proposal two is to use a reverse IRDA pulse stream.
1. Data would be coded as 3 of 16 clock width dark pulse (laser off), with position determining logic "0" or "1" state.
2. The advantage is no guard time is needed between laser aiming mode and bullet mode.
3. There will need to be a minimum on time before the data stream is sent.  This is to allow for the ambient light cancelation circutry to adjust to the laser light intensity.
1. I've tenitively set the period to 5ms.
4. This seriously effects the laser sensing filter circuit.  It still has the Ambient Light cancelation circuit, to filter out everything below 100kHz, but it needs to look for quick dips in the light level instead of peaks.
7. The Sender ID data packet will consist of five three byte sequences.  Byte one will be value "10101010" binary. #2 will be the Sender ID, #3 will be the Sender ID XORed with a constant. (A value for the constant needs to be determined that allows there greatest ability to detect collisions.)  The three byte sequence will be repeated 5 times with no gaps between them.

---

Target / Receiver Specifications

1. The Sensor that detects the Laser light shall be known as "Target Sensor".
2. The LEDs that are used to provide a reference to the location of the Target Sensor are to be known as "Target LEDs".
3. Target Sensors shall be sensitive to a 0.5 mW output laser with the maximum beam divergence allowed over a 180 degree angle.
4. The Target shall have 4 green LEDs in the 500 nm to 570 nm wavelength range with at minimum 5 mCd (? Lux) output each over a 120 Degree viewing angle.
5. The target LEDs will be strobed in a 50% duty cycle at a frequency of 15 Hz.
6. Target LEDs will be arranged in a square pattern with side dimensions from 10 cm to 25 cm.
1. The allowance for square side variance is so people don't try to judge distance based on square size.
7. The Target Sensor shall be located at the exact center of the 4 Target LEDs.
8. The receiver shall look at all 5 three byte sequences, throw out the ones with errors, and take the Sender ID of the best match of the rest and increment the hits from for that Sender ID.  Failing that it shall chalk up a hit to the unknown ID number 0.
9. Each receiver circuit shall be treated as a separate circuit.  A laser hit on one shall not interfere with a laser hit on any of the others.
1. Due to the difficulties inherit with trying to separate out multiple simultaneous hits targeted on one sensor, it isn't required that sensors be able to handle that case.  With good electrical design and simple software coding, it should still be possible for sequences that start atleast 4 character lengths appart.