Arduino Hex-Bridge Shield: Concept and v1.fail

So, I guess I am finally coming to terms with living in a world where Arduino rules. If you've been living under a rock, an Arduino is an AVR-based microcontroller development board with an array of peripherals, a huge library of code, and a large user base. They have become a staple of DIY projects and "Arduino compatibility" of DIY hardware is now a legitimate concern.

I'm faced with two options, then. One: I could continue to rant about how I designed most of my current TI MSP430-based hardware to do everything the Arduino does, but better, and how the Arduino is not a replacement for learning how to design circuit boards and program microcontrollers directly. Or, two: I could drink the Kool-Aid and make something useful that also happens to sits on top of an Arduino.

Cue the Hex-Bridge Shield. (Scientific name: Large Arduino Switching Shield with Field Effect Transistors.)

Here are some pictures of v1.0, a failure for reasons which I will discuss below:

Hex-Bridge, Top Side: MOSFETs.

Sidecap.

Hex-Bridge Bottom Side: Gate Drive.

Okay, so calling it a shield is a bit of a stretch. It doesn't really sit on the Arduino so much as the Arduino sits under it. (Can you see where?) It's pretty compact for what it is, though: six semi-independent, high-power MOSFET half-bridges, with all the gate drive circuitry included. Each bridge was a version of my modular half-bridge design, which I've used in every motor controller I've built for the last two years.

The gate drive is based on a design we originally did for the Cap Kart long ago. Each FET gets its own 2.5A gate drive optocoupler (HCPL-3120). An optocoupler passes a signal through an LED and photosensor (packaged in a single chip) to electrically isolate a circuit, which is useful for protecting the microcontroller from high power switching noise. These particular optocouplers are designed to drive the gate of a MOSFET, on when the LED is on, off when the LED is off. By arranging two LEDs in anti-parallel and including a low-pass filter, passive shoot-through protection for each bridge is achieved.

One high-level half-bridge schematic.

Notice how the LEDs are arranged so that only one can be on at any given time. Also notice that the low-side gate drive optocoupler is fed by an inverted signal. This creates synchronous rectification, mirroring the PWM on the low-side to minimize diode losses and allow regenerative braking. This is just a high-level schematic, leaving out details such as the shoot-through delay filter and the gate resistors and protection components. But it should give the general idea. One down side of this method is that it requires a separate high-side supply. This makes it expensive (about $15 per bridge for all the gate drive components, which is more than the FETs themselves). Integrated half-bridge drivers such as the IR21844 provide a less expensive solution. v2.0 will use these.

The MOSFETs are IRFS3107 surface mount packages. They have a typical Rds of 2.5mΩ. (For reference, that's about the same as one foot of 14AWG copper wire.) These are monstrous 75V FETs that can, with proper heat sinking, probably handle "high-double-digit" currents. Throw a fan on and I don't even want to speculate how much current you could pass through it.

IRFS3107 Output Characteristic. 

0.2V at 85A...way better than an IGBT.

Everything on the board is sized for an input voltage of 18 to 48V. On the input, there is 990μF worth of 63V electrolytic capacitors. (These could easily be replaced with 50V or 35V capacitors of higher capacitance for lower-voltage, higher-current applications.) An LM2575HV switching regulator provides 15V @ 1A to power the Arduino and the gate drivers.

An here's where the failure comes in. Take a look at an Arduino. (I know you have one.) All of the digital signal pins are on the top row of headers, but the +5V, VIN, and GND pins are on the bottom row. I made the horrible mistake of running lone +5V and VIN lines from the LM2575 and the logic ICs, around the entire high current switching board, to the bottom headers. Bad bad bad bad bad bad. I can't even describe how bad it was.

By eliminating those traces and running an external connection for +5V, GND, and VIN, I was able to eliminate at least the most dramatic of the failure modes. While in this hacked state, it was able to run 20A continuously through a single phase with just natural convection. The resulting FET temperature was about 90ºC. Extrapolate as you see fit for a current rating with paralleled FETs, heat sinking, and/or fans.

So it has the potential to work, but in terms of a board design, this one is total scrap. Version 2.0, which is already in the works, will be better in every way. (Smaller, cheaper, better mechanical and thermal layout, easier to stack additional shields on.) But since I have nothing much to show for it yet, I can only tell you the design intent:

It would be great if the Arduino had six completely independent high-resolution PWM channels like some chips do. Then you could control two brushless motors. You could even do sinusoidal field-oriented control! Well, maybe not. But anyway, it would be cool if this shield could be used to control two brushless DC motors using square wave drive, at least. With six phases to play with, that should be possible. The trickiness is in multiplexing the PWM signal from Arduino pin 9 and 10 out to each set of three phases. Thinking about NAND gates makes my head hurt, but fortunately I got some help in coming up with a creative solution using an analog switch:

Chuxxorplexer

Actually, the real key is using one selector pin to completely control each bridge, including being able to disable it. This is where tri-stating comes in. If the selector pin is driven high, the relevant PWM from pin 9 or 10 is ANDed in and the bridge executes synchronous rectification. If the pin is driven low, the low-side FET is steady on, grounded that phase. If the pin is set as an input (high impedance), neither FET is on and the phase floats. This allows full four-quadrant control while still preserving the "off" state. Don't ask me how the analog switch accomplishes all that in one shot...but it does. Just stare at it until it make sense. That part totally works. This is what comes out of the magic box:

Digital pins 2-7 are used to select a state for each of the bridges. The bridges are labeled {A, B, C, U, V, W} from left to right. Each bridge can have one of three states:

• When its state pin is written HIGH, the bridge executes synchronous rectification based on the PWM present on pin 9 for A, B, and C, or pin 10 for U, V, and W. This means the high side FET will be PWMed with a duty cycle set by analogWrite(9 or 10), while the low side FET does the opposite.
• When its state pin is written LOW, the low side FET of the bridge will be steady on and the high side will be off. This is effectively like grounding that phase. The PWM does not matter.
• When its state pin is set as an INPUT using pinMode(), it will turn off both FETs and the phase will float. This is useful for disabling the controller or for the undriven phase in BLDC control. Note that even in this state, diode flyback can occur.

Unfortunately, the Chuxxorplexer won't make it into v2.0, which uses a different gate drive configuration entirely, but the functionality will be preserved using a much less elegant brute force set of logic chips. The important thing is that the three-state control in the table above will be preserved. This is, IMO, the cool part, giving almost complete flexibility of bridge configuration for one or two motors.

Here are a few examples:

 Monster H-Bridge

The monster H-bridge can be achieved by setting {A,B,C}={1,1,1} and {U,V,W}={0,0,0} for forward, or {A,B,C}={0,0,0} and {U,V,W}={1,1,1} for reverse. This parallels three bridges to make a super half-bridge, then combines two super half-bridges to make the full H-Bridge. This gives the highest current reversible control with regenerative braking.

Dual H-Bridge

The dual H-Bridge, also known as the drive controller. This can be used to drive the left and right sides of a tank steer robot. Since each bridge only uses one FET per leg now, the current capability is lower than the single monster H-bridge. To get this configuration, {A,B,C} = {1,0,X} or {0,1,X} for forward and reverse and {U,V,W} = same idea. X means that the unused phase is set as an INPUT, left floating. Hey, why not use the two unused phases to make a third H-bridge? Because there are only two PWM channels. Sorry. But the next one should be obvious...

Hey now...

The dual-channel BLDC controller, something I've seen before somewhere. Basically, you would cycle through every permutation of {1,0,X}, one phase driven, one grounded, and one floating. Except now you're on your own for how to achieve electronic commutation. One idea would be to use the floating phase and an analog pin to do back EMF-based sensorless control. Another idea would be to use Hall effect sensors and interrupts.

Monster Half-Bridge

The monster half-bridge, also known as the weapon or spin controller. It can only go in one direction, but it parallels all the MOSFETs for the highest possible current capability. This is actually not a "safe" configuration, since it is possible (and likely) to shoot-through from ABC to UVW if the PWMs are not in sync. To get this configuration, use only one PWM, 9 or 10. Set the other as an input and tie them together with a resistor. If you don't do this, instant destruction will occur. Along the same vein, there is also a monster BLDC controller configuration that ties A to U, B to V, and C to W.

Lastly, my favorite configuration: the SepEx controller:

SepEx Controller

This combines a super half-bridge with a regular H-bridge. The super half-bridge controls the high-current armature winding of a separately-excited DC motor. (By the way, don't bother reading the description of the SepEx motor's regenerative braking method on that page...it's totally wrong.) The smaller H-bridge controls the low-current field windings, allowing the field to be varied and reversed. Now, I don't want to pretend that this controller is powerful enough to drive a D&D SepEx motor under full load...it's not. But conceptually it can be configured for the SepEx by using {A,B,C} = {1,1,1} and {U,V,W} = {1,0,X} or {0,1,X}. Actually, don't I have a SepEx motor somewhere that I can try this with?

Oh right, there it is.

I'll leave off with a teaser for v2.0:

 Can you spot the layout improvements?

Pirate Radio Control: HK123's and Field Weakening

It's nice out, and I'm done with finals, so I took out the RC car again and made a few improvements. Then I crashed it and undid some of those, but don't worry it's not too bad!

First, I changed the batteries. I had been using A123 26650 cells. These are LiFePO4 cells that are most abundantly found in 36V DeWalt drill batteries. In fact, since they are virtually unavailable to the general public, the cheapest way to get them is actually to take them out of drill batteries. I'm sure there are significantly more 36V DeWalt drills than there are batteries for them at this point. Each pack contains 10 cells, and can be found on eBay for roughly $100, so about $10 per cell. Wasteful...and still expensive.

A less expensive solution is lithium polymer. Sites like Hobby King sell these pouch-like batteries for more like $5 per cell, for an equivalent capacity. They're 3.7V nominal, instead of 3.3V, and they come in prismatic packs, so overall they have a higher energy density than LiFePO4. The 30-40C discharge versions are comparable in power density as well. The one downside is that they tend to burst into flames when abused...

A compromise, then. Hobby King also makes LiFePO4 prismatic batteries. (We call them HK123s now.)

HK123

For $70, you get 12 cells. That's just under $6 per cell. Now, these packs are decidedly hit-or-miss, based on the reviews. They might arrive with one or more cells completely dead. In fact, the one I ordered had two dead cells. :( But since I was going to cut it open anyway, I wasn't too upset. Taking the packs apart is a real pain, but I don't imagine it is significantly harder than taking apart a DeWalt battery. One snag I ran into was that the positive terminals are aluminum crimped to nickel tabs. I ripped off the nickel, not realizing its importance, and had to resort to aluminum soldering to connect the cells. (Yes, you can solder aluminum.)

Questionable soldering job.

I rearranged the cells into 6S1P, same as the old RC car pack. Putting it together is easier than putting together cylindrical cells, which almost makes up for the difficulty of taking it apart. All the balance and power leads come out of the same side, and it makes a nice compact package that is easy to heat shrink. Or, if you don't have any heat shrink, caution tape...

Notice the size difference.

The cells themselves are almost the same weight as A123 cells. (They should be, being the same chemistry and capacity.) So I only saved 122 grams (6% of the total car weight), mostly in packaging. But since they are prismatic, they stack nicely and take up much less volume. I measured their internal resistance to be about 13mΩ, which is a little higher than an A123 cell but not much. I fully expected it to be able to handle the 40A peak current on the car. Here's what it looks like on the car:

 

 

Step two in the RC car upgrade was implementing field weakening control. Setting up the full explanation of field weakening would take one or two whole posts, so here I will just get straight to the point. The car uses half of my 3ph Duo brushless ESC, which is a fully functional AC controller that treats everything as a vector in the rotor frame of reference. The voltages applied to the motor are balanced three-phase sine waves, which leaves only two degrees of freedom: magnitude and phase. 

Under normal operating conditions, the controller sets the phase wherever it has to to place the current vector right between the magnets, using feedback control. This is the point of optimum torque production, the least amount of current for the most amount of torque, and varies with speed and load due to inductance. The magnitude then just sets the magnitude of torque.

In field weakening, the controller sets the phase ahead of the normal operating point. There are many ways to think about what this does. In one way of thinking, part of the current vector is now opposing the permanent magnets a little, weakening the field that the other part of the current vector interacts with to produce torque. This reduces the back EMF of the motor, allowing it to spin faster at a given voltage magnitude, but with less torque. It effectively changes the motor constant, almost like an overdrive gear. Hey now, where have I seen this before?

I wish I could provide a more thorough analysis of the field weakening capabilities of this controller, but in all honesty it gets a little messy. For one, the unit frequency that the controller uses to do all its calculations is the PWM frequency, which is 14.5kHz. With the motor now spinning at 45,000rpm, or 750Hz, the resolution of everything is shot. Furthermore, lag in the measurements starts to become significant and the rotor frame may not even be in the right place anymore. This controller was designed for direct-drive scooter motors that spin at 1,000rpm...so I'm happy if it doesn't go unstable at this speed.

Time for testing! Here's the baseline, a normal "full-throttle" acceleration with no field weakening:

It gets from 0-30mph in 1.9 seconds, pushing about 34A (peak) to the motor. The top speed is 34mph and the peak power output (to the ground, m*a*v) is about 200W. Notice that by the time the motor has hit top speed, the voltage phase is a full 42º ahead of where it would be at no load. This keeps the current right between the magnets, lined up with the back EMF, for optimum torque. At this phase angle, the power in to the terminals of the motor is about 330W. So from the motor terminals to the ground, a system efficiency of 61% at peak load.

Now with field weakening:

The acceleration profile up to 30mph is identical, taking about 1.9s. Then, at 30mph I hit the "boost" button. The controller tries to put some current on the axis that fights the magnets (negative d-axis). It does so by advancing the phase to 75º, sacrificing current on the q-axis (torque producing current) to get there. So, the acceleration slows, but it can get to a higher top speed of 44mph. Maybe you just need to see it:

 

That ant-looking thing is the car. The sound is probably the more useful measure. With this kind of motor, field weakening is fairly limited, but a 30% increase in top speed without changing anything other than software is still much appreciated. That is...until you hit a pebble at 42mph...

Unfortunately, I do not have video of the crash, but I do have the car's last transmission:

Black box.

Clearly I had half a second to attempt to slow down and regain control. I probably needed another half second to do so, though, because it still hit the curb at 27mph. This time, something happened to the radio before the battery came out. (You can tell because the voltage never drops.)

Yep, antenna got ripped out. 

 That might be fixable with some solder. The brand new battery did indeed fly out as well, landing several feet away. Here's the aftermath:

Not right.

But even the bashed-in cell is okay.

That's a big check in the durability box for the HK123's, if you ask me. The only thing that really broke was a tab on one of the cells. And it wasn't the aluminum solder joint; the tab just sheared off completely. Good thing I have four spare cells from the original pack.

The car itself was totally fine.

So in summary:

• HK123s are a viable and fairly rugged LiFePO4 solution, if you don't mind disassembling and reassembling a pack. More compact and less expensive than A123.
• Field weakening is cool, until you hit a rock.
• I should find a wider test location.

Super Mean Well: The Scooter Fast Charger

Disclaimer: Do not try this unless you are very comfortable with the concepts and dangers of battery charging. I am pursuing this as an experiment, not advocating it for general use. Attempt at your own risk.

A while ago, I had the idea of repurposing large LED power supplies as battery chargers. The premise is that both use the same output characteristic. That is, they will apply a constant current or a constant voltage, whichever is lower. For batteries, the constant current is applied first and supplies most of the charge. Then, when the applied voltage reaches a certain threshold, the voltage remains constant and the current ramps down. If you don't understand how this works, you probably don't want to work with batteries anyway.

Mean Well makes inexpensive 100W LED power supplies (presumably for commercial lighting) under the PLC-100 line. They are roughly the size and weight of laptop power supplies and are available in a range of voltage outputs, up to 48V. They have a constant-current and constant-voltage trim pot that allow adjustment within a limited range around the nominal output. They retail for about $65 and are available from several electronics distributors including Mouser.

I have been using the PLC-100-36 to charge the batteries on the BWD scooter for some time now. The scooter battery pack is lithium iron-phosphate. (Note that these are generally safer than other lithium-ion chemistries, which is why I am more comfortable using a non-standard charger.) It's a 33V, 4.4Ah pack (equivalent to two 36V DeWalt drill batteries). I set the constant current to 2.2A, so it's a C/2 charge, meaning it would take approximately two hours to fully charge the pack.

There is obviously no balancing circuit (though I did try to make one). It's important that the cells be well-balanced before charging and that the voltages be monitored in case one starts to peak early. Cell voltage monitors are widely available, for example this one and this one that also balances. They will not automatically cut off the charger, though, so constant observation is required. (Generally a good idea for battery charging anyway.) For general use, an integrated charger/balancer such as this takes care of all the monitoring and cutoffs. The downside is that for most of these RC chargers, you still need a bulky front-end DC power supply.

Though it is compact, inexpensive, and plugs directly into the wall, the 100W Mean Well supply falls short of the RC chargers in output power. So I was very glad when I came across the new HLG-240 line. This is a 240W version of the Mean Well LED power supply that retails for about $130. It comes in a compact (but dense) aluminum enclosure with wires already attached. Here's the HLG-240-36:

And for scale, here it is next to the scooter:

It's not as light as the 100W version, but it's still something you could see carrying in a backpack. And just like the 100W version, it plugs straight into the wall. This particular model has a voltage trim range of 33.5-38.5V and a current trim range of 3.3-6.7A, a good match for the scooter battery pack. Other models offer other ranges. (Be careful: Only the model with the "A" suffix are adjustable!) And here it is doing its thing:

With a maximum output current of 6.7A, this supply can now charge the scooter pack in about 45 minutes (~1.5C). Whether or not this is practical or necessary, I don't know. I've never had a case where I absolutely needed to charge it in less than an hour. But it's interesting to know that the capability exists for about the same cost and size as a laptop power supply. (Okay, this is a little bigger than a laptop supply.) I still don't recommend it for casual use, since it doesn't implement balancing or voltage monitoring. But if somebody made an small adapter that did these things, I could see it being a good, inexpensive solution to small EV charging.

Twitch, the part where I try to build something.

Twitch (or, Twitch, Jr., since the original Twitch was much bigger) is finally underway. (I decided it would be a good idea to finish writing my thesis first so I could graduate.) It should be a relatively quick project, especially considering that I got most of the important parts sent out for water jet cutting.

Mail-order robot.

Actually, this is the first time I've tried to make a drive like this, with so many moving parts. Here's a quick reminder of what it should look like:

Both sets of diagonal wheels are coupled by parallelogram linkages. The two wheels on each side can also be coupled by a cross link as well, though with two linkage drive servos this is not entirely necessary. The most critical pieces are the bearing blocks that support each wheel and motor module. These are made from Delrin for low friction and ease of machining. There are a total of eight, for four wheel modules:

Four identical wheel modules, mounted in the corners.

The bearing blocks sit on aluminum posts, hopefully aligned correctly between the top and bottom plates. With the two diagonal linkages in place, the wheels can be moved in pairs. Normally, both pairs will be moved together to switch between the "long" and "wide" orientations.

 "Long" orientation (top) and "wide" orientation (bottom.)

Besides these two orientations, there are other possibilities. One is to put all four wheels at 45º. Another is to put one set "long" and one "wide." Since they are omni-wheels, either of these would be capable of full 3DOF movement. If the cross links are used to couple the two diagonal sets of wheels, the range of intermediate wheel positions is more limited. Needless to say, this project will become an exercise in input mapping and control at some point.

For now, though, there are still a few mechanical details to work out. After the first assembly, it's clear that there is a bit too much friction in the wheel module bearing blocks for the servos to drive the linkage. They were made to be fairly tight, for stiffness, but after seeing it in real life I think I would trade a little slop for less friction. Unfortunately, this linkage gives the servo the least amount of mechanical advantage at the extremes, so if the bearing friction is constant, the servo sees the most torque at these points. I'm crossing my fingers that it's actually the wheels, driving against each other during the transition, that can create the torque for overcoming this friction. (Again, why does everything converge to a controls problem?!)

Next step is creating hubs for the Vex 4" omni-wheels that allow them to attach to the gearmotor shafts. Then, wiring and programming. Okay, so it wasn't quite a two-week job, but it's progressing.

2.00thesis

Design and Prototyping Methods for Brushless Motors and Motor Control

Actually you should read James Mevey's thesis instead.