Fresh models were printed. The handle adapter was printed first because if this couldn't be made stable the whole tagger would fail. All the mechanical stress would be put on this one part. For this reason, a handle had not been designed, simply purchased. The purchased handle was already known to be able to take abuse and withstand mechanical stress. A simple model was used for the trigger but that part was less vital. Both worked as well as hoped.
A tricky part for every tagger has been the emitter portion. No one sells a ready-to-use emitter so they must always be built or designed by a manufacturer. Some of the details for this tagger had been decided, like what components would go on the forward array, so space was limited, very limited on the plastic. The graphic below shows a large hole, where the lens will be mounted, and a piece moving back and forth, where the IR LED will be mounted. The LED will be able to travel on three machine screws. This will allow the LED to be moved back and forth for focusing but it will also allow it to be aimed properly. These factors should allow for very well-tuned taggers.
The rest of the parts were printed. An accessory rail was purchased since printed rails need higher precision than my printer was capable of. They don't have to be the expensive rails, cheap ones for hobbyists like paintball or airsoft were purchased.
All the parts were modeled. Since a handle wasn't modeled there wasn't one shown on the drawing, otherwise, it would look like the complete tagger. Accessory rails were modeled as gray bars and two additional bars were added to the sides. The intention was to simply mount the steel, originally purchased for the previous revision, to the sides to add some weight and character.
A revision to the forward array now showed another part, a lens holder, which had been left out of the drawing above. Two pieces of plastic were needed to sandwich the lens between. The sleeves on the forward array and back array were lengthened since they needed more distance in order to catch a screw from the outside to keep them inserted. Friction was not enough to keep them in place.
With all the models looking good enough, it was time to start the hardware interfacing. A Pi0, not the new Wireless version, was given a breakout ribbon cable, LEDs, and switches. This breakout kit was ordered months ago since it was inexpensive, I never knew if I would have a use for it.
The code was started. The majority of code written had nothing to do with game mechanics, it was simply laying the groundwork for the inputs and outputs. Data over infrared was not attempted yet.
Running the code successfully felt like an accomplishment since Python programming has not been my focus. I'm still learning the nuances of Python and the Raspberry Pis hardware. I found out that a lot of trouble I had with the Pi-ano could have been fixed in code. Live and learn.
Printed parts being tested
A tricky part for every tagger has been the emitter portion. No one sells a ready-to-use emitter so they must always be built or designed by a manufacturer. Some of the details for this tagger had been decided, like what components would go on the forward array, so space was limited, very limited on the plastic. The graphic below shows a large hole, where the lens will be mounted, and a piece moving back and forth, where the IR LED will be mounted. The LED will be able to travel on three machine screws. This will allow the LED to be moved back and forth for focusing but it will also allow it to be aimed properly. These factors should allow for very well-tuned taggers.
Demonstration of the emitter adjustability
The rest of the parts were printed. An accessory rail was purchased since printed rails need higher precision than my printer was capable of. They don't have to be the expensive rails, cheap ones for hobbyists like paintball or airsoft were purchased.
Printed parts on PVC pipe
All the parts were modeled. Since a handle wasn't modeled there wasn't one shown on the drawing, otherwise, it would look like the complete tagger. Accessory rails were modeled as gray bars and two additional bars were added to the sides. The intention was to simply mount the steel, originally purchased for the previous revision, to the sides to add some weight and character.
A revision to the forward array now showed another part, a lens holder, which had been left out of the drawing above. Two pieces of plastic were needed to sandwich the lens between. The sleeves on the forward array and back array were lengthened since they needed more distance in order to catch a screw from the outside to keep them inserted. Friction was not enough to keep them in place.
Most complete collection of models
With all the models looking good enough, it was time to start the hardware interfacing. A Pi0, not the new Wireless version, was given a breakout ribbon cable, LEDs, and switches. This breakout kit was ordered months ago since it was inexpensive, I never knew if I would have a use for it.
Pi0 wired for testing
The code was started. The majority of code written had nothing to do with game mechanics, it was simply laying the groundwork for the inputs and outputs. Data over infrared was not attempted yet.
Code for testing and some game variables
Running the code successfully felt like an accomplishment since Python programming has not been my focus. I'm still learning the nuances of Python and the Raspberry Pis hardware. I found out that a lot of trouble I had with the Pi-ano could have been fixed in code. Live and learn.
Physical buttons and LEDs reacting while the program acknowledges
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