truglodite

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

Sorry I'm resurrecting this, but I have $.02 to add...

I don't think this argument between belt vs flywheel is as cut and dry as it may seem after reading this thread. I think some arguments are not adhering to the laws of science, and some are just not focusing their scientific eye on the right spot. So I'll start off with our working equation (how a nerf dart accelerates using flywheels/belts... any friction energy transfer method really):

Work on the dart ~ Ffriction * distance ~ u*N*A*d

u = coefficient of friction (I think 99.9% dynamic, however I talk about static below)

N = normal force (ie how hard you squeeze the dart)

A = surface contact area between the conveyor (flywheel edge, belt, whatever) and projectile

d = distance over which the frictional force is applied (can be very large for a belt)

... a very simplified version, but it is enough to make my point about flywheel velocity and size. Flywheel size and RPM aren't even part of this equation, or at least they have very little to do with the dynamic friction available to accelerate our dart. A bigger flywheel may increase A a little bit, you can squeeze the dart more for a bigger N, and use rubber coated ribs to maximize u... but I think a belt will win this battle more often than not. With belts, the friction occurs over a much longer distance, and is applied over a significantly larger area. The distance force is applied in a belt is easy to design, and relatively unlimited compared to flywheels (you can only make the flywheel so big...much easier to play with the distance of the front/rear pulleys on a belt). Of course with a belt, the same leverage over N can be had by squeezing the dart, and coatings can modify u... so those variables don't really enter this argument.

With so much extra leverage over d and A, belts already seem very interesting to me. Then when I think about controlling the belt in a way that allows the static friction to come to play, available force could go way up! That might be doable with a clutch/flywheel accelerated belt, hehe! Yeah you could also use a secondary flywheel and clutch to similarly accelerate a flywheel drive, but with the flywheel drives tiny d (and huge inertia... we won't get into that here), slipping is pretty much the best way to go. The big d of a belt means there may be enough time to maintain a static coefficient (inertia? shoot, those are some super slick lightweight parts in modern RC road race cars that would certainly spool up easier than a big ole flywheel). This would be so cool to see IMHO!

Also, at first glance I think an experimental belt drive may be doable without access to a mill & lathe. I know in the RC car hobby there are a lot of examples of belts running stable at very high speeds, and of course gearbox/motor setups that could be adapted somewhat easily in a typical Nerf hacker's garage. I haven't ran the numbers nor do I have equipment to experiment with, but I'm guessing if the dart emerges anwhere near an RC car's belt velocity, it would be very impressive. I think (due to radial vibrations), a similarly performing belt system could be much quieter than flywheel. Battery life would of course be reduced vs flywheel, but I think something like 20min trigger on time should be easy to do (should be enough, right?... extra lipos in the bag?). Yeah fast RC cars only last 10min, but they're also putting out a c**p ton more work. Spitting foam those setups might last hours. Anyhow, I just don't see battery life as a major design consideration here, but I'm not a veteran nerf warrior. I'm sure there are good arguments to have long battery life in the field. Please share them with us.

Anyhow, that's probably more TLDR than $.02, but I wanted to give my support to those interested in developing a belt nerf drive. It has favorable design trades that IMHO are worth looking in to. I'm fairly confident my arguments are well supported by physics, however I'm no nerf engineering genius (just an old Wolverine BSAE who loves to tinker with everything). Please share your arguments on the belt vs flywheel subject... maybe we'll end up with something to show at the end of it all. Maybe it'll fail, but I think it's got enough merit to deserve a go.

Kevin

 

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.

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

I love cherry switches for my arcade controllers, and imagine they'd also have a quicker feel on a nerf gun. You could use a fet or relay to mitigate impedance concerns with a cherry switch... get the best of both worlds.

Regarding lipos, be aware that many affordable lipos on the market are not correctly rated (ie watch out for the 10C lipos marked as 30C, etc... forum research is good to weed them out).

When it comes to lipo chargers, whatever you get make sure it will balance charge with decent precision (+-0.01V), and preferably get one that can do storage charging.

There are a ton of cheapo lipo balance chargers that do a sloppy +-0.2V balance, which will result in way out of spec operation and wear out your packs very quickly (few months vs 5yrs for example). Unfortunately, balancing precision is not a very big marketing term, so only the higher end chargers are likely to actually state the spec (rc forums are a good place for such data). Storage charging is underrated, and it does wonders for the lifetime & performance of your lipos. If you haven't heard of storage charging, google it... it's how they keep lipos going forever in satellites & stuff.

There's also amp and volt rating... you'll want one that can handle the voltage and amps you might need for your lipos. If you ever want to try 4s in your nerf guns, you should invest in a 4s capable charger now. For amps, lipos are best charged at a rate of 1C max... ex a 600mAh: 0.6Ah x 1C = 0.6A charge. Some newer lipo packs are rated for higher C charges, but they all last much longer charging at 1C or less (high C charge lipos are for things like RC, where a pack lasts just 5-10min and waiting 1hr to charge can suck the life out of an outing). Since nerf guns don't blow through packs, you won't need to invest in 'fast charge lipos', nor a bigger (amps wise) charger to go with them.

I have a bunch of iCharger's I swear by (i have a pair of 106b+'s, and a 210... paid for a 106b, helped the company with early D+ mode development, and they send me the other 2 free as a thanks), but they aren't cheap. I also do A LOT more than just charge nerf gun packs with it (rc/arduino/powerwheels/etc... lipo/nimh/pb/lithium... 50mAh to 10000mAh... 1s to 6s). They have rediculous specs for the $$$, really (like getting a legit $600 charger for $100). Someone else may want to chime in here on some more affordable models that meet typical nerf needs (just beware of the above mentioned specs).

Hope this helps,

Kev