Laser tag is a fun group activity that is commonly viewed as a rare outing activity. Often times, those wanting to play laser tag must travel far distances and pay exorbitant amounts of money to play for a limited time. Purchasing laser guns on Amazon is extremely expensive for a set of only a few laser guns. Our product is a low cost alternative to the traditional laser gun and target vest game. Also included in the system is a pair of stationary targets which dynamically respond when hit by lasers. Furthermore, this system supports a wide variety of game modes. Examples of game modes are team battle, 1v1 duel, single player target practice, and capture the flag. Players use the gun to shoot lasers at opponents’ vests. In addition, each gun-vest pair will track statistics that are easily accessible on the internet. Internet connectivity is optional so the system can be used anywhere, anytime. As the devices are connected with Bluetooth, scores can be kept track of on a microprocessor and accessed by connecting the device to a computer.
Code (requires lots of library downloads) https://drive.google.com/file/d/0ByE0gOOPc7NPankzcWplLVFLb3c/view?usp=sharing
When designing the architecture of the project, it was decided that the game controller would have complete control over the responses of the gun. The guns would have no control over game logic. They would only be able to shoot, and report to the controller that they had been hit by a particular gun. Doing so made debugging easier, as every action the guns took could be traced back to the controller. If a gun incorrectly stated that it had been affected by friendly fire, the problem was with the controller and not the gun. And once a fix was found, it only needed to be uploaded to the controller to be applied for all guns.
An “event based” communications methodology was chosen over a regularly scheduled “update”. A clear event log of a game was desired, which would be difficult to implement if multiple events happened to a gun in between updates. Additionally, the system would be more responsive with an event based system as the guns needed the controller to update themselves for the player.
Laser: The laser consists of a 3W RGB LED fitted with a 30 degree viewing angle lens. The lens focuses the LED and turns into more of a laser. The LED consists of 3 monocolor LEDs, each on its own circuit. The LED is powered through RGB LED driver, which provides the voltage and 330 mA current necessary to power the RGB. It is requires a minimum of 6V, but is fed directly from a 9V battery. The driver allows for the arduino to PWM the individual LEDs with significantly less current to control the brightness.
Laser detection: Laser detection is done via an RGB color sensor. The two guns manufactured have 2 different color sensors, due to a lack of available hardware. However, the basic premise is the same as they both experience spikes in their output values when exposed to the laser. This spike is then read and used to determine the color of the laser shooting the sensor. From there, the team of the shooting gun is known and can be sent to the game controller. Communication with the arduino is done via I2C.
LCD Display: An LCD display and adafruit LCD backpack is used to provide visual feedback of the game state to the players. The display is powered by 5V from the arduino and receives data over I2C. A full LCD display was chosen over a few LEDs on the gun due to the fact that laser tag requires the user to be aware of a lot of information, such as sync status, team score, and personal score which cannot be easily displayed by LEDs.
Radio Communication: The radio module used was the nRF24L0L module, which functions both as a transmitter and receiver. It was used to communicate with the game controller. The reason why RF was chosen as the communication method was its increased range, ability to support multiple channels, and easier user experience. Bluetooth typically has a range of 10m, which is suboptimal for laser tag. The modules used have a range of 30m, which is more adequate. Bluetooth communication can only be used between paired object. This puts a severe limitation on scalability, meaning that every new gun added to a controller required another physical module. RF does not suffer from this, as it communications have a destination ID that can be changed regularly. Finally, RF was preferred over wifi because a laser tag system should not require the hassle of internet access to run. RF was chosen as a compromise between the short-ranged paired communication of bluetooth and the broad communication of wifi.
Power supply: The power supply for the gun is a 9V battery which fits within the gun casing. A 9V battery was chosen because the RGB driver required at least 6V to function. The main power line features a split, with a set of wires going directly to the driver and the mail line goes to a connector for the arduino. Battery use does not seem to be high, as the laser is not used for very long in a game.
LCD: The LCD display on the controller was wired similarly to the displays on the guns. An LCD was deemed necessary due to the inherent role of the controller. The game controller needed to display a wide variety of information to the user depending on the state of the game, and an LCD display was the simplest way to do that.
Pushbuttons: At a bare minimum, the game controller needed to be able to assign guns to different teams and start the game. A particular gun could be synced to a team by pressing the trigger for the current accepting team. The current accepting team can be changed by pressing one of the buttons. The second button allows the game to be started.
RF Communication: There were two basic communication “protocols” involved, with one from the controller to a gun, and vice versa. Due to the limitations of the RF library used, only “long” data types could be successfully transmitted. The addresses did not need to be specified by the protocol, as communication was sent over “pipes” created in the library, with a transmitter “reading” from a static address while another was “writing” to the same address. The signal sent from the controller to the guns involved 8 digits, with the first 4 digits being the game time, the next 2 being the action for the gun, and the last 2 being any data needed the gun needed for the action. An example of this might be 02451102, meaning at 0245 seconds into the game, the receiving gun would need to register that it had been hit by an enemy gun(11), which was on team (02), or blue. The gun would then need to update its record of how many time it had been shot and update the LCD display. The gun to controller protocol was much simpler, consisting of 2 digits. The first for the shooter, and the second for the action. The only times in which a gun needed to notify the game controller was when it had been shot. An example of this might be 21, meaning that the gun registered a blue laser(2), and that it had been shot by it(1). The game controller would then determine if an enemy had hit the sending gun or if it was a case of friendly fire, update its records, and transmit the necessary commands to the guns.
Standard Cplusplus: A library bringing most of C++’s data structures into Arduino. In particular, the Vector and Pair data structures were used. The vector was used to have a variable length array, something not provided by the arduino library. Pair was used to keep the address of a to-be-sent message with the message itself for the controller.
RF24: The library used to facilitate radio communication. Communication is organized into “pipes”. A speaker opens a “writing pipe” with a specified address while a listener opens a “reading pipe” also with the same address. A module can only have 1 writing pipe open at once, and up to 5 reading pipes open. The library does have some quirks, such as that the radio must start and stop listening every time a writing pipe with a different address is opened.
Adafruit_LiquidCrystal: A library which facilitates sending messages to the LCD.
Adafruit_TCS34725: A library used for the TCS rgb color sensor, which returns very accurate results but takes a long time to get a reading.
SFE_ISL29125: A library used for the SFE rgb color sensor, which is not nearly as accurate as the TCS and is slightly faster. This library was used because a second TCS rgb color sensor was unable to be obtained.
Due to the limitations of the radio library, the radio addresses of the guns needed to be hard-coded and loaded into each of the guns. That aside, the guns do receive initial information from the controller about which team they are on, and what their ID for the game is. Likewise, the controller will only send messages to guns which have been added for a particular game. The sole limitation on the number of guns possible in a particular game is the maximum 5 reading pipes from the radio library, but there are possible workarounds. The syncing suffers from some reliability issues, and can occasionally crash the controller. However, simply restarting the system solves such issues.