I’ve spent some time now experementing with brushless direct drive bolt motors. If you’ve seen Project 12 you’ve seen so far the most success I’ve had, but I did a lot more testing with them.
These experiments actually go back three years, to mid 2018. When I was first designing Project 8 I made this big list of design ideas, some of which I tested before ending up with what was basically just a reshelled T19. One of those ideas was a brushless pusher motor to save weight and bulk from the T19 stepper. I built a test platform using a Racerstar 3000kv 2205 motor, of ultracage notoriety. I knew this motor would not be ideal, but figured if I could get it to at least sort of behave, then it would give me confidence to try to find better motors. This test platform didn’t actually drive a bolt, it just spun an oblong disk while I checked if it would stop in time. It was programmed like a rapidstrike with cycle control, i.e. if the switch was not pressed, the motor was powered, and if the switch was, the motor stopped. I used simonK firmware on the ESC with COMP_PWM and MOTOR_BRAKE enabled. Results were not great (it kept overshooting the switch, even with a large braking zone) so I put it aside and put a stepper in Project 8.
Fast forward to fall 2019 and I tried again. This time I went straight to buying a new motor, the QXMotor QM5006 used on Project 12. I also used some different ideas towards motor control. Rather than being full on or full off like a DC motor, I used some timing controls to slow the motor down a little in advance of the switch. 50 milliseconds after the bolt limit switch is released, the software checks the trigger. If the trigger is not down (so we’re not continuing on in full-auto), then the motor’s throttle is cut to the minimum value that still reads more than zero. This slows the motor down just enough that when it hits the switch it can come to a complete stop.
By and large, I consider this bolt drive system a qualified success. “Success” in that:
- It does actually work.
- It is substantially lighter than a stepper.
- It is axially shorter than a stepper, allowing Project 12 to be about 20mm shorter heightwise than a T19 despite very similar construction.
“Qualified” in that:
- There were some nagging issues with getting double shots when I intended single. More on that later.
- It is substantially wider than a stepper. Made worse by the fact that as an outrunner, wires can’t be run right next to the motor like they could a stepper.
- It’s expensive. $25+ for the motor and then another ~$20 for an ESC. Compared to about $12 for a stepper and a few dollars for the DRV8825 driver.
- Needing to fit the ESC somewhere means the total blaster really can’t be *that* much smaller overall.
Going back to the double shot issue, I had two theories why it might be happening. One was that the 50ms timing when the blaster checks for trigger state to decide whether to fire another shot comes earlier than it would on a stepper. And the other related to Project 12 using a tach-based feed instead of the fixed delays on the stepper-driven Project 8, my only comparison blaster. This, combined with the super light flywheel on Project 12 meant there was less time between pulling the trigger for the first shot and the blaster checking trigger state for the second shot. Time which may not have been enough for me to get my finger off the trigger.
To investigate this I built a T19 driven by a QM5006. This would remove the flywheel inertia from the equation. I also tried putting in some delay-based code as well just to get another data point. The result? ¯\_(ツ)_/¯. Honestly, it’s kind of hard to tell the difference between all of these things now. All the different methods blur together a bit, probably exacerbated by this all happening in quarantine when I’m unable to do any real-world testing. I have been to one game recently where I used this T19, modified to enforce a minimum feed delay of 25ms (the smallest delay the scheduling on Project 8 ever gives) which would really only come into play in a follow-up shot, and, well… ¯\_(ツ)_/¯. It’s... fine? I guess? I don’t really have much to say one way or the other.
With that question decidedly not answered, I also tried working on qualifications 2, 3, and 4. SimonK really isn’t meant to drive a motor one revolution at a time, so I bought some L6234 motor driver ICs and set about programming my own motor controller, driving it forward in discrete steps, like a stepper. I wired it up per Figure 1 in L6234 application note AN1088. There was a false start or two with trying to use a six-step commutation scheme where every phase was either full on or full off but that didn’t work very well. I settled on the PWM based scheme described here, using the lookup table provided. This was a partial success. I could make the motor move and had fine control over it, but it didn’t have the torque to reliably strip darts out of a magazine, even when destroked down to 30mm. It’s possible there was some kind of issue with my circuit – I didn’t have exactly the right diodes to match the diagram, so I just used what I had laying around and that may have caused a problem. Measuring the current through a motor phase showed about 2.5A, which is near the max L6234 rating, so I figured even if the diodes were causing a problem, I probably couldn’t get any more out of it anyway.
All of this testing so far was with the QM5006. I also tried a 260kv 2206 gimbal motor with even less success. About the same story with the L6234, although this one wouldn’t move darts out of a magazine at all, where the QM5006 would do it sometimes. I tried the new motor with simonK as well, and it kind of just jerked around instead of spinning. I’m going to assume I did something wrong here as that should have at least moved it, but honestly at this point I was well past the point of caring and abandoned it.
The T19 was put back together with the QM5006, simonK, tach based feeding and minimum 25ms delay. Project 12 has yet to see a field trial, although I plan to put the same minimum 25ms delay code in it before it does. The L6234s and the 2206 gimbal motor have been set aside. At this point I have no further plans for any testing but have uploaded my giant mess of code in a big unorganized lump here if anyone cares to look at it. Most testing was done on the bench, so the code is generally just cycling the bolt one time. The CAD for my various test platforms is also in there, although at least some of them were not correct as printed and I had to take a saw to them to fix them. As an aside, I learned through this that setting the TCCR0B register on the AVR (which I needed to do to get enough PWM channels for the L6234) changes the timing so that millis(), micros(), and delay() are no longer consistent with the real world. Any code that uses these functions must be corrected by factor of whatever the prescaler is set to, in my case 8. For some reason delayMicroseconds() appears to be unaffected.
Filaments for the T19 are esun transparent green, yoyi transparent purple, and some variety of white, don’t remember the brand. All petg.
