At one point in time, I think I was working on some kind of motor controller. In fact, I might have sold a few here or there! And some of them might even still be working!
It’s been six months since I had an unexpected robot baby and had to drop RageBridge development efforts. But I’m glad to say that much progress has been made, and the first batch of beta testing units is almost ready for the SECOND Somewhat-annual RageBridge Breeding Program. We pick up the story again in June…
Here are some revision 3 boards under construction. Revision 2 was slated for immediately after Motorama 2015, but I discovered enough stupid board bugs on it to warrant skipping directly to revision 3. Namely, there were some incorrectly assigned pins to the ATMega chip and the current potentiometer was backwards. There were a few other trace optimizations made.
I use a small soldering tip – a Weller NT1 – to do everything but the “big power” components, then switch to a big chisel tip iron with a Weller LTD tip to restrain the FETs and other heat-grubbing parts, including the main capacitors. The gate drive chips, in ever-convenient TSSOP package, have their center thermal pads heat gun reflowed first, then the legs are soldered individually.
Two test units of Revision 3 built out and ready for abuse. At this point in development, the firmware was left in an R/C-only, hacked together mode. I began refactoring code I’d written “just to get by” for Motorama. At the same time, I started testing the boards using some standby motors:
Here’s Rage2 being tested on some motors it’s meant to drive – something roughly DeWalt sized, perhaps, and a scooter motor. I’m finding out some critical characteristics of the system, such as “Will my MOSFETS consume themselves?” (the answer is some times), and “Will it reset or stumble because of noise?”
Unfortunately, the answer to the last one is yes, and probably contributed to the Revision 1 unit that died at Motorama. With any hard reversing or command stepping – moments when the current draw increases sharply – the controller would reset, brown out, or exhibit other forms of bad behavior.
Uh oh. I’d been through this before, with RageBridge The Original, so I immediately checked the usual suspects. Poor ground routing. Placing capacitors in the wrong place such that they broke the grounding discipline. High power switching next to vulnerable signal traces, and so on. In the world of power electronics, where you put things is often more important than what you put there.
That’s my 5V logic power line, measured at the output of the power converter, being punched by nearly 1Vpp transients.
The brown wires are scoping points where I’d pay attention to the behavior of the system. The two blue wires were intended to jump the logic power input – which, up until this point, had been taken from the very end of the power plane feeding four gigantic MOSFETs – and gives it its own connection directly at the bus capacitors. It’s kind of like making a reverse Kelvin connection for the logic power.
As I suspected, I made a “cap derp”. The Allegro A3941 datasheet is not very clear (to me) about what it considered signal ground or power ground. In my view, it could stand to be a lot more descriptive about which pins need to be considered “dirty” – directly connected to switching power, so they should under no circumstances be routed to logic/analog ground. Instead, they choose to distinguish between “quiet ground” – what I’d call the logic ground – and “controller ground” vs. “power ground”.
I think I made a mistake here in routing the chip’s main bypass power – which is connected to VDD (battery positive) and “controller ground” – which I interpreted as logic ground for this board, but really should not be. I decided to try jumping this capacitor directly to the chip’s “ground” pin instead of taking it through the ground plane. I did the same for several other capacitors indicated on page 18 of the datasheet, forcing their “ground” sides to avoid the logic ground plane and basically making the only access point of the chip to the logic ground plane at its own ground pin (instead of in a few places).
These two hacks together basically resolved the resetting problem. I could no longer get the DeWalt – a very “dirty” motor, electrically speaking, to reset the board even with current limits off.
Once again – not what you put on the board, but where you put it.
With that cluster of issues resolved, I pushed a “revision 4” with a few other changes like trace optimizations under the microcontroller, separating everything into a “tree” topology as much as I could – no longer was the 5V supply for the chip coming from 2 different places (!). All the microcontroller’s grounds were gathered and tethered to the plane at 1 location. I also separated the 5V line into a “clean” and “dirty” line – the dirty one is the one fed out to the headers, leaving the “clean” line, which is tapped after the final LC filter stage, to only the microcontroller and current sensors.
Some illustrations of trace optimization for the microcontroller region.
A week and some later, Revision 4 appears…
Okay, so I still had to put them together. This is what the board looks like.
Yes, on the last revision, I forgot to hit “Black LPI please!” and so it was green. I shall not make that mistake again.
This board refused to power on at all. No matter what, the 5V rail never came on, and instead hovered around a few tens of millivolts. What gives? How did I take that many steps back!?
I have a tendency to resort to “explosion debuggin” quickly. That means just running unlimited amps at a low voltage through what is shorted, and seeing what begins smoking first. Every motor controller I’ve made save for LOLrioKart’s controller has been “explosion debugged” at least once. And that’s only because I was running low on the large “brick” MOSFETs.
I took one of the spare boards and ran 10 amps through the 5V rail. Amazingly enough, nothing started smoking, indicating something very low impedance and near to the source. The board did get suspiciously warm in one corner, so it was under the microscope…
Oh my goodness.
It’s a left over stub of a trace that I thought I had erased, but in fact was still there, bridging my 5V straight to ground.
So you might be thinking… But Charles, wouldn’t DRC have caught this? Well yes, but my boards generate so many DRC errors (on the order of 1500+) I just ignore them all and use freedfm.com to check for the most obvious stupidity, but it doesn’t tell one net from another!
This is really just telling me I should set up design rules to actually conform to how I design boards ಠ________ಠ
Well, I suppose I’m glad I don’t have to do this for 250 boards.
A revision 4 board being absolutely hammered to death by the “end boss” of motors – the AM Equipment “D-pack” motor, a marine diesel engine starter motor that, many years ago, drove heavy- and superheavyweight Battlebots with contactor control because no ESCs existed which were hardcore enough to handle them. They can easily draw over 1,000 amps at 12 volts, and their no-load current alone is 30 to 40 amps.
And RageBridge passed the test spectacularly. Check out the “abuse video” here, featuring some other motors while I’m at it.
This is not to imply Rage can control 1,000 amp motors, but that the current limiting algorithm is robust. If I held onto the throttle for longer, the FETs would have unsoldered themselves and attempted to escape. It’s ultimately still thermally limited.
Some more brown fungus sprouts to double check that the noise demon has been exorcised enough within the performance envelope of the controller to not be a nuisance. Notice how I didn’t say eliminated. There’s no such thing in motor controller design.
The story, however, doesn’t end there. You know this to be true because if it did, I would be taking orders right now.
Ever since one of the late models of RageBridge 1 prototype, it has not wanted to operate above about 33 volts. The 5V converter would just shut off and enter what seemed to be a discontinuous mode, or some other mode where the frequency of switching was cut back drastically. Here’s an example, looking at the output pin of the converter BEFORE the inductor:
That’s normal – 24 volts in, 5 volts out. As soon as the voltage crests about 31-32 volts, this happens:
Less than 1 volt out! The ringing indicates that the buck converter is operating in discontinuous mode, but to enter it so quickly and suddenly? Something was going on. During this time, the LM2594 chip itself also got hot quickly, which is not advertised or documented behavior in discontinuous mode.
This fact has prevented RageBridge from operating above 30V reliably, forcing me to rescind the “up to 36V nominal” specification, which fortunately only affected a very small number of users.
So what gives? The LM2594HVM chip is supposed to run up to 60 volts. All my parts in that part of the circuit are 50V on the input, so it ought to at least be fine with that.
I ended up spending the night trying all sorts of stupid things, like making these inductor sculptures. Perhaps the inductance was still a little on the low side? After all, my HV requirements are still in the “coffin corner” of the LM2594 inductor selecton chart.
Nothing changed.
So what has been a constant factor in these boards? The LM2594 power converter design, which has been more or less copy and pasted from older schematics without change. However, everyone else seems to use them fine, including Shane. Since we talk about motor controllers like normal 20-something cosmopolitan guys talk about craft beers and beard maintenance (I have nothing in that department), I went to him for some more perspective.
Umm… let’s take a look at the schematic.
That part number – the MBR120VLSFT3G, is a 20V, 1A Schottky diode. In fact, I found the exact version of RageBridge 1 where I elected to put this diode in: it was when I switched back from the LT3433 buck-boost converter and remade the LM2594 circuit from scratch.
This sounds all too familiar.
Anyways, I likely picked that diode to minimize the losses associated with forward voltage, forgetting the fact that the Output pin of the LM2594 is connected to battery voltage periodically. The lesson here is therefore
don’t use 20v diode at 30v it doesn’t work
I shipped 94 of these.
Sounds good. I replaced both of the MBR120VLSFT3G parts with 50v parts – what I used in RageBridge versions long ago, the STP0560Z.
Three of the four Revision 4 boards in various stages of construction here.
Undergoing a little more stress testing here, now with the D-pack hooked up to a…. leftover propeller from the GLP electric boat class. I wanted a bit more viscous load such that it can draw more amps at higher duty cycles, as well as have a up to 950% greater chance of decapitation.
What else is new? After validating R/C mode, I used the same output driving kernel to make the “EV mode” a lot of you have been craving. I made the signal processing code as modular and functional block-like as possible, sacrificing some speed for the ability to pipe whatever garbage signal into it I please.
Analog mode has two submodes :
- “unmixed”, using a sprung throttle. Single ended, expecting 1 – 4v active range to represent 0 – 100%, with a discrete reverse switch, or
- “mixed” using 2 analog joystick axes centered at 2.5V, with a 0.1 to 4.9v active range, controlling forward and reverse and turning in one joystick. This was even easier to write, because that’s literally the same code as the R/C mixing mode.
Selecting the “Combine” jumper forces the outputs to act together, creating a single channel controller. Combine and Mix jumpers are mutually exclusive and logic-checked, since it can’t be single and 2 channel at the same time!
This single channel mode is still not entirely reliable. I’ve rebuilt one of the revision 4 boards twice, finally electing to scrap it.
Since it still is paralleling devices at the driver level, if one driver hiccups or lags, it’s easy to cause cross-conduction (a high side and low side FET of the same half-bridge turned on at once) and destroy everything instantly. To counteract this, I’ll likely increase the deadtime – which right now is just barely enough to not cause cross-conduction in one channel mode – to permit more timing slop.
Will from Hypershock paid a visit to help me test single-channel R/C mode on Hypershock itself. Unfortunately, the aforementioned unreliability made this test largely a flop. However, if I improve this reliability, Rage2 in single-channel mode is a great match to a single “short” Ampflow motor, which means it’s not out of the question for use in heavyweight / BattleBots classes.
The price of progress – the twice-rebuilt and scrapped board, along with some more destroyed parts. After a board blows up once, none of the semiconductors are really the same ever again, so I’m not sure why I even bothered with rebuilding.
When one Rage dies, 10 more take its place!
These are “revision 5” boards – hopefully the last of the revisions, and once assembled, will go out for beta testing. A few are slated for appearance at Dragon Con in 2 weeks, another few are being sent to Power Racing Series competitors to see how it holds up under the rigor of racing. Two completely different loading regimes and set of input & output requirements!
It’s time to order more gate drivers.
Also, here is an interesting picture.
