The incoming data was previously transmitted in hexadecimal, which was a remnant of the IRremote code which used hex as the default. This was abandoned on the Python software side since it became confusing and difficult to parse. This should make it easier for anyone writing their own software to understand the transmissions and create their own games.
The firmware was given a list of names, previously written for the Arduino-based laser tag game, and those names could be retrieved by the software by sending a number. The returned names were intended to be fantastical-sounding names associated with each tagger. Since this list would be consistent with all players, it was possible to show that some hit by tagger 13 would report being hit by "Mackinosha" and everyone else hit by that same tagger would report being shot by the same player.
In addition to having specific names, different teams can be assigned with an infrared remote. Each team has an associated number and color. The color corresponds to a special scale devised to avoid impure colors. Impure colors would be those which appear faint or whiteish. Fifteen teams were selected based on the remote being used which had fifteen colored buttons. These colors were evenly distributed across the color spectrum, starting at red and ending back at red.
Since teams were selectable, it seemed logical that shots from the same team could be ignored. The appearance of "Friendly fire" on the printout indicated that a shot was received from a teammate. These shots would not disable the player and neither would take damage. These factors could be changed in software if someone wished to design a game where friendly fire received partial damage.
When the known bugs were worked out of the firmware and the software had all the known kinks worked out a video was taken to demonstrate the operation of the game. It was run as though an actual game were starting where the player is given a team color, takes damage and is eventually eliminated.
Software reached a point where it was ready to be tested. Not all of the work for the hardware was done, most importantly, no testing had been done with the infrared emitter and lens. A visible light LED was temporarily installed to make it easy to see how well the LED was positioned. The animation below shows a red dot on the wall growing slightly larger and fainter as it was moved away from the wall.
Incoming IR transmission and the location of each numeral
The firmware was given a list of names, previously written for the Arduino-based laser tag game, and those names could be retrieved by the software by sending a number. The returned names were intended to be fantastical-sounding names associated with each tagger. Since this list would be consistent with all players, it was possible to show that some hit by tagger 13 would report being hit by "Mackinosha" and everyone else hit by that same tagger would report being shot by the same player.
Code for asking the tagger about a specific player's name
In addition to having specific names, different teams can be assigned with an infrared remote. Each team has an associated number and color. The color corresponds to a special scale devised to avoid impure colors. Impure colors would be those which appear faint or whiteish. Fifteen teams were selected based on the remote being used which had fifteen colored buttons. These colors were evenly distributed across the color spectrum, starting at red and ending back at red.
Changing teams and colors
Since teams were selectable, it seemed logical that shots from the same team could be ignored. The appearance of "Friendly fire" on the printout indicated that a shot was received from a teammate. These shots would not disable the player and neither would take damage. These factors could be changed in software if someone wished to design a game where friendly fire received partial damage.
Printout showing valid shows and friendly fire
When the known bugs were worked out of the firmware and the software had all the known kinks worked out a video was taken to demonstrate the operation of the game. It was run as though an actual game were starting where the player is given a team color, takes damage and is eventually eliminated.
Video demonstration of laser tag game
Software reached a point where it was ready to be tested. Not all of the work for the hardware was done, most importantly, no testing had been done with the infrared emitter and lens. A visible light LED was temporarily installed to make it easy to see how well the LED was positioned. The animation below shows a red dot on the wall growing slightly larger and fainter as it was moved away from the wall.
Demonstrating focus
The rest of the weekly summaries have been arranged by date.
Disclaimer for http://24hourengineer.blogspot.com/
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
This disclaimer must be intact and whole. This disclaimer must be included if a project is distributed.
All information in this blog, or linked by this blog, are not to be taken as advice or solicitation. Anyone attempting to replicate, in whole or in part, is responsible for the outcome and procedure. Any loss of functionality, money, property or similar, is the responsibility of those involved in the replication.
All digital communication regarding the email address 24hourengineer@gmail.com becomes the intellectual property of Brian McEvoy. Any information contained within these messages may be distributed or retained at the discretion of Brian McEvoy. Any email sent to this address, or any email account owned by Brian McEvoy, cannot be used to claim property or assets.
Comments to the blog may be utilized or erased at the discretion of the owner. No one posting may claim property or assets based on their post.
This blog, including pictures and text, is copyright to Brian McEvoy.
Comments
Post a Comment