Project T19 Part 13: Part Model Bugs Stomped; Core Visual Schematic

A super quickie:

The Rev2 models for the Gamma Major main section (enlarged phase wire channels), grip base (add clearance notch for the drive housing spring perch reinforcement thingy) and breech (trim the lower edge of the side cover mounting bosses) have been added to the Google Drive. Should be print, drill, tap, deburr, hand fit mag release and trigger axial play with file/sandpaper if necessary, and go.

Gen3 Hy-Con wheels now have a full range of gap settings from the old standard 9.5mm up to 11mm in 0.25mm increments. If you are concerned about decaps or trying to run at less velocity than 175-190fps, those should help. Remember that you probably will want to change your governor settings down from the stock 9.5 wheel 25,510rpm setpoint to match the wheels, even if you aren't trying to go subcritical to meet limits. Hy-Cons seem to greatly dislike being oversped.

Also, this should help you build a Core compatible controller:

https://drive.google.com/drive/folders/1lskje8W1EY8FvAvpWagquWdowgmAX9a8?usp=sharing

I have been thinking over the subject of PCB Core boards and also due to the Project FDL precedent, I have been getting a number of inquiries about assembled blasters and T19 wiring/electronics kits. I'm reluctant to say I won't do either of these flat out, but I just can't supply the world with T19 blasters and turnkey electronics.

I will look into the PCB subject and at least supplying that bit. My reluctance is due to the fact that within probably 6 months, new features will have been implemented and the hardware changed/added to. But at the same time, it's not like a couple dozen Core 1 PCBs would not go to good use.

Chaotic Shortbus functional completion

Does anyone remember the Chaotic Shortbus? Probably not, but it's a build that's been on my mind recently. It's been several years since work started with, thus far, too little to show for it. As of the last update, this project consisted of a nifty concept, a sorta-ugly shell, and a pile of half-completed internals with vague plans for how everything would eventually fit together. There was still nothing that actually shoots, despite the fact that this build started in 2015. Since then, we've seen the end of the great motor drought, seen the rise and beginning of the stagnation of the Rival line, seen the rise of 3D printing as a widespread tool in the hobby, seen the rise of brushless motors, and seen the development of the Caliburn - but, at least as far as the Chaotic Shortbus is concerned, nothing worth writing home about.

There were reasons for this, mostly having to do with the fact that I wasn't confident in how to proceed in certain key areas, but . . . these were not really good reasons to shelve the build, in as much as waiting hasn't helped to make answers to those questions appear, resulting in a half-completed project rattling around and taking up space nigh-indefinitely - a situation which, I realized, was doomed to persist until those still-present obstacles are simply ignored and completion attempted regardless.

So, it's time to finish this darned thing.

Project T19 Part 12: Flywheel drive tuning progress.

I mentioned a while back that I was having trouble getting consistent motor startups out of this one problem gun with its extra-stiff DC bus (and it's a T19, so it runs on 4S too). After perhaps 20 experimental SimonK builds, I think I have that squared away, and furthermore I am happy with what progress I have made on the wheel-drive front as a result.

Current SimonK build here - Afro NFET binary: afro_nfet_reschedule.hex also source for the Afro NFET, (note why I included the afro_nfet.inc file - watch out for board .incs clobbering settings, as afro_nfet.inc would do to MOTOR_ADVANCE!)

This is by no means a SimonK tuning workflow, or anything. Just the directions my experimentation took:

• MOTOR_ADVANCE = 13

Previous to the last post about it, I had nailed down static phase advance (MOTOR_ADVANCE) at 13 degrees. One click higher or lower gave more rotor position losses at the transition to run mode, and the powerskipping to recover from those would result in less consistent spinups.

Next were startup mode parameters. Some N.b.'s about SimonK startup mode: Not only does that change the input filtering, but it forces maximum phase advance. This is, as far as I can tell, unavoidable, because BEMF zero-cross detection with only phase voltage feedback can only tell us which segment of the 6-step modulation diagram we ought to be in. We don't know where we are within that (60 degree) segment. So, applying an angular phase advance requires also knowing the speed of the rotor and that requires knowing the last few timings. If the speed is zero or unknown, it's undefined and all we can safely do is immediately slam the correct space vector at the motor. Now, something about these particular motors and highly advanced timing at low speed - that is very nonideal (I found out by setting MOTOR_ADVANCE to 30 in order to observe it in run mode) and makes VERY little torque. It follows; of course shifting things way too heavily toward the direct-axis current component at low speed. Thus, what matters to us is to enable timing control and set phase advance to something sane that (1) Is reasonably MTPA-ish (because, you know, we're trying to accelerate here) and (2) Ensures reliable sync holding, as soon as possible by quickly getting the hell out of startup mode:

• ENOUGH_GOODIES = 6

What the fridge are "goodies" you ask? That's some dense SimonK jargon. Good zero-cross detections, good commutations, that's all. Stock setting is 12. This cuts the current-inefficient, sluggish startup mode window in half. Seems to have no negative impact, 6 commutations must be enough goodies for these motors to have stabilized a timing measurement for run mode. Also, how long we keep startup mode on appears to have no impact on run-mode reliability and current control considerations - it doesn't sound like these motors are managing to accelerate much in startup mode to speak of anyway.

With the change, acceleration is definitely more prompt. Stock SimonK can "sit there whining at 8 kHz" (it IS turning, just not making much torque and not increasing in speed very fast) for a brief but tangible moment before it really gets rolling. You probably know what I mean. That moment is startup mode staying on until there are enough goodies.

Also messed with:

• START_DELAY_US = 0 (stock)

That adds blanking time before looking for zero-crosses during startup mode (there is also an algorithm that adds steps of delay on every failed start, which would auto-unbreak certain mistuned setups if you just keep trying to start the motor) - anyway; leave the above alone. You can try messing with it, but on my motors and boards, startup mode itself seems to perform well already and cranking this parameter worsened glitchy starts.

So that leads me to working with run mode, which turned out to be a source of some of the glitches.

The key thing here is current control. The back-EMF that is being measured for rotor angle detection is very low at low speed. Slamming too much phase current at the motor can cause too much noise to reliably follow. Sure, it MAY produce harder accelerations to crank the shit out of all the duty schedule parameters, but a harder acceleration that might follow a aync loss and powerskip and thus become a delayed harder acceleration (taking more time overall) 3% of the time, is flatly useless if we are trying to make a blaster more responsive. At the same time, there is saturation in the stator, so past a certain point it won't help as much as you think. And also at the same time, the current control in SimonK is not current control, it is a frequency-based duty (voltage command) schedule, so actual currents scale with bus voltage, and thus with my motor and 4S, it is already considerably more aggro with stock SimonK than, for example, a FDL drive on 3S.

Detour to overview of late SimonK duty scheduling:

* PWR_MIN_START (stock: POWER_RANGE/6) and PWR_MAX_START (stock: /4) set the endpoints of a "ramp" used in startup mode. Normally, PWR_MIN_START is all that matters unless you fail a startup (which like the start delay deal above, modulates more power within this "ramp" on every occurrence, which can help to auto-unbreak problem cases and get motors to at least run).

* PWR_COOL_START is used if a whole shitload of start attempts fail. This is normally set to /24, it is for locked-rotor protection and shouldn't be changed.

* PWR_MAX_RPM1 (stock: /4) sets the lower run mode duty limit, which is associated with TIMING_RANGE1.

* PWR_MAX_RPM2 is deprecated and isn't used anymore, I don't know why that is still there in the source. That was for the old versions, which shifted duty like an automatic transmission in discrete hard steps. Later versions do a ramp that is more refined.

* TIMING_RANGE1 (stock: 0x4000) sets the speed under which the lower run mode duty limit PWR_MAX_RPM1 applies, in steps of 0.25us per commutation step (stock=4096us). Above this speed, the main run mode ramp applies.

* TIMING_RANGE2 is unused, see above.

* TIMING_RANGE3 (stock: 0x1000) sets the ramp endpoint speed at which the duty limit becomes 100%.

* TIMING_MAX is the governor.

And my settings:

• PWR_MIN_START = POWER_RANGE/6
• PWR_MAX_START = .../6
• PWR_MAX_RPM1 = .../6
• TIMING_RANGE1 = 0x6000
• TIMING_RANGE3 = 0x1000

Non-stock settings bold.

Logic behind these:

* We know we have a startable drive and not some random motor (stock SimonK is set up to reliably make any random PMSM/BLDC type thing that anyone might hook up to the controller start and run). Thus, there is no need for the startup mode ramp. Thus, it is disabled by PWR_MAX_START = PWR_MIN_START.

* PWR_MAX_RPM1 being set at /4 produces too much phase current at low (LOW low, like sub-300rpm low) speed, and causes glitchy sensorless operation, so this is chopped back to /6 resulting in MUCH more stable transitions into run mode and effectively no "unpredictable spinup" incidents. Also, it being /6 mates up smoothly with the PWR_xyz_START and prevents a hard step in duty from happening there (which is also a phase and bus current step and can result in problems with noise).

* TIMING_RANGE1 is moved back from 0x4000 to 0x6000. This just about compensates for the previous by starting the ramp sooner.

The difference between the problem drive with my old Model Pandora era build and the problem drive with the new build is night and day and puts the formerly buggy Serial One setup right back on par with or better than the Model Pandora on its preferred battery.

It also has the side effect of better current-efficiency and less heating during startup. The motors are definitely cooler after a series of 0 rpm starts.

The tune should be generally applicable to any 14-pole flywheel drive situation with maybe only a timing tweak for different motor families, and should have the impact of reducing the sensitivity of the drive to battery, wiring, motor and controller variations.

Project T19 Part 11: more parts info, turbo mode demonstration, drivetrain lubrication.

All locked down for combat test at this point. I don't anticipate anything happening, but the old reliable Model Pandora will be on backup duty. I have come to greatly trust that blaster.

 

So first of all I will hit some quick parts-related things that I didn't cover:

The top rail is a AIM Sports 12x0.40". Amazon carries them. Don't buy the other two thicknesses! (The mounting dimensions are different.) 10-24 socket head cap screws (not button head) are required to mount accurately. Again, watch out for that mounting hole depth in the cage! Too long screw can DENT THE BARREL, DON'T DO THAT.

The bolt motor is a OSM (available from StepperOnline) 17HS16-2004S1. M3 flat head (meaning countersunk) screws are required to mount, and a 10-24 x 3/8" setscrew for mounting the crank on the motor shaft. Shaft must be shortened - use drive spacer as a guide and cut carefully with a zip wheel.

Flywheel motors are Turnigy V-Spec 2205 2350kv. "CW or CCW version?" Doesn't matter, it's a bolt-pattern motor and we don't care about which thread direction of prop adapter is included, which is the only difference, because we don't use prop adapters. Again, very careful with your screw lengths around those stator windings, same as drone applications. M3 and M2 button heads. I use, don't trust these OTOH lengths entirely-- 10mm M3 (mount) and 6mm M2 (flywheel bolt) from Hobbyking, those are kind of soft steel and munchy so maybe not the best.

Flywheel motor controllers need to be able to run SimonK (not BLHeli, I do not use, do not like, and cannot support BLHeli, I have no idea what BLHeli would even do on my high inertia wheels and these motors - probably work, with careful tuning, but with an annoying startup lag and without the right sort of closed-loop mode, and you're on your own with the tuning part!) and have a large enough power stage to run these motors. This is not well defined, but any 20-30A controller should be safe. Look up the datasheets on your mosfets. Notably, I would personally steer clear of the Afro 20A RSM/20A Mini, which has the little SON mosfets and typically are Toshiba TPCC8076/8073 (same as the 12A Ultralite more or less!) rated for only 88A? peak drain current, which is kinda scary for running these with 4S on the bus. A hard lockup from speed is something SimonK does a very good job mitigating damage from, but it is finite, and NOT magic, and there's bound to be a little current excursion associated with that. I personally use Afro full size 20A, which is more or less the same board as the 30A fullsize, just with a bit less actual PCB area, and thermally derated. Perfect for our very transienty (but low continuous current, intermittent duty) app. The 20FS Optos come with Fairchild FDMS8018 mosfets, and that's one beast of a device for that size. Some of the 20FS, 30FS and 30RSM come with Toshiba TPCA8087 and that device seems OK too, though I only have a single pair of those.

Note I tune with Afro 20FS Optos and publish binaries of the T19 wheel drive firmwares for the afro_nfet board target. You need either a USB ESC flash dongle like the corresponding Afro one (if you're sure the SimonK bootloader is already installed) or appropriate AVR ISP gear to flash the controllers, a driver for that, and KKMulticopterFlashTool or just avrdude to do the flashing. If your board is not afro_nfet, you will need to download AVRA and build from source. Or ask me/send me the parameters you want if you know them (I don't expect you to, don't worry) and I will concoct a build for your board. Correspond with me if you have tuning issues/questions, too.

The preliminary Core backplane is built on a 2.0x3.0" Vector perfboard that bolts straight into the drive housing. The processor card is an Arduino Pro Mini (not Pro Micro, that's a different board!), you can use generics or Sparkfun first-source ones. You will need the corresponding FTDI USB serial interface breakout board (I got mine from Sparkfun) and drivers to flash the Pro Mini, but this is what I recommend, because it is rock solid and glitchless; trust me, onboard USB on a dev board like those Pro Micro things, is shit and I will never go back. The bolt driver card is a DRV8825 carrier board; all mine are cheap generics, which are fine, TBH. Other bits you need for the controller build and wiring are 100k and 1k resistors, a small electrolytic cap for the 5V rail, a ~220uF low-ESR electrolytic cap for the 8825 driver's DC bus, and male and female headers, lots of them for socketing both plug-in cards and making every cable connector. Note, your bolt limit switch connector needs to come out the back of the board where the big cutout is in the drive housing.

For logic power, I always advise a buck/boost converter, nothing less, for reliability (brownouts are not fun and can happen, there's a lot of current and noise nearby). I use Pololu S18V20F5. It's a big, expensive, overkill monster, but overkilling these things is not a bad idea, particularly the 35V input rating on that unit. A bad or overapplied logic PSU that shorts and puts unregulated DC bus into your 5V logic stuff will smoke your Arduino, 8825 card, and ESCs instantly and then you are out A LOT of hardware and money (including two increasingly-unobtanium Afros if you're using those) over a stupid fucking pocket change voltage regulator.

The schematic is coming; I promise. But if you look at the firmware... It tells you which pins on the APM board hook up to what. Wire em up. Not rocket science. Switch input circuit for trigger (both throws, so 2 inputs) and the bolt limit switch is a 100k in series with the MCU pin (for input protection) and then on the outside end of that, a 1k pullup to Vcc. Common terminal of the switch goes to ground. Pololu site tells ya how to hook up a 8825 driver - except note from the firmware the numerous pins on the 8825 card that need to be controlled in software in this blaster and should be connected to pins on the APM and not tied high or low. Then, you have Vcc and ground to distribute to every Vcc and ground pin, and raw DC bus to hook to the VM pin on the 8825 with the buscap from that to ground, set Vref on the 8825 to 1.0-1.1V, flash it up, plug it all in and away it should go. Unless your trigger cable is reversed and registers a constant down state when up. Then you won't finish booting and get the selftest growl and flywheel blip (turn it off and flip the trigger cable around and turn it back on).

Now to the part where "SimonK says 'get wrecked'":

This is a 22 round Workermag packed full, on turbo mode, set to 14.2rps and doing well. Shooting garbage darts this fast in long bursts can trip up the magazine on occasion, but the T19 is generally rock solid. The only time it skips steps is when it OUGHT TO skip steps, i.e. when a mag misfeeds catastrophically and a typical DC drive would have crunched the round into a huge folded mess (in which case, you let off the trigger momentarily, the bolt backs up and the malfunction normally self-clears). So that's kind of a thing, isn't it? Not quite the spam level of the DC drive FDL, but close, and it's still direct drive and brushless. Remember when there was skepticism about the stepper motor? Well, I guess there is still skepticism about the stepper motor, but I don't see why.

Now, bugs DID manifest and in this case it was a tribological blunder with the Production's all-printed drivetrain after some use. I didn't lube it at all, initially. I ran it dry like the Model Pandora (n.b.: the Model Pandora's bolt is PVC, so it has a dissimilar-material solution in place). The thrust faces on the side of the bolt and the inside of the spacer rails developed some minor galling with the symptom of random skipped steps after too long a burst was fired (and things heated up and got frictiony). Whoops; that was remarkably stupid to not lube that. The flip side is that (removing the galling and) lubing the drivetrain with white lithium grease resolved all problems and made general operation much smoother, and just messing with some scrap PETG prints, a little grease makes a MASSIVE difference in friction and makes galling almost impossible. Regardless, now that my attention is called to what's getting loaded heavily in this design, I'm definitely going to try out a rollerized bolt with some little bearings to eliminate the sliding friction at that one troublesome side thrust surface. Should help at high ROF and assist with maintaining tolerances without hand-fitting too.