Archive for the 'Motor Controllers' Category


The Return of a Legend: ChibiKart Reunion Tour feat. Brushless Rage

Jun 20, 2017 in D.P.R. Chibikart, Motor Controllers

Brushless Rage is moving along quickly! I’m really hoping now to do a limited release (to people with known loads and needs) in time for Detroit Maker Faire. I’ve been working on it more sporadically in the past month due to other… obligations? but now I see the tunnel’s end. Here’s what’s been going on with it in the past few weeks when I haven’t been hiding under a van.

So that 2-way optocoupler salad was good in concept, but it ended up being incompatible with its purpose in life: to communicate bidirectionally so I could use the servo cable as a programming cable for SimonK/BLHeli enabled bootloaders.

It seems that the protocol requires the ability to tri-state, or at least assert both high and low logic levels. The circuit I modified can only drive high (or low) and otherwise has to rely on a pullup resistor, and that might not be playing nicely with the needs of the protocol. That is something I haven’t studied in depth due to its poor documentation, so if you know the specifications for the protocol, chime in!

Either way, it was looking like the final board revision would just use a single unidirectional optocoupler for the R/C signal input, and another galvanic-coupled pin on the same line but on the microcontroller’s side of the optocoupler as a programming header.

When the optos were bypassed (….again…. sigh) I was able to use the AfroESC programming dongle to re-upload firmware and change settings at will. The first step in this process is to flash the ATMega microcontroller with a socket and use the Enable Bootloader setting in KKMulticopter. Then I can just use the USB dongle instead of breaking out the socket every time.

I prepared two units this way, and also had heat sink plates cut. These heat sinks were designed a while ago for the Half-Rage that doesn’t exist yet – it has exactly half of the spacing of the mounting holes of RageBridge! So it was a good pick for the 6-FET power board for Brushless Rage. I cut out a square of silicone pad to fit underneath. In the ‘production’ version they’d obviously be die-cut to shape.

So now I have two mini Brushless Rages. What would I ever test them on!?


It’s back! I reclaimed the D.P.R Chibikart from the MIT shop not long ago, since they were refreshing a lot of the space displays and I’ve been gone a full year and a half now (…). This thing was kind of the pinnacle of my design class years, it having won an Instructables contest and all, and serving as a foundation for not only my next few years of students but for about a dozen or so builds worldwide (possibly more – those are just ones who wrote home).  A lot of tricks and hacks were used on it to make things easy to build for people without machine shop access. It’s also just stupidly fun to drive, and before the MIT IDC became populated extensively, we had stupid indoor go-kart races in it.

Over the intervening 2-ish years after my EV building class finished its run and now, it had been on display in various forms, so it wasn’t operational. The batteries had been removed and the motors’ sensor boards (which were partially designed for vehicle projects like this!) were broken off.  So I was just going to rewire it from scratch to accept two Brushless mini-Rages!

I focused on mechanical restoration first, like retightening some bolts. I had to add a new chain on the right side since the old one fell off (with the sprocket) a long time ago.

The sprocket itself is also quite well used, and the set screws are no longer very tightenable without stripping. I’ll likely have to drill these out to rethread them later due to the much higher potential torque going through them now with Brushless Rage.

Battery-wise, I decided to look for a 36V solution to make sure they can operate at 10S/36V reliably. I had some older 10Ah e-bike packs which were given to me with broken BMS cards. So I just removed them and soldered output wires in place. Classic!

The output wires terminate in XT-90 connectors, which were also retrofit to the existing wiring harness.

The Brushless Rage units are mounted with not much more than some Dual-Lock patches, and.

I had to pick through two boxes of random electronics to find my last working servo tester unit. In a pinch, these can be chopped up to accept Hall Effect throttles in place of their potentiometers. The Hall throttles typically put out between 1 and 4 volts instead of a full 0 to 5 volts, so the motor controller would need a calibration ability to get the full range out of it.

As expected, the Hall throttle’s 1 to 4 (well, about 0.9 to about 4.2) volt swing puts out somewhere around 1.13 to 1.85 millisecond servo pulse lengths. I set the Brushless Rages to accept 1.2 to 1.8ms as a result.

Everything’s bundled back up now!

Riding this thing has now become very interesting. Due to its very low gearing to the ground (only 3:1), it does have a hard start, but will always do so after a cog or two. This was actually a good test of how tuned out the SimonK firmware is; the mass-to-force ratio of an EV is usually much higher than that of a robot, even the 240b Sadbot, so it’s a tougher load to get going. The power is not unlike what BurnoutChibi ended up having, but more muted; BurnoutChibi had the advantage of being able to spin the motors much faster to get some ‘free power’.

I immediately ran into the problem of blowing the set screws right off the small filed flats on the motor shafts. This thing was originally designed for maybe 500-750W of power using the e-bike controllers, not an unlimited-current dump.

Either way, some replacement set screws and Loctite enabled some “road testing”. Here’s a highlight:

Results: My Starting-and-reversing optimized SimonK is okay in an EV application but only under some circumstances.

Specifically, you need to either turn down all the braking ramp speeds and magnitudes, or remove motor braking completely. In a robot drive application, the motor braking very closely following the command input helps decelerate the load and therefore reduce the momentum the motor has to start against the other way. In an EV application, that just means you decelerate as hard as you accelerate. It COULD be okay for some things, of course. I found that Chibikart drove well if I had the BRAKE_POWER setting cranked down to 1/8th of MAX_POWER, as well as the BRAKE_SPEED (ramp-down rate of the output PWM, basically) reduced to 3.

With these settings, I could modulate the throttle pedal to give a predictable regenertive braking effect. Too fast BRAKE_SPEED or too high BRAKE_POWER and you just end up impaling yourself on the handlebar here. I could see this on a tight Power Racing Series just thundering around never touching the brake pedal/handle, but it would still be a little annoying for a scooter or electric [skate,long,mountain...]board where you’d rather coast. In that circumstance, I’d just turn MOTOR_BRAKE off and forget about regeneration anyway.

For comparision, I found that Sadbot drove the best with BRAKE_POWER = MAX_POWER and BRAKE_SPEED at 4 (BRAKE_SPEED maxed out at 8 actually tried to slow the motor so fast it tended to either lock up wheels or slip motor poles on deceleration).


And with that, I sat down and pounded out board rev 5:

The main difference is removing the bidirectional optocoupler, as discussd, for a normal one. That’s still a 2-channel opto; I have yet to find a single channel (4-pin) opto in a package I like, but it does make more sense to use one here. Besides that, in rerouting some of the optocoupler traces, I got suckered into giving it better analog and digital signal separation (oh, boo-hoo…).

I also finally implemented the damned LEDs. SimonK actually has LED support, for signals that indicate throttle state and motor state. About time I figure out what this thing is doing!

Overall, I think Brushless Rage is ready to be fitted on something for Detroit Maker Faire. I’m not sure right now if I’m racing anything, or going to marshal and tech-safety-Stalin. I may choose to temporaily rebody Chibi-Mikuvan for funsies, since I want to keep the CMV shell in good shape after retirement.

Well, those are just thoughts anyway. There are also other thoughts:

Brushless Hipsterism Intensifies: Returning to Brushless Rage. Brushless Mini-Rage!? And Trying Hub Motor Drive in a Beetleweight

May 12, 2017 in Motor Controllers, Reference Posts, Roll Cake

Oh, Brushless Rage… how far you’ve fallen. It’s been standing idle since late last year when I got the first version running. Thereafter, it began having some rather obdurate power supply problems that I couldn’t resolve with a few different attempts, and with #season3 still unknown (TO. THIS. DAY. UUUUUUGGGGGGGGGGGH.) and having to pick up and move shops, I lost motivation. Now, with the spring and summer silly go-kart season coming up, me really wanting to pregame getting Overhaul back in shape ( *cries deeply* ), and my comrades over at Robot Wars screaming for assistance, it’s time to put my robes and wizard hat again.

The last time I really worked on Brushless Rage was in October. After tuning out the first one, I went ahead and made a 2nd one. I wanted to get Sadbot running on them for a few test drives.

Here’s my innovative housing for the two controller! Bolted back-to-back with drilled holes in the Ragebridge shipping box.

And that was all! It was retained by a few zip ties running through the bottom ‘breadboard’ baseplate. I didn’t take much test video of Sadbot running on them, unfortunately;really the only one that exists within easy reach is, uhh, this one. While it doesn’t show them getting whipped, they definitely don’t not work! Yay!

But not for long. I soon lost both of the units in further off-bot tuning of settings. They didn’t blow up, but simply failed to ever power on, with the LM5017 regulator simply sitting there getting hot. The only “fix” was replacing the regulator, and I say “fix” because that really didn’t fix anything, and they would die again within minutes or even seconds.

No problem… maybe it’s just an issue with the two boards. I’ll just try another one of the five total I ended up making….

Nope. Nothing. They died one by one, all to the same symptom. I tried redoing my math for the regulator for the 4th time, thinking maybe  I made a mistake somewhere. I even tried mimicking the reference design to try and get something running. I literally never do that.

At this point, I figured it must have been something incredibly dumb and simple I missed. But why would the first two have worked at all, even for a little while?! Convinced the solution might just suddenly invent itself, I stopped thinking about it.

And so here we are, a few weeks ago, when I’m slowly building up a new rev of the logic board that fixes up some trace routing problems and Little Blue Wire problems. Again, the logic regulators kept exploding, some times dramatically taking out the input trace like seen above. The little light is strapped across the 15V gate drive supply to give me a visual indication of it being on.

What is with me and being unable to use switching regulators!? I recalled the Ragebridge Diode Debacle of 2015, and decided to take one last Hail Mary run through the datasheet along with friends to carefully cross-check each other for boneheaded mistakes and…….

TI, you assholes.

So here’s what’s going on. The Vcc pin of this chip allows you to power it from its own output voltage, which is often fairly low, so it prevents a lot of heat dissipation in the chip since otherwise it would have to derive its own power from the voltage input (up to 95V). But what I missed is this only works up to 13 volts. My gate drive supplies were 15 volts by design.

Beyond that? Who knows?! It might work, it might not. I’m guessing my first two were just high enough in manufacturing overhead that they worked for a little while. Subsequent statistics were not on my side.

Okay, whatever. I cut off the 11.3kohm feedback resistor and threw on a 9.1kohm to drop the voltage from 15V to about 12.5V and let’s see what happens.

Ah, it wakes right up.

Of course it does.

So I decided to respec the gate drive for 12.5V. Why do this instead of go for the full 15+ volts? Because I’m really aiming to make this design work at high-for-robots voltages of 36-48v, possibly up to 60V nominal with a different power stage, so I’d like to save the power dissipation in the chip’s onboard logic power supply.

The change in drive voltage will slightly affect the drive characteristics and switching time. For now, I’ll keep all the power stage parts unchanged, but I’ll probably tune the gate resistor values later.


To get rid of the noisy ripples on the feedback network and to stabilize the switching frequency, I added some more bypass capacitance to the chip. This was not included in the design at first, since I figured my large ceramic input and output caps were nearby, but it really really wants its own little private capacitor on Vcc. Gee, I thought I was a princess at times.

So now this thing is pretty much bombproof. Here’s a video of it throwing around one of the 30-pound old MIT CityCar prototype motors (which I inherited 4 of after the project was dismantled):

In that video, it’s running from 36 volts. I tested it with a smaller motor all the way up to 50V input before getting too scared for my power supply’s life; I’ll need to try it on a larger high-for-robots voltage power system later, but nothing smelled imminently unhappy!

With the regulator death issue apparently behind me (again) I decided to push another board revision. This time, I added all the necessary bypass caps and changed the layout of the logic power supply, as well as take out some parts I decided were superfluous.

The logic power supply got a little smaller and more electrically optimal. The whole thing is just less messy now. I like it – it takes up around 1/3rd square inch of PCB space on one side. At the behest of a professional PCB engineer friend, I turned the inductor 90 degrees and joined it with the LM5017′s switching node with a small trace instead of a larger groundplane. This would prevent the switching node (a source of huge voltage swings in microsecond timescales) from broadcasting as much noise.

Besides some other minor trace chasing, what’s going on down below on the board is also something experimental:

That there is a bidirectional optoisoated I2C bus for transmitting data between two microcontrollers which should never meet directly. I had a single-direction opto input on the board revisions so far, but this prevents updating of settings via the SimonK/BLHeli type bootloaders. That means tuning the settings require busting out my chip socket every time, which is annoying. I reviewed a couple of bidirectionally isolated bus schematics and decided to try this one out first, since it involved diodes only, not transistors.

The problem is, the I2C bus is a open-drain configuration with pullup resistors and ’1′ bits transmitted by pulling the line down to 0v. I kind of wanted to try keeping the opposite polarity, so to speak (even though SimonK supports an inverted input setting) just because I’m used to thinking about things this way. So I tried flipping the circuit over…. pullup resistors became pulldowns, and common-emitter became common-collector, and so on.

It makes sense in my head, but I’m sure excited to see this work!

On the board, this is the layout. It doesn’t consume much more space than my previous 1-direction optocoupler setup, and can be bypassed for testing with 2 wires if needed. That’s the nice thing about keeping things upright signal-wise.

So before I sent this board revision out, I stopped for a moment to think who would really be wanting to use Brushless Rage. I’d designed the 12-FET board to effectively replace Overhaul’s 250A DLUX controllers (with more realistic ratings, mind you). I’d say the majority of people who would buy such a thing won’t be running motors that big.

Recently, the thought of a “Half-Rage” has been coming up in my mind as something worth pursuing. This would be a board with about half the footprint of a RageBridge 2 and supporting about 1/2 of the amperage. As some curious question-askers had innocently drilled into my mind, this would be an Actually More 30lber-Sized controller.

> mfw "When are you going to make a 30lber/12lber version of RageBridge?


With this in mind, I decided to make a copy of the power stage and began downsizing the hell out of it.

Step 1: Reap what I sow when it comes to the sheer number of vias I deposited under the FETs.

After bunching the FETs together, I referenced one of the earlier abandoned Brushless Rage layout ideas for the output wires. This board is now short enough that I’m comfortable pulling the phase outputs all the way to the right with the power. Keeping all my wires on one side is something I prefer.

Somewhat final routing of the fat bus traces here. I had to move a few gate drive traces, as there was no longer an opportunity to swap sides in the middle of the FET bank. Power+ runs straight from the bottom right corner, through the bus capacitors, into the high-side FET. Power- emerges from the current shunts and then has 3 paths to return to the buscaps before being slurped up by by the wire hole on the upper right.

Here’s an overlay of the signal board design on the power stage, showing roughly the size of things. The final power stage is 2″ x 2.75″. Not the tiniest thing, but I have more capacitors than you!

This board shares a lot of thermal characteristics with RageBridge, so I’m pretty comfortable calling this a 50A continuous class controller. 50 real under-partial-throttle amps, so that’s what, like 1,200 Hobbyking Amps?

In all likelihood, this controller will be able to handle an average 63mm SK3 motor in continuous duty applications like a silly go-kart. Robot-wise, it will probably be stressed handling the same in bidirectional drive mode.

Fast forward a few days and….

OhmygoditssocuteIjustwanttohugit and then make it run a 80mm outrunner on 12S violently. I’ve ordered parts to make a handful of these, and two are going on Sadbot ASAP to be driven until something blows up!

Direct Outrunner Hub Drive for Your Little Bot

Next up, something even smaller!

So I’ve long been a connoisseur of fine handcrafted hub motors. I got curious recently on using direct-drive small outrunner motors in an ant or beetle after thinking a while on the redesign of Roll Cake. Version 1 of Roll Cake was honestly just a braindump of a vision I’ve had for years for the shape of the bot, and everythng else came second to that. On the beetle scale, the multi-pulley serpentine pulley drivetrain simply had too much friction for the Fingertech motors (which were severely underpowered for the task) to overcome.

For the next version, I’m ditching the triangular cheese wedge shape for something more straightfoward. The cheese wedge will be back for a heavier weight class. Roll Cake’s design really wants to have the middle of the bot kept clear for the flipper linkage. I’m sure I could work around it with low-mounted drive motors and similar, but this was an excuse to play with brushless things!

I based my thoughts off Jamison’s mini-gimbalbot which used camera gimbal motors for drive with a small Hobbyking R/C car ESC. It drove “okay”, certainly capable of a weapon delivery platform. So naturally, I wanted to put some SimonK-capable controllers on it and see how the handling would change. I got a small selection of motors: A pair of DYS and Quanum 28mm motors as well as a pair of Multistar “HV” 460kv motors. 460 RPM/V is reeeeeally slow for that size of motor that isn’t a gimbal motor, so I was quite interested in them.

These are the gimbal motors. I like them for their pancakeyness – the Quanum motor is more 30mm and has a bigger stator.

Playing around in the CAD model a little for component placement. At this point was when I realized Roll Cake in this incarnation might end up looking a lot like The Dentist :P

I designed up a few hubs that bolt to the face of the motors and have a tapped middle hole to sandwich a wheel. The wheels are spare 1.625″ BaneBots wheels that I originally bought for Candy Paint & Gold Teeth.

Shown with those motors is a ZTW Spider 18A controller. My typical SimonK ESCs, the Afro series, were out of stock when I placed this order, so I took recommendations from people on what I should use. The Spider series are fairly popular these days among small bot folks.

The issue is, they come with BLHeli firmware, the other other open source drone racing / vaping rig development path. It’s a newer effor than SimonK and has a more polished interface. I’d read about it before, but not worked with personally. Other builders have said it doesn’t run robot drivetrains as well due to being much more optimized for propellers. So hell, why not – this was a chance to explore that side of things.

Here’s some real life CAD layout, featuring the Multistar motors.

I really wanted to use the gimbal motors, but they disappointed me in bench testing sufficiently that I didn’t even end up installing them. Basically, they can’t draw enough current to make torque at typicall little-bot voltages. With phase resistances of 10-20 ohms, they can really only draw ~ 1amp or so. I mounted one in a vise and could stop the motor with my pinky finger at full radio stick input.

These motors might be better at 6S and up, but for the time being, since all of my small-bot batteries are 3S, I decided to pursue making a test platform using the Multistar 460kv motors.


The platform of choice was…… one of Candy Paint’s spare weapon pulleys. I literally spilled my “preformed robot spares” bin on the ground and tried to see what was good to use as a base. Hey, it’s round and has convenient wheel holes in it already! All I needed to do was quickly whip up some motor mounts (3D printed) and I was in business.


Here’s everything hooked up. That nut is for a counterweight on the front to add some friction against the ground while turning. Otherwise, it had a tendency to keep spinning and spinning if you even thought about turning.

Communicating with the ZTW Spiders was a hell of an adventure in its own right, and I am putting this post under Reference Posts because I’m 99% I will need it again or someone else will randomly find it while needing the information. If there was any industry that continually pisses me off with how undocumented and tribal-knowledge focused it is, it’s the R/C anything industry.

So, here’s how everything went down. I lost my AfroESC USB communicator, so I purchased the Spider SPLinker advertised as working with the controllers. I also bought one of these stupid things:

That’s a “SimonK/BLHeli compatible” dongle called the ESCLinker. It allegedly can talk to either kind of ESC, but there was nothing remotely resembling a manual or operating guide; all of the search results for this brilliant device were people complaining that there was no manual.

So I’m writing the manual now: This thing does not want to talk to KKMulticopter Tool (my go-to for flashing SimonK ESCs). It will only talk to BLHeli Suite. As a matter of fact, I couldn’t get the Spider SPLinker to talk to ANYTHING. For all of my tuning here on, I used the ESCLinker tool.

Here is BLHeli Suite, which is hosted on the sketchiest possible website that is one tier above compiling it from the Git repository yourself.

Notice how I’m connected to the ZTW Spider now. The ESCLinker (and SPLinker) install as virtual COM ports.  The necessary baud rate is 38400 baud, not 19200 (Afro/Turnigy USB dongles, to my knowledge)

By the way, once I realized this, I tried to talk to the SPLinker and ESCLinker on KKMulticopter Tool again using 38400 baud; no dice.

Further investigation revealed that the ESCLinker needs these options to communicate to the ESC – both options 2 and 3 will work. So if you’re listening, people mystified by the ESCLinker: Talk to it on 38400 Baud and ask it to communicate to your ESCs with BLHeli/SimonK 4-way-if bootlader.

Ugh. One of my selfish reasons for wanting Brushless Rage is so it’s one known quantity and I never have to dick around with other people’s open-source bullshit again.

So with all that behind me, I decided to try out BLHeli drive on the little pulleybot. I went with intuitive settings based on my SimonK advice, which included “Damped Light” mode, a fancy euphemism for synchronous rectification/complementary PWM, medium to low timing and maximum start power. BLHeli also has a “demag compensation” feature which appears to delay commutation to compensate for current decay in the windings. Who knows!? I wasn’t given the imprssion that its users actually understood what it meant, nor does the manual really say anything useful.

I found that Demag Compensation turned all the way up gave the best performance, along with maximum start power. However’ it still couldn’t compare with my SimonK experience. It seems like even maximum start power is much weaker than what SimonK permits you to do.

Here’s the final test drive I made with the BLHeli Spider ZTWs:

I’m honestly not very impressed. I think BLheli is very much optimized towards multirotors and helicopters (hmm, maybe it’s even called BrushLessHeli for a reason!) and the settings are more high-level and mask the underlying mechanicals of the firmware. I think this makes it much more accessible to hobbyists, though. In the end, I’m not very enamored by it.

These were my final settings:

For a direct comparison, I decided to replace the ESCs with my old SimonK Afro 30 amp units. These have been on quite a few bots now, starting with the original Stance Stance Revolution, and they were completely beat up. But they still worked!

A direct replacement into the existing wiring harness later… we have SimonK!

I found myself in the awkward position of using KKMulticopter Tool to compile a customized SimonK formware, then uploading it via BLHeli Suite because my USB dongles didn’t talk to KKMulticopter Tool; I’d lost my AfroESC USB dongle a long time ago.  BLHeliSuite doesn’t seem to have a firmware editor window that I’ve found yet.

Here it is. I found the SimonK version so much more responsive that I actually needed more counterweight on the front. So, a non-fitting bolt gets zip tied to the nut! Now the bot’s a lot more controllable:

I like it a lot. It might even be worth doing 4WD to give me more yaw damping, or I’d have to design the bot to be well balanced enough on front skids, or something. I used my typical SimonK parameters: complementary PWM, maximum braking power, maximum braking ramp speed, and adjusted start PWM limits to something like 50%.

I’m aiming to get Roll Cake and maybe Colsonbot running for this year’s MomoCon in a couple of weeks, so hopefully I’ll post up some design news soon!


A Brief Interlude from BattleBots with Brushless RageBridge

Jul 26, 2016 in Motor Controllers

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] 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.





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….


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.

A New Beginning, the Second Story; RageBridge 2 FINALLY Going to Manufacturing; Season 2 and #SADBOT2016

Dec 01, 2015 in Bots, MIT, Bostoncaster, Cambridgeshire, Motor Controllers, sadbot2016

It’s official – after December 31st of this year, my contract with MIT as the MIT-SUTD Collaboration‘s International Design Center shopmaster will end, and will not be renewed. As of then, I will no longer have official ties to MIT. Hard to believe, eh?!

There’s no better timing for this, too, as #season2 is on the horizon early next year. My goal is to use this same epochal shock to usher Equals Zero Designs into prime-time, with the release of RageBridge 2 and a host of other stuff I’ve been working on this fall semester – stay tuned for that.

Ultimately, it was a combination of the fear of complacency as well as organizational changes that is pushing me to move on. First, because I have commitment issues and can see myself being a shop instructor & design class instructor for the next q years, which frankly scares the shit out of me. Sorry, ladies. Second, the IDC has moved on from its more “Wild West” days of supporting any which project, towards a more professional research-centered model with strong ties to industry. This is without a doubt better for the Center and will make it sustainable past its years with the MIT-SUTD collaboration alone, but I just didn’t see myself contributing to it any longer. I’m one of the last of the “original generation” of IDC inhabitants, and that presence has made itself painfully obvious in the preceding few months.

The thing I’ll miss the most is not anything to do with the Center, or even “my own” shop, but my interactions with the student maker community and being the go-to guy for late-night uncommon parts and advice, because yeah, of course I have one and of course I’m upstairs right now. That, and not being able to continue the great experiment that is 2.00gokart, but perhaps this will be remedied in due time.

In the coming weeks, I’ll be winding down my operations at MIT and shifting most of it over…

…to my little corner at the Art is a NSA sylum. What I might lose in the coziness of “my shop” I gain in a real, dedicated space for shenanigans and a much wider array of on-site resources and a massive community of deranged makey-types. Thus begins the story of Big Chuck’s Robot Warehouse & Auto Body Center. What, you thought I was kidding?

The downside? I have so much shit to move.

So many more people making and building things at MIT is a mixed blessing: nowadays nobody can get their own little private corner for too long. I’m currently trying to knock down my stuff load, which dates back to mid-2007, across 3 or 4 different sorting systems (at least 1 of which is just “NONE”), and several midden-esque locations. So, perhaps watch out on the For Sale page soon


Oh dear, I’ve officially become one of those delayed crowdfunding product people in addition to being just a crowdfunding product person.

Ragebridge2 got basically pushed back a month to resolve one of the biggest issues plaguing it from the start: the one channel “giga-mode” where the two sides are tied together so Rage becomes a single channel twice-as-awesome controller. A lot of prospective users were asking for this so Rage could conceivably be used in a heavier robot design. For example, the two sides put together at 150 amps limited would be plenty of current for, say, an Ampflow A28-150 motor.

Now, how hard could this one-channel thing possibly be? Isn’t it just copying and pasting the output of one control loop cycle to the other?!

Well, basically. But first, there were secondary issues that had to be resolved.


One thing that eternally plagues power conversion and motor control designers is noise. Switching tens or hundreds of amps thousands of times a second is not easy on sensitive logic. The bigger the parts get and the higher the amps go, the more likely you’ll start seeing things like optical isolation and fully isolated independent gate drive supplies, and the like. I think Rage is on the big end of what is basically “non-isolated” designs, where power and logic ground eventually meet on the same board. When they do, layouts and trace routing become as critical (if not MORE critical) than exactly what FETs you use…. I could have the most hardcore power devices in the world, and my board would just reset over and over if the current draw went over 5 amps or something if I dropped a haphazard or autorouted (shudder) layout.

Now, fortunately, for Rage, the critical current wasn’t 5 amps, but more like about 130-150 amps. On very hard reversing with the current limits near the top, the board would still trip up. However, it was no longer the microcontroller resetting, but the Allegro A3941 chips themselves that were having issues.  In fact, one side (channel 1) would preferentially shut down.

In fact, here’s a scope trace between low-side return (LSS) of the gate drive chip and my logic supply ground measured at the logic bus capacitor, on a 100%-to-0% step where I just kind of let go of the transmitter stick, with the current limiter set to maximum (75A) per channel. That’s a nearly 6 volt peak to peak smash, especially with a strong negative component. And this was at PWM frequency – happening 15,000 times a second.

If Rage were in dual-channel mode, this resulted in that side simply no longer responding, needing a reset to clear. If it were in single-channel mode, well… stuff generally blew up.

There wasn’t much more trace and component placement optimization I could make, however. I repositioned several of the gate drive traces, and more importantly, moved where the gate drive chips got access to VDD (system voltage) and VSS (system ground), specifically moving them away from “right under the drain tab”. I’m not sure why I even did that, but…

One last thing I decided to finally do was to airgap the whole logic ground plane.

Before, the plane filled the whole area that is now black in the center. This placed it right next to the high-power planes and the switching output of the motor, not to mention the high dV/dt gate drive traces. This is no longer the case.

All of these changes called for a new board revision, number 6. I decided to try a new-to-me vendor that I’d been clued into,, not to be confused with I see what you did there.

They have the quickest turnaround of any place I’ve used so far that doesn’t cost four-figures. I’ve actually since used PCBWay for a few more sensor boards and consistently get orders in on Wednesday afternoon, and receive them the following Monday, including shipping time with an air express service and which doesn’t even cost that much. The “downside” is no “fancy stuff” like 4 layers, microvias, plated holes and edges, etc… on your boards or it takes as long as it normally does.


It, uhh… Oops.

I’m pretty sure I clicked on the wrong choices for LPI (solder mask) color and silkscreen (text) color. The buttons are actually next to each other, okay?

Just in time for the cold season, the wild RageBridge gains a brilliant white winter coat to better camouflage itself against low-inductance motors and people who don’t know how to solder.

To be fair, this doesn’t look bad. However, the white board is easily stained by flux, and after reflow-soldering the FETs and gate driver ICs, there’s obvious yellowing of the board to a more ‘off white’ or ‘soft white’ kind of color. I think this is partly the flux, and partly because I cooked it too long. My process is not nearly as controlled as a production reflow line, so it’s not an entirely correct criticism. For production, I’m going to stick with black.

But did this revision solve anything? Quantitatively, I haven’t recharacterized the noise, but qualitatively, I haven’t gotten the board to reset or shut down in any way once. It will now happily grenade the power traces on a cross-side short, and continue working once I bridge the gap. This is all while driving a motor like 10 times larger than what it should be driving.

Well, that means it’s still blowing up in single-channel mode. It turns out there were quite a few structural problems with the firmware that allowed the input-taking loop to ‘override’ the current control loop. As the fastest loop in the code, the CC loop is what should be controlling the outputs at all times. The issue centered around passing variable values back and forth between the two loops. This itself was not causing the board to explode, per se. It needed an accomplice on the hardware side.

The other issue was that my deadtime between high- and low-side FETs being turned on was too small for the switching time.

The red trace is the gate of the high side FET discharging, turning the FET off, and the yellow trace is the corresponding low-side turning on. There’s very little error room here. It seems like the high side barely makes it off before the low side turns on.

Again, not very bad if the two sides were separate, but if they were switch together, all of the components better match perfectly. A few extra dozen nanoseconds here and there in delay and switching time differences would cause one side to be momentarily on while the other is off, or vice versa.  When this happened, there was an audible click from the capacitors as the cross-conducting FETs swished what must be peaks of hundreds of amps out of them and in a loop around the board. That was my sign to, umm, power everything off right now.

Prior to this, the board only exploded made terrifying sounds at very high throttle percentages (e.g. above 95%). I found out that the “output overriding” issues in the firmware were permitting very high PWM duty cycles, since the input-taking loop does not constrain its outputs to include deadbands on the low end (0-5%) and high end (95-100%). When this happens, it means the low side FETs occasionally turn half-assedly on and off due to the rapid on-and-off cycle.

I increased the deadtime to a safer margin to test again. The combination of correcting my variable-passing and adding more deadtime made for perfection! I just had to make sure that the outputs never went above about 95% – from there, it jumps to 100% – to avoid the possibility of one-side off (no FETs on) and one-side on, which is a slightly less bad case of one-side-high, one-side-low.

This jump is handled by a conditional in the fast (current limiting) loop. In practical use, this is almost unnoticeable (and is also used in RageBridge 1 and basically all other motor controllers, to avoid the things I explained previously)

With these issues resolved, Rage is now incredibly close to production. I’ve put in for the assembly quote and have already amassed the Bill of Materials. Associated tasks include getting quotes for heat sink manufacturing, and of course, in due time, readying the website and producing documentation. I hope to have everything out the door by mid-week, so Indiegooglers stay tuned for a huge update!


Way back during the middle of #season1, when we thought building a 250lb robot in roughly 5-6 weeks was going to be a breeze, I came up with the idea of a “practice assbot” for the 4 newer team members to construct so we can practice driving Overhaul v1 against it. Because, y’know, we were totally going to finish a week ahead of time and have time for everyone to take a turn at it and decide the chief driver on who’s the most skilled and… okay, that kind of died a little bit as we were welding the last bits of the new lifter assembly together on Tuesday night of production week.

But we were left with this tool, which just had to be used on something. The original plan was to put some wheelchair motors and tires on a square tube frame (leftovers from constructiong the OH1 frame) and throw this on a third of said motor. It would just be an irritating practice opponent.

During the brief interlude before #season2 work took off in earnest, I decided to take this project to fruition and adopt it, much like I am adopting the name and concept of Overhaul itself – more on this in detail soon, is my hope. I wanted first and foremost to have a 250lb-class driving practice machine. The difference between driving a 30lber and Overhaul was much like a small sports coupe and an overladen Chinatown bus. The second goal would be to test stupid experiments for Overhaul V2 (….more details on this soon, again, as I hope!) and basically make a “prototype” to make sure that certain bad ideas work, or are ruled out, before the proper build.

So I extracted OH1′s wheelpods from the apartment  and proceeded to think of the simplest, most durable frame I could build around it. Each wheelpod had four mounting points which were rubber shock isolators, so I just needed something to bind it together. A simple tube frame would have sufficed, but it was actually not heavy enough. To really get in the weight range I needed, there had to be much more steel.

My salvation came in the form of giant C-channel, specifically the “6 inch x 10.5lb per foot” type. That’s how it’s sold, pounds of STEEL per foot. In all, the thing above contains about 140lb of steel alone. Add in two roughly 25lb wheelpods and  batteries and it should be right up against ~220lb, so I could run this in other 220lb Heavy events if I really felt like it. The wall thickness is around 1/2″. It’s just a blob of steel.

But what it really needed was the Stick of Poking. For that, I conjured up a quick structure to contain a modified, chopped-down version of it.

The gear ratio may or may not be similar to one I intend to use in OH2′s main lifter, with the tip possibly kinda-ish at around the same distance as the anticipated new lifter, and it also miiiiiiiight be expanding on using the BaneBots P80 in applications most people would make fun of me for. All maybes. Nothing is certain at this stage, after all, and we don’t want to get too far ahead of ourselves, right?

I elected to use chain to keep it simple, with stock keyed shafts and sprockets running on stock mounted bearings. No fanciness here, just something quick to put together. The structure is entirely 1/4″ steel weldments from waterjet-cut puzzle pieces. I’m pretty sure it’s too spindly to be battleworthy, but again, I just wanted to see the numbers at work.

Oh dear, this thing is now looking too legitimate. I added some big rubber bumpers (which I ordered months ago for OH1 but found them too hideous to use, as well as heavy and improperly sized). Even if the arm is never installed or functional, at least it will be (relatively) soft with the big bumpers. Maybe I can use it to tow vans.

One of the intentions of this build is, of course, after all the experiments and bad ideas are finished, to have a sparring opponent for not only the future Overhaul v2, but also the potential storm of new heavy-class bots emerging in this area.

So, because the only purpose of this bot is to get experimented on and thereafter, shat on and beat upon, I figured it must be really sad, and so began calling it sadbot. It’s only tangentially related to #sadboys, I promise.

I ordered an unnaturally large quantity of STEEL compared to my usual daily recommended intake from Turner Steel, a local distributor, who delivered for free. By which I mean, dropping off slabs of a future overpass/bridge on the loading dock, and leaving me to try and budge it while making adorable squeaking noises like a rubber squeeze toy. If there is anything that building one (and soon to be 2, later three?) heavyweight-class robots is doing for my benefit, is MAKING ME LIFT, BRO.

To make up for it, building the frame was actually the most straightforward thing ever. Ignore the painted weeaboo face – I was somewhat delirious at that point. The cuts were made on a horizontal bandsaw, chamfers were gouged in with an angle grinder, and future weldment regions cleaned up with one of those fluffy paint remover wheel things. Word of caution: they are not fluffy at all, in real life. In fact, they throw chunks of hard plastic coated with abrasives at you.

After the mounting holes were drilled, I bolted the wheelpods in and actually used this assembly as a welding fixture. Long bar clamps held the sides in place at the correct height, while the whole frame was on wheels so I was able to push it around. In this exact form, I poured a few more pound of MIG wire into the frame. All possible edges were welded, both inside and out.

Having to build a heavy-class bot across multiple shops and buildings sucks. I should have invested in an engine crane and swapped some pneumatic tires onto it to sling this around. Pretty soon, this became too heavy for me to lift by myself safely, so I had to grab whoever was nearby. Here, the baseplate’s been installed.

Check out the 2×2″ hole pattern that peppers the 1/4″ cold-roll baseplate. I lined up the edges of the plate on the waterjet to make the pattern in one go. It’s like an optical table, except dorkier. This ensures I can attach any stupid thing I want to this baseplate.

The battery brackets are two pieces of 1″ angle stock, with a channel milled through each. The battery will be retained by a giant ratchet strap threaded through those channels. Each Overhaul battery is 37v (10S lithium) and 16 amp-hours. That’s literally 2x the battery we needed per match as reported by the chargers, as it turned out.

Here’s the pokey-arm tower cut, cleaned, and assembled, but not yet welded. Like the frame, I’m cheating and using the mounted bearings and shafts as a fixture to give some kind of perpendicularity.

The next step was to prepare the poker itself, which entailed drilling a 1.25″ hole through the solid 2″ diameter steel handle. I purchased an annular cutter off eBay for cheap, which are basically hole saws but actually built for cutting steel instead of just being coerced into doing so. I’ve always wanted to use one, but they’ve either been far too expensive or I had not needed to ever go through this much steel at once.

After using my cold saw to sever the handle to the needed length, I set everything up on the Bridgeport mill and gently massaged the cutter through in low gear. The process was utterly painless and the resulting finish was spectacular.

It’s almost like paying for the right tool makes your life easier or something! Go figure.

To-dos on #sadbot2016 involve welding the poker-arm assembly together and making some permanent temporary wiring to get it up and running. I’ll have more updates on this thing as the science experiment results roll in.


RageBridge 2: The Indiegogo Campaign

Aug 27, 2015 in Motor Controllers

Back my kickstarter.

- Charles in every ironic statement ever

Today, that statement ceases to be ironic (or perhaps, is even MORE ironic). For I’m proud to announce the RAGEBRIDGE 2 INGIEGOGO CAMPAIGN!

You’ve been following the story of RageBridge 2 behind the scenes here, so now you can support its production and be first in line to get them! Or, perhaps, run far away because you know how derpy the development process is!

The link to the campaign is:


After the campaign has been fulfilled, RageBridge2 will be available on