Wednesday, February 14, 2018

Hy-Con/T19 Part 7: Aesthetics experiments, Model Pandora's new wire covers, power system change overview.

I had a USF HvZ game coming up, so something greatly needed to be done about the motor phase wires strung across the sides of this blaster before they got snagged and ripped out. I took the opportunity with these wire covers to try out this fluted surface finish, which will definitely make it into many Production T19 parts.





As a final tweak, I drew up a flash hider for it as well:



There is a considerable practical purpose to this device aside from making my blaster look more tacticool and less truncated. Namely, a bit of barrel length (including any muzzle-thingies) is desirable for working past bunkers and cover. I had a habit of shooting darts into my bunker. Furthermore, with a bare Hy-Con cage, firing pointblank into an obstruction, such as a cover item or a charging zombie crashing into you, would lock the flywheels up and completely pulverize the back half of the dart. The flash hider gives somewhere for that dart to go and avoids unnecessary drive abuse and unnecessary dart vaporization.


It's also the first official piece of Production T19. I'm working my way back from the front of the blaster. Things are gonna get modelled and tested quite fast in the coming month or so.

The power system also got a considerable revamp. Gone is the 3S battery. I now run on 4S with the closed-loop control discussed in the last post. This greatly enhances performance of the flywheel drives with much better speed regulation during firing, better startups, and consistent full speed and critical velocity throughout the battery charge cycle. It also buffs up the stepper bolt drive's torque curve and allows running higher ROF. I currently run at 11rps and have fewer skipped steps than I did running 9-ish rps on 3S, which were not many to begin with.



A change to support the use of 4S is that the backplane's 5V logic power buck/boost module needed to change, since the S9V11F5 is rated to maximum 16V input, which can be exceeded with a fully charged 4 cell battery (though for a while I was feeding it straight 4S and there was never any failure). I have purchased a few different alternative buck/boosts with higher input voltage ratings to try out, but what got me through all the recent combat and will probably remain in the Model Pandora for good was in fact a S9V11F5 with two 1N5551 diodes in front of it to waste a volt or so. Yes, it's janky as fuck, but sometimes janky works! if anything goes wrong with the alternative modules, that may very well be a backup plan.

motor tech - Intro to closed-loop speed control with SimonK.

Shifting gears a bit. Closed-loop control, specifically speed control, has been a wanted and discussed feature in flywheel drives for years now. What I didn't realize was that it has been right in front of my face all this time and I was, in fact, using it. Not optimally yet, mind you - but it was there.

SimonK has a simple "governor" feedback loop to duty cycle, configured with the parameter TIMING_MAX. This is to prevent motors from overspeeding and exceeding the frequency limit of the firmware, which follows from the calculation used to generate the next commutation timing on each cycle. In pre-2015 SimonK, this timing calculation was 24-bit only, and TIMING_MAX was set stock to 0x00e0, giving a commutation period of 56us which equates to 178,571 electrical RPM. With a 14-pole machine (7 pole pairs), this becomes 25,510 mechanical RPM. It turns out my old Hy-Con drives have been governing at this speed all along! The oscillation I mentioned earlier is a minor control instability which occurs under certain conditions because the governor loop is a fairly crude controller, more or less just meant as a safety rev limiter. However, keep the bus voltage*Kv product well away from the governed speed (i.e. not my old 3S hycon!) and it works damn well, giving rock-solid speed regulation. Not like the faint rumble affects flywheelers anyway, I had it all along with T19.

By contrast, 2015+ SimonK has a more agile timing calculation methodology and can safely be governed at up to 312,500eRPM (TIMING_MAX = 0x0080).


Followings from all this:

TIMING_MAX/4 = commutation period.

This is a six-step drive scheme, so 6 commutations = one full AC cycle, and the period of the AC is (6 * TIMING_MAX / 4) microseconds. Divide that period by 10^6, and invert that, and you get frequency in Hz. Divide that by the number of pole pairs in the motor, and multiply by 60 and you get mechanical RPM.

There's your governor setting crib sheet. Back out a TIMING_MAX, punch it in, set all your other parameters how you want them, build and flash.

There is at this time no way to adjust the speed setpoint post-build. You cannot, for instance, have a throttle command interpreted as a speed setpoint, or send the speed setpoint over some protocol from your blaster controller, or anything of the like - you need to recompile and reflash to change governor setting. This ought to be fine, since motor speeds normally pair with physical flywheel and cage parts - and if you are intentionally turning down velocity by slowing your flywheels down, the difficulty of changing the governor settings only makes it more legitimate as a means of safety compliance.

Going closed-loop of course has some very good ramifications for subcritical operation - no longer do startup times and torque curves need to suffer as they do when speed is reduced by commanding less duty a la FDL.

If you need to go faster than 178,571eRPM you need to use 2015+ SimonK and build with your specified TIMING_MAX value. If you want to govern at 178,571eRPM (25,510 mechanical RPM with a 14-pole motor), it is very convenient to simply use stock SimonK version 2014-09-30. For Hy-Con 9.5mm wheels, 25,510 is, or nearly is, critical speed, and a perfect governor setting (I tested while free-spinning my motors on 4S with 2015 SimonK to annoying-sounding 30K+ speeds and didn't get more velocity from that). SimonK 2014-09-30, and indeed every version of SimonK I have ever run, operate perfectly with the Turnigy V-Spec 2205 motors without any sync issues or the like and I have been running 2014-09-30 in combat as of late with zero problems.

Disclaimer


More testing is required with various TIMING_MAX settings and motors before I call this anything other than beta, so if you are using these findings for something different than where I have explored so far, recall the warning in SimonK: "If it breaks, you get to keep both pieces!"

motor tech - Brownout reset issues and proven workaround on 20A Opto Afro with SimonK

Up to this point everything I have tested and used under the Hy-Con umbrella has been run on the same trusty pair of Afro 20A controllers (BEC version, though I don't use the BEC in my system) on their stock flash of whatever version of SimonK. They have served up thousands and thousands of rounds without a single fault and weathered numerous violent stalls and shredded darts during the cage's evolution. They're rated a bit lower than my overbuilding mind would like, but hell, they have proven themselves.

I went to buy more controllers, and the old trusties were sold out. So I bagged a bunch of the "opto" (really just non-BEC... with no real optocoupler anywhere to be found... like most "opto" ESCs...) version instead. Putting my lucky pair of controllers safely aside, I began using them for firmware experiments, starting with stock latest release SimonK.


First discovery: These Opto Afros die and reboot every single time if you send them a hard throttle step while the motors are spinning down and reach low enough speed. Oh, not this again!

Preliminary poking around revealed absolutely zero difference in the logic power supply arrangement between the two versions. Firmware was also cloned from my old lucky 20A Afros to the test pair of new resetting ones with no change, so it doesn't seem to be a SimonK version or parameter difference. I tried a wide range of SimonK versions, with both low-speed/startup duty cycle management strategies (the old variant that did discrete hard shifts in duty at set speeds, and the newer smooth-ramping one) without improvement.

That leaves two hardware and one low-level software possibilities to explain the different behavior between these two nearly identical drives that ought to behave identically:

* The inverter MOSFETs are different components between the two models. The BEC one has Toshiba TPCA8087 (rated for 56Adc and 168A transient, incidentally). The "Opto" one has a visibly different, so-far unreadably labeled, device. So this could be a lower Rds(on) or other different properties, and maybe make the startup current transients nastier.

* The stock DC link capacitors are different. Both are Haicap brand, 35V, 220uF (IIRC, but both are the same ratings) but the one on the "Opto" has a longer can. We would expect longer = lower ESR = better; but perhaps not. Insufficient buscap can cause all kinds of hell with motor drives, and seriously, who is "Haicap" anyway?? Replacing these with something BIG and GOOD as a test is on the list.

* The ATMega fuse bytes may be set differently, resulting in a lower brownout detection voltage on the working drives. In this case, the resetting ones may be behaving properly, while the "working" drives may be running the ATMega8 out of spec for Vcc at 16MHz. This is bad. Recommended BOD settings exist for reasons. The microcontroller could crash from the Vcc sags. If it crashed with the motor underway, very bad things could happen! That will be investigated once I have the right ISP socket to read the fuses on them.

Anyway though, what I noticed while testing was that the brownouts corresponded with what looks like a MASSIVE current transient. My phase wires were jumping around from the magnetic fields, like the leads on my battery welder! This gives pause. It is entirely possible that the usual fix - throw an increasingly mahoosive battery at it until it stops rebooting - will cover the issue up, and changing to stabilized logic power WILL cover it up, but if there is actually an unexpected gigantic current excursion going on here, that really needs to be addressed. That's not supposed to happen and especially with a 0.077 ohm phase-to-phase motor and a tightly sized drive here, the inverter mosfets may get blown sky high if it's getting hammered with 100% duty at low speed and that isn't mitigated - it certainly isn't nice to any of the equipment including the battery.

Duty at very low speed should be limited to POWER_RANGE/4. Should. I suspect a bug - especially because hard throttle steps from 0 rpm never cause any symptoms, only hard throttle steps from low but nonzero speed while the rotor angle is still being tracked.



A solid workaround found was to enable SLOW_THROTTLE. This is something that sounds wrong after the history in this hobby of chasing more and more current and torque and the most aggressive possible responses from every component, but it doesn't seem to affect startups.

Per my understanding, enabling SLOW_THROTTLE won't even affect the duty (hence current and torque) profile of a 0 rpm startup with an inertial load attached (like a flywheel) as:

* the minimum duty SLOW_THROTTLE permits is POWER_MIN_START anyway;

* the TIMING_RANGE (frequency-based) duty scheduling strategy used in the startup process should always result in lower duty slew rates when accelerating an inertial load than SLOW_THROTTLE's restriction that the duty may only double in a single cycle and no more... at least from what I can tell.

Now, SLOW_THROTTLE really ought to not affect a start from such a low speed with a turning motor, either, because the TIMING_RANGE based duty schedule ought to still be enforced as part of the update_timing* routines. So why DOES turning SLOW_THROTTLE on matter? Hell, how does such a fast duty ramp (as doubling per-cycle from a starting minimum of POWER_RANGE/6, thus going to 100% in 4 commutations... I think) even help our issue by itself? Yes, this warrants further investigation and dissection of SimonK. SLOW_THROTTLE has given flawless operation and great results so far on 3S and 4S and will be part of my official SimonK variant for the Hy-Con/Production T19 for now, but it's a kludge fix.

Sunday, January 28, 2018

Google Drive link for Hy-Con part files, T19 Firmware, etc.

Github and Git vexes me. I do need to get my neolithic mind around the proper use of version-control systems eventually, but for now as a stopgap here's the big dumpster of Hy-Con stuff:


I'm working on converting all source CAD files to STEP so people don't have to attempt to edit meshes, but that's gonna take a while. I figure that if you don't use FreeCAD like me you probably can't import my .fcstd files.

Also note: Gamma Minor Cage is not posted. That's because it has some very dumb goofs in it with motor clearances that resulted in the dremel being broken out. For now, just print a 100% infill Beta Prime and that will do the trick. Also, it is going to be shortly obsolete when the Gamma Major is finished as the first big piece of the Production T19 1.0, which will have non-borked motor clearances, smoothed externals, and its own matching, aesthetically blending Cover component with the other half of the muzzle bolt pattern, so you can finish your blasters off with flash hiders, barrels for working past bunkers, or twistlocks.

Model Pandora T19 development gun: Parts are posted, if anyone brave wants to play around with them.

Firmware: DZ Core V24.0 is posted. This includes the latest delay settings I have been running, which do whittle away slightly at first shot velocity for responsiveness at least with 3S. Also, some bolt drive parameters have been buffed somewhat which will give 10.5-11 rps, because I now run the flywheel drives closed-loop and use 4S (as the Production T19 will) and stepper torque is no longer a problem. If you've used this code in something and are running on 3S, you will probably want to read the comments in that section, and set the last one back to the listed default for maximum reliability - at least as a baseline.

Added to the firmware as of late is a neat little power-on selftest routine that gives tactile confirmation that all the motor drives in your blaster work, nothing is locked up, etc. without having to dryfire it.

Hy-Con/T19 part 6: Groove Filler Success, importance of cage stiffness, rotor-centric flywheels

TBNC4 (our 4th major event post-Reboot) was a success in many ways, including the notable lack of T19 jams running the Beta Prime cage. Every ragged-ass old dart I picked up went right through without a single hitch.




Groove fillers work, people. They absolutely, positively make a HUGE difference in reliability. Nuff said.

Because there is no good place to stick these, have a whole bunch of Beta Prime/Gen2 9.5 part images.







However, a discovery came to light with my print of the Beta Prime cage, that being the monumental importance of cage (and overall system) rigidity in these large-format flywheel blasters. I have never seen it discussed much. Anyway, my Beta Prime print used 20% hexagonal infill, 4 bottom and 3 top solid layers and 3 perimeters. This with PETG makes a very rugged part that absolutely isn't going to break, but this cage dropped the T19's velocity by about 15 fps over my previous Beta non-prime, which was printed with a few more solids tops and bottom, with all generations of wheels I tried (which were all of them, including my old PLA prototype set).

Thus, this happened.





It's called Gamma Minor and it has a lot more meat on it. I also cut straight to the chase and printed at 100% infill, resulting in a part that is heavy as fuck and took about 6 hours to run. Velocity went right back up to 176 average with Raytheon waffle blue. I think I overkilled things a tad and can maybe print a bit more sanely in the future while still getting optimal numbers out of this with the inherently stiffer design trend going on (not the Beta's thin motor mount "wings") but at least it proves the point. Cage stiffness, DOES in fact matter way more than anyone has yet given it credit for. Flexibility you can barely feel by hand can affect the dynamics of parts under the shock loads of firing darts. Respect that fact - and stock-cagers should really revisit this with the popularity of the printed cages.

I will probably always print my 'con cages at 100% after this however simply for the NVH reduction. It's a good bit quieter and smoother feeling than my Beta Prime print was.

Now for an installed pic, and...


Wait. What's up with those flywheels??

This is the sort of way development tends to happen with me: in the last few days/hours before a game, with a sudden spark and a mad dash to fab parts and change shit and hope it doesn't explode in my face tomorrow.


So this is the Gen3 Hy-Con flywheel, the "rotor-centric" that I may have referred cryptically to at some point. The profile geometry is the same as the Gen2 with all its refinements in that regard. The big change happens on the other side of the rims. Up to this point I had been designing flywheels with the structural concept of old-school, shaft-mounted wheels from the DC dark ages. I just replaced the shaft bore with a bolt pattern to hook onto the rotor flange of the outrunner, much like an engine flywheel. So did FDL Jesse and most others. I was pondering optimal print parameters and possible design revisions for these Gen1/Gen2 wheels in light of the cage stiffness observation and some concentricity/balance questions with them as well.

Ultrasonic2's Ultracage wheels came to mind, in which there a small step to use the rotor OD as a pilot diameter/locating feature to center the wheel, when it suddenly clicked: Why does the web need to carry a bending load, anyway? The rotor has a large external cylindrical surface, why not just use that to both locate and support side load from the rim?

So there it is!


Consider it a synthesis of multiple older concepts:

* The flange-mounted Hy-Con/FDL or shaft-mounted old style wheels: we still use the web to axially position the wheel and to transmit torque.

* The Ultracage rotor-OD piloted wheel, for being my actual inspiration for using the OD of the rotor on an outrunner in this way.

* Kelly Industries outrunner Stryfe cage, since the press-fit hubless "tire" flywheels transmit their side load in the exact same way. Only mine don't rely on that fit to either transmit torque, or to maintain axial position.

These are dimensioned on spec to get reliable solid fit without movement of the wheel on the rotor. If you early adopters print these, be aware you WILL need to scrape down any layer-change blips first to get a mostly-round bore, and then sand to snug fit on the rotor OD (tight isn't necessary). Careful of the motor bearings when fitting these, avoid excessive force or you could brinell them. Aligning the bolt holes is fiddly; use your allen key for the flywheel bolts while pressing the wheel on. For now the 3mm pilot bore is still there and still needs drilling/reaming to clean up just like before.

The most profound immediate result from this design was better concentricity and greatly reduced NVH. Using the rim ID and rotor OD as a locational fit helps deal with printing tolerances and warping and such in the web and automatically pulls the rims into concentricity with the rotor when bolted down. These things feel almost machined, and my printer is still not as perfectly square as I want it, even. The rigidity also prevents things from wet-noodling at speed under imbalance forces and worsening any imbalance.


Recommended print parameters (with 0.2mm layer height 0.4mm nozzle) for the Gen3 are random start point, 3 perimeters, 4 bottoms and 3 tops (Less mass is priority over pretty top layers) and 20% hexagonal infill. The Gen1/2 wheels benefit from more solids. These do not, because there isn't any bending load on the web. It will just add pointless mass and make you need to crank your delays up and have longer lock time.

At this point I should address printed wheels and inertia briefly. Those rims look awful thick, but keep the above image in mind; there is structured infill in there, thus the rims are mostly air. The majority of rim mass in a printed wheel is in the perimeters. This is why the Gen2 wheel design was admittedly kind of dumb - all I ended up doing was moving the inside perimeter outward, increasing its circumference (hence quantity of plastic) AND its radius, while only saving a tiny tad of infill volume inside. Gen3 is probably not optimized for inertia because the top layers start getting heavier with such a thick rim as well as the infill, but its structural benefits are undeniable and the Gen3 runs the same delay settings as my old Gen1 wheels, which are acceptable. Further mass reduction may indeed be explored within reliability/durability bounds to pep up startups.

I also happened to get this image that ought to embody part of the answer to the question "why brushless?" that I often get. Of course there are about 6 different factors in why brushless (inverter PMSM) drives kick DC's sorry ass all the way to Alpha Centauri and back, but packaging is one of them:


There is no way I could possibly achieve a flat cage package like the Hy-Con with brushed motors. That's, at minimum, a 380, at about 3 times the length.

Thursday, January 11, 2018

[moderation] Anonymous comments now disabled due to spam.

Spambots have been submitting a torrent of garbage comments lately, so anonymous comments are now disabled for the time being. If you're a human or other sentient being, please create an account and continue posting feedback and ideas.

Tuesday, January 2, 2018

Hy-Con cage refinements, Gen2 wheel models, etc.

So far what I have been testing and playing nerf with is very nearly the original version of the Hy-Con system. There has been, up to this point, only one 9.5mm gap wheel that has existed completely unchanged from the get go, and the "Beta" cage used by the Model Pandora development gun is basically the Protocage repackaged save for one fillet. I guess I did well enough, but make no mistake, this is far from finished.

Problem one is that I have been having incidences of a specific and aggravating malfunction with this cage, which has been occurring solely with used waffle darts (never anything else, especially not accustrikes). The failure mechanism is the foam being dragged around with the lag side of one of the flywheels after the contact zone and getting sucked into the little gap where the bore re-forms, created by the extremely concave wheel and the cylindrical flywheel cavity in the older Hy-Con cages. The thing then seizes up tight as a rock. Sometimes the dart can be unwound out the breech or muzzle by hand. Other times a rod is required. Not a good situation.


I was aware of this misfeature, as well as potential solutions to it, and it was my greatest uncertainty when I designed the original Hy-Con system. The reason for its persistence is or perhaps was that machined cages are or perhaps were planned down the road, and any internal geometry gnarlier than a cylindrical flywheel cavity would probably result in a significant cost increase and prevent a one-piece cage from being possible to assemble.

Unfortunately, this does not appear to be working out.

This blaster must shoot any common super/ultrastock ammunition, and it must be able to shoot garbage. It's allowed to chop or mutilate garbage in any way, and it is also allowed to have garbage accuracy and consistency with garbage as is the reality of garbage, but it is never allowed to stop firing and require attention to clear, even if the ammo is garbage.

And so the CADding begins again. I am holding off on further work on the Production T19's "Gamma" cage for the moment until I get the internal geometry of the Hy-Con cages nailed down and field tested. To that end, this is what I am calling "Beta Prime", a straightforward addition of the experimental feature to the old Model Pandora cage.


Note those protrusions - they stick down into the flywheel grooves, and fill that stupid little offending gap in so stuff hopefully can't get pinched in there and cause a mess. They have about 0.75mm clearance off the rims of a 9.5 wheel, so there is a bit of room left for the 9.0.

This is actually a feature the PFDL cage has had for a while now. It probably is overkill with the low envelopment there, nor does it seem to be necessary with high-envelopment smaller diameter systems like Eclipse, Ultracage and DrSnikkas cages that generally just have a cylindrical cavity and ignore that gap, but I may have discovered a case (high envelopment AND one of the largest diameter systems ever in practical use) where it is very, very necessary to have that little groove filler doohickey.

I should also mention my suspicion that this troubling malfunction is all the fault of waffle darts all along once they get used and the tips start getting loose - the root cause may be the waffle tip grabbing/sticking in the 14mm barrel and causing the foam to buckle or bunch-up behind at which point the lag sides of the wheels are going to nip the foam. I had the same exact jam happen when I was using TBNC David's FDL for one round and put a couple hundred rounds through it. The difference is that when T19 does this, the dart becomes a mangled, compacted, FUBARed shitshow. When the FDL did it, the dart was still pinched and the motors still locked up, but grabbing the dart and ripping it out, then dryfiring dislodged all the debris and restored functionality. That I am guessing is the limit to the value of the gap-filler doohickeys and the true solution is to not shoot those darts and use something else. I am having massive second thoughts on Accustrikes/clones - they are AWESOME in CQB and HvZ.

Anyway, here's the result when you add wheels:



Note the protrusion is asymmetrical. The motor mount side cuts it a bit closer to the wheel profile with a 45 degree edge there in the hopes of printing more easily.

You can also clearly see another related change - the cage no longer splits straight down the bore axis. The parting line was moved 4mm from the motor mount part toward the cover part. That gap filler protrusion makes assembly impossible if it is not entirely in the motor mount section of the cage. Note it also makes assembly impossible if the guards or anything else are integrated into the motor mount section without sufficient clearance and block the sides of the motor mount. You must be able to mount the wheel to the motor, slide the motor in from the side, and bolt it down to get the wheel rim past the protrusion.

There are also some minor external changes on the Beta Prime cage from the previous Beta. Guards were thinned by about half but are still quite robust, and some edges have fillets. No big deal.


I have also modelled a new series of wheels. Changes include more refined rim backside geometry, 0.5mm larger OD to take better advantage of the standard Hy-Con cage clearances and take the rim-to-rim clearance down to a nominal 0.5mm, a series of gap settings that presently range from 11mm to 9mm, and radiused rims rather than chamfered rims, which are a bit smoother and sacrifice less contact at the edges.


This one is a 10mm, incidentally. I have high hopes for 10mm with this system being quite competitive on velocity but easier on darts than the 9.5.


This cage has Gen 1 wheels. Note what happens with those rim chamfers. Also note what is considered a large rim clearance in this day and age, not a fitting thing for the original "100%" envelopment cage.


This one has Gen 2 - note softer edge provided by the fillet instead of the hard chamfer, and note the closer rims and generally much better fidelity of the hydrostatic compression profiles to the ideal circle.


Finally, since I didn't get any images of the real blaster that show the drivetrain guts of a T19, have a Model Pandora cross-section. Perhaps that will clear up some things.

Specifically, look right above the NEMA 17 mounting pattern and you can see the cavity where the crank web sits, and above that, the bolt guide rails. The bolt is completely 2-D like a sheet part (the proto one IS a PVC sheet part like the crank web), and is about 6mm thick. The limit switch bolts to the little perch behind there. The purple top cover forms the upper rails, capturing the bolt in there, and the rest is just a magwell, a closed breech guide and a cage and that's all there is to it.

The stepper motor's shaft is shortened considerably, before anyone asks.


More updates once I get my Prusa going. That's gonna be fun...

Sunday, December 24, 2017

More T19 Prototype Bits, Hy-Con Design Directions, TBNC Ultrastockification, etc.

Literally a hour before the TBNC match where the Model Pandora, and by extension the T19 running gear and the Hy-Con flywheel system, got its trial by fire... here I was cracking her open and pulling the processor card for a quick reflash. So that gave me an opportunity to get an image of what is inside the brick-like confines of the lower drive housing.


Of course lots of wiring, and of course you can see the end of the bolt motor. Less obvious is the controller board, mounted on some PVC standoffs (that will be part of the drive housing model as soon as the board is standardized). You can see the heatsink and distinctive purple PCB of the DRV8825 driver card for the bolt motor. Just to the left of that is the processor card, an Arduino Pro Mini which is my new favorite micro board (highly recommend). What you can't see under the wiring are the flywheel motor controllers, stuffed partially in between the stepper and the housing. The phase wires cross over from the left drive to the right motor and vice versa in front of the bolt motor with all those 2mm bullet connectors and no slack. A weirdo configuration. What a pain in the ass to deal with, and incredibly dependent on using the same Afro 20A controller to even fit.

Where these controllers are going to go in Production T19 is getting massively revisited, including accommodation for larger ones that might be required for certain configurations in the future. I never did like the "wasp-waisted" FDL-like look that was trying to happen, so that's... going away and the drive housing lines will be continued forward. The fly amps and phase wiring to the motors are going in that side space under big cover panels. This change will get rid of the need for breech wire covers/raceways and splicing the too-short stock motor phase leads in the process. It will also remove numerous items of bullshit from the lower drive housing and make it less packed in there.

I was reflashing to tweak delay schedules and heat up some low velocity cold start shots I was getting. Partial success (I get 150-160 ish first shots now), but no cigar. There shall never be; the process of tweaking timing schedules will continue ad infinitum.


Overall though, "Layla" did well. An absolute successful test, and a lot of fun to run this.

This was the first time a T19/Hy-Con and a FDL have been in proximity. Some have said my blaster looks FDLish. Yes, there was inspiration for doing a horizontal-cage device, and I kept the trademark visible wheel edges because I thought it was cool, but the designs are actually totally unrelated. Note how much bigger Hy-Con wheels are, for one.

The titanothere in the room? The drivetrain internals. I promise, I will show you the prototype's guts someday, but here's the deal, it is a completely different design than a FDL. There is no "drive plate" like a Rapidstrike box. The crank web is, just a crank web. It doesn't support the bolt/yoke, and isn't circular. Rails in the case parts are the only contact for supporting the bolt. Less friction, less inertia hooked to the motor, etc.

LOL those phase wires hanging out

Speaking of drivetrain? Direct drive FTMFW. Did super well. There are reasons I, as someone who has been playing since before flywheel was even a factor, am 100% down with stepper drives. Rock solid and super easy on darts and easily capable of the highest ROF anyone should be shooting at, even without any real envelope-pushing yet.

So now onto where Hy-Con is going and the internal debate I have about that.

Beta Model

When I designed the original Hy-Con System what seems like ages ago, the state of the art was different. People weren't shooting 200fps single stage. The top contenders were HBC Riot/OFP 41.5 with Riot wheels, and FDL cages. We were maxxing out at around 160fps average with excursions into 170s. I was angling for a system tuned to do 175 average, maybe 180, with 150 as a floor, and to do it using intentionally LOW crush. Thus, I made a possible blunder in futureproofing by not anticipating the possibility of needing to shoot more than 190fps for any reason so soon or that I would want to crank the crush up, and thus, not having enough surface speed out of my drive system's speed capability and wheel root diameter to support more than 190fps.

The "Hy-Con 1" is still well suited to the application it was meant for and I still admire the sort of conservative and balanced design that steered it from the get go. The V-Spec 2205 2350kv motors and 20A drives are nicely economical and compact and yet do a good enough job swinging these giant flywheels with decent dynamic performance, and if you're trying to shoot 175fps (or less for game rules), there isn't much point to more speed, either. I am very reluctant to outright ditch this setup. After all, T19 is not meant to do maximum-everything. It's meant to be a practical and competitive survivor.

At the same time, the Hy-Con's design basis has since mutated into awesomeness like Eclipse (200fps out of a Stryfe envelope), other similar Eclipsish experiments with other profiles have worked well to nearly identical results (Ultrasonic2 cages) and this giant dinosaur cage of mine is left in the cloud of dart dust from those two for lack of surface speed to support any further profile development. Oh, but my format has such potential in being so big, if I can get the tips to stay on the darts. I'm wondering if Hy-Con should have a more capable power system, eyeballing some 2306 2150kv motors and the use of 4S. Even more torque for faster startups plus support for up to 220fps. 4S on my current motors and the right high-eRPM capable controllers would be a tad speedy, but could support 250fps. There are motors, like the NTM 2836, that could net me even more torque and WAY more speed than either and are lower pole count to make those speeds easy on ESCs too. Oh the temptation.

However.

Something I already notice is that available/accurate dart ballistic envelopes are becoming a problem in the ultrastock band. Accufakes to begin with have utter garbage velocity retention, I'm at a loss why ultrastockers would want them. Waffles are substantially better, but my 175fps Hy-Con doesn't seem to shoot much if any farther than a 150fps FDL setup with them - just a bit more accurately, but that is another matter entirely.

What worth is that 25 extra fps on a full-length waffle dart that's already going 175fps anyway? I'm open that I might be getting tunnel vision for the chrono and being led astray from system design goals by the allure of 15-50fps that might not even wind up being practical to exploit from a system of this root diameter because of dart decapitations. Especially since a better set of these original 9.5 flywheels (this set are printy, rough and imbalanced and my old PLA protocage wheels were better) would probably do 180 average with waffle.



In any case I am ordering a bunch of 2205s and 20A Afros with intent to hold the course.

Of note in all this Hy-Con and 175fps and such discussion is that since I first fired a 'con at someone in anger, I... guess I'm officially fielding ultrastock blasters now. Where I have been fielding them is TBNC. Which was conceived as a superstock group and had 150fps velocity caps. Uh... About that. I feel kind of sheepish, but at least it was an agreed-upon and unopposed thing that the admin team just kind of simultaneously and flagrantly stomped on our own velocity rules. Ignore all the brushlessness for a sec and look in the background:


Yeah, that's a Caliburn, and it was used in combat last game.

I'm about to post the updated ruleset document. Change: Nix the 150fps bit. It's in the way and we don't want it there any more.

We're ultrastockified. It's official. Captain Slug, isn't that your dream? It's happening.

What I DON'T see is... nearly any practical change to gameplay. Last event saw stock and basic-upgraded Rival blasters and an older HvZ-specced Stryfe with AR and Artie aluminum smooth wheels and these were competitive just like my 130fps T17ACR would still easily be. Oh; it also saw SOCKS in the correct hands soundly destroy an entire team with ultrastock and high-end super gear.
Perhaps the moral is that player skill and luck always come before equipment, and a small amount of well laid out cover and balanced objective design from the get go makes a robust and fun game that armsracing can't derail; but I would call good game design a given. More or less, I have serious doubts that the "Super-to-Ultra" transition is anything other than a straight-up enhancement to superstock in any situation where >150fps can be tolerated. I don't think there is an accessibility problem nor a substantial change in game dynamics associated with it.

Saturday, December 16, 2017

T19 Prototype Build

I have rather insufficiently documented the progress of the Hy-Con flywheel system and its greater role in me going to clean-sheet blaster designs and exploring new tools like 3D printing, but that is in fact what is happening with me as of late. The main project here is called T19, following on from a T18 design that was put aside for later.

The key elements coming together here:

  • AC direct drive pusher, using a NEMA17 stepper motor, covered in the last post, as the drivetrain component.
  • the Hy-Con System as the ballistic component, including its associated motor/drive pairs.
  • My software package for integrated control of exactly such blasters.
  • A single-board modular controller architecture that just sort of designed itself as this project progressed.
  • A distinct design philosophy in terms of human factors/layout aspects that I found lacking or shoved aside in prior art. Examples are having a very tactile and consistent real trigger, a full length monolithic top rail, a trigger guard, conventional firearm-style trigger logic as opposed to FDL logic, etc.
  • A distinct feature/functionality philosophy best summarized as "You turn it on, you shoot it, and you turn it off". Rather than overcome varied roles with lots of options, controls and settings, I prefer versatility be inherent and all the software intelligence be buried under the hood. You shouldn't need, for example, selective fire. A combination of full auto mode only, superior trigger logic, good trigger hardware, and easily learned operator skill renders it one hundred percent objectively pointless.
Layouts vacillated for a while. T18 was to be akin to a "giant mutant alien Stryfe" - vertical plane cage and vertical plane drivetrain. It is still in the works... eventually. I just decided not to prototype and do Hy-Con field testing with it, but to design a simpler, cruder test-mule, and that, is T19.

The inspirations are:
  • The FDL series (the horizontal flywheel orientation).
  • Old school electropneumatic paintball markers, like the PVI "shoebox" Shocker and ICD Bushmaster 2000, for the packaging approach used to accommodate the NEMA 17 bolt motor and the electronics package while maintaining a clean top profile:

So I got CADding. Here are some models for printed parts (note magwell is a dummy part and is not used):


I had 3DK print these for me, since I am a lazy SOB and haven't built my own printer yet. That's next.

And it came together, with a bunch of handmade PVC buildup parts. I have referred to this design as "Model Pandora" for quite some time and it is unique as a testbed and meant only for that more or less. I'll just let the images talk for the most part.


On "Delay change per step" pitfall and salient features of the stepper motor bolt drive.

Time to geek out about motor technology a bit. As a starting point an excerpt from FDL-2 non-plus firmware:

void StepRange(int stepperPin, double startDelay, double endDelay, double steps){
 
    double delayChangePerStep = (endDelay - startDelay) / steps;
 
    double loopDelay = startDelay;
 
    for (int index = 0 ; index < steps ; index += 1) {
        digitalWrite(stepperPin, HIGH);
        delayMicroseconds(loopDelay / 2);
        digitalWrite(stepperPin, LOW);
        delayMicroseconds(loopDelay / 2);
     
        loopDelay += delayChangePerStep;
    }
}
Okay, we've all heard the usual runaround about open-loop stepper drives for feeding darts in nerf guns. The one about too much torque decay at high speeds to run reliably at higher ROF and all that. Well, this function above is right at the core of the matter, and no offense, there's a pretty big and apparently very common blunder in it. Angular acceleration of a synchronous motor can be expressed as commutations per second squared. Steps per second per second; or if dealing with the period of a signal, delay change per second. Not per step - per second. The motor commutation frequency is increasing, so "delay change per step" doesn't generate anything resembling a linear velocity/constant acceleration profile. Rather, it gives linearly increasing acceleration, and quadratically increasing velocity.

That is the very LAST thing we want for actually driving something, to accelerate harder as speed climbs and the torque curve drops off.

How about a graphic long timescale example of what this is doing:


https://www.youtube.com/watch?v=25XOH7JPU5w (Check the code in the description!)