No, I’m not skipping all the odd numbers. My projects are numbered by when I start working on them, not when I finish. And Project 9 and Project 11 have both hit snags, so here we are.
Project 12 is a 3D printed, brushless flywheel, fully-automatic Vortex blaster. As with Project 8, it draws on the work torukmakto4 did on his T19, but where Project 8 was basically a T19 in a different body, this is much more different. As general highlights, Project 12:
-
Features a brushless outrunner based direct drive bolt. No steppers, DC motors, gearboxes, or solenoids.
-
Has only one powered flywheel, like the Nitron.
-
Has a Turnigy V-Spec 2205 motor for the flywheel drive.
-
Uses an Afro 20FS ESC for the flywheel drive, and an Afro 30FS for the bolt drive.
-
Uses torukmakto4’s Flyshot protocol to set the flywheel speed.
-
Uses torukmakto4’s tach-based single-trigger control that measures flywheel speed in real time and fires when it is up to speed.
-
Can carry a spare magazine in the stock
It is large and very heavy. Somewhat larger than it needs to be, with the muzzle extension and foregrip, but I wanted it to feel like a Nitron. I initially tried it with two powered flywheels instead of an idler because I thought that would give me more control of the disks’ trajectories, and for a little while I thought that maybe I could get more velocity out of it by pushing both sides. Neither of these worked. At the end of all this, the disk trajectory still isn’t as consistent as that of the Nitron. I tried various wheel speeds, flywheel gaps (currently set at 33mm to roughly match the Nitron), and various amounts of control bore, primarily by using printed sleeves to narrow down the bore. I also tried using a non-rotating idler, which fired fine, but didn’t really give any advantage. It currently features a 38mmOD powered flywheel and a 36mm OD idler on 70mm center-center spacing. I’m curious if that softer elastomer rim on the Nitron flywheel is important.
It’s having some reliability issues, but only with Pyragon drums. I’m not 100% sure what’s going on here. Might be just because it’s firing so much faster than the Nitron and the drums can’t keep up. 20 round stick mags are fine. I’m waiting for the chance to combat test this to see how it works there before I spend too much more time on it.
Printed in Snolabs red, Reicher blue, and black amethyst petg. Weird mixed bag of qualities here. The red is very good, the black amethyst is very stringy, but also has perhaps the best surface finish of any filament I’ve ever used, and the blue is terrible, with a diameter that varies so much I can see the effects in the finished parts.
Let’s talk more about the bolt drive, since that’s the big piece of new tech here. It uses a QXMotor QM5006, which despite the name, I think is actually a 4106 sized motor. It is 24N28P, with a KV of 350. It is 48mm in diameter, 20mm tall, and has a mass of 90gm. That really is what I was going for here. I’ve had good history with the stepper on Project 8, but steppers are heavy, at ~400gm. Cutting 310gm would reduce the mass of Project 8 by something like 15% on its own and partially cancel out the added mass on Project 12 of printing much more robustly, making just a bigger blaster overall, and adding a crapton of mass with a Pyragon drum. It’s expensive though, and behaves a little oddly at the moment. More on that later.
It uses a custom tuned version of SimonK on the ESC to enable forward/reverse operation and motor braking. I also played around with the throttle pulse widths to better match up with what I was able to get from the ATMega8 on the Arduino. I am using the governor to set the RPM of this motor, not Flyshot, since Flyshot is not currently compatible with the variable throttle needed to get forward/reverse operation, deceleration, etc. that I needed for this to work. I may play around with this and try making new version of it, but it’s not a high priority for me right now.
On the Arduino side, I’m using a Pro Mini and the AVR’s Timer2 to get a 488Hz hardware PWM for the throttle signal to the bolt drive ESC. Now that I’m only using one flywheel drive, I could use the other Timer1 channel there to drive the bolt, but I programmed this with the intent to use two powered flywheels, so the bolt motor had to get its throttle signal from a different timer. With that timer and the pulse width ranges set in SimonK, I have 2% resolution on the throttle signal. The codebase is essentially torukmakto4’s S-Core 0.96, with various changes for my use:
-
I changed the pinouts to work with my hand-wired board.
-
I got rid of the variable speed flywheel drive handling code and just set it once at boot time.
-
I got rid of select fire code, although I kind of flipped back and forth between blowing it away completely and just setting it to full auto all the time, so it’s a huge mess. There’s definitely a ton of useless code in there now that I should probably get rid of.
-
Obviously, the changes to use the outrunner bolt drive.
If you just want to see what I did to make the bolt drive work, look at the following functions:
-
fire(), decelerateBoltToSwitch(), and reverseBoltToSwitch(), for obvious reasons.
-
setup(), for enabling the Timer2 hardware PWM signal.
-
die(int major, int minor), because without a stepper to make error code noises with, I had to handle them some other way. I settled on broadcasting them through the serial monitor.
Because the bolt motor is brushless and I retain all the fire control logic from S-core, the bolt is stall- and jam-resistant. It will self-home at boot and reverse if at any time it fails to reach its goal by going forward.
There are a couple weird things about how it works though. First is that the typical math for setting the governor (described in https://torukmakto4....loop-speed.html) just doesn’t work with this motor. Right now my TIMING_MAX is 0x0BE4, which should be 938RPM, but I’m actually getting more like 730. No idea why this is.
Second is that I had this running like clockwork on a testbed that consisted of just the motor, bolt, and associated electronics, but as soon as I put in in the blaster, everything went kind of wonky. I’m getting a lot of double-fires when I try to single, and a relatively slow tap tap tap of the trigger often gives me a sort of bursty type firing of a bunch of shots. I’m going to continue to play around with the code, try adjusting the position of the limit switch, etc, and see what I can find, but I’m also putting this out there so if anyone with more time and/or programming experience than me wants to take a look at it, they’re welcome to.
I mentioned that I tried having both wheels spin at different speeds. That took some code changes to work with flyshot, so I put another version of the code up (in the misc folder) in case anyone wants it. For how I did that, see, primarily:
-
setGovernorBoth (void)
-
updateSpeedFixed (void)
-
ISR(TIMER1_COMPA_vect)
Although there are various other places where it comes into play, like variable definitions, and bits of loop().
Anyway, files are all in my google drive if you want to see my code, or try making one of these yourself.
https://drive.google...PID?usp=sharing
