Jump to content


Photo

Another Nerf-puter project

Started by truglodite, Apr 11 2017 04:34 PM
counter arduino computer modular

12 replies to this topic

#1 truglodite

truglodite

    Member

  • Members
  • 8 posts

Posted 11 April 2017 - 04:34 PM

*
POPULAR

Hey all, I recently rigged up this ammo counter/chrono/voltmeter/volt alarm gadget to add to my 9yo son's collection of nerf things (yes, he did ask me to put this circuit in his red dot scope). This project is more in line for the custom builders/diyers, especially those adept with Arduino stuff. The pinout is written at the top of the code (please note this is ported 328p specific). This should be more than enough info for those willing/able to make one of these to proceed with success. I hacked up one of my son's red dot scopes to house the circuit; this way it's modular for use with many guns. Although it would actually be easier to build in to a gun if you prefer (usually there's much more room than inside a rail attachment anyways).

 

What does it do: It constantly measures voltage and warns the shooter of a low battery (long beep + highlighted Voltage value). The low voltage alarm threshold is automatically set (for 2s and 3s lipo only, as coded... I may add more chemistry/cell count options if ppl need). It measures and stores FPS, RPM, and voltage for every dart fired from the clip. After the clip is empty, min/avg/max values are displayed for FPS/RPM/Volts, then tables are scrolled through showing all of the dart data in the order fired (max/mins values are highlighted). The method of timing used for FPS yields +-65nsec precision (~30000 counts for a 100FPS Elite dart... overkill really). More details are written in the comments in the top of the code. Other than that, it's a pretty dumb code that could be improved upon for your specific application (recode it for clip reed sensors, etc...)... and oh yeah, it does also show rounds left. It also does 1-beep&lights and LED when there's one round left... then 3beeps when empty... but what Nerf arduino thing doesn't do that?  ;)

 

How do we get FPS with 1 sensor: We know more or less the dart length, so we know how fast it is from how long it blocks a single sensor. This means variances in dart length go in to speed calculation. This is not a problem with 2 sensor FPS measurement, but the simplified hardware is well worth it as long as we understand we get some relative measurement errors due to dart length. Note that if we are really needing to go 2 sensors, we could wire both sensors to the same pin using a simple circuit, and change the code to interrupt on a pair of falling edges instead (vs a falling then a rising edge). Then a 2 sensor barrel can be used with this code no problem.

 

Some folks would say I'm not smart for sharing this code here. I personally hope that posting my open source code will result in it being 'borrowed'... hopefully we'll see these ideas make their way in to the current crop of commercially available ammo counters. Those folks making those things probably won't charge extra for these features anyways (takes less time to solder i2c than 7-seg anyways, LOL). That would be IMHO a big plus for Nerfers. I'm not putting time in to make/sell these myself, so please don't bother asking.

 

Items needed:

 

16MHz 5V 328p (I used a spare pro-mini)

OPL550 IR photo logic sensor

OP240a IR photo diode + 100ohm 1/4W resistor

128x64 I2C SSD1306 monochrome display

5V regulator (I used a spare LM7805 TO-220 sans heatsink... this circuit won't draw much over 100mA unless beeping (very brief & low duty), so the smaller package will also work fine)

0.1uF & 0.33uF output & input anti-ripple caps for the above regulator

5k6 & 3k3 resistors (10% is OK... you should be calibrating the vbattRatio anyways)

LED + limiting resistor (stay under 20mA since it's pin driven... I hacked the PCB in my son's red dot scope so I could wire in the stock LED instead... this involved cutting a trace and soldering some wires)

5V peizo buzzer (doesn't require tone libraries... 5V in = buzzzzzzz)

3@ momentary NO buttons

A power switch (again, 100mA... I hacked the stock switch on my son's red dot Nerf scope to work as my on/off switch)

Nerf Scope of choice (must obviously be big enough fit everything, and hacked as needed... or I guess you could just put it in a box and velcro it to your gun LOL)

Electrical project tools & sundries (connectors, solder & iron, dremel, hookup wire, hotglue, bits of proto PCB to mount your buttons & regulator, plastic/foam/glue/paint to make it aesthetically pleasing... whatever else you need to git'r'done)

 

Notes:

1- The 5k6 and 3k3 resistors make a voltage divider which is used to read your main Nerf battery. These values are good for batteries up to 13.4V, which should work for most. If you need more (like 4s), please adjust the values accordingly... vbattRatio will also have to be adjusted to match your divider.

 

2- A 100ohm current limiting resistor for the photo diode was needed for a 1 1/4" PVC barrel adaptor I made for mega darts. However this may result in a somewhat shorter doide life. If your sensor/diode will be less than 1" apart, 150ohm will work and will last forever.

 

Oh yeah baby... modular nerftec!!! The Deans plug taps in to the Stryfe's 2s lithium battery, for both power and voltage monitoring (velcro a tiny 2s to the front of the 'scope' for the springers)

20170411_132318.jpg

Erm, yeah the cat6 guts aren't sehksee, but it's what I had and I wanted my son to be able to use it on several guns (thus not built in to this Stryfe, which would be very sehksee... the Dupont plug in the middle is for 'built in' setups)

20170411_132337.jpg

 

Fugly breadboard action... that extra multi-turn poti is there just to simulate low battery alarms for testing/debugging (not installed):

20170407_094940.jpg

 

Dry fitting the guts in the scope before cutting and soldering the wires... my favorite part of any project is the dry fit/brainstorming stage:

20170407_172159.jpg

 

Shameless blocking splash screen, LOL...

20170411_132233.jpg

 

Setup mode after boot, we see live voltage, and can setup clip capacity and dart length...

20170411_132225.jpg

 

Fire mode, with live voltage, round counter, 1 round left LED (w/ single beep), 0 rounds left 3 beeps... (LED not on since there's 8 left in the clip for this pic)

I think the format of this screen can be improved upon by putting volts, fps, and rpm on the left, and enlarging the counter font so it reaches the bottom of the screen... todo list.

20170411_132254.jpg

 

Empty mode min/avg/max values, and live voltage... (yes this photo was shot before I fixed a typo bug in the avg& max voltages;) )

20170409_131706.jpg

 

Empty mode per dart data tables, with highlighted max/min values... yeah using the stock red LED for the 1round left/empty warning wasn't such a great idea (better off mounting a wide angle LED pointed toward the shooter's face, instead of using reflection of the stock LED off the foam paneling as I did)

20170409_134341.jpg

 

Some prototype 1-sensor housings, alongside a more traditional 2-sensor housing which I use for faster stuff (& to verify the 1-sensor thing works well)

20170407_125319.jpg

 

Here's the open source code (I'm compiling with Arduino 1.8.1):

Attached File  nerfGunU.zip   12.69KB   271 downloads

 

Spoiler
Hope this leads to a more Nerfy world... please, if you make yourself one I'd love to see pics!

 

Cheers,

Kevin


Edited by truglodite, 12 April 2017 - 05:43 PM.

  • 2
DIY Nerf Gun
Build your weapon Nerf Hopper
Add a magazine DIY Nerf Darts
Make some ammo Rules for Nerf Games
Learn the game Nerf War Schedule
Find a war Register your account
Join the forums

#2 Speedr117

Speedr117

    Member

  • Members
  • 57 posts

Posted 11 April 2017 - 04:50 PM

You stuffed an arduinuo into a nerf gun and didn't rig up an ammo counter. Balphsemy!
  • 0

#3 Pineapplepies

Pineapplepies

    Member

  • Members
  • 150 posts

Posted 11 April 2017 - 08:14 PM

Could you hook this up with a system, and or could you possibly code this to regulate the flywheel speeds and then furthermore control the thing with dials, that would make this FDL-2 but open source AND in a much smaller and versatile package which would be groundbreaking.

Edited by Pineapplepies, 11 April 2017 - 08:18 PM.

  • 0
<p>It's nerf or...... every other blaster brand that is better 

Darth nerf "I used to like the deploy, I ''twas but a learner, now I am the master" Obi buzz bee kenobi "only a master of nerf evil darth"

#4 Meaker VI

Meaker VI

    Member

  • Moderators
  • 1,192 posts

Posted 11 April 2017 - 09:30 PM

You stuffed an arduinuo into a nerf gun and didn't rig up an ammo counter. Balphsemy!

 

Pretty sure he has a counter in there too - the thing displays stats when the mag is empty. And one of the pictures shows dart count.

 

ED: Trug, this is pretty cool. I now kinda wish I'd have requested an IR sensor instead of a switch for my strayvan's counter. But I also would have probably gotten frustrated trying to get it programmed, so I'm not too miffed about it. Very good on you sharing this with the community, have you posted it to the nerf reddit?

 

ED 2: Oh, also, maybe throw a spoiler tag around that code as well.


Edited by Meaker VI, 11 April 2017 - 09:34 PM.

  • 0

#5 Speedr117

Speedr117

    Member

  • Members
  • 57 posts

Posted 12 April 2017 - 06:03 AM

Could you hook this up with a system, and or could you possibly code this to regulate the flywheel speeds and then furthermore control the thing with dials, that would make this FDL-2 but open source AND in a much smaller and versatile package which would be groundbreaking.

The fdl2 has dials for Firesign mode:semi, burst, full auto. And rof control. This cannot be done with the mechanicly pushed stryfe.
Whoops on the dart counter meaker. I thought that would have more attention as one of the coolest things.
  • 0

#6 truglodite

truglodite

    Member

  • Members
  • 8 posts

Posted 12 April 2017 - 01:49 PM

Yeah the work involved to make it a 'counter' was kind of trivial so I din't highlight that feature, but yeah that should be given more emphasis given it's the most important part of it. Also, I called it a 'round counter' in my post, not an 'ammo counter'. Rounds/ammo... same difference... though "round" seems like the more appropriate word. When I hear the word 'rounds', I'm thinking darts in a clip... when I hear the word 'ammo', I'm thinking darts in a scavengers bucket. IDK, LOL!!!

 

Pineapplepies, that's the first I've heard of 'FDL-2'... I'll have to look in to that. As far as controlling flywheel and feeder motors, I think both features would stay within range of the 328p. The select fire feeder motor thing would require probably 4 GPIOs (2 switches on a dial => bits for 4 modes, a feeder position switch, and motor driver output), and some simple logic fed from the remaining rounds variable. The flywheel could be controlled with a logic level FET (I'm a big fan of those) and analogWrite() I believe, since that uses Timer0 and the IR sensor is rigged to Timer1. Not 100% sure, but one problem I forsee with using Timer0 analogWrite(), is it may introduce some error in the RPM measurements (which gets micros() from Timer0). I think the errors would be negligible though, and if they weren't then maybe analogWrite() can be ported to use Timer2 for this project (I've ported a servo lib to another timer on an unrelated mega based project... wasn't that hard to do). With 3 analog inputs left, adding a 'flywheel speed dial' to that would be trivial.

 

Now my mind digs deeper down the rabbit hole... how about developing a PID loop to set actual FPS with the dial... that would be tight!!! We could get the flywheels smart... make them adjust up/down depending on what FPS is coming out the other end.

 

Anyhow, my time to work on code can be hit/miss depending on my work/family schedule. This is open source code, and I'm no expert coder. There are many things that could be done more clearly/efficiently, on top of adding desired features. I haven't shared on Nerf reddit... I figure one place is better than 2, and Nerf Haven seemed the best spot for this. That said, I might put this on github if there are other dudes wanting to work on it.

 

At the moment, it compiles around 84% progmem with the useless splashscreen, and 69% without the splashscreen. That leaves plenty of 'hard drive' to add features. SRAM is at 82% with or without the splashscreen, but so far the heap hasn't crashed on me. Before I was using float arrays, 90% SRAM, and that was crashing. So, when we start talking about adding more to the data tables (like current, etc...), or expanding the max clip size, we may run in to the limit of the 328p. That said, I've got some extra esp8266's. I think the code for that would be even simpler, since the ide has built in esp stuff that does better than 65nsec (so no need for input capture, and direct port probably won't be necessary). That would make for a much more compatible and easier to read code, but I enjoy squeezing blood from rocks.

 

Kevin


Edited by truglodite, 12 April 2017 - 02:57 PM.

  • 0

#7 truglodite

truglodite

    Member

  • Members
  • 8 posts

Posted 12 April 2017 - 02:08 PM

 

ED 2: Oh, also, maybe throw a spoiler tag around that code as well.

 Oh boy that code is a nasty scroll isn't it. I used the forum's built in "< >" code dialog and that's what it gave me. I was kind of hoping for less lines and a scrollbar... working on it now.

 

BTW, I noticed the pic of the "data table" I posted contains data from an unmodified starwars blaster I was testing (before modding). So it's not off by 20FPS... the 2s Stryfe is slinging around 70-80FPS. ;)

 

Kev

 

ED: Meaker VI, thanks for your post below about spoilers... done, and I just left the zipped .ino in there for convenience.


Edited by truglodite, 12 April 2017 - 05:39 PM.

  • 0

#8 Meaker VI

Meaker VI

    Member

  • Moderators
  • 1,192 posts

Posted 12 April 2017 - 02:24 PM

 Oh boy that code is a nasty scroll isn't it. I used the forum's built in "< >" code dialog and that's what it gave me. I was kind of hoping for less lines and a scrollbar... working on it now.

 

LOL, no success. Maybe I'll just attach it as a text file if that's cool.

 

Oh BTW, I noticed the pic of the "data table" I posted contains data from an unmodified starwars blaster I was testing (before modding). So it's not off by 20FPS... the 2s Stryfe is slinging around 70-80FPS. ;)

 

Kev

 

Should work like this:

 

Spoiler

 

Spoiler is in the 'special BBCode' button next to font.


  • 0

#9 Pineapplepies

Pineapplepies

    Member

  • Members
  • 150 posts

Posted 13 April 2017 - 04:40 PM

The fdl2 has dials for Firesign mode:semi, burst, full auto. And rof control. This cannot be done with the mechanicly pushed stryfe.
Whoops on the dart counter meaker. I thought that would have more attention as one of the coolest things.

  
That's not what I mean, I meant that it would be similar to the FDL-2, and as opposed to having electronically powered pusher, I mean this system or make a dial that can manipulate the voltage going to the motors, and modify the speeds, and potentially have something that can be control the fps.


Yeah the work involved to make it a 'counter' was kind of trivial so I din't highlight that feature, but yeah that should be given more emphasis given it's the most important part of it. Also, I called it a 'round counter' in my post, not an 'ammo counter'. Rounds/ammo... same difference... though "round" seems like the more appropriate word. When I hear the word 'rounds', I'm thinking darts in a clip... when I hear the word 'ammo', I'm thinking darts in a scavengers bucket. IDK, LOL!!!
 
Pineapplepies, that's the first I've heard of 'FDL-2'... I'll have to look in to that. As far as controlling flywheel and feeder motors, I think both features would stay within range of the 328p. The select fire feeder motor thing would require probably 4 GPIOs (2 switches on a dial => bits for 4 modes, a feeder position switch, and motor driver output), and some simple logic fed from the remaining rounds variable. The flywheel could be controlled with a logic level FET (I'm a big fan of those) and analogWrite() I believe, since that uses Timer0 and the IR sensor is rigged to Timer1. Not 100% sure, but one problem I forsee with using Timer0 analogWrite(), is it may introduce some error in the RPM measurements (which gets micros() from Timer0). I think the errors would be negligible though, and if they weren't then maybe analogWrite() can be ported to use Timer2 for this project (I've ported a servo lib to another timer on an unrelated mega based project... wasn't that hard to do). With 3 analog inputs left, adding a 'flywheel speed dial' to that would be trivial.
 
Now my mind digs deeper down the rabbit hole... how about developing a PID loop to set actual FPS with the dial... that would be tight!!! We could get the flywheels smart... make them adjust up/down depending on what FPS is coming out the other end.
 
Anyhow, my time to work on code can be hit/miss depending on my work/family schedule. This is open source code, and I'm no expert coder. There are many things that could be done more clearly/efficiently, on top of adding desired features. I haven't shared on Nerf reddit... I figure one place is better than 2, and Nerf Haven seemed the best spot for this. That said, I might put this on github if there are other dudes wanting to work on it.
 
At the moment, it compiles around 84% progmem with the useless splashscreen, and 69% without the splashscreen. That leaves plenty of 'hard drive' to add features. SRAM is at 82% with or without the splashscreen, but so far the heap hasn't crashed on me. Before I was using float arrays, 90% SRAM, and that was crashing. So, when we start talking about adding more to the data tables (like current, etc...), or expanding the max clip size, we may run in to the limit of the 328p. That said, I've got some extra esp8266's. I think the code for that would be even simpler, since the ide has built in esp stuff that does better than 65nsec (so no need for input capture, and direct port probably won't be necessary). That would make for a much more compatible and easier to read code, but I enjoy squeezing blood from rocks.
 
Kevin

Yes, that's what I meant, I mean find a way to allow this to control or post how you can control the speeds of the motors. Some people may not think it's useful, but when you get into the area of FDL-2 performance you may not want to give some nasty welts so you can turn down the speed. My other idea with that was that if you are in a really long battle you can limit the voltage going to the motors, so if you only get one 2s pack you don't burn through your battery too fast. And yes, that's exactly what I meant, finding a way to control fps.
  • 0
<p>It's nerf or...... every other blaster brand that is better 

Darth nerf "I used to like the deploy, I ''twas but a learner, now I am the master" Obi buzz bee kenobi "only a master of nerf evil darth"

#10 Ming Batt

Ming Batt

    Member

  • Members
  • 12 posts

Posted 15 April 2017 - 11:32 PM

I've been working on the exact same thing, ammo counter/chrono/voltmeter all in one, (https://github.com/etnom/ming-batt) and even in that same optic, haha. I just haven't found the time to work on the hardware. Mine includes a wireless barrel attachment and optic, but this is amazing!

 

It must've been a pain writing all the display functions and initialization, I use two libraries for a similar display, in case it may come in handy:

- https://github.com/a...afruit_SSD1306:OLED driver library

- https://github.com/a...it-GFX-Library:Graphics library


  • 0

#11 blasterdad

blasterdad

    Member

  • Members
  • 8 posts

Posted 17 April 2017 - 07:45 PM

Fantastic work. Excellent use of the Red dot sight, it finally has a purpose... definitely picking one (a few) of those up now.


  • 0

#12 truglodite

truglodite

    Member

  • Members
  • 8 posts

Posted 02 May 2017 - 05:47 PM

I've been working on the exact same thing, ammo counter/chrono/voltmeter all in one, (https://github.com/etnom/ming-batt) and even in that same optic, haha. I just haven't found the time to work on the hardware. Mine includes a wireless barrel attachment and optic, but this is amazing!

 

It must've been a pain writing all the display functions and initialization, I use two libraries for a similar display, in case it may come in handy:

- https://github.com/a...afruit_SSD1306:OLED driver library

- https://github.com/a...it-GFX-Library:Graphics library

Nice! I am jealous of how well organized your code is (my 'training' if you call it that, is very informal... a googled expansion from one semester of C in college LOL). The optic setup is almost ideal isn't it? I found it after researching several 'Arduino chrono' projects. I honestly got a bit worried when it started to get a weak signal at >1.25" separation, but it's just a nerf gun. So upping forward current to near max continuous rating was an easy decision, LOL. Screw playing with discretes, analog amps, ...bah! Optek stuff rocks!

 

I'm curious to see how you went about the wireless part. I've got an assortment of spare 'robotic' radios I could play with (433,2.4,SPI,UART,ESP82xx, etc)... I thought it would be cool to develop a system that has various attachments (barrel sensors, red dot screens, etc) and guns (firing mechanisms, motors, etc) essentially 'talking to each other'. Unfortunately that would take more time that I alone have to put in to this stuff. Although if someone is already started, I don't mind donating some lines of code. This idea could be developed to include GPS, inter-troop data sharing... a modern comprehensive networked battle system for nerfers LOL! How cool would that be, to glance down at your phone and see your friendly positions, last known enemy positions, friendly ammo counts, etc? That would be a real advantage IMHO... and I bet there are nerfer clans who would demand to have it if it was available.

 

OTOH, a simple 'look ma no wires' application could be fun... for example a pair of 328's linked via NRF radios (or whatevers ya' got on hand), one reading the sensor and processing data, the other displaying data on a screen (and possibly responding to muzzle data for physical 'on gun' functions... ex. killing flywheels when the clip is empty). Nobody likes wires, and this idea could remain modular (just keep the gun specific code on the gun uC, and leave the muzzle code generic so it works with many gun/sight setups). My guess is something like that would be enough to meet all needs of the average nerfer. 

 

So many ideas, so little time. I think my next step on this project will be to play with controlling my son's stryfe motors using AnalogWrite(). That's a more reasonable goal to reach in a couple free weekend hours (whenever that comes next).

 

Kevin


  • 0

#13 Ming Batt

Ming Batt

    Member

  • Members
  • 12 posts

Posted 02 May 2017 - 11:58 PM

Nice! I am jealous of how well organized your code is (my 'training' if you call it that, is very informal... a googled expansion from one semester of C in college LOL). The optic setup is almost ideal isn't it? I found it after researching several 'Arduino chrono' projects. I honestly got a bit worried when it started to get a weak signal at >1.25" separation, but it's just a nerf gun. So upping forward current to near max continuous rating was an easy decision, LOL. Screw playing with discretes, analog amps, ...bah! Optek stuff rocks!

 

I'm curious to see how you went about the wireless part. I've got an assortment of spare 'robotic' radios I could play with (433,2.4,SPI,UART,ESP82xx, etc)... I thought it would be cool to develop a system that has various attachments (barrel sensors, red dot screens, etc) and guns (firing mechanisms, motors, etc) essentially 'talking to each other'. Unfortunately that would take more time that I alone have to put in to this stuff. Although if someone is already started, I don't mind donating some lines of code. This idea could be developed to include GPS, inter-troop data sharing... a modern comprehensive networked battle system for nerfers LOL! How cool would that be, to glance down at your phone and see your friendly positions, last known enemy positions, friendly ammo counts, etc? That would be a real advantage IMHO... and I bet there are nerfer clans who would demand to have it if it was available.

 

OTOH, a simple 'look ma no wires' application could be fun... for example a pair of 328's linked via NRF radios (or whatevers ya' got on hand), one reading the sensor and processing data, the other displaying data on a screen (and possibly responding to muzzle data for physical 'on gun' functions... ex. killing flywheels when the clip is empty). Nobody likes wires, and this idea could remain modular (just keep the gun specific code on the gun uC, and leave the muzzle code generic so it works with many gun/sight setups). My guess is something like that would be enough to meet all needs of the average nerfer. 

 

So many ideas, so little time. I think my next step on this project will be to play with controlling my son's stryfe motors using AnalogWrite(). That's a more reasonable goal to reach in a couple free weekend hours (whenever that comes next).

 

Kevin

 

Haha thanks! I actually do not have too much formal training myself, just self-taught starting at 12, and it's been 4 years since that. Not too much opportunity at my school either, just got rejected from the AP Computer Science course at my school for "knowing too much". Not too much experience in electronics or electrical engineering though (learning from Khan Academy), although I do know a bit of the basics. I'm always learning more, though, so I can make something even cooler in the future. The display's weird angling makes display placement much more difficult and awkward for, but the size seem

 

Your code doesn't look too bad at all, it's just some aspects really annoy me, like the single-line variable declaration, although that's needed for the comments, and the "uint8_t", and some lengthy variable declarations. Maybe it's just the JavaScript developer in me, but C/C++ really annoys me sometimes. Personal preference, I suggest to move that display code into another file. Once it's written, it basically acts as a library, so you won't need to edit it. It helps make your code a lot more readable and manageable. Conventionally speaking, the declarations are usually placed in a separate C++ file, <fileName>.h, and the logic and the definitions are placed in another file, <fileName>.cpp. A lot of the code is looks repetitive, but it looks necessary for that nice data table.

 

I really like how you read the voltage after every shot! I never thought of that. A lot of my electronics work is also still a lesson in physics as well, since the only physics course I took was probably designed for middle schoolers.

 

To implement the wireless feature, I have some 433MHz radio transmitter and receiver modules, which are super Arduino-friendly. Transmitting data between two Arduinos can get a bit messy, and I'm still learning, but so far, I've been more interested in the physics of electromagnetic radiation than radio communication, both of which stemmed from learning how to use the the radio modules. I'm trying to learn how UART, SPI, I2C, and other communication protocols function as well. I think it would ultimately be easier if I hook up a couple ESP8266's that I have to some FireBase real-time database or something, or probably some sort of local server. This is where my backend experience is useful! In IoT! With this...I think you can see where I'm going. Remote control NERF blaster army, and more. I would like to develop something like a network battle system, using the ESP's since that would give me an excuse to practice more React and React Native. You just gave me an awesome idea! I think that would have some implementation into VR as well...

 

Expanding upon the idea of modularity, I also strive for that as well. It's always the vast permutations which keeps things interesting. I've made a barrel attachment which houses an IR gate, but communicates to the microcontroller with wires. I want to design a circuit which communicates to the microcontroller, specifically in the blaster, wirelessly. The end goal where the IR gate data encapsulated within the barrel attachment would be able to connect to different blasters, so all that's necessary is the correct hardware within the blaster to be able to communicate and connect to the barrel attachment. Communicating with a separate microcontroller in the some sort of optic which houses the display would be the simplest tasks, since only integers, or at most strings, would be transferred. Actually, now that I think of it, strings would not be necessary at all, just some boolean and number values. Also, leaving all the inputs on the optic housing the display, such as select fire modes, magazine size toggle button, or whatever blaster functions desired to be manipulated, would be much easier labor-wise, as the display housing could ultimately be 3d printed to specific specifications.

 

A completely modular, wireless blaster attachment system would be the coolest! Hope to get all of that done over the summer. Planning on working on some sort of quadcopter with onboard blasters, just for fun, and maybe for college acceptance, if personal projects even mean anything.


Edited by Ming Batt, 02 May 2017 - 11:59 PM.

  • 0
Back to Modifications

Also tagged with one or more of these keywords: counter, arduino, computer, modular

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

  1. NerfHaven
  2. → Community Forums
  3. → Modifications
  4. Terms of Service and Privacy Policy
  5. Code of Conduct ·