Overhaul vs. beta: The Post-Match

OMG THAT WAS SUCH AN EPIC MATCH DID YOU SEE THAT MATCH GUYS IT WAS SO AWESOME AND…

A little early, no? I’m going to be at the Detroit Maker Faire this weekend with all of Friday the 29th being a travel day so it’s either now or next week. If you’re in the area, stop on by the Power Racing Series track where I’ll be acting as technical inspector, Grim (penalty disher-outer), flag bro, or really whatever needs doing. Chibi-Mikuvan isn’t in a battle-ready state, so I’m foregoing bringing it.

For this match, there’s not an extensive backstory and tale of preparing, so I’m going to just jump right into the analysis! So be warned, don’t hit the “Read More” line unless you actually do want to Read More!

Read more “Overhaul vs. beta: The Post-Match”

A Brief Interlude from BattleBots with Brushless RageBridge

Brushless RageBridge alt. Brushless Rage (n): A magical piece of robot hardware that everyone wants to exist, and whose developer keeps promising “eventually”. Kind of like the Duke Nukem Forever or  Deadpool of motor controllers. “I’m going to use Brushless Rages in my robot when Charles releases them.”

in a world

My own brushless ESC design has been a bit of a white rabbit project for years. While it’s lead me into learning a lot about motor control and power converter design, I’ve not actually made a working one. Melontroller version 2 came close in 2010, and it actually did run Razer Revolution (version 1) for a short while before consuming itself enthusiastically and being retired. It also required the now-legendary Common-Mode Nut to work properly. My next attempt, Tinytroller, was basically a miserable failure all-around, but my discoveries made during the testing of RageBridge meant it might not have been a total loss design-wise, just hampered terminally by a connection error in the schematic (that story can be found here).

In the era beween that and the last time I talked about Brushless Rage in 2014, shortly before I had an unexpected robot pregnancy for BattleBots Season 1, I tended to make do with mass-market EV controllers and R/C motor controllers, like a regular person. I don’t like to talk about those times, trying they were. Man, that post was a while ago. BattleBots Season 1 also pushed back regular-old-RageBridge basically a full year.

where brushless ESCs all suck

With the few months prior to the BattleBots Season 2 build kicking off devoted to hacking up HobbyKing controllers, it basically rekindled the flame that I had with my own brushless ESC bloodline. After Season 2 action wound down, I spent some of the intervening period before the premiere thinking about the next steps of the Brushless Rage project.  I didn’t want to keep modifying hardware not designed to do something I wanted it to, in order to get something which mostly works. Having chopped up dozens of models of R/C controllers, I was getting sick of dealing with them. An ESC of my design would mean I can account for all the variables that were cost-optimized out of the bill of materials, and they could be tailored to my specific application of getting the shit whipped out of them every time they are powered on. I wouldn’t need to worry about the global supply chain for #season3 either.  Furthermore, the robot market is slowly shifting brushless basically as I’m typing. And with the discovery of SimonK and other firmwares by the community, suddenly the bar was significantly lowered for the part I hate: firmware development.

It seemed to me that it wasn’t very difficult to get a SimonK compatible basic Brushless Rage put together, and I was in fact about to pull the trigger on the original board design (with a few changes) a few weeks into the build when the Great DLUX Famine of 2016 occurred, a go-for-broke move that was one of the failure mode branch analysis decisions of last resort. Overhaul 2 was a trailblazer in many ways for #Season2 (No, these things will never come without hashtags), so since I’ve reached a point where I’ve stopped caring about R/C hardware, it’s time to move on.

one man

It’s also interesting to see that my desires for a brushless ESC haven’t really changed – something that performs well in roughly the 2 to 5 kW range typically 48V and up to 100 amps. This segment of the market is still poorly served for the casual roboticist or hobbyist. Most Inexpensive Chinese equipment for e-bikes are 1kW and under, otherwise you’re looking at unreliable R/C controllers or really expensive industrial ones. This is where I come in.

But first, let’s rewind all the way back before BattleBots ruined my life yet again and see where this first model of Brushless Rage ended up.

Recall that this was the “component splattering” I first put together in late 2014. I do a bunch of trial layouts without schematics just to see if there’s enough space to do what I want. The form factor is still “RageBridge”. This board is based off the Arduino Leonardo, which has since been discontinued anyway.

After the component splattering is established, I then make the schematic (not shown here, but plenty of other examples abound). This is the final layout I decided to use, since it provided a clean U-turn path for DC current and three straight traces for the motor phase current towards the right side of the board.  The gate drive passives have been arranged around the A4910 chip for its own local sanity checking, and otherwise the micrcontroller and logic power supply are already arranged (and basically identical to RageBridge 2’s known good setup)

 

I enjoy a good game of “detangle the gate drive traces” every once in a while. Brushless (3 phase) makes this more entertaining since there’s an extra set to route!

Here’s the hilarious way I ended up routing those traces. What’s with the little curly offramps?!  Well, the traces all had to turn 90 degrees, but 90 degree hard turns are less desirable than 45s or straight lines. I could have gone with simple 45’s, I suppose, but decided to get cute with things and use the spline routing method instead.

This is the bottom layer of the board, looking the most “circuit board” of anything I’ve ever designed. There’s 6 gate driver lines logic pins from the microcontroller (three high, three low) to detangle, plus numerous other control pins and feedback pins. It also showes the layout of the power traces.

Finally, this is the completed version 1 board as of December 2014 or so. I actually had several boards made along with the version 1 of the RageBridge2 boards, but never did anythng with them.  Knowing what I do now about RageBridge 2’s design though, there’s a few things I’d change about this board before populating and trying to use it.

but now

Fast forward to about two months ago, and my desires to try again were high. Seeing the HSOF-package FETs used in the Vex BB controller at Season 2 also spurred me to try that package, which I had only speculated out before and whose high price per unit in low quantity kept me from buying a rail to blow up. However, I found that other companies besides Infineon also made parts in the package, such as the Fairchild FDBL0150N80, which were priced much closer to my favorite D2PAK-7s.

The HSOF package has very short legs, which enabled tighter packing than the D2PAK-7 devices. This was both a blessing and a curse, since I usually ran traces under the ‘overpass’ of the legs, but the tighter packing would potentially allow FET packing in parallel for more current. A lot of new leadless packages for all sorts of devices really want you to use them with 4 layer boards, and I openly admit that moving to 4-layer would have made life a lot easier and added current capacity.

I also did some more look-ahead for the architecture of the controller. One of the things I wanted to do with RageBridge2 was finally move to a split signal board and power board architecture, which is fairly common the higher amperage R/C controller market. This would allow me to finally use 4+ ounce copper on the power board, which the fine pitch packages and traces of a signal board wouldn’t usually permit. The signal board could also be designed with tiers of components to drive differently sized power boards…. just look at my dreams of this from tinytroller (That’s a 600V, 200A, 3-phase IGBT module…)

So here we go. I decided to play with placements first, once again. I basically just imported a RageBridge outline to start with, to see if I could keep the controller in the same size class, rather than define a new physical form factor. The hidden agenda of this is that I have 1000 RageBridge 2 heat sinks and only 250 RageBridge 2s, so I’m gonna use those damn heat sinks!

 

One thing I was unclear on at the time was whether I wanted the gate drivers on the board or not. Having the drivers on the board would make the logic-power separation even more strict, as the only thing passing between the boards is command signals, not even the (relatively, compared to logic) high powered gate drive signals. This took up more space on the board, of course, so I had to get to a point first where I could judge the space requirements. You could really make an argument for both approaches, but the gate drive on logic board is more common in R/C-world.

I also made this crazier version which is basically just a block of MOSFETs. This was a complete “out there” concept, as there’s too much semiconductor to be useful – the rest of the board won’t really be able to support the current, and those two lone capacitors will become depressed quickly.

It also left zero space for things like current sensing resistors or really any gate drive parts. But it did show the potential of the HSOF package if I decided to make this board even slightly bigger to permit these components.

Another musing was if I could use the D2PAK-7s that I already have. The answer is “barely”. It also really needs a bigger board to work out. This specific layout, for instance, would make adding current sensing really difficult.

There was another version which I did not take a screenshot of where the FETs are spaced closer together after I played with gate drive routing, which left space for current sensing resistors on the left where they are picture now.  This version was actually a candidate worth pursuing if I did not end up using the HSOF packages.

Getting a little more serious now as I start actually listing the signals I need.  This is now back to the first configuration.

While I don’t intend to make current sensing a priority (as SimonK doesn’t support it), I made sure to add all the possible signals I WOULD need, which includes current sensor feedback pins and a thermistor, for instant.

(Kelvin refers to a Kelvin connection, by the way)

At this point, I also started thinking about what signal header to use. The 20-pin wide through hole header row was not the final selection. I looked around first in the libraries of parts I had to see if anything tickled my interest. While the common 0.1″ spacing single row headers would have worked, I wanted a more production-ready solution and also wanted to browse what the latest offerings on the market were.

Off to Digi-Key and Mouser for some window shopping. Connector manufacturers will often sample parts for free just to get you hooked on their product, so you keep coming back wanting more, and eventually you’re standing on a street corner with a baggie of mezzanine headers.

I found what I liked in a Samtec product, the HLE series. This is a “pass through board” header. My qualifications were basically…

  • 0.1″ pitch, so it is easy to use as an extensible standard – anyone with some perfboard could potentially work with this design in the future
  • Two row, since 1 row takes up too much boardwidth and three rows is more painful to route
  • Pass-through-board (connector on top side) because I did not want to pay extra for double-sided SMT assembly for ONE PART (the connector) which would be necessary for a non PTB design.

So I sampled a handful of HLE connectors and matching male-side dual row terminal pins, their TSM series. After getting these in hand, I decided to move on with them.

I generated the footprint for this part according to their datasheet, but the pads are a little shorter than specified to give me more space to work with. Check out the current working arrangement now. The decision to move the gate drive offboard was made, so this freed up space for more capacitors as well as current sensing. I realized that even two FETs in parallel was going to cause a massive capacitance shortage. Cue a day of shopping for the latest in capacitors…

In the end, I’m only able to get around 2,600uF of bus capacitance at 63V ratings – two 820uF large cans and three 330uF smaller ones. This ought to be sufficient, and is on par with RageBridge 2 which was easier to buy caps for due to its lower voltage operation.

This board is also about 0.25″ longer than RageBridge 2, accomplished by exploiting Eagle’s 100 x 80mm board limits by using the “Well, technically, it just limits where your COMPONENT CENTROIDS can be placed” method.

So I honestly tried for a while to put all the outputs on the right side for convenience. The narrowness of this board wasn’t very conducive (hehe) to it since it left very little space for power traces. This would limit the current capacity due to trace resistance, and ruin the point of two devices in parallel.

Again, a matter that a 4-later board can help fix, and so I might try a 4-layer version in the future.

 

In the mean time, to keep life simpler for initial testing, I moved the motor phase outputs to be next to the FETs. This also let me push everything to the right a little and give more space for routing.  Pictured above is the first shot at the power board, which was, uhh, rage-routed in my typical fashion.

This screenshot also shows the working project name for Brushless Rage, which is “ThreeBridges”. I honestly don’t know, because it sounded reasonable. Technically, you could argue it’s only three half-bridges. Go away.

Now that the power board is settled, time for the signal!

I set the signal board size constraint as being no wider than the two mounting screws on that end of the power board such that I could still unscrew them. The length was dictated by hitting the phase wires. This is after the “initial scattering of components”, where I was routing the logic power supply little by little at the top. For now, I put a row of right angle headers on the left side to make sure I leave space for routing signals, even though the SimonK board would only need one R/C servo input.

The gate drivers are all new – the FAN7390, which is like my old favorite the IRS218x4, but with a little more crank and with independent inputs. I went on the hunt for gate drivers that offered Vss-COM floating capability (kinda-sorta isolation) that were higher current than the IRS218x4, and found these quickly. Sure, why not!

The logic regulator is also a new addition to Charles_Favorite_Parts.lbr that I hope to learn to love. I decided to leave my good ol’ LM2594 behind and explore the higher voltage market a little. The LM2594HV is my go-to for all up-to-50v solutions, but I eventually wanted to go higher with this controller.

From looking at the DLUX 250, I know it used a LM5009 regulator, so I shopped in the same family of DC/DC regulators to start with, while also letting DigiKey show me what worked for my specifications. Ultimately, it seems like the easy one-chip converters stop around 100 volts. Makes sense – the higher you go in voltage, the less standard/well characterized the loads tend to be (e.g. every consumer electronics device hovers around 5-24 volts for power so there are many one-chip ready to go solutions).

I settled on the LM5017, which has roughly the same operating voltage range, can switch near 1Mhz (which I wanted to do in order to reduce passive size), and is higher current, for in the future if I want to drop this design on a more powerful gate drive.

This chip is a little………..special. I’ll get to that in a bit.

 

Moving more components in now – the microcontroller’s support passives have been added, the resistive sensing network for phase voltages has been added, and a new challenger appears at the bottom… what’s that? It’s a TLP2160 2-channel optocoupler in a SOIC-8 package.  I wanted to get into the habit of opto-isolating the logic signals, since it cuts another point which noise from coupled EMI or ground loops can be injected into the logic, so I explored the space of small optocouplers a little, most being the larger wide-DIP size. This part is another “Digi-Key, are there any in-stock parts that match these peculiar spoiled brat needs of mine?”

 

Version 1 of the signal board is complete after some more routing! This board was almost theraputically easy to route for some reason. The joys of having ONE INPUT and no giant MOSFETs next to you…

A quick synthetic image showing the stackup of boards.

These boards were sent out for fabrication through my current favorite shady Chinese PCB source, 3pcb (not to be confused with 4pcb, or really any of the [1:10]pcb.com places). The signal board was to be fabricated in regular 1oz copper, and the power board in 2oz. I could have went for the full 4oz, but it was more than twice as expensive as the other options, so for a test board, it was not justifiable.

In the intervening week, I ordered a load of BOM parts from Digi-Key. First up is the HSOF package FETs!

Man, these things really are like a D2PAK-7 with the legs cut off. Pretty sure I can get the same effect doing it manually myself and save some money…

But less facetiously, they’re much thinner than the D2PAK and so have less thermal conductivity problems from the top side. They’re still designed to be heat sunk primarily from the bottom, though.

Everything else! There were so many new parts involved this time…

A day later, the PCBs show up. I’ve worked out that if I hit “go” on the DigiKey order as soon as I get a shipping notification from 3PCB, my orders will make it here in roughly the same timeframe (+/- 1 day).

The first thing I wanted to try out was the board stackup height. I was correct in choosing the male header pin height here, since the signal board sits just barely a millimeter higher than the tops of the FETs!

Next begins the job of populating the boards. I started with the signal board, so I can quickly test “FET integrity” by manually poking the drive pins with 10 volts to make sure nothing is dead.

The capacitor farm on the right was going to be impossible to assemble unless I tried some trickery. For the pins in the middle of the aisle between the small and large capacitors, I ran a bunch of vias to the bottom layer and added a small square of solder mask stop. That way, I can solder the capacitors in from the bottom by holding the iron to the bottom side and feeding solder from the top side.

Not a production tactic, but good enough for now.

I built this assembly in stages, testing each ‘new thing’. For instance, the next family of parts to assemble was the 15 volt gate drive power rail supplied by the LM5017.

This is where things got exciting, and where you have to know how technical datasheets for chips are produced.

First, a team of engineers working high up in a mountaintop monastery like this one writes the specifications for the chip – its operating voltage range, logic input thresholds, current draw, and so on. They summon the Gods of Silicon Fabrication through magic-smoke-heavy ceremonies shrouded in secrecy, tradition, and middle management. Next, to bring the chip into the world, the datasheet must be written by a group of immortal, trusted unpaid-intern scribes. Unfortunately, as this modern electronics research facility is a mountaintop monastery, it has no Internet connection.

So the chip specfication and application & design notes are communicated via one of several methods: via magic-smoke signals, or by dropping smooth pebbles from the mountain in such a way that they bounce a specific number of times before hitting the ground, with the number of times being interpreted as a character or a vector graphic drawing command. This is, needless to say, not a lossless method of communication, as winds and weather can hinder the processing of the smoke signals or inhibit them completely, and the backup provided by the dropping of the pebbles could be corrupted by the law of probability and how many mountain goats are grazing on the way down.

What I mean to say is, datasheets often suck and have inconsistent symbolic notations and naming schemes that make it difficult to understand precisely what is being asked of the designer. I messed up a few passive part value calculations (such as the feedback network filter among other things) which meant NOTHING WORKED. AT ALL. GOD DAMMIT. until I ran through the design equations basically 3 times before I finally got that ohhhh, you meant the on time AT MINIMUM DESIGN INPUT VOLTAGE, not maximum like the last page was talking about.

Then I got it to work.

This was the culprit. What is shown here is the waveform at the feedback network. Essentially what’s going on with this regulator is that it uses the voltage across the output inductor as a feedback element.

Capacitors, specially the output capacitor, take a little time to fill up (voltage to build up – current leads voltage) after you feed current into it, and by the time the final output voltage – taken directly from the capacitor in the usual case – rises above the feedback threshold, shutting off the current in the inductor then takes a little more time (voltage-leads-current), which fills up the capacitor past what is desired. You can often get an unstable feedback loop going this way with the regulator always hurrying to do exactly the wrong thing, and your output voltage becomes unregulated. The type of feedback network used by the LM5017 is more complex, but it eliminates the capacitor as a source of lag in the response.

What’s seen in the waveform is the scaled inductor current (represented as a voltage) increasing (ramp up) as the regulator pushes current from the input side (battery) into it, the peak tripping the feedback threshold, and then ramping down back down when the regulator shuts it off. The peak shifts left to right depending on the duty cycle – basically how much time the regulator keeps the current on vs. off.

This is a small waveform imposed upon a DC offset voltage which is provided by the usual two-resistor divider, which is for large-scale changes; for instance, a sudden load might drop the DC voltage significantly, which means the peak of the triangle won’t reach the regulator’s shut-off threshold, basically sending a “NO KEEP IT ON LONGER FOR REAL” signal.

The astute electronics engineer would note that I technically didn’t have to do any of this, just implement a normal feedback circuit, because the gate drive power can be “dirty” since the microcontroller’s power is derived from its own linear regulator from that, but I wanted to get used to these kinds of feedback circuits since they’re more common on high voltage regulator parts.

This is the output voltage at the ‘switching node’ – the output pin of the regulator, before the inductor, doing what it’s supposed to do finally . Again notice how it matches up with whether the slope of the feedback voltage goes up or down.

Mystery number 2 of this chip was that it clearly did NOT want to run at 1Mhz. It just sort of went crazy and the output waveform was extremely unsteady and not remotely square like this one.

I backed down the design frequency to about 600khz, and all was good.

By the way, thesea re in fact all screenshots from my beloved DSO Nano Quad.

Okay, with everything populated, it was time to take it for a literal spin. I designed the signal board to be a directly compatible port of the SimonK DLUX settings I made for Overhaul, so this part was super easy!

Aaaaand…. nothing happened. Hmm…. Well, at least it didn’t light on fire instantly! I have created something that is more than just an elaborate firework.

First little blue wire hack time!

So I read the TLP2160 is an inverting output. Sure, makes sense, most optos are set up that way. So  I just wire the output in an emitter-follower configuration and all is fine, right?

Nah, it’s a push-pull output that can both source AND sink current, overriding your clever inversion by doing whatever the fuck it wants. Whoops. So instead of reading  1.5 millisecond long pulse from the ratio, the ESC was receiving a 20ms – 1.5ms = 18.5ms pulse and becoming very confused. Time to bypass it for now… On version 2 of the board, I’ll add a tiny transistor inverter to make up for this.

Okay, it’ll definitely work now! Right!?

Well, I can hear it trying to do something, but it’s obviously not driving anything. Scoping all of the low-side MOSFET pins showed they were being switched on correctly, but none of the high-sides were driving at all.  Perhaps the bootstrap capacitor arrangement was too low-value to pump those big fine MOSFET gates. Nope, the voltage at the bootstrap capacitor read just fine. Might as well double check the pinout connection and…

 

Oh dear.

Again, another “Electronics engineers might get this” reference, but take a look at the FAN7390M1X datasheet and let me know what I did wrong.

Alright, more little blue wires time. I fixed this issue in the chip footprint and symbol right away, and it’s also now queued up for revision 2.  The other two drivers also needed this same hack.

OKAY, IT’LL FINALLY WORK NOW! AAAAND….

*twitch*

*twitch*

*twitch*

Whoops. Another transcription error. Who’s the unpaid intern monk scribe communicating via smoke signals and goat droppings now?! Fortunately, this was quick fix. Ahhh, software…

Without further ado, I bring you….

AAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHH WHAT IS THIS MADNESS DID A MOTOR CONTROLLER I MADE JUST WORK ON THE FIRST REVISION

literally because i didn’t write the software.

Not shown was the test after this where I almost beaned myself with a SK3 63/74 outrunner when running from Sadbot’s 10S battery. It tore itself out of the crude clamp and alligator clips I set up on the table and proceeded to attack me.

There was one additional small hack I had to make, and it was that the bootstrap capacitance was indeed a bit low for how fast I was switching and the gate charge of two MOSFETs, plus gate-to-source “insurance resistor” leakage. It ended up that I need something like a 4.7uF and I had a 1uf installed from stock since I already had it. The high-side drive voltage was sagging pretty far during long slow commutation cycles. I intend to resolve this by installing the correct capacitor next time and also backing down on the Rgs from 10k to perhaps 22 or 47k – something to keep them happy under undefined drive states, but it doesn’t need to be that low.

Well, to keep things going for now, I’ll just DROP ALL THE BASS on it. How’s 101uF of bootstrap capacitance sound to you? Good? ALRIGHT!

Future revisions of the signal board, or a different signal board altogether, may see a charge pump or other kind of high-side drive supply added. For now, it’s fine if the high-side gate drive voltage sags a bit on longer switching cycles, which would happen with slower motor rotation near full throttle, such as if I drive a bigass hub motor instead of a small fast R/C motor.

Shown here is my DSO Nano Quad and a bunch of little blue wire probes that I was moving around to check my work.

 

Here’s what a gate drive signal looks like! Nice and clean, just uner 1 microsecond switching time. The small twangs are the complementary (high-side) transistors turning on and off, which shows that my deadtime could afford to be a little less, but I will probably keep it here for insurance purposes – transistors start switching slower as they get hotter, for instance.

Again, this is on completely unchanged SimonK DLUX settings from Overhaul.

Out of curiosity, I took a snapshot of the phase voltage divider output (going to the microcontroller, blue), and the virtual neutral point (star network, yellow) which the controller bases its switching decisions from. For more technical and whimsical info on this process, see Xo’s post.  The controller bases its switching decision on the last drive state of the motor and the “zero crossing” – actually the phase voltage crossing the virtual neutral point.

The signal is clean enough and my switching is fast enough (sub 1 microsecond) that I may try increasing the switching frequency even further. Right now it’s around 20khz, and I’m thinking of trying 32khz. The higher the frequency, the less work the capacitors have to do, the more opportunities the controller has to sample the zero crossing, the lower the magnitude of current pulses which could induce noise, and the less I and my friend’s dog hear it. Downside is increased heating of the transistors in the form of switching loss, because how happy would you be if someone slapped you 50% more times a second?

All of this is speculative. My goal is to build three to four working units and beat them up using the SADBOT vs. OVERHAUL method, which I know everyone has been dying to see, including me! The revision 2 signal boards, incorporating most of these changes, arrive later this week, and my BOM for making a few more power boards should also get here in the same timeframe.

In the mean time, it’s time for OVERHAUL VS. BETA this coming week of BattleBots! I have a post-match being put together for that too.