Narfduino has been making it’s way into Software Defined Blasters originally designed for other control systems. While this is in no way a bad thing from my perspective, please remember to honour the licenses of any community designed blasters you are modifying.
Software Defined Foam Dart Blasters
Using Narfduino to drive Flywheels
I released a YouTube video demonstrating the use of Narfduino driving flywheels with motor breaking. It’s fairly straight forward, go and check it out!
Solenoids or Gearbox pushers?
Once upon a time, a few months ago, solenoids were considered to be something mythical, reserved for the most hard-core modder, and for those crazy enough to build with them, they imparted god-like Nerfing prowess and serious street cred.
These days though, it seems that the Nerf hobby is awash with solenoid conversions. I’ve released conversion kits for Stryfe, Swordfish, Dominator, Rapidstrike, and even a Jolt. FTW have kits for Retaliator, and have work in progress for Deploy and Longstrike. And some dude even got one to work in a Hurricane – of all things!
Surely this means something, right? Solenoids are the be-all and end-all of pusher technology?
No.
Like everything, solenoids have their advantages and disadvantages. I suspect their recent popularity is a result of conversion kits (such as mine), 3d printed blasters built for them, and recent releases of the miniturised smart electronics used to drive them – such as Suild’s kits, and my own software defined blaster configurations. Perhaps the mainstream “newness” is also drawing people into using them. Who knows?
Jumping straight into it, here is the high level view of solenoids in a blaster
Advantages
- They are easy to wire up
- They are fairly easy to get working
- They give very distinctive tactile and audio feedback
- They are immune to gearbox stripping, burn-out, and locked pushers
- When programmed well, you can sustain up to 16 DPS
- You need a single switch and wire for semi-auto use
Disadvantages
- They are quite large and need room in front, and to the rear
- They are heavy
- They are hard to perfect operation
- They impart less force and are more likely to skip darts
- They are only reliable for 8-10 DPS without closed-circuit monitoring
- You need electronic control systems for auto / burst / select fire
There are a couple of high-level themes that stand out.
Wiring
Solenoids are generally easy to wire. In a normal situation, you would use a single mosfet to control it, and something to generate a pulse to activate the mosfet. On the other hand, in a software controlled blaster, a motorised pusher requires a half-h-bridge. This is not a trivial prospect, generally requiring 3 mosfets, with their pullup/down resistors, and the flyback diode.
This is a half-h-bridge for a Woozi:
Of course with the release of Narfduino and my independant half-h-bridge board, this is much less of an issue and presents no wiring difference. Of course, building your own electronics is still an issue.
Control System
Solenoids are easy to write firmware for. You pulse the mosfet gate on and off, and that’s it. However they are not easy to write good firmware for. The thing about solenoids is that their pushing power is directly proportional to the battery voltage, and it matters a lot. The behavior of a 12v solenoid on a fully charged 4s battery and a depleted 3s battery is significantly different, and this needs to be catered for.
I have had suggestions to use a buck converter to power a solenoid, but I don’t believe it’s a great solution for these reasons:
- A buck will only reduce voltage to a set point. If you are trying to keep a constant 12v on your solenoid using a 3s battery, it’s not going to happen. You need to use a 4s battery – and you will lose out on the performance that extra voltage gives
- Your buck will need to be appropriately sized to prevent failure, and therefore will take additional space in an already cramped blaster
Instead, a variety of sensors can be employed to adjust your solenoid performance. Return and full extension switches will provide excellent feedback, and monitoring the battery voltage and adjusting the pulse time works quite well.
How does this stack up to a motorised pusher? It’s much of a muchness. Good half-bridge pusher control is equally complex, and has it’s fair share of challenges. They are just different challenges. However if you fuck up half-bridge control, it’s entirely possible to blow your mosfets and control system… So there is more real risk involved.
Speed
Once you’re above 10dps, does it really matter? In an 18 stick mag, you’ll deplete your darts in 1.8 seconds instead of 1.5 or 1.2 seconds. Where a solenoid is really good at is a consistant, responsive pushing speed. Your first dart out will occur at the same rate as your 10th.
A gearbox pusher needs time for the motor to accelerate and get to operating speed. For a neo 180 pusher motor, it may not be a big deal. But for honeybadgers on 3s, it takes a few shots before you’re hitting over 20dps.
And for a motorised pusher, actually decelerating the motor is a thing too. So for a high speed motor, by the time you take into account acceleration and deceleration times, a single shot might take quite a while to come out, and the time to be ready for the next shot will be a little slow too. However, because the pusher isn’t being constantly stopped and started (like a solenoid), sustained DPS is higher than a solenoid can usually achieve.
Tactile Feel
There’s no getting past the feel of a solenoid. The fact is you love it, or you hate it. They’re dak-dak-dak noisy, and they have kick. You know you’ve fired a dart, because your blaster is feeding that back to you. There is nothing even close to this on a motorised pusher. Personally, I love it.
Reliability
This is interesting… The failure mode of a solenoid pusher and a motorised pusher is quite different. For a motorised pusher, if the dart jams, the pusher will generally as well. So you will need software controls to detect this, and stop the pusher’s drive mosfet. Failure to do this will lead to motor burnout, gearbox stripping, and all sorts of nasty stuff.
Of all motorised pushers, Toruk’s T19 has the most unique control system and mechanical setup. First – it uses a stepper motor (similar to original FDL-2’s) and is therefore immune to stall-induced burnout, and secondly it’s control system won’t just detect the jam, it will reverse the pusher back into it’s home position and will attempt to strike the dart again. Wow.
The failure mode of a solenoid is vastly different. First, they don’t stall. A jam has no impact on the longevity of the solenoid. And secondly, they auto-home under spring force. So by default they will keep beating at a dart until it either goes through the flywheels, or you stop. A solenoid’s weakness is actually it being quite weak. They have very little mechanical advantage and in the retracted position, they are at their weakest. A poor tune will mean there is not enough power applied to the solenoid, and it will jam. It may take a few shots to fire a single dart in this state, or it may be so poorly tuned that it’s no exerting any force on the dart.
In general, you could say that the reliability of a motorised pusher equates to longevity of it’s parts, and not buying new motors & gearboxes. Reliability of a solenoid pusher equates to a consistent play experience. An unreliable solenoid pusher setup won’t cost you money, but it will cost you tags.
Conclusion
Well is there a conclusion? Not really. One is like coffee, one is like tea. It’s all a matter of personal preference. If you have not tried a solenoid pusher yet, I would encourage it. IMO, they are super fun and very engaging. But having a solenoid in your blaster will not make you a Nerfing demi-god. Sorry!
Debouncing… Tying your shoelaces in the electronics world.
There’s a lot to get excited about when programming stuff. Tough challenges, wily algorithms, and the feeling of success when it all comes together. When adding electro-mechanical aspects, this also brings a rather theoretical concept, and makes it a physical reality…
But like everything in life, there are chores. You have to wash the dishes. You have to wash your underwear. You have to tie your shoelaces. And you have to debounce.
For those who don’t know what debouncing is, well simply it’s compensating for bouncing. And bouncing is the world being imperfect, practical, and not cleanly theoretical. When you close your switch, there is never a perfect electrical connection.. It takes time to settle. Us humans aren’t fast enough to see what happens, but your microcontroller is. They are very sensitive to this, and will think you have pressed the button a few times really quickly…
And it looks like this:
You can see in this graph at least 4 falling edges before the signal settles. You see one button press, Arduino sees 4.
This manifests in many ways… An ammo counter counting extra darts. A pusher firing less darts. And the bane of all existence – a rotary encoder that skips and does other weird shit.
And so there are as many ways to combat this (i.e. debounce) as tying your shoes. There are quick and dirty knots, I tie fresh double knots every time I wear shoes. Other people have them loose and just slide their heathen feet in and out. And some people don’t tie their shoes at all….
Ultimately it doesn’t matter how you debounce, as long as you do (*). However, if you don’t debounce, like the idiot who walks around with untied shoes, you will eventually fall flat on your face.
(*) Fine print: Of course there are circumstances where it’s not necessary. Sometimes just merely detecting an edge is good enough. Other times you’re not worried about the edge, but rather the logic level at a particular point in time. But in general, things like trigger’s, pusher return switches, UI buttons, etc will benefit from it.
What are some ways of doing it?
- Software using a library (like bounce2.h)
- Software using your own algorithms (e.g. watching for interrupts and waiting a few milliseconds… Or shifting the pin register bit values through a serial buffer)
- Hardware by using your ADC (i.e. analogRead)… Please don’t do this, you heathens.
- Hardware by monitoring both your switch’s NO and NC position, and considering the input true when both lines agree
- Hardware by using a series of resistors and/or capacitors. I have actually released a board that encapsulates this for 4 channels.
Each way has their advantages and disadvantages. You can get away with any of the above techniques on a simple switch or a button, but if you are using rotary encoders, your options are rather limited. I have had luck with both hardware solutions and attaching the encoder to an interrupt, and I have also had luck with a pure software solution.
The only thing I would say about the solutions is that using an ADC to sample the average pin voltage, as opposed to using something to watch for a rising / falling edge is barely better than not debouncing at all. ADC in an Arduino is slow. When you perform an analogRead, the function sets up the *single* ADC to sample your pin through the onboard multiplexer. It then waits a period of time, while the ADC gets about collecting and averaging these readings. An register flag is used to indicate when the reading is complete, and your execution then resumes. If you are constantly polling a pin using analogRead, your code will be slow.
The only time that you should be using the ADC to read a digital switch is if you are multiplexing a number of switches on a single pin using a voltage divider network… There are other ways to do this (such as using a shift register), but given the additional complexity, this is a reasonable compromise. However this is another story for another time.
Narfduino – Warning (a.k.a RTFM)
Narfduino is a pretty handy gadget. You get all the configurability of an Arduino Nano, with the convenience of having some Nerf specific circuitry installed on the board.
Normally, using an Arduino is a fairly benign thing. You apply power, and as long as you’re not silly, they work fairly well. But if you stuff up, the worst you’ll get is a bit of magic smoke.
Narfduino is a little different. It has an integrated Half-H-Bridge and runs on a LiPO battery. If you aren’t careful with it, it’s possible to cause the mosfets to directly short the LiPO battery you are using. If you are lucky, a violent explosion will be your prize. If you are unlucky, your LiPO battery will pop as well. And your computer, if you have it attached. And any ESC you have attached.
Therefore, when using the Half-H-Bridge hardware, exercise caution.
Luckily, I have a library that takes all the headache out of using a half-bridge and makes it fairly safe to use. If you are not entirely sure what a half-bridge is, or what dead time, or shoot through means, please use the library provided.