Ragebridge: It Needs More RAGE (and Testing)

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

Hmm.

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.

A New Pushybot

IT’S ROBOT SEASON!

My annual robot party, Robot Battles @ Dragon*Con, is right around the corner. Again.

This is a competition I’ve been attending since 2002 and competing in since 2003 – it’s been my “end of summer festivity” for every year since then, except 2007 when I was retained by the mits for freshman orientation.

For most of my RB history prior to the MITs, I’ve had a primarily drivetrain-centric entry, Test Bot, that worked all the time and was undefeatable so long as I didn’t mess up. After that, beginning with Test Bot 4 in 2006 and really kicking off with Uberclocker version 1 in 2008, I began focusing more on cool actuators and weaponry.  That probably explains why I haven’t won anything since, or really have a robot that can put on a performance without being unreliable. Cool weapons and whirly things are funny until you can’t get it to move straight across the arena to beat the other guy senseless with it.

I’m kind of sick of that. Lack of any real motivation to fix the drivetrain issue with Überclocker Remix thoroughly has led to its losses in 2009, 2010, and 2011. That’s 3 straight years of fail, and I can even name the reasons why. In 2009, the robot lost drive functionality early on because I dared to think that using $2.50 drive motors was a good idea (and brought no spares, also a good idea). I upgraded the gearbox and motor rig to a custom DeWalt solution for 2010, but it slipped a poorly-made output shaft and I didn’t care enough to try and ninja-fix it during the actual event. And finally, last year, with the drive motors finally reliable, the robot ditched chains left and right. Literally. Both of them. Poor tensioning results in the chains catching on… something – I couldn’t tell what was actually going on, but it cost me the tournament. Again, what just totally sucks about it is that it was no fault of the design itself, but just my inattentiveness or ambivalence.

Sigh

So I’m starting a new 30lb build which will be 100% drivetrain. The goal of this build, really, is to just come up with something that’s fun to drive and run into things with again. Piloting the (comparatively well-handling) Cold Arbor test rig around a few weeks ago reminded me of how important it is to keep your robot short, dense, and 4WD with the center of gravity smack in the middle. Soft wheels helps too, as does an immense amount of horsepower in the motors. This 30lber will act as a baseline to compare all my future designs with. The drive will be modular, with one motor per wheel, quickly replaceable and with easy to find spares (something Clocker has never been very good at). The frame will be pretty damn near indestructable. If I can’t beat the all-drivetrain pushy-brick with a new design, then anything else is pretty much hopeless. It will function as the null hypothesis test of robots – to be a proven design, it has to reject (/defeat) the null hypothesis.

Incidentally, that’s exactly what I’m calling it. Introducing Null Hypothesis:

Well gee, it looks like I’m almost done designing it already. Usually my CAD posts start off with a rectangular extrusion or something equally simple, but I’ve been slowly digesting this design for a little while.

Short rundown of the design: Four 18v Harbor Freight 900rpm type drills (now on sale again as item 68239) direct-driving four 40A durometer “McMasterbots” wheels. 1″ thick UHMW bar frame, and polycarb top and bottom. True 0.75″ ground clearance each side. Classic indestructable pushbot! The outside of the bot measures 18″ x 18″, which is a reasoanble 30lber size.

The design above is the “first pass” appraisal of the concept. It has a solid UHMW front wedge that was intended to be carved from a 3 x 4″ block. That turned out to be $150 of UHMW, which seems to have gotten way pricier since my last UHMW brick in 2006, because UHMW is just condensed natural gas or something.

Note how it gets a little weird and irregular out back – I wanted this bot to have no rear traction gaps. A classic “box” frame leave you a finite, usually less than 45 degree, tip angle before the frame lifts the wheels off the ground (for Test Bot 4.5 this was only about 25 degrees because it’s so damned low). One solution was to cut up a pipe and round off the end of the frame, but this left me little space to mount the motors. Hence, I settled for 45 degree ‘facets’ that can get pushed further back to let me add mounting features for the drill gearboxes.

The ground clearance is called “true” 0.75″ because the top and bottom covers are inset into the frame. This leaves me with a 2.5″ frame that has 2.25″ of internal space given the choice of 1/8″ polycarbonate top and bottom, which actually turns out to be not that roomy.

Here’s a “second pass” of the design. When I do a “first pass”, it’s generally just to puke ideas and generate shapes. Some times I find that the shapes end up being nonsensical or impossible.

There wasn’t such an impasse with this design, but I decided to get rid of the solid UHMW brick front. As funny as it might be, I really can’t justify spending $150 on UHMW just to use maybe $70 of it. The wedge ‘sections’ are made of the same barstock now as the frame. A 1/8″ 4130 steel plate forms the business end – I got a plate of the alloy for reasonably cheap, but there might not be an oven big enough for this thing with immediate reach to fully heat treat and take advantage of its strength.

The battery and its retaining mechanism is now shown too. It’s actually really hard to make an all-UHMW 30lb bot – UHMW is just not dense enough, really, so the weight needs to be made up. In this case, it’s with theoretically enough  batteries to run 4 or 5 matches back-to-back. The intended voltage of the system is going to be 25.6 nominal, 8S A123 cells, with 4 effective cells in parallel, physically arranged as two separate 8S2P packs. This should yield a decent top speed of 15mph: not too quick, but also not sluggish. Middle of the road pushybot.

The battery packs will be made with shock mounting padding, then captured inside a 3/8″ or 1/4″ polycarbonate ‘cage’ inside (hard to see, with polycarb being modeled as transparent). The cage is part of the top and bottom plates.

Electronics-wise, I’m trying to decide between the Botbitz controllers that I got to test for Arbor, or my full-custom board (yes, again):

The hell is that thing? I christened it RAGEBRIDGE because, somehow, I have never managed to produce a reliable small H-bridge controller. Landbearshark’s custom controllers were a miserable failure for several now-obvious reasons. I’m also really in need of a synchronous-rectified current-control-capable H-bridge for an outside consulting project – which is really what this board was developed for.

So I took another stab at it. I took every precaution to not loop my grounds and cross my logic with power, so I hope this can become a reliable hardware base.

That is, if i ever receive it. It’s been nearly a month, MyroPCB. The excuse I got was that my order was ‘damaged in fabrication’ and had to be redone. Well hhmm, I hope it wasn’t all those vias….

The reason I’m still holding out hope for these things is because the BB controllers can’t do “true 24v” systems – the Hobbyking ESCs they’re based off of are rated to only 6S lithium polymer cells, or around 26v peak. There are 35v parts all over the place, including the main power capacitors, and the FETs are 30v parts. In other words, a freshly charged 8S A123 battery at 28.8v is most likely too much for them. And I’m not going to back down from that – NH will be too slow if I only run 6S.

Worse come to worst, I have all of those Victor 883s (classic ones, mind you… The FET layout above is clearly borrowed from the Victor883107-7.).

Here’s the front end of the bot. I’m most likely going to just stencil-paint (or laser-etch?) the H_0 onto the front, instead of making it a cut-through, because that weakens the steel too much. Else, I might weld a backup plate behind it.

The top and bottom (and wedge) hardware on this bot is all 1/4″-20 countersunk cap screws, with the side/frame screws being 3/8″-16. Big, meaty threads. I considered using giant lag bolts for maximum grip strength, but they were not available in anything other than “giant oversize decking and timber-clamping Hex head”.

Random little electrical details will be added soon, when I can decide on the choice of electronics.

If you’re wondering where the hell the drill motors are disappearing into…

Hey, first real picture of the build!

Here’s what’s going on. The McMasterbots wheel will use the nose portion of the black flanged piece as a secondary ‘bearing’. This is a scheme to avoid hanging the entire wheel solely off the 3/8″ shady drill steel axle (as is common in drillboxes). The D-shaped nose of the drill gearbox is additionally supported by the mounting flange, giving it more plastic meat. The motor is prevented from torquing and moving axially using fine-threaded set screws (the cross holes in the picture). The flange itself is screwed into the UHMW side rail.

The black plastic piece is made of ABS, rapid-prototyped on the Lab Replicator. The final version will also be made of ABS, and incidentally also to be rapid-prototyped on the Lab Replicator. On a side note, most of my complaints in that post seem to have been wrapped up in the latest firmware for the Replicator – they were probably common enough that an official fix was distributed.

I’ve ordered pretty much everything I’m going to need to make the mechanical bits of this bot in the coming two weeks or so. I have eight drills now, and the buffer pile on my desk is becoming insufferable.

I have to make a decision about how to build the frame. While I was initially going to buy and mill slots in UHMW barstock, I snagged a large plate (48 x 8″) of UHMW on eBay for very cheap. It has all of the square footage needed to build the frame, but separating it into chunks will be a bitch.

While my normal tactic when faced with a giant plate and needing bars and shapes would be to Just Waterjet It, UHMW is well known to be so soft and abrasive resistant that it cuts poorly.

I laid out some test parts (these are the side bumper things) using different qualities to see if any were remotely tolerable. Anything short of high quality (or in Omax terms, “Quality 5”) just doesn’t even make it through all the way, and I can’t get the part out of the material! Even the above piece, which was on Q5, needs all the holes drilled out. The outline is reasonably acceptable, though, and I may make the parts which don’t need to be critically square using the cheap plate. This include those side bumpers as well as the little wedge triangles.

I bought a 4 foot stick of UHMW for the parts that can’t be waterjet-cut, but I might have to get friendly with this plate and a slitting saw in the near future.

This is not it. I have several other robot updates on deck as August rolls in, including:

  1. My kinda-open-secret project of creating a new arena hazard for the new Atlanta Bot Arena
  2. The last round of updates to Überclocker before it will be retired after this D*C event
  3. Maybe a new beetleweight design that I’m tossing around.