Archive for August, 2012


A Hysterical Constant-Current Mode for RageBridge

Aug 15, 2012 in Motor Controllers, Reference Posts

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.

Null Hypothesis: Finishing Up and Testing the Ragebridge v1

Aug 11, 2012 in Bots, Motor Controllers, Null Hypothesis, Project Build Reports

This it!

The post where my project gets stuck in motor controller hell. It happens to everything I try to build a motor controller for, so be prepared to read about exploding FETs and endless nondeterministic troubleshooting!

Well, the story is actually slightly happier than that. In the past few days,

  • The frame has been put together, all the wheels mounted, and battery pack made
  • The Ragebridge has been installed and the robot successfully tested and driven using it, seemingly exhibiting no adverse noise issues
  • The Ragebridge has been successfully detonated when a motor suddenly locked up.

Let’s start from the beginning.

With the wheels bored out, making hubs was the next step. I decided to make these more consistently on a Nice Thing with digital readouts, courtesy of the Edgerton Shop (They were also the nearest straight knurling tool, incidentally). The knurls will help the hubs not slip and strip out against the soft plastic bore of the McMasterbots wheels.

The hubs are installed with an arbor press.

Two wheels in. The hubs are very conventional “drill hubs” with a 3/8″-24 internal thread and internal shoulder that lets the reverse-threaded 5mm locking screw hold the hub in place against both threads. I’ve always found it funny how the ‘cheap drill’ converged solution ended up using an English and a Metric thread on the same part. The outer thread is not M10 or a metric thread, and the internal thread is definitely 5mm x .8 and not #10-32, which only fit down to a few threads. I’m mildly interested in how shady Chinese factories converge towards which design to copy and paste.

It’s starting to look like a robot now.

I temporarily secured the front wedge on with a few screws in preparation for a test drive.

Okay, robot’s done. Nothing more to see.

Using a spare 7S battery pack (from the long-retired Segfault) and the Botbuttz controllers I bought a while back, I threw together this test rig just to try out how the robot handles. Conclusion: It handles like a pushybot with a wide wheelbase and near-midpoint center of gravity! Unlike Clocker, which is back-heavy out of necessity and so oversteers very easily, this thing is extremely stable in turns. The braking effect of the BB controllers also contributes to snap turning response and smooth starting and stopping. These are all features I want to make sure Ragebridge can duplicate.

I spent a while scooting this around before moving onto the real challenge: the aforementioned Ragebridge.

I soldered up another board (the first one having been put into the Silly Media Lab Vehicle). There were no changes made to the board layout, only the modifications addressed in its first post which included moving the low-side gate drive bypass capacitors into the right place.

After verification of the hardware functionality, I spent the majority of 2 days hammering out an R/C input firmware for the board. I added features in the following order:

  • Radio signal-loss failsafes! I figured if I just wrote a dumb Servo-to-PWM program, it would stay that way forever. ESCs for robots need to have a way to shut off the motor outputs on recognition of signal loss, so the robot doesn’t just keep rolling. This part wasn’t difficult: every time a valid servo pulse is received in the pulse-reading interrupt, a flag is set to indicate the reading was good. A checking routine runs once per half-second to see if there were any channels which did not set their validity flags – if there are, then the gate drivers are shut off until all signals are good again.
  • Command ramping, meaning the ESC takes a small amount of time to slew from one direction to another. This is to prevent instantaneous “step reversing” which can cause huge current draws, up to twice the DC bus voltage to appear at your ESC’s power inputs, exploding motors, and other terrible things. I created quite an epicly named function, mapWithRampingAndDeadBand(); to perform this task.
  • Linear stick response. Directly mapping of the pulse widths to PWM output %, through the ramping limiter. This was just to get the robot driveable so I could add…
  • Invert mode, a feature which allows you to redesignate which end of the robot is forward. Useful for invertible bots like NH because otherwise your robot would drive backwards when upside down, as well as have swapped turning behavior. This is activated by the channel 5 toggle witch on my radio, and just swaps the left and right commands while adding a negative sign.
  • Exponential stick response. This makes the initial response ‘softer’ so the robot can be driven more precisely when moving slowly. It tends to reduce spin-out and oversteer tendencies. It is implemented as a simple lookup table – raw command goes in, expo command comes back.

I began to add a ‘stick calibration’ mode, but decided against it for now. Stick calibration is a luxury, because radios can generally be trimmed and have their endpoints modified to suit just about any desired pulsewidth range.

The current version of the RB firmware is here. It’s written in Arduino 1.0.1 (which finally got rid of the CTRL+SHIFT+M bug!). I generated two exponential response tables, one a little more expo than the other. I found the “more expo” one to be a little sluggish in responding without moving the sticks really far, but your experiences may vary.

Ragebridge v1 installed in the robot on its little standoffs…

After testing the controller out on a power supply first (which has nice features such as non-infinite current output in case of a fault) I put the test battery right back in because I hadn’t gotten to making the actual robot pack yet, then made some test driving videos!

The “basic test” was done right after I finished the linear stick mapping, and the more advanced testing is with exponential.

I like Ragebridge’s functionality in those tests. While open-floor driving is not as strenuous as pushing another robot (trying to push you back), high-current transients like from reversal and stopping will be what causes noise-induced failures and latchups. I didn’t observe any of those issues during that test driving, which bodes well for more sustained heavier loads. Unfortunately I neglected to put a Wattmeter on the thing, so I don’t actually have power throughput figures. Typical drill motor drivetrains in this size robot will draw about 30-40A per motor accelerating or changing directions and about 15 amps spinning out the wheels.

With at least a slim prospect of the robot working properly, I started putting together the battery pack:

The voltage of this pack will be 8S2P in lithium iron phosphate, so 25.6V nominal and 28v peak. This high voltage was just to get the speed I wanted out of the motors, but it could prove to be the proverbial Achille’s Heel… or perhaps Achille’s A123 Cell for the robot.

Those yellow things are PTC thermal fuses. I usually just lay more busbraid across the cells to put them in parallel, but the PTCs add another layer of failsafing by limiting the rate at which the cells can differentially discharge. If one cell suddenly fails (or gets punctured) and becomes a short, then the very low resistance of the bus braid will let the other healthy cell short into it, potentially causing even more damage. The PTCs will at least limit this to a reasonable current.

I chopped up some spare 4S JST balance extension cables for the cell taps. Generally I make my own using JST-XH connector shells and pins (e.g. Digikey’s 455-2217-ND), but it takes longer (and most chargers don’t have slots for 8S pack taps anyway). One JST lead is the lower half of the pack and the other is the upper half.

The balance leads are insulated by some Kapton tape layers as I soldered them in. I didn’t want them laying directly on the cell tops any more, after this happened, but on this pack there’s no space to route the wires only down the sides of the cells (it will be laying flat in the robot).

Since this pack will be more enthusiastically jostled inside the robot, I’m giving it a layer of foamy armor.

And after Giant Heatshrinking! I gave the pack its initial balance-and-charge wakeup routine with my 1010B+ charger doohickey.

While the pack was slow-roasting to perfection, I took care of the last bits of electrical work on the robot itself.

This adorable ABS-printed connector holder houses a Deans connector and an XT-60 connector. The Deans is going to be the master switch via the “Georgia Tech Key” method. In order to prevent myself from being confused at which terminal to charge the battery from versus to bridge together (hint: bridging the battery is a bad thing), I just used a totally different connector for the charge plug. The connector housing is mounted to the bottom plate.

This is the “Georgia Tech Key”, so named because I’ve only seen it on random GT creations before. Technically it’s called a removable link.

I made this loop a little too long and it sticks out the top of the robot by a little, but some tape should keep it down. In the worst case I’ll just replace it with a directly shorted Deans connector.

Alright, here it is. That’s it. The robot’s done.

Now to hand it off to other people and drive it around until it blows up! The best way for me to find the weaknesses of any of my builds is to give it to other people. I subconsciously go easy on things I know may be unreliable (the so called Creator’s Mercy), but other people have no concept of, say, the drills being severely overvolted, or for instance in the case of the Chibikarts, that flooring the throttle from a standstill may not result in satisfactory behavior.

I wasn’t able to whip out the video camera in time to capture the magic moment, but what happened was this:

And this:

What triggered the failure was a MITERS member driving (very happily and enthusiastically) NH into a solid machine frame at pretty close to top speed. The robot stopped moving, and I instructed him to give a little throttle to see if the controller was still working. It’s actually very difficult to judge what people consider ‘a little throttle’ based on experience, so I can only assume that it was near full stick or something. A small explosion was seen inside the case.

The superficial damage was the blown ground trace and one very, very unhappy MOSFET. The actual damage, though, as I found out through subsequent hours of checking and debugging, was pretty much the whole thing. The Arduino Nano was fried (noted when I powered it back on and the ATMega started drawing half an amp…), as were all 4 FETs on the exploded side (gate-to-source shorted through), both of the IRS21844 gate drivers on that side, the gate-to-source protection zeners (which I’m sure did all the protection they could before exploding), as well as half of the 74LS08 quad AND gate that is involved in piping the PWM signal to the gate drivers.


After replacing most of the semiconductors (and the Nano) failed to make the controller work consistently again, I decided to just scrap this board. Some times, enormous transients damage components in ways that are unexpected

And that’s the motor after I took it apart.

I think a combination of being oversped (18v overvolted to 28v) and sudden impact (running into the solid object) must have blown off the commutator segment. These motors are not really what I would call “well made” since the whole drill they come in costs $20. Running 28 volts is certainly up for compromise. But, I enjoy the speed of the bot on such a voltage.

Good thing I have a small forest of these drills!

So the final version of the story is, NH was finished and blown up, and is now unfinished. Putting together a new controller (with some mods I will discuss below) and pitching the bot  back together should not take long.

ragebridge mods

Now that I’ve gotten to know Ragebridge a little better, I have in mind a list of issues and changes I’d like to make when it’s time for version 2. Since V1 actually seems to work fairly well, this is not an immediate task.

First issue to take note of is of course the misplacement of the gate drive bypass caps. This is what led to the very first board not working at all until I changed it. Clearly this is a routing matter and the second version of the board has to address it, but for now it is easy to hack by hanging the little capacitor off the pins of the 21844 chip.

Second, the row of input headers at the top of the board are not in a very useful order. Two of them were designed for “servo” style connectors which are terminated signal-power-ground, and two for ‘potentiometer’ style inputs, terminated power-signal-ground. Well, I got the servo input order wrong anyway – those two headers actually are connected signal-ground-power. So I had to make two different styles of deceptively incompatible servo cables to suit the board because I needed 3 channels of input. I’d just line them all up signal-power-ground in the future, even the “analog” inputs, for better consistency.

Next, and an issue I can hack around for now, is the way that the power traces narrow awkwardly and haphazardly:

Those yellow highlights is where the trace width drops significantly from the average. The ones at the left and right bug me in particular – I was definitely trying to keep the controller within a reasonable width, but the heavy power traces around them are easily double the width and very short too. I was intending to reinforce those with braid or wire, I think, but didn’t actually do it for this board.

The circle near left center is a really obvious design derp. Most of the power stage of the board is basically rotated 180 degrees from eachother, except that current sensor placement. The right side of the board has no corresponding narrowing – current flows down through the vias on the right center two FETs for MA2, and the right side’s current sense path is a straight shot.

Given that these traces are all made in 1 oz copper, they’re exceptionally prone to sudden current overloads, such as a near doubly-overvolted drill motor suddenly slamming to a halt. The current sense path on the left is a little more difficult to reinforce since it’s under that FET, but as long as I’m not using the current sensor on these boards yet, I could hard-jump it with a piece of wire.

Overall, I’m satisfied with how Ragebridge has been behaving (short of being inductively crowbarred by an unhappy drill motor), and I’m going to be building more of them to test on other bots soon…and of course fixing this one.


Null Hypothesis Grand Update: From Zero to Something, I’m Not Sure What

Aug 08, 2012 in Bots, Null Hypothesis, Project Build Reports

What do you mean Robot Battles at Dragon*Con is in 3.5 weeks?!

Again? I swear they move the thing up one week every year just to surprise me. Actually, it’s more like 2 and a half weeks before I get to Epic Road Trip once again from Boston to Atlanta (ideally not through The Sprawl) and temporarily set up base camp at the Invention Studio. So maybe it’s time to start on a robot or something.

Luckily, I’ve actually been working on Null Hypothesis on and off for about a week. As explained in its introductory post, I was needing to separate a large 8 x 48″ panel of 1″ thick UHMW into slightly funny-shaped bars with the waterjet. I test cut one of the less important frame pieces to check for quality of finish, and determined that only cutting on the highest quality was going to even have a hope of getting through the material. UHMW is notoriously hard to do anything abrasive to since it resists abrasion really well.

One mistake I made but only realized later is that I was testing that piece on a setting meant for polypropylene plastic, which machines much easier – one of the most machinable plastics.. Every material is assigned a “machinability” value in the OMAX software, and this is one factor in controlling how fast the jet moves – and cut quality is pretty much a function of slow. Even “generic” plastic and acrylic-specific settings have machining speeds around half of polypropylene. Therefore, I elected to just throw the panel on the machine and hope for the best using the highest quality finish.


By the way, cutting a mushy plastic like UHMW – or any plastic, really – causes a disgusting film of plastic goo to cover the surface of the pool, because the particles both float and stick together. I was skimming handfuls of plastic snot out of the tank as the job progressed.

The job took an hour and a half, which I can’t really say is much faster than me cutting off a bunch of barstock like I would have done Back In The Day. I had bought enough UHMW barstock in the correct size (1″ thick, 2.5″ wide) to make most of the frame anyway because I was uncertain that the huge panel would have been useful. But, with the combination of very high quality cut (slooooow) and actually selecting the correct material properties, the frame pieces came out very smooth and square. I was otherwise prepared to redesign the frame a little to get rid of those hard internal square corners and slots to relieve me of the extra machining.

Also on deck in the same session was the front and rear steel parts, the top and bottom polycarbonate covers, and the internal electronics mounting structure. Above are the front wedge and eventual rear bumper thing. Both are made from annealed 4130 plate steel purchased from McMaster.

While I don’t really have facilities big enough to heat treat these plates short of throwing it on top of a gas fired barbeque grill for an hour, buying a plate of generic mild steel was actually more expensive – a 6 x 36″ plate of 4130 in 1/8″ thickness costs $36, whereas generic 1018 steel in the same dimensions is more like $50. Strange, given how much more versatile 4130 can be -  not only is it stronger even in annealed form than mild steel, but I could harden it to the high Rockwell C40s.

I attribute it to McMaster knowing what people buy most frequently and giving those product some… extra markup.

Here’s the pile of structural parts. The top and bottom plates are 1/8″ polycarb, and the supplementary electronics armor is 3/8″.

I’ve pre-bent the rear bumper because it took me a few tries to get it right. First, the extra-strength 4130 defeated my attempts to bend it using the largest metal brake I could find – a 10 gauge rated, 50″ box-and-pan brake. The cold 4130 plate, a foot wide and at the limit of the machine’s capacity, would not bend.

Next, I tried heating it up with a torch, but I don’t think I got the part nearly hot enough (that or my torch was too small, another possibility). While the hot plate did bend, I didn’t tighten the finger clamps enough or something similarly bad happened, so my bend line slipped about 1/4″ back on one side. Whoops, asymmetric part…

I gave up and recut the plate out of some scavenged 1018 mild steel plate – this bent just fine. Honestly, for Robot Battles I could well make this plate from jello and it would still be enough.

UHMW is almost always manufactured oversize and to rather loose tolerances because its primary industrial application seems to be skid pads and wear plates. For that, precision is not necessary. My 1″ UHMW plate was more like 1.03″ (not 0.003, 0.03), so some of the rectangular slotwork in the top plate didn’t fit. I plowed off the extra thickness in the region of the slots using tinymilll, our super adorable LittleMachineShop mini mill.

The frame standoffs are stock from McMaster. Now, these things come threaded, but I actually just need spacers (unthreaded, pass-through), so I drilled them out.

It turns out that large standoffs only cost about $1 in quantity. McMaster must have found a cheap supplier for standoffs recently, because I definitely remember almost all of the small ones like 4-40s and 6-32s also costing $1 each or so. But now they seem to hover around 30-40 cents.

This is great, because it means it’s actually far cheaper for me to buy a bag of them as “stock” than to machine them myself. Previously, if I needed a bunch of odd standoffs, I’d machine all of them, which takes alot of time, and I’m sure an industrial manufacturing process can produce more consistent parts than I ever care to.

Because I was able to keep the slots and cutouts, the frame acted as its own machining fixture very well. I clamped the parts to the table and drilled where needed. It was pretty much assembled in situ. All of the fasteners are 3/8″-16 button head cap screws. On the top and bottom, I’m going to have 1/4″-20s because larger screws have impractically large heads to countersink into 1/8″ thick material.

The back plate was clamped in place on the bot first, then the mounting holes drilled and tapped in-place. The steel was very slightly too acute of an angle, but the screw pressure was enough to keep it fully flush with the beveled surfaces. I like how this back plate came out.

One advantage of keeping with the strict waterjetting diet is that I was able to easily make these ‘form fitting’ mounts for the drills. Granted, 3 holes and a big center bored hole would have gotten me the same.

Because the material is so thick, the entirety of the gearbox is well supported. The motor is actually fixtured from movement on the outside of the frame rails…

…like so. I’m really hoping these 3D printed ABS hub-things stand up to physical abuse. They’re 100% solid, but ABS is still a pretty soft plastic, especially when laid down in noodle form using the Lab Replicator (because we live in the future now). This let me build the double-D shape of the drill output exactly.

I didn’t actually get to mount the motors permanently – the frame wasn’t done with hole drilling, and I was also missing the correct screws to secure the flange to the frame and those giant set screw things for the motors.

Most of the frame is now completed. The top and bottom plates were also drilled and tapped in-place using the holes in the polycarbonate plates as a template. Afterwards, they were clearance-drilled and countersunk appropriately.

Frame fully assembled now, but without the front wedge holes drilled yet. I was waiting on the correct length 1/4″-20 screws to show up before I mount everything.

In the mean time, I started dissecting drills. I have, in total, 8 dril….err, drive motors for this thing, and hopefully I don’t go through all of them. These are all Harbor Freight p/n 68239, the latest model of shady 18v drill HF offers. They have a verified 24:1 gearbox, though with a plastic first stage (not necessarily bad, in my opinion).

Even 24:1 is a little high ratiowise for the speeds I want to get to with this thing. The bot will hit about 15mph on 26 volts (8S A123s, 3.2 volts each), which is a little on the slow side for my tastes despite Clocker never hitting over 10-11mph. It is, after all, a 100% drivetrain bot. I’m also uncertain that the drill motors will like such drastic overvolting. That question will be answered concretely once I put this thing on the ground and push some things around.

The drills’ torque clutches were hacked in the classical fashion. I used to know many guides on to hack these things, but they were from years ago and many have gone offline as builders retired. Basically, the hole is the perfect size to tap for #10-24 or #10-32. Short set screws are used to entrap the dog clutch element that is the main component of the adjustable torque limiter – without these, the ring gear would just spin freely and no torque can be transmitted to the wheel. Dale has another method of locking the torque clutch which is a bit more compliant.

I decided later to proceed with drilling the wedge mounting holes, since I had a bad idea coming up for the plate itself. The wedge was clamped directly to the frame, aligned horizontally, and the holes drilled and tapped in situ.

The process I’ve been using is first drilling a dimple using a pilot drill of the template hole diameter (in this case, using an F size drill because I designed those holes to clear 1/4″-20 scrws), such that the dimple is reasonably well centered. Next, I switched to the tap drill diameter and let it settle in the dimple, then just freehanded it. Not all the holes are dead square, but that’s just a consequence of free drilling and only practice and experience can get them close.

Alright, so this is the bad idea. Not shown in the robot’s 3D model, but in the works all along, is turning the wedge holes into slots. This would have been a trivial operation if I were actually just slotting, but because bolts protuding from the surface of your wedge is a glaring sign of n00b, I had to make countersunk slots.

It involved a 6-flute metalcutting countersink (no, do not try this with a cheap hardware store 1-flute wood & drywall countersink), lots of cutting oil, and going very slowly. The whole machine would occasionally rumble and generate a small local earthquake every time I began cutting. In the end, countersunk slots!

And they fit!

Well, most of them – there’s at least 2 which I felt were “oversunk” and wouldn’t be as strong as one of proper depth. That’s why there are 16 screws up front, right?

it’s also being screwed into uhmw.

The ride height of the wedge is adjustable from essentially floor-scraping to about 5/16″ up. The D*C arena/stage/combat surface is not guaranteed to be flat anyhow, so this lets me calibrate the height to the stage as needed.

The last operation of the night is coring out the wheels. These are McMaster’s p/n 2243T41, or “McMasterbots” wheels as I call them, 40A durometer donuts of rubber overmolded onto polypropylene hubs.

As shown in the design previously, these are supposed to partially envelop the motor mounts and use them as a rudimentary secondary bearing. Hopefully, this will make the drivetrain nearly indestructable (from axial and radial impacts like being dropped or flipped) because the majority of shock loads will not be transmitted through the gearbox nose.

The machine of choice for this job is hueglathe, the 19″ LeBlond Regal, because its chuck can effortlessly grab the entire wheel.

Four wheels cored out to the appropriate depth. Can you guess for which one I forgot to tighten down the chuck before plunging the boring bar into it?

This is how it will go together.

Still to come: Making the wheel hubs, permanently mounting the motor and wheels, and then…


That’s about it. This is a pushybot, after all.

Kitmotter 0002 Design Files

Aug 04, 2012 in Kitmotter!, Reference Posts

Now that I’ve put a few miles on Kitmotter 0002 in the form of Johnscooter, I’m more confident in releasing the design so people can build their own versions or modify it.

Ride testing has let me measure Johnscooter’s propulsion efficiency at about 29 Wh/mi. This is a little worse than RazEr’s 25 Wh/mi, but besides having the World’s Trashiest Bearings, the fact that Johnscooter is operating almost entirely in 25A constant-current mode (due to the current-limiting nature of the motor controllers) means I’m basically full-throttling it everywhere. RazEr and RazEr Rev had a more “open loop” voltage drive which let me draw brief bursts of current to get over obstacles at a higher speed where Johnscooter would slowly crawl through the same.

The motor itself has been holding up fairly well for being made of particleboard (more properly, hardboard, which I suppose is rather plastic-y as wood goes). The new stator hub has been holding up with no issues so far, and it was the most worrisome part of the current design.

It has a few dings on it from actual use on sidewalks and bike lanes, and I never did drill those through-holes for the wheel mounting flange. So the wheel is loose on the motor a little, but when rider weigh is pressing on everything there’s nothing that feels strange.

The trashy 5/8″ bearings have loosened up substantially over time – both in seal drag and in…. radial runout tolerances. I can now grab the motor and wiggle it very slightly, and the greatest contributor to the noise spectrum when riding is those bearings. If anyone else builds this, remember that even though I have the Trashy McMaster Bearings listed in the Bill of Materials, real precision flanged 5/8″ bearings should still be seeked out if possible.

Speaking of BOMs, the files are located here and this is what the ZIP file contains:

  • Original design files in Autodesk Inventor 2012 format. Unfortunately I’m not quite so motivated as to provide generic/open source models for everything.
  • Premade DXFs of all motor mechanical parts ready to cut on your favorite 2D Rapid Proto gadget. The materials (e.g. “0250_al” meaning .25″ aluminum) are recommendations, but the rotor rings MUST BE STEEL. Otherwise, feel free to cut the 1/8″ spacer rings and 1/4″ endcaps from polycarbonate for that clear case-mod motor effect or aluminum for extra strength.
  • Basic bill of materials with most hardware and mechanical parts. The tools I used to carve out the wheel center are also included in the BOM. There’s things that are missing from the BOM because they are variable with each design, including the magnet wire, output leads/termination methods, and optional Hall Effect sensors.

There’s some fab considerations which I’d like to share for this particular design, as they might make the motor more durable:

  • Please, please make the endcaps from something which is not wood. Pleeeeeease. (There’s nothing that wrong with it mechancially, I suppose, but just don’t ride through rain).
  • The two 1/4″ discs can be made from four 1/8″ discs – this is in fact what my endcaps above are – if it would make it easier and cheaper to fabricate. For instance, I ordered a single panel of 4 discs plus the “0125″ parts from Big Blue Saw.
  • The stator hub is designed to be a loose fit with a standard non-kerf-compensating laser cutter. Waterjet cutters and BBS’ laser services all offset the kerf such that parts come out “true” to dimension. Parts made using this method will be tighter-fitting into the stator and shaft as a result and might need filing or sanding.
  • My final winding is 30 turns (+/- 2) of 9-strand-parallel 28 gauge magnet wire. This is equivalent in area of copper to a single 18.5 gauge wire. Dual stranded 22 gauge wire is also workable and 22ga is probably easier to find. This results in an intrinsic Kt (V/rad/s, or volts generated per rad/s of rotational speed & Nm/A, torque per ampere of phase current) of 0.18 – the Kt will vary a little depending on exactly what drive profile is used (trapezoidal, sinusoidal, sensored vs. sensorless, poor vs. well-timed sensors…). The final line-to-line resistance was 0.31 ohms.
  • Magnet wire is cheaper on Amazon and eBay, but here’s a McMaster roll of 22 gauge.
  • Drilling the wheel flange holes through the tire is probably a good idea. Wood/sheet metal screws, with coarse threads, should be used to fasten wheel to the flange.
  • Really, really crank down the #2-56 axial tie rods (but don’t strip the threads!). #2 hardware will pretty much fail in shear instantly if they’re loose and your weight is on them, which is why I tried to use so many tie rods to compensate. The more these are tightened, the more static friction exists between the layers of the motor, so the more weight they can take from the wheel without shearing the screws.

I expect to see more examples of this construction in the near future. Remember, buildable without big machine tools!

Ragebridge: It Needs More RAGE (and Testing)

Aug 03, 2012 in Motor Controllers, Project Build Reports

After a brief detour to Otakon 2012, I’m back and ready to push forth on the everything ever that needs to happen for Dragon*Con 2012 and its associated Robot Battles. There’s actually alot that has been going on lately, but I haven’t been keeping up with the site updates. I’m going to fix that now… but notice how there’s no update on Null Hypothesis yet? That’s because I haven’t started on it. Hmm…

First up is a new chapter in my neverending fairy tale of chasing after the mythical working motor controller, Ragebridge. First addressed in the NH post, but actually designed several weeks ago, Ragebridge is my newest attempt at finally making a reasonably reliable small H-bridge controller for robots or certain DC powered vehicles. My first (and only) successful H-bridge was one hell of a start – it was a 60V, 100-200A (the amperage never having been truly pushed) unit for LOLrioKart. I have not produced a single working H-bridge since, and I really can’t say I understand why even after this board.

The last update concluded with myroPCB taking eons to process my order. I’m glad to report that since then, I’ve gotten the boards!

…all 4 panels of them. Wait, I only orderd one panel of 4 boards, and now I have 16 boards. Is Myro’s excuse for fucking up your order in-production (their excuse when I called them to inquire, 2 weeks past the 1 week leadtime guarantee) to just send you an asston of boards so you’re happy?

Well, I’m sure as well happy. Who can stay mad when there’s more boards?

Now, these things had better work… If they do, I really might consider releasing some of these to other robot builders to test, because 16 boards is alot of door decoration.

I begin the board population by placing all of the ICs and flat stuff.  The FETs and capacitors, since they stick up pretty far, will go on last. On this board, I placed almost all of the passive components (the Rs and Cs, and some other things) on the bottom side. Diodes, such as the zeners for the FET gates, are all on the top side, since they’re semiconductors.

If I were actually to try and get this board made by an assembly house (or maybe I’ll just sell it to Hobbyking), I’d try my darndest to put all of the components on one side. Double sided boards are more challenging and expensive to populate because they involve flipping the board. So if the design proves reliable, I might make some more layout permutations and possibly even form factors/sizes.

I tend to test my boards in stages – getting the logic power working is one such stage. Here’s some verification that my 15V gate drive and pre-logic rail is indeed working – it’s lighting a 12V LED incandenscent-replacement.

Incidentally, this step took a little while to finish. I accidentally replaced a logic bypass capacitor with a 0 ohm jumper resistor. That explained why the regulator was only outputting 50 millivolts and becoming very unhappy. It took me a while of searching for accidental net overlaps in Eagle and solder bridges before I thought that the number of resistors did not quite match up with the board design.

After that minor issue was fixed, the logic power began working fine.

Now with more Arduino. I first wrote a “dumb” PWM testing program to make sure the outputs were all working. This just entailed putting a 50/50 PWM on each side, alternating between forward and backward every 5 seconds to test if the gate drive and PWM AND’ing circuit worked. During this process, I discovered that one FET was dead – which was unsurprising, since it was salvaged from another controller.

The FETs I used on this thing are some 3.4 mohm units from Infineon. I’m generally a die-hard IRF fan, but their shit is getting too expensive for me to keep blowing up ($6-7 each, and I went through a whole rail of 25 for the Tinytrollers and LBS boards…) and these D2PAK-7 FETs were only $2.18 each in reasonable quantity… And it’s not like I’ve had a controller fail from overheating yet.

Since my outputs were all valid, I decided to throw a small test motor on it. This small 24v random motor worked fine, even on a bench power supply with hard stepped reversing.

Mostly because it stores too little energy to actually do damage. I next tried this exercise with a classic robot motor, the EV Warrior. Hey, I figured if it can hard-punt an EV Warrior on 24 volts (by this time, I was running 75% duty cycle on a 30 volt power supply), it could survive anything. Except it was still on a power supply. Power supplies, generally, do not “sink” current very well – if there is an attempt to reverse current flow, they either tend to crowbar (protection circuitry) or the voltage on the output will surge uncontrollably as the reverse current charges the output capacitors. In my case, I briefly saw the supply flash to over 60 volts before it shut off its own outputs.

I was left with an entirely dead side  – the spike itself was likely much higher than 60 volts. After appraising how much of a dipshit I was for trying that stunt, I replaced the dead IRS21844 chips (and 1 blown FET) and all was good again.

The original application for Ragebridge is to drive the Silly Media Lab Vehicle project I’m working on this summer (like… just about every summer, now that I think about it). Now, while I like documenting and publicizing things I do, this isn’t really my project to do so with. So here’s a picture from a little later when the test board has been installed into the vehicle. The drive motors are some 500W wheelchair motors which are rated to 100A stall, so they should be a pretty healthy load for this board.

Ragebridge’s first test was a little inconclusive. I began running into the same regulator latchup problems as Tinytroller – the LM2594 circuit would, seemingly randomly (but vaguely correlated with surge loads) enter a state where it outputs approximately 6-7 volts and makes an audible buzz. The situation is only resolved with a power cycle. These things are supposed to switch at 150kHz, so if I hear it, something’s gone terrbly wrong.

I spent a while trying to figure out what might be causing it, going through my usual motor controller differential diagnosis processs like…

  • checking that I didn’t swap my Zener diodes with 100V bootstrapping Schottky diodes, or vice versa (which would actually be bad, as I was running about 30 volts and my Zener stock is all 16-17 volts)
  • adding more capacitance to the regulator circuitry, since the amount I had on was under the recommended bus capacitance in the datasheet
  • adding zener diodes to the 15V rail in case for some reason power was backflowing into it,
  • and adding a “precharge resistor” to the regulator’s input in case it was a dV/dt problem during direction changes – the resistor and input bus capacitors form a RC circuit which should absorb any sudden input spikes.

I never got to that last one. Since Tinytroller exhibited the same kind of regulator latchup, and seemingly nobody else in the world has ever seen this problem happen, I decided it must be some kind of systemic terrible layout fuckup that must be obvious. I submitted the design files for Ragebridge to He Who Has Actually Reliable Motor Controllers and Stuff, and the verdict we agreed upon was that nothing substantial was wrong with the design, except this weird arrangement of capacitors:

This is where I need to explain how the IRS21844 gate drive chip works. It has two different grounds, one for logic and one for power. Hypothetically, they are allowed to float 5 volts apart, providing some semblance of isolation between logic and power. It’s not as pure as fully optocoupled logic in terms of noise robustness, but they sell these things to people so they must work, right?

Anyways, the pin on the chip that is supposed to be logic ground is called VSS. I generally call my boards’ power-side return (/battery negative) VSS also. The actual pin on the 21844 which is supposed to be on the power ground side is called COM, and the datasheet recommends a ceramic bypass capacitor between VCC and COM to accommodate the pulsed gate drive current, which can reach about 1.5A for a few dozen nanoseconds (read: super-fast dI/dt). If you’re lost, don’t worry – clearly so was I.

I’ve generally copied and pasted my gate drive & power schematics from one controller to another. Looking back, this particular nugget of the schematic was taken from Tinytroller. After Melontroller 2′s success, I decided to start totally over with the layout. This is where the mistake occurred: Instead of routing the “low side” bypass cap from VCC to COM, I bridged it between VCC and logic ground, the chip’s “VSS” or my “AGND”.


So basically what this means is, first, the low side had no bypass capacitance at all. Looking at the Ragebridge original design picture, gate drive return current has a hell of a long way to go before it can reach the regulator’s return, all through narrow traces with lots of corners and vias.With pulses of 1.5A needing to evacuate in matters of nanoseconds, I’m not exactly surprised that substantial voltage transients could have been induced in the ground traces. The job of bypass capacitance is to absorb these rapid voltage transients very close to their source (the drive chip) so they do not propagate to the rest of the board.

Second, should the local 15V gate drive supply become unstable because of the pulsed current draw, its effects are capacitatively coupled into my logic ground. Again, while possibly small, it can’t be that good.


I had to execute a little bit of ninja soldering using the finest SMT tip I could locate in order to fix the (not even certain) problem. The caps were removed from their pads on the underside and then carefully jumped across the requisite 21844 pins (VCC and COM) on the top side.

And it worked. I’m guessing moving the errant cap to the correct side of the divide made the VSS-COM distinction actually useful, because this seems to have cured all of the ills that was plaguing the regulator.

While I can’t really post video of the SMLV working, I have yet to get Ragebridge to reset a single time after this change was made, even under rapid forward-backward direction switching. The maximum batttery-side current (measured with a Wattmeter) was 76A, though this was surely very brief. But it proves that Ragebridge can at least handle those kinds of surges. The 3.4mohm FETs used on this board should be good for at least 40A continuous duty. The components on the board are selectable for a wide range of voltages – the board I put together above can probably run 36V robot systems without problems, with 60+ volt rated major power devices.

I’m confident enough now in this design that I want to pitch it on a robot. Even as powerful as the SMLV motors were, they were fighting against alot of inertia (literally, my morbidly obese ass) and generally moving very slowly. I can’t just whip the whole thing back and forth on a timescale of milliseconds. A robot motor, such as the venerable 18V DeWalt motors, have much less inertia and can change directions (and currents) very quickly. This test would be to see how well the Ragebridge design stands up to these higher, faster transients. If they prove to be no problem after the changes were made, then I will rage-quit everything because god that was so obvious of a fuckup.

Too bad I took apart my only generic 30lb drive base last month. Fortunately, I’m building another one soon. Overall, I’m glad that to fix at least 90% of the problem, no traces and wire jumps were needed because that would have seriously made these boards unattractive for use.