When I first started a laser tag project in 2011 a lot of the process revolved around using inexpensive infrared remotes to set game parameters. For example, the players may have been assigned to a particular team with one button and the game might start at the press of a different button. At the time, I used remotes intended for camera control because they were what I had on hand and they only cost a few dollars but they only had a few buttons. Now, one US dollar can purchase a 21-button remote that comes with a receiver and many people have already written code for these exact remotes. Due to the mass-production of these remotes, finding a replacement is simple. Infrared remotes are still a useful tool but they don’t have to be the primary controller in this system.
Physical inputs, two buttons, in this case, were added for prototyping. These will eventually be the trigger switch and reset button. When the buttons are pressed they each send a unique code and they send another unique code when released. In this way, the computer will not have to constantly poll the Arduino to look for a pressed switch. This is in contrast to the analog inputs which have to be polled.
When data is polled it is called explicit messaging but when data is transmitted only when necessary it is called implicit messaging. An analogy could be mobile email apps. Some phone apps check for new mail every XX minutes while some wait for the server to notify the app. There are advantages to each system.
Individually addressable LEDs were attached to one of the controllers and controlled through serial data and IR commands. In the picture below, the lights are trying to look like a police car.
For the Color/Touch project I decided to utilize a much different method of color designation. It seemed appropriate for this project two. The problem with assigning a random color to each of three LEDs is that when you combine three random intensities of red, green, and blue you end up with everything looking like it’s basically white. Especially when the colors are changing rapidly. One way to correct this is to select only two of the lights and activate them randomly but this makes it possible that both numbers are low and the light is simply off. The method for the Color/Touch was to scale the intensities based on a simple chart. All the relevant colors are seen from 1-191, starting with red and ending with red again. If someone were to step through all the colors, in order, then repeat the process, the LEDs would seem to cycle through the rainbow colors endlessly and smoothly. From 192-255 there are varying intensities of white. The chart below shows the breakdown of the colors.
Since it would someday be necessary for the Arduino firmware to communicate with a Raspberry Pi, one was connected. Setting up the Arduino Micro on a Windows machine was tedious. On a Linux machine there was no process, it simply worked. The most difficult part of connecting the Micro to a Pi was figuring out which serial port to connect. This was easy because the Arduino software, which installs with a single command, automatically found it. Linux as an OS was very appealing today.
Something ridiculous happened. I suspect it was an issue with the IRremote library. When the fourth byte sent to the IRremote library was over 128 or more (>= 0x80) the previous byte would be decremented. This tiny issue took an entire evening to locate and program a countermeasure. Granted, the countermeasure was a simple if() statement but the problem was wholly unexpected.
Remotes used to send specific signals
Physical inputs, two buttons, in this case, were added for prototyping. These will eventually be the trigger switch and reset button. When the buttons are pressed they each send a unique code and they send another unique code when released. In this way, the computer will not have to constantly poll the Arduino to look for a pressed switch. This is in contrast to the analog inputs which have to be polled.
When data is polled it is called explicit messaging but when data is transmitted only when necessary it is called implicit messaging. An analogy could be mobile email apps. Some phone apps check for new mail every XX minutes while some wait for the server to notify the app. There are advantages to each system.
Physical buttons for testing inputs and their matching serial data
Individually addressable LEDs were attached to one of the controllers and controlled through serial data and IR commands. In the picture below, the lights are trying to look like a police car.
LEDs trying to imitate police lights
For the Color/Touch project I decided to utilize a much different method of color designation. It seemed appropriate for this project two. The problem with assigning a random color to each of three LEDs is that when you combine three random intensities of red, green, and blue you end up with everything looking like it’s basically white. Especially when the colors are changing rapidly. One way to correct this is to select only two of the lights and activate them randomly but this makes it possible that both numbers are low and the light is simply off. The method for the Color/Touch was to scale the intensities based on a simple chart. All the relevant colors are seen from 1-191, starting with red and ending with red again. If someone were to step through all the colors, in order, then repeat the process, the LEDs would seem to cycle through the rainbow colors endlessly and smoothly. From 192-255 there are varying intensities of white. The chart below shows the breakdown of the colors.
Description of color scale
Since it would someday be necessary for the Arduino firmware to communicate with a Raspberry Pi, one was connected. Setting up the Arduino Micro on a Windows machine was tedious. On a Linux machine there was no process, it simply worked. The most difficult part of connecting the Micro to a Pi was figuring out which serial port to connect. This was easy because the Arduino software, which installs with a single command, automatically found it. Linux as an OS was very appealing today.
Receiving serial data on a Raspberry Pi 0
Something ridiculous happened. I suspect it was an issue with the IRremote library. When the fourth byte sent to the IRremote library was over 128 or more (>= 0x80) the previous byte would be decremented. This tiny issue took an entire evening to locate and program a countermeasure. Granted, the countermeasure was a simple if() statement but the problem was wholly unexpected.
Seriously‽
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