Jake Read committed Nov 19, 2017 1 ``````# MachineKit BLDC Driver `````` Jake Read committed Nov 13, 2017 2 3 4 5 6 7 8 `````` ## Background, Motivation This project is largely a follow-on to [my Teensy-Powered Brushless Motor Controller](https://github.com/jakeread/tesc), and with this new work, may the TESC project RIP. A moment of silence. TESC, April 2016 - August 2016 *As the world turns, `````` Jake Read committed Nov 13, 2017 9 10 ``````so did those motors. Once around is never enough* `````` Jake Read committed Nov 13, 2017 11 12 13 14 15 16 17 18 19 20 21 `````` Eulagies aside, I am still motivated to do this. Brushless motors are the go-to motive force for electromechanical systems. By that I mean that just about any time you see a robot-like thing, or machine, moving about, there's a big likelihood that the thing doing-the-moving has a brushless motor in it's guts - or some variant thereof (stepper motors count as BLDCs in my books). #### A few things to understand: **(1) Electric Motors move by rotating a magnetic field** - we have something with magnets, and something else with electromagnets, we use the electromagnets to rotate the field, we pull the magnets along. Rotating the field is called *Commutating* or *Commutation*. **(2) Brushed Motors rotate the magnetic field using 'brushes'** - these are mechanical switches that use the motor's own rotation to change the magnetic field. Super neat. [Here's a link to Sparkfun's explanation](https://learn.sparkfun.com/tutorials/motors-and-selecting-the-right-one/dc-brush-motors---the-classic) And a GIF. While the rotor rotates, different switches are connected to current, and the coils - to - pads relationship is set up such that the current will cause the motor to rotate. Pardon my abbreviated explanation. `````` Jake Read committed Nov 13, 2017 22 ``````![brushed-dc](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/brushed-dc.gif) `````` Jake Read committed Nov 13, 2017 23 24 25 26 27 28 29 `````` Brushes are awesome - and make motors very simple. You just pump voltage (so current) through the rotor, and things happen. However, there are resistive losses at the brushes, as well as friction losses. With the advent of transistor technology (for switching logic AND for switching big power) we can do this electronically - use a computer (or simple timer) to switch the phases. **(3) Brushless Motors rotate the magnetic field with switches** - so we can make the coils stationary, and 'artificially' switch the direction and timing of current flowing through them. Here's a nice GIF of sinusoidal commutation (where phase currents follow a nice, smooth wave). `````` Jake Read committed Nov 13, 2017 30 ``````![bldc-animation](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/bldc-motor-vectors.gif) `````` Jake Read committed Nov 13, 2017 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 `````` We can see the three current vectors (that translate into a combined magnetic field vector). We also have a simpler type of switching, where we only turn two of the three phases on at a time. You can see an example of that [here](https://www.youtube.com/watch?v=oFI7VW6WGR4) - including a nice diagram of the switch setup. #### Where it gets complicated: - Circuit design to switch big voltages / currents - Closed loop control on current in motor - Sensing: rotor position, electrical phase, offsets, shunt amplifiers oh my! #### Towards accessible robotics Mostly the motivation for me to go through this is (1) to train myself in the field, and (2) to help others along a similar journey, not just cobbling bits together, but understanding how and why they work. Also, providing better tools / kits / examples to others who are putting robotic systems together. ## Circuit Design This page is incomplete - I'm going to violently segue into a roughly train-of-though design process now. #### FET Selection Using 2x20 pin header on ATSAMS70 Switch - I want to use these fancy DirectFets because I know they can handle really big currents in astoundingly small packages - aiming at a 2kW spindle here. The PN1 I found is IRF6648TRPBF, switches 60v at 86a - this is rated by the silicon2, so won't really get that close, but it's a big number nonetheless - and even at ~ 40% of that I'm running near 2KW (also, power is switched with 6 - so load is a bit split up, though the picture is not so simple - i.e. during moments of the phase only one is 'full on' on the top - or bottom - side of the phases.) I also found an eagle library for this package, nice. These are apparently a pain to solder - you need reflow. I'm OK with that, as I think reflow ovens are not hard to build... I know it makes it a little bit un-fabbable, but it makes me stoked about this project. So here we are. Now - an aside, to introduce you to [Ben Katz](http://build-its-inprogress.blogspot.com/search/label/Motor%20Control) a researcher at MIT's Biomimetic Robotics Lab, who is an expert in motor control, and keeps this great blog about it. Also, this is [Benjamin Vedder](http://vedder.se/2015/01/vesc-open-source-esc/)3 - who's project is hugely popular in the Electric Longboard community. Niche. Great software, great board design. #### Layout I start by laying out the Three Half-Bridges that drive the Motor. The FET I am using actually has multiple pins per connection - so I pulled those out on the symbol to make it clearer what I needed to connect. Here's my schematic for the gates: ![gates schematic](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/schematic-gates.jpg) A few notes - I'm using Labels instead of directly 'routing' on the schematic. This helps keep things diagrammatic... And not messy. You'll notice my Shunt symbols have separate legs for sensing - you'll get that when you see the layout. I also pull out a pin from the low-side of the gates that the gate-driver uses to sense the voltage there (actually not ~ exactly ground). I also have a few voltage dividers setup on phases, which is useful when doing closed-loop sensorless BLDC or FOC control. Not something I imagine I'll have time to implement in code, but good to have. Now I try a first-shot at the gate layout on the board, to get a sense for generally where things will end up. ![gates single layout](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/board-single-halfbridge.jpg) This is really just to figure out what the topology is - what wraps around what. When I really route the big juice, I'll be drawing big polygons that I can do copper pours in. I like this particular layout because I have a 'side' for each big current pull - my shunt is happy with a big tail to some groundplane I'll lay down over there, the phase (in between the FETS) gets a nice edge to face-out to where I'll put motor lines (and that pesky voltage divider), and I have another happy, big edge to dump VCC on. I can even sneak the gate-drives in without any vias, nice. Next I'm going to draw the DRV8302 Schematic and Footprint. Oy. ![drv device](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/drv-device.jpg) TI Provides an excellent example layout - I'm using this as a reference as I draw the circuit. ![drv reference](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/drv-reference.jpg) I got the DRV8302 all schematic'd out, and put a rough plan in place on the board. This looks a bit complicated .... That's because this DRV8302 packs a lot of circuit into one die. I'm actually not sure if it is only one die... You can see this all here: ![drv blocks](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/drv-blocks.jpg) Here's my schematic block for just the DRV ![drv schematic](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/schematic-drv.jpg) There's gate drivers - that's the real business that we're after - this comes with a swath of external capacitors. Critically, BST_x and CP1, CP2 connected capacitors are Charge Pump caps - these are what the DRV uses to crank voltage into the high-side gates - very important that these find a good home really close to the DRV. GVDD and DVDD are still a bit of a mystery to me - internal voltages in the DRV that want external bypass capacitors. There's also the current sense amplifiers - the bottom chunk of the chip. These amps *TODO: explain current sensing* and they get a tiny filter on the inputs, a reference voltage. On the 'top' of the chip is a buck voltage regulator, a world into itself. The buck gets a whole whack of support - a BST_BK capacitor, a whole bunch of R_Sense circuitry, etc. And then there are a few fault outputs (that I connect to LEDS for super-simple debugging, but should properly trigger interrupts on a microcontroller), some settings-related pins, etc. It's a lot, and with more time I would write my process for this up in detail. Wrestling with this chip taught me a lot about EE. OK. Next, I'm going to try to reconcile the pin-inputs I need for this driver with the pin-outputs I've developed for Machine Kit. Briefly, I know I'm going to need 6 PWM Pins (3 phases x hi/lo) and 5 ADC pins - two for current sensing *TODO: explain kirchoff's summing*, and 3 for phase voltage measurement. Actually 6, because I want to measure the input voltage as well. So I already know I need (want) another ADC pin on the MK Header. This is a lot of analog (er, PWM-ish) circuitry! I'm glad I have this test case in developing the MK Switch. Turns out I am maxed on the analog pins available on the ATSAMS70. So I have to jettison measuring source voltage, which is OK when we are not running on batteries - but kind of a bummer to have that hardware limitation. Could open one phase to high and measure then, I think, but wouldn't be able to do it continuously during operation. That's fine. I'm also going to add a header / plug for 'other things' - I'll use the SPI pins, that I think I can set as GPIO as well - I want to be able to talk to SPI devices (sensors, etc) and / or ABI input encoders. Wow. I am biting off a lot. Also - I want to push 48v into this chip (I am planning on most machines running at 48V, the power supplies are readily available, and 48v is the right amount for a KW spindle - says reasons?). This means I have to push a bunch of big capacitors onto the chip - 10uF at 100v (next step up) is a 2220 package - big ! OK - I finally got my schematic dialed down where I wanted it, and footprints worked out. I'm going to start routing. #### Routing ![routing begins](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/routing-begins.jpg) I have one ground plane (bottom trace) and three voltage planes on the top - a VCC (motor voltage, will be nominally 48v), a +5V (the output from the buck regulator, also - turns out I need this on some SPI / encoder devices, nice bonus) and a +3V3 - that's my logic level - the DRV uses 5v logic, but, all good. I got started routing the inputs to the DRV, working over to the drive side. Once there, I focused on making the FETS and Caps etc... power side... work well. I'm also keeping an eye on my ground plane - a big problem with two-sided routing is that you can 'pinch' the plane out in some cases. This was a big issue when I routed that 100-pin switch, here it seems a bit easier - there's less going on overall - the scale is a bit different. ![routing halfway](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/routing-halfway.jpg) I got this routed, and I'm feeling good about the board. I turned on only the layers that will actually show up in fab - so the solder mask, traces, holes, etc - really I want to take some time now to make a decent silkscreen - this can make component placing much easier! ![routing presilk](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/routing-presilk.jpg) For adding silk, I tried to go about doing it by adding silk to the components - not just drawing them on the board. OK, actually I want to keep the silk really clean. Things should be beautiful. I sent these out, and sent an order to digikey for parts. Now some waiting. Here's a list of notes, as they occur, for next time. `````` Jake Read committed Nov 19, 2017 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 ``````## Fab: the board OK, I got these boards in from the fab. Noice. I also splurged for the solder paste stencil (spending the CBA's money, thanks CBA!) - actually it's only \$15 to get a stencil, and it saves me 2hr/board that I assemble, so if time = money... well. ![fab stencil and board](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/fab-stencil-and-board.jpg) I'm well into reflowing boards (it's amazing, and has a surprisingly low overhead - highly recommended) and this is kind of the next step. The stencil lets me apply all of my solder paste at once, a huge time-saver, and prevents me from accidentally applying too much and shorting pins together. [Here is a great tutorial](https://www.sparkfun.com/tutorials/58) from Sparkfun on how to do this. After I lay the paste down, it takes about ~35 minutes to lay the components down. If I did this in parallel, I would guess I could do 10 boards in ~1.5 hours, probably less if I got really into the zone and had a nice workstation. In any case, here's the back of one of those DirectFets and it's associated footprint to the left. Here you can see the heckin' silicone die RIGHT THERE underneath the tin. I'm not super sure that I nailed this footprint, so we'll see what happens when I try to boot it up. ![fab directfet](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/fab-directfet.jpg) A group of components pre-reflow: ![fab prereflow](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/fab-prereflow.jpg) And afterwards - I am excited that these 56-HTSSOP pins on the DRV8302 are not welding together. Go solder paste, go. ![fab postreflow](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/fab-postreflow.jpg) And completed - looks nice! ![fab smd complete](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/images/fab-smd-complete.jpg) `````` Jake Read committed Nov 13, 2017 154 155 ``````## Incremental Notes - 2.2uF @ 100v -> 1206 smallest available package. Can replace with 1uF or up package. `````` Jake Read committed Nov 19, 2017 156 157 158 159 160 `````` - Would via to heat-pad underneath fets, next time. could also go to 2oz copper but have to push out to 0.2mm spacing. - VCC Net could be happier - see pinch pts... in many places. - Tented Vias, or move away from FET - No Thermal Relief on Power In / Big Fet Pads - Push output plugs right to edge - the input gpio header is right on edge, it's a nice minimal look (y) `````` Jake Read committed Nov 13, 2017 161 162 163 164 165 `````` # Footnotes 1. Part Number. Searching Digikey (or octopart, or what have you) for bits is an art, kind of. It's intimidating, but offers much gold at the end of the rainbow. 2. This means that this is where the FET breaks down at the transistor level. The real constraint has more to do with heat - there is *some* resistive loss in any transistor (spec'd as RDS_on) - that resistance turns into heat, and if at 86A that can be a lot of heat, and if you aren't able to get it out of the package fast enough it will break down due to high temperature. THIS is why the directFET package is cool - rather than being wrapped in plastic (not conductive) it is wrapped in a metal tin (conductive) so it's easier to really suck the waste energy out of it. 3. Both are Ben. Both control BLDC. A coincidence? Consider that.``````