Here’s where I deviate a little from the progress updates on Null Hypothesis to focus only on RageBridge for a little while.

After detonating the first board by shorting it through a very stalled and unhappy drill motor, I decided to fill in the current sensor pads and actually put them to use: I elected to investigate if I could give current limiting to RageBridge. Yes, you heard me right.

I, Charles Z. Jesús Sergeyovich Guan Kennedy III, after years of bitching endlessly about crappy robot controllers with fancy current limiting and how they don’t work, am building a motor controller with current limiting.

The primary motivation was to not detonate my hand-built boards left and right every time a motor decides to disembowel itself such that I can better appraise the reliability of the board. It’s nice to have an ESC that can dump forever into a stalled motor without any form of protection, but such a controller would of course then be dramatically overkill for any normal loads it is expected to experience. Even a shitty drill motor can pull a hundred amps for a few seconds (before it lights on fire), and very few reasonably-sized robot controllers will happily dish out those hundred amps. They do exist – they just fit nowhere in my robots.

That aside, I also have a personal grudge to settle (okay, fine, THIS was the real motivation). Most specialized robot ESCs these days are pretty smart and do feature current limiting. The problem is, when they say current “limiting” they mean “After this number of amps, I will shut off completely, without notice, and won’t turn on again until you cycle power”. Or even if it does turn on again by itself after a few seconds, the damage is already done, so to speak, – your bot has been totally defenseless for several seconds and is now probably in more than 1 piece. Granted that these are complaints only for the combat domain, which admittedly is a small realm of robots as a whole. Generally if you have a fancy controller like a Sabertooth driving an autonomous rover or whatnot, it’s not going to be making sudden full throttle forward-reverse slams, unless it is very confused or special. In that case, it’s totally legitimate to assume that if the current goes over a certain limit, something terrible has happened.

But that kind of current limiting, more properly called current cutoff, pisses me the fuck off. It’s the reason why I keep using Victor 883s, as old school as they are, in my drives because they just don’t care. I’ve scared Banebots controllers, Sabertooths and SyRens, Robo-Claws, all purported modern intelligent motor controllers, with said shitty drill motors. Not even anything exotic or special! Cut-off is not smart – it’s stupid and easy, which is probably why it’s done.

True “current limiting” would behave much like a bench power supply. After a certain amp threshold is crossed, the output voltage will reduce to the level needed to sustain that current. Ideally it will dump x amps into a load forever, even a dead short. It would work something like:

Yeah. That. I’ve named it the “hysterical” current limiter since while it resembles a hysteresis controller I have no defined lower bound and it’s not trying to keep the current within a certain range, just giving it a ceiling.

Green represents nondimensional command (say “100%” voltage output), blue represents nondimensional voltage output, and red is nondimensional current of a load. Shown is a pure resistive load whose current just directly scales with voltage.

The idea is that with each timestep of the controller, it will increments the output voltage magnitude a small amount to follow the command. Also at each timestep, a current reading is taken, and if it is over the set limit, the limiter will take away that increment plus some more, such that the output voltage is lowered. If at the next timestep the sampled current is still higher than the limit, then the limiter will take away more output magnitude again. And so on – all this method needs is the current limiter ‘takeaway rate’ exceeding the maximum voltage ramp rate of the controller for responding to the inputs, e.g. my radio stick.

How big the current hysteresis band (the ‘triangle’)  is will depend on the ratio of the two rates and the timestep. If the current limiter takes a large amount of output magnitude away, then the input command portion will take a longer time to catch back up, the magnitude of the hysteresis band (“ripple current’) will be higher, but the response to an overcurrent condition would also be faster.  If the current limiter can’t take away as much magnitude as the input command contributes, then it doesn’t work.

Since I already have a “ramping” function in Ragebridge’s firmware, I could just inject my current limiting process directly into that. In fact, having this kind of limiting would make the command ramping I have obsolete – the maximum acceleration of the motor would only be dictated by how high I want set the current limit. A small motor which can’t pull enough amps to hit the limit will be slapped back and forth relentlessly, and in the best case, I can hitch this controller directly to twin direct drive Magmotors and have it slowly crawl along. Forever.

It’s not the same as current control which only increments/decrements as fast as needed to maintain a certain current (and your stick inputs are translated into a value representing how much current you want) – it really is current limiting. If your motor always wants more amps than the controller will output (e.g. twin direct drive Magmotors), then you will be operating always in the constant current regime – accelerating at a constant rate to your target speed.

So let’s start. First things first, I need to put together more boards:

Here we go. When I have the parts out, it’s actually more effective to just keep populating more boards since I can copy and paste my motions. The only limiting factor this time for me was the lack of MOSFETs. These fuckers are expensive and each board has 8 of them. Just these 3 boards are like $80 of MOSFETs, and by using them in my controllers I’ve pretty much sentenced them to death by burning smoky fire.

I’ve added reinforcing wire to the long return traces in the hopes of staving off another current-induced explosion. Ideally, if my hysterical current limiter works, they won’t be needed.

Three boards made, with the first board at the top background now being used as a reference  and parts junkyard. Only one of these has the current sensors built in right now – when I can verify that it works, the others will be adapted (Those current sensors are also kind of pricy – if I were to take these to production, I would try to use a resistive sense circuit instead of the hall effect sensors on there right now).

The ACS714 current sensors are bypassed externally by a 1 mohm current sense resistor, which reduces their sensitivity by about half. Otherwise, I’d only have 30 amps available to sense, whereas with 1 bypass there is “60 amps” available. Multiple current sensor bypass surgery is reasonable – current will divide itself according to the resistances of each path available, and I’ve done up to “double bypass” to get 90 amps on Tinytroller before.

The current sensors have up to 80khz bandwidth if there is no external filtering (datasheet), but the noise at those conditions is pretty frightening. Because my loop will only ever run at 500hz or 1khz (maaaaaaybe faster in the future), I can afford a little bit of external filtering to keep the peak-to-peak amps noise down. I elected to pitch 10nF filter capacitance on this board. I could go even higher if needed because the ATMega’s analog-to-digital converters take over 100us just to do their job (this is horrifically slow for modern microcontrollers), so the current rise time can be really slouchy.

This was at the stage where I was just checking the current sensor values to see which polarity they read, and how much. The huge 2.5 ohm power resistor was a decent, if a little high-resistance and induction-less load. Start gently, I suppose.

Alright, now we’re getting serious. I don’t have a real low-ohm power resistor, but did find another one of those huge green things in MITERS, so 1.25 ohms is enough for now. While I could have taken several dozen feet of fat wire and dumped through it (and it would have some meaningful inductance to boot), these things were low enough to test up to the limit of the power supply. At this point I had written a basic version of the code which only applied to 1 sensor and in 1 direction.

The next step was to start puking into an RL type load, like a motor winding. Purely resistive loads have no ability to smooth their current (since ideally it tracks the voltage in proportion directly). Inductance adds a bit of ‘mass’ to the current, making it tend to keep going. When combined with a switching output stage (like my H-bridges, or every switching power supply ever) it is one component of producing very smooth DC outputs. Conversely, an RL load will tend to ‘coast’ for a while, making it actually much easier to control.

Plus, I’m building a motor controller, so it damn better work when I run a motor with it.

The test load is a classic EV Warrior motor I’ve had sitting around for a long time. Back in the day™, if you were a newbie and were building a 60 to 120lb battlebot, EV Warriors were the shit. It’s also a good candidate motor for this test – it’s got a huge armature with lots of inertia AND inductance, and can pull a hundred amps easily. It already killed the unprotected Ragebridge once.

To up the stakes, I clamped it to the table and locked the shaft with a vise grip. Or more accurately, I locked a vise grip onto the shaft… one is more dangerous than the other. I was about to find out if my current controller worked or not – if it worked, the EV Warrior will barely nudge the vise grip against my clamp. If it doesn’t, then the EV Warrior will shoot the clamp through my stomach.

Luckily, the answer was it worked. Okay, minus an accidental sign error in the reverse direction that had the radio input fighting the current controller whenever I hit reverse, but no blood was spilled!

After verifying that the current control worked for several currents between 5 and 20 amps, it was time to get serious. I upped the limit to 30 amps (as a start) and lobbed it in Null Hypothesis. Having 2 severely overvolted drill motors per channel, it will happily suck down over a hundred amps.

Driving the robot on only 30A per side was amusing – it actually didn’t take much longer to get up to speed, because the wheelspin current of each motor was about 10 amps (typical for drillboxes – here, have a drivetrain calculator). The motors would have tried to draw a brief burst of high current to get up to speed normally, whereas now they would have been limited to 30A, so they would have had to ramp up to speed a little slower. But that transient is so short it is nearly negligible with respect to the robot’s mass accelerating with the floor’s traction limitations.

But what it couldn’t do was push anything. As soon as there was additional weight on top of the robot, the sum of the motor currents exceeded 30 amps and the motors were capped in the amount of torque they could produce. It may have handled another 30lb robot fine, but I could stop it with my foot – something that normally results in me being toppled over as I get my center of gravity displaced.

I decided to up the limit for NH to 51 amps per side (up to 25 amps per motor, shared equally, or 50A per motor if one is totally fucked or unevenly loaded) and close the bot up. The weird limit has no particular reason – I could go up to 55 or so amps, but what I don’t want to do is saturate the current sensor so it never actually recognizes that it hit the limit.

One of the perennial fixes I have to make to my controllers is the “common mode nut”. I’m not sure what it does, but on the old Melontroller it helped resolve an issue where the controller would behave oddly and occasionally reset under heavy loads.

The problem with this board is a little different. I’m still not sure on why it happens, but occasionally my 15 volt power regulator would latch up and emit an audible buzzing sound. The voltage output is typically just enough to keep the ATMega alive, but no gate drives. It’s then impossible to reset, even with a power cycle – chances of it entering a normal operating mode are rather slim. The same issue has plagued tinyTroller as well – everything I’ve made with the LM2594 has displayed this latchup problem. Melontroller had it easy because it used a linear regulator.

It’s weird because only this board does it so far – the first one I made did not have this problem at all. Even better is that the board displays no issues after I manage to successfully power it on, just that I should not try and turn it off again!

I’m fairly certain it’s inrush-current related, but it also seems to involve temperature. What fixed tinyTroller’s problem was turning the 15V regulator’s input from a diode only to a diode-resistor circuit, with a 10 ohm resistor supplying current to the input capacitors. It basically puts the LM2594 at the output of an RC filter, limiting how fast the voltage transients can be. In this case, the controller will power on fine if I

1. Turn it on, but do not try to turn it back on from a power cycle within about 2-3 minutes
2. Or turn it off and expect to be able to turn it on again after it has been on for more than about 30 seconds

I’ll try adding the inrush-limiting resistor to the logic regulator and see if that fixes anything. Or just put together another board and see if it’s some kind of strange assembly problem!

Hardware oddness aside, here are some pretty scope pictures.

Just a shot of gate drive voltages, measured at the gate of the FETs. Purple trace is low-side, red trace is high-side. The turn-on and -off time for the IPB034N06 FETs I’m using with the IRS21844 gate drives is only about 200ns. I’ve become used to just setting the “deadtime” on the 21844 to 1 microsecond, but that’s clearly excessive. I split that time roughly in half for this controller, and it seems to be working great. 1us isn’t terrible, but having excessive deadtime not only limits how high of a duty cycle you can achieve with purely bootstrapped gate drivers, but for very fast loads it can also cause voltage spikes to occur at the FETs if the load gets ‘cut off’ suddenly, kind of like punching your bartender in the face if he waits too long to serve you another drink.

To investigate how fast I can have my code run, I decided to time the main loop by quickly switching on a pin and then turning it off. I accomplished this using direct port manipulation – the digitalWrite procedure in Arduino adds something like 100us of overhead, which is a little distressing. A port write is done on the next machine cycle, adding negligible time if my code take several hundred microseconds to run already.

The entire control loop, from taking in the latest inputs to calculating the output magnitudes, takes only a little over 300us. This was good news – I started the code running at 500hz, and could conceivably bump it to over 2khz! The faster the loop, the tighter my ‘hysterical triangle of current’ gets.

Unfortunately, my ramping function only works with integers. I’m already only letting it ramp 2 LSBs per loop, and to take the loop much faster means I’d start having to do 0.75 or 0.5 or something, which would imply floating point math (sloooooooooooooooooooow). Maybe I could ‘prescale’ the ramping function by having it run only ever other loop or something, but that seems impractical. Given that I have the current limiter, the ramping function is almost unnecessary.

For now, I decided to just leave it in, so I had to pick a speed that could still accommodate it:

I decided on a 1khz loop. That means it is checking the current every millisecond, which ought to be fast enough save for the lowest-inductance pancake motors and raw resistors. There isn’t really harm in dumping into a non-RL type load anyway – the current ripple would just increase in magnitude.

This is a trace of the current sensor’s raw reading, showing the triangle-wave-like waveform that results from the voltage command being tugged back and forth by the limiter. It’s important to note that neutral (zero current) is at about 2.5 volts, or above the displayed waveform. Therefore, the current dips sharply down (the shorter, steeper slope) before incrementing up again (the longer slope). I can’t accurately judge the ripple current from this screenshot because the wave is barely bigger than the pixels. Maybe I’ll take a more accurate picture later.

For now, though, some video I shot during the process. The video shows me bobbing the EV Warrior around at 5 amps and 10 amps, then standing on the robot to keep it still. Even though the current sensors weren’t verified for the video, it’s important to note that the voltmeter is trying to take an average reading – the peaks might be at 5 and 10 amps, but the average is a little less because of the ripple.

I have yet to try the “crowbar” test where I run a motor near top speed and then suddenly short the output with a screwdriver. This would be the ultimate test of it saving itself without interfering with robot operation otherwise.

While NH may be able to make use of this for saving its drive motors, I’m more interested in this controller now for Uberclocker. Not only does it have bigger drive motors, but the lifter would certainly benefit from current limiting. I don’t have limit switches on the actuators, so the only thing saving them from fiery explosion (or unreleasable self-inflicted lock) is me not being too hard on the stick at the wrong moment. Historically, the top clamp arm has had a habit of locking itself into a position where it doesn’t have enough torque to pull back out. If I had, for instance, asymmetric current limits, then I could clamp with a lower current allowed than releasing, guaranteeing it would be able to free itself again.

I’ll need to fix that regulator inrush problem before really trusting this controller, however, but for the time being I will go ahead and populate the other two spare boards with current sensors!

Oh, yeah, before I forget: The current control firmware that is running on Ragebridge as of right now.