A couple weeks ago I wrote about how I was building a brushless motor (BLDC) driver board, for the ultimate goal of using them in a quadcopter design. Well, the boards came in about a week ago and I'm finally ready to show off what they look like -- and maybe complain about how much work they were in the process :P
You can check out my previous post for more about the exact design (or find the source code on my github), but as a very brief summary, there are three main stages to my board: the digital/control stage, the power stage, and the back-emf sensing stage. The digital stage is mostly centered around an ATmega328 which controls the pwm, commutation, and does the back-emf sensing; the power stage involves six high-efficiency mosfets and associated components, and the back-emf sensing stage is an LM339 comparator and an analog mux that feeds it. Here's the board design I came up with:
And here's what these things looked like when I got them back from OSH Park:
These are by far the most involved boards I've made so far, and I still definitely get a rush seeing my design turned into a fine-precision physical object. I bought six boards, even though I only need 4, originally because OSH Park sells boards in quantities of three, but it turned out to be quite nice to have extras. I bought enough parts to assemble just one of the boards, since my I didn't have too much confidence in the boards or part selection, and then set off to get the first board working.
I started hand-soldering the first board, and things were going ok for a while: I feel like I'm starting to get the hang of TSSOP/QFP/0402 parts. There are definitely things about the layout that made it tough to assemble, that I want to avoid in the future: I put some components too close together, making it tricky to keep their solder separate, and some components were very difficult to place and access once the surrounding components were in place (in particular, the 0402 decoupling caps between some of the ICs). But these issues were dwarfed by the trouble I had with another problem: bad footprints.
I've been getting most of my package footprints from the SparkFun eagle libraries, or directly copying the manufacturers recommended land pattern when I need to create a new part. I guess I got a little overconfident with this board, because I used a couple new SparkFun footprints without verifying them first, which ended up causing a depressing amount of desoldering+resoldering+touchup work on those parts. First off, I'm not really sure how this happened, but their 0805 footprint is way smaller than I expected compared to an 0805 part; the pads are only as wide as the component itself, which means that you need to leave extra space around the pads for the component itself (as opposed to their other footprints such as 0402/0603/1206). Luckily I only had one place where this was really an issue, with three 0805 parts next to each other; for the subsequent boards I side-stepped this issue by putting 0603 caps on those footprints, which turned out to be fine.
The big problem, though, was with the resistor array footprint I used. This was my first board where I used these parts; they seemed pretty promising, giving a pretty good area reduction and reducing the number of components (if not the number of pads). I grabbed the RES-ARRAY footprint from the SparkFun libraries, and put 8 of them on my board. Big mistake.
The SparkFun footprint was totally different than the parts I had ordered. I'm not really sure how this happened, but the pads ended up being too close together, and also too short, which meant that the component completely covered the pads when placed. This meant that it was extremely hard to get solder to the pad, especially when hand-soldering, but I also had difficulty reflowing these parts (though that did turn out better). I went through many many many many cycles of desoldering the array, desoldering the pads, resoldering the chip, removing extra solder, checking for opens or shorts, and repeating. I definitely spent the vast majority of my touchup/debugging time on these parts... and unfortunately I have more boards coming in with the same footprint. Luckily, even though the footprint wasn't that close, I was able to eventually solder all the resistor arrays, and I didn't have to scrap the boards.
The last part of the assembly was the power stage, which posed it's own challenge: I designed the power stage to handle high current (I was shooting for 20A though I doubt it can actually support that), which means that there are large copper pours with lots of thermal conductivity to the power stage components. At one point, I actually got the soldering iron stuck to a blob of solder -- it was wicking away so much heat that the solder was able to solidify onto the iron! It was also interesting to solder the exposed pads of the mosfets: I put a number of vias on the pad for this purpose, which actually worked quite well (maybe too well, since I ended up using too much solder).
After many hours of work, I finally got the board assembled:
Getting it to work
I'm going to skip past the part where I spent hours tracking down an issue I thought was with the design but turned out to be just another short in one of the resistor arrays. After fixing all of those, I got the digital stage working, and the power stage working as well. I complained in the past about how difficult it is to debug a sensorless bldc design, because the back-emf sensing only works at high speeds. On the other hand, it definitely was nice that the three stages (digital, power, back-emf sensing) could be addressed sequentially: I first left the high-voltage disconnected, and tried to see if I could get the ATmega to work; then I connected the 12V rail and tried to see if I could slowly step the motor without any issues.
I had a lot of problems when it came to the back-emf sensing stage, though. I overbuilt this part of the system to give myself flexibility if I wanted something different: I feed the three sense inputs through an analog mux, since you only need to ever look at one of them at a time, and then fed the selected voltage into a comparator, where I compared it against three reference voltages, and then fed the outputs into the ATmega. I breadboarded something similar, but I hadn't used an analog mux or this particular comparator, so suffice it to say, my design didn't work out of the box.
The first issue is that I bought the wrong part. I don't know how this happened... but I designed for a 4052 dual 4-to-1 mux/demux, but instead I bought the 4051 8-to-1 mux/demux. No problem, I'll just put the 4051 on a breakout board and manually wire it up:
No luck -- it's still not working. Using my DIY scope, the issue seems to be that the analog mux was clipping the output voltage at 5V -- which is weird, since the datasheet says you can control large voltages with logic-level inputs. Reading it again, though, it specifically meant large peak-to-peak voltages, which is assuming that your negative peak goes far below ground, to the analog negative rail. I have no idea why this part includes two negative supplies instead of two positive supplies, but the result is that I actually needed to power this chip from the 12V rail, but when doing this, it no longer takes logic-level inputs (Vih=10V)! So even if I rewired the board to supply 12V instead of 5V, I'd still need to shift up the control inputs, which involves a few more components than I think can really be bolted on. Things were looking kind of bleak.
Then, I decided to try something: I hard-wired just one of the sense inputs to the mux, and changed the software to only do back-emf sensing one third of the time, when that specific phase was idle. It turns out that this ended up being fine! I suppose that I could have better or faster control of the speed by sensing it three times as often, but qualitatively the motor seems to drive just fine.
I wish I had taken a picture or video of it at this point, but to my huge relief the board was successfully driving my test motor. So, it was time to order more components for the other boards.
I decided to slightly change the components to reduce cost; I decided to make four additional boards (I didn't trust my prototype board after cutting it up so much), and that plus the RC supplies were starting to add up in cost. I made two substitutions: I used cheaper 4mΩ MOSFETs (the original ones I picked were 2mΩ), and I switched from ATmega328's to ATmega88's, since the code size was relatively small. Also, I ordered a stencil for the board, partially because I wanted to try stenciling and I found OSH Stencils (no relation to OSH Park) that produces them pretty cheaply.
Fast forward to getting the new parts...
Assembling the other boards
My plan was to first assemble board #2 (the original hand-soldered board was board #1), to make sure the new stencil+reflow process worked, and then assemble boards #3 #4 and #5 at the same time. Here's my first-ever attempt at using a solder paste stencil:
I tried to not put much on there since I put those vias on the MOSFET pads specifically for hand-soldering, but I was worried that in reflow the solder would get sucked through (which it did). Even ignoring that, the paste application was pretty bad; I must have jostled the stencil or board while I was applying it. (Pro tip: apply the paste away from the fingers you're using to hold the stencil, to best keep the stencil flat and in place.) Here's a closeup:
My past experiments with reflow soldering showed me that it's far more important to have the right amount of solder, and the process is hugely forgiving to the exact placement of the solder. So, despite the fact that most of the footprints have barely-discernible smears of paste, I decided to go ahead with this board. Either way, it will give me good insight into how precise the solder application needs to be.
Well, the answer is a little more precise than what I did, but not too much more:
Above is the result: everything is in the right place, but you can see several solder jumpers in the above picture, along with a decoupling cap that has been completely claimed by one of its pads and is sitting vertically. All in all, I was actually pretty impressed by how the results came out -- this is far fewer jumpers than I would have created soldering this by hand. I just went through with some desoldering braid and cleaned it up, and used the multimeter to show that electrically things looked good. Except, of course, for the resistor arrays... I had to pull a bunch of those up and resolder them by hand. In fact for this particular board I was unable to get one of the arrays soldered before ripping up its pads; luckily it seems like those resistors were superfluous anyway, so I just replaced them with 30AWG wire.
Migrating from an ATmega328 to an ATmega88
So, according to what I read on the interwebs, the ATmega88 and ATmega328 are supposed to be interchangeable. What I found was that while, yes, they are pin-compatible and use the same instruction set, you can't just drop one in for the other and expect it to work. There are a few reasons why, apart from the obvious one that they have different amounts of program flash and RAM:
- The interrupt tables are different. In the 88, each interrupt vector is 1 word (2 bytes), but in the 168/328, they're 2 words (4 bytes). This isn't too big a deal, since the compiler will generate the right table for you (or maybe it's one of my libraries, not sure), though you do have to tell the compiler that you're targeting a different part.
- The fuses are very slightly different; this was probably more confusing than actually damaging.
- Finally, the generated code is different, with slightly different timing characteristics! I'm not 100% sure what the exact cause is, but my guess is that it's because the compiler emits "rjmp" and "rcall" instructions on the 88 instead of "jmp" and "call" on the 328. Tiny differences like this probably don't matter for most projects, but I'm trying to commutate the motor with sub-microsecond accuracy, and the reduction in function call time drastically changed the timing parameters required.
In the end I got the ATmega88's working just as well as the 328's, and learned more about them in the process, but I'm not sure if I'll do this again. This is especially true due to the fact that the price savings from going from an ATmega328 ($2.77) to an 88 ($2.13) is less than from buying the 328's in bulk ($1.74 @25), so for ATmega's it seems more worth standardizing a part and buying more of them, than trying to pick the perfect part for each project. I didn't want to do that for this project, since I'm not sure if I'm going to stick with TQFP parts or if I can make the jump to QFN parts -- but that's a different story.
There was one last problem with the board: I had removed the 4052 part from the design, but that unfortunately didn't mean I could ignore it, since its footprint and traces were still there. If you look at the top part of the above photo, you'll see that there are a couple jumpers on the unpopulated footprint; the one on the right is a jumper between the 5V rail and a motor lead, which needless to say, caused havoc until I cleaned it up.
Building the rest
Now, it's time to build the other three boards. At this point, after several nights of working on it, I'm getting pretty tired of soldering, especially for these boards. My hope was that by assembling all three at the same time, I could significantly cut down on the assembly time. For instance, I find that when assembling a board I seem to spend more time "picking" than "placing" components, at least with this design where there are many different components (many different-value resistors, for instance), and my hope was that by doing three boards I could amortize the picking across three times as many placings.
It turns out that I was mostly right: while board #2 (the first reflow board) took me about an hour to solder, boards #3 through #5 took a combined 90 minutes to solder. It's not really a fair comparison since there was some aspect of me overall being faster at these boards (the time-per-board would have gone down even without doing multiple boards at once), but it was definitely a welcome speedup. The big difference, though, was in the touchup and debugging stages. First off, my solder paste application was better, requiring fewer manual adjustments -- but still some, so I still need to work on my process:
The big wins, though, came from reductions in the debugging time. At this point I only ran into issues that I had already had with the first two boards, and I had already mapped out the hot-fixes I needed to make, so I was able to make all three boards in a night, as opposed to the first two boards which each took an entire night themselves.
I haven't taken any videos yet, since right now I can still only run one motor at a time (due to power supply limitations), but here are my assembled boards:
I assembled them left-to-right, top-to-bottom (board #4 is in the bottom left), and you can see the marked reduction in extra wiring.
There are a lot of things I would change if I wanted to put together a v0.2. For instance, I didn't put a pull-down resistor on the PWM line, which means that when I hit reset the driver input will be left floating, ie the mosfets will still be on! I found this important enough to change that I actually soldered 10k resistors onto these boards. There are also a number of places where I deliberately overbuilt the circuit to leave headroom (there are still features I want to add) and in general I think the 20A target was way too high -- running a single motor at 1A is enough power to blow things off my desk, and forceful enough that I feel the need to wear safety glasses while testing. If I were to start from scratch, there are also some all-in-one BLDC driver chips that could have replaced... pretty much all of my circuit.
But the boards are working, so that's it for this step! I'm not sure how much current these things can handle, but at 1A the boards didn't even feel warm at all, and based on feel, I think 1A is more than enough current to hover the copter, so I may never fully stress these things. From here, I need to attach the final wiring solution (18AWG wire instead of 22, and with proper connectors on the end), and follow through with my plans to create an ATX-to-XT60 connector that would allow me to power all four boards from an old computer power supply, at which point I should be able to drive all four motors at the same time, and hopefully achieve (uncontrolled) flight! The final piece of the copter is the central control board, which I just got a notification that OSH Park has shipped and should be here in time for the weekend :)
For the past couple weeks I've been working on a new project: implementing a brushless motor (bldc) driver, with the distant goal of building a quadcopter from scratch. Sidenote -- I'm still narrowing in on what I consider to be doing something "from scratch". BLDC drivers (apparently called "ESCs" in the RC world) seem to be easy to buy, but I wanted to build them myself. I'm having the pcbs made by OSH Park, but the pcb fabrication isn't something that I feel like I need to do myself; same goes for the motor construction. And I think this can change over time; I bought a cheap quadcopter frame for testing, but I plan to eventually build my own frame.
Anyway, there are a couple things that I found challenging in designing the driver:
- Learning the theory of the control -- it's not as simple as "simply apply a voltage and it goes", like the brushed DC motors I used for my simple robot. There are several good resources out there on this, though; somewhat surprisingly, though I guess it makes sense once you think about it, the best references are by different IC manufacturers who try to help you build your BLDC driver using their products. Anyway, here were the ones I found most helpful:
- Parts of the control algorithm -- specifically, the back-emf sensing required for sensorless control -- only work at high speeds, which makes the system hard to debug.
- It takes a surprising amount of power to lift even moderate weights using propellers. The motors I bought are 300W -- by comparison, the motors on my previous robot were sub-1W. There are two things that this means: a separate supply voltage (12V), and much higher currents. For my breadboard, I targeted 1A current draw, but for my eventual quadrocopter I'm targeting 20A.
I started off by building a breadboarded prototype:
I'll be the first to admit that the circuit isn't very clean; I didn't know what I needed to build when I started off. Here's a simple diagram of the major functional blocks on this breadboard:
The alligator clips are connected directly to the metal tabs of the low-side mosfets, and go off to the motor on the right which is off-picture. I'm using a simple 12V, 1A "wall-wart", which I feed through my multimeter in 10A mode to get current measurement. I also bought a surprisingly-handy barrel plug switch, since I found myself cutting the 12V supply a large number of times.
I used a standard ATmega328, like you would find on an Arduino. I'll talk more about the code that's running on it in a sec.
One thing that is apparently important for sensorless bldc control is that you are supposed to drive both the high and low sides with the same PWM signal. At first, when I did no back-emf sensing, I used a "high-side on, low-side pwm" (called PWM-ON) system which worked pretty well, but then I read somewhere that this won't work for sensorless control. I haven't validated this for myself, but to be safe I added this part of the circuit and haven't tested taking it out.
This section consists of two 7408 quad dual-input AND gates; I take the 6 signals from the ATmega and AND each one with the PWM signal. I'm kind of bummed that I'm using two 14-pin chips for this function, since it feels like this should be a fairly standard thing to do. In fact, I found a chip that does almost exactly what I want: the 74139 dual 2-to-4 decoder. Here's a screenshot I grabbed from the datasheet:
Each decoder features two selection inputs and an enable input, and has four outputs. This sounds perfect: since I only want one active signal per high/low side at a time, each of the sides gets one of the decoders and I'll wire up two selection inputs, and the PWM will be the enable signal. This was all sounding great until I noticed that the entire chip uses active-low logic; this isn't a big deal on the input side, since it's easy to generate an active-low PWM, but the output is going to be fed into a MOSFET driver which seem to all have active-high inputs. This could work by putting a hex-inverter between the 74139 and the MOSFET drivers, but then we're back up at two chips and haven't gained much. There's a similar 74239 chip which is apparently the same as the 74139 but with active-high outputs, but a cursory search revealed that this chip is not / no longer made.
This would let me save some pins on the ATmega, since you only need four inputs rather than the 6 with the AND scheme. Since there are only 6 commutation states, you should only really need 3 bits of selection input: by playing around with it, you can see that this is actually pretty close to possible, the only issue is that you need to AND together some of the outputs, which introduces yet more parts (though perhaps as simple as a resistor array). Saving the pins would be nice, but I decided to go with the AND method as I'll talk about later
I actually found this surprisingly helpful for debugging, but I wired the 6 AND-ed control signals to six LEDs. I used serial output from the ATmega for most of my debugging, but for a quick view of whether or not things were working, the LEDs were actually quite nice.
One thing I've learned to do is to use the 74AC series of chips, which can drive 24mA from each output; the 74HC chips I used earlier drove LEDs too dimly.
I didn't really understand the need for this stage at first, but this stage is essentially a series of small transistors that the microcontroller can use to control the large power MOSFETs. Some of the resources I read said that you needed these due to high gate threshold voltages, but I found some logic-level MOSFETs that could handle the current I wanted, so I thought I could get away without it. Well, on the low-side at least; on the high-side, the ATmega328 is unable to directly control a 12V signal due to its ESD-protection diodes. I had tried using the ATmega outputs to pull the high-side MOSFET's gates down, which worked, but when I tried to float the ATmega's pins by setting it to an input state, the ESD diode limited the gate voltage to somewhere around 5.5V. I used a simple 2-cent NPN transistor to do this, but I was still wondering why you would want a $1+ driver.
There were a couple reasons I found:
- The driver chips can add features, though I found that the cheapest chips don't add much that I could use for a 3-phase BLDC application.
- N-MOSFETs seem to overall be better that P-MOSFETs, in terms of both price and performance, so there's incentive to use N-MOSFETs on both the low and the high side. This means, though, that you have to drive the high-side gate pins above the highest supply voltage in the system, which requires some dedicated circuitry
- The mosfet driver can push more current than the microcontroller, which will switch the mosfets faster, reducing switching losses.
The last point is what I think to be the most important and the one I understood the least. When I thought of switching losses, I assumed they meant the energy it takes to charge and discharge the MOSFET gate capacitance. Instead, it's actually the fact that while you are switching the MOSFET, the gate will be at a low voltage that is intermediate between "on" and "off", where the MOSFET allows a large current but takes a large voltage to do so, resulting in large power dissipation. In effect, either the voltage or current (depending on if you're switching it on or off) will turn on before the other one turns off, so for an amount of time dependent on the gate current, the MOSFET is draining power.
In the breadboard picture you can see me using some "High-Low side independent" drivers, which seemed to work pretty well, though at a slightly higher price than I would have wanted.
This is a relatively simple part of the circuit to build, but I spent an inordinate amount of time picking them out, just because there are so many darned options. I wanted to not have to heatsink the mosfets, so I was looking for some with low Rdson; when I picked out the parts I was also looking for ones that could be driven by 3.3V inputs, though for the part I picked that reduced the maximum gate voltage they were rated to handle, which I was exceeding, so I wouldn't recommend it.
The main issue I ran into was that the ATmega kept on behaving very erratically and it took me a while to pin down all the reasons why. The main things I had to do were
- Connect ground better throughout the system. I'm not really sure how this was possible, but I was seeing 100mV swings between the two ground pins on the ATmega. I had wired up the ground on each side to the ground rails on their respective sides, but I had only connected the ground rails at the bottom of the breadboard setup. I connected the ground rails directly over the ATmega, which fixed this issue.
- I connected more filter caps everywhere.
- I had to be very careful to not connect high-voltage to the ATmega pins, especially when set to output mode. I blew out two ATmegas entirely which was actually easy to debug despite being disappointing, but the high voltage at times had more insiduous effects, causing the ATmega to skip around the program wildly and reset the timers randomly.
Once I had the breadboard all set up and the electrical parts working, the main challenge was the firmware. Getting the motor to jerk around randomly was quite easy, but getting it to move smoothly, especially at high speed, was quite challenging and I'm still not done.
There are two ways to control brushless motors: you can use Hall-effect sensors to directly measure the movement of the motor, or you can measure the back-emf generated by the unused motor phase, called sensorless control. It sounds pretty daunting, but the electrical part of it is fairly straightforward: you measure the voltage on the unused phase (ie the one you're not powering or pulling to ground), and use that as the input to your firmware.
I had a lot of issues with this because the ATmega's ADC is either slow or inaccurate, at least in the context of this application. An ADC conversion takes 13 ADC clock cycles, and by the default the Arduino libraries will set the ADC prescaler to 128, giving an ADC conversion time of 100us. By comparison, my motor should be capable of driving at 12k rpm with no load. From some simple empirical testing, it looks like my motor requires 42 commutation steps to do a complete revolution, which means that at a full speed of 200 rotations/s, a commutation needs to happen every 120us. Clearly, a 100us ADC time makes this impossible.
I changed the ADC prescaler to 4 (setting it to 2 made the ADC not work), meaning that the ADC conversion should theoretically take about 4us. I think there was a fair bit of overhead, since I was only doing about 8 ADC measurements per commutation cycle, at significantly less than the maximum of 12k rpm. I wanted to increase the number of back-emf measurements I could do; some references suggest that you only need to do three or so, but I wanted to shoot for closer to 10 so that I could get better resolution and potentially do some debugging.
So, the method I ended up going with was using some LM358 op amps as voltage comparators, since the control algorithm only requires a threshold detector, rather than fine-grained voltage measurement over the entire range of voltages. I was pretty surprised though: this didn't increase the controller speed at all! I think the issue was from using the Arduino's digitalRead() function, which turns out to be quite expensive (maybe 10s of microseconds). I switched to directly reading from the corresponding PIN registers, and suddenly the system could drive the unloaded motor at 11k rpm -- not quite at the max, but at this point I was maxing out the current my little wall adapter could provide. It's quite an experience to have something on my desk rotating 180 times a second! With the propeller attached, it was able to drive the motor at about 60 rotations/s, though that was limited again by the dc adapter current. Side note -- I'm planning on adapting a spare computer ATX supply I have as a simple bench supply, since it has both 12V and 5V rails and a large current capacity.
You can find the firmware here, though I would discourage using it or copying anything from it.
The next step is to get PCBs made, which can be lighter and higher efficiency (and cooler, both thermally and socially). I made a few changes from the breadboarded version:
- I used 3-input AND gates, since you can get 4 of them in the same number of chips that I was using to get 4 2-input gates. I used the extra pin as an "ENABLE" signal, which is currently just pulled high with a 10k resistor, but it gives me the option of using it as a "hard stop" signal that bypasses the microcontroller
- I changed from using 3 "high-low" drivers to a single 3-phase driver. This should be both cheaper and more functional than my previous strategy.
- I changed MOSFETs I'm using. I went with these MOSFETs from NXP -- they seemed to offer the best combination of low-cost, low-size, high-efficiency, and large number of pin-compatible options for future replacement. But again, there are so many options that it's hard to know how good a choice this is. I picked their 2mΩ variant, which should hopefully be efficient enough to drive up to 20A without requiring crazy heatsinking.
- Added a 5W current-sensing resistor. The 5W rating seems excessive, especially since it's a 3mΩ part, but 20A is a lot and forced me to revise my perceptions of what a "power electronics system" looks like.
Here's the board I came up with, which measures 1.65" x 2.15" ($17.50 for three at OSH Park). All the components, and the majority of the routing, are on the top layer, since I wanted to keep the ground plane on the backside as pristine as possible, since I'm nervous about interference with the microcontroller, though I'm hoping that the current-sense resistor, which I put on the low side, hides some of that:
Eagle files here (same disclaimer about how you shouldn't trust them).
You can see that I put a couple dividing silkscreen lines to visually separate the different stages: the top is the power stage (high-voltage high-current), the middle high-voltage, and the bottom low-voltage.
- Power stage: schematically very simple, but tricky to route due to the large current requirements. The large number of vias in this stage are mostly for thermal purposes, though I suppose they should also improve conductivity.
- High-voltage stage: this consists of the motor driver, analog multiplexer, and analog comparator (plus associated passives), which are all equipped to interface with the 12-18V supply.
- Digital / low-voltage stage. This stage consists mostly of the microcontroller, its parts, and the two AND chips, all of which needs to be protected from the high voltage. This stage is far more pin-dense than the other two, leading to routing congestion, which I should have foreseen before placing the ICs and starting routing, at which point I didn't want to rip up my work.
I've never tried assembling something with this many components on it, especially at this density, so I'm hoping that it's going to be assemble-able. I'm a little unhappy with the number of components I needed, particular the 5 non-microcontroller ICs on the board. I think with more careful use of the ATmega pins I could probably do away with the AND gates and the mux, but for this version I purposefully left some pins unused so that I could repurpose them on the fly if needed. I don't think it'll come to this, but another option is I can use a larger ATmega part with more IOs, though that costs a few more dollars.
On the topic of price, I don't feel like I've hit the price target I wanted with this board -- an off the shelf 20A ESC costs about $11, so I was hoping to hit around $15 per board for mine; instead, my total cost came out to about $23 for the first board. In decreasing order of amount, the main contributors are:
- $5.85 for the circuit board ($17.50 for 3). My current design doesn't quite fit into the 5cm x 5cm seeedstudio $10 size, but assuming I can get it to fit that, this will go down to $1.
- $5.45 for 6x 2mΩ MOSFETs. Once I build the other boards I'll get better bulk pricing ($4.90), and if I can use lower-efficiency 3.4mΩ MOSFETs (or lower), it will go down to $3.75.
$2.75 for the ATmega328. I have a feeling that I can use a lower-flash ATmega part, such as the ATmega88 for $2.13, or maybe I'll bulk-order 25 ATmega328's for all my projects, and bring the cost down to $1.75 per.
- $2.25 for 6x 3A flyback diodes. I'm not sure what can be done about this, but maybe the RMS current will be low enough that I can use smaller diodes?
- $1.85 for the mosfet driver. I think I could build a cheap replacement for this, albeit without its non-essential functionality, though the main tricky part I foresee is building the high-side driver circuitry.
- $1.08 for the 2x AND gate chips; hopefully I can get rid of these entirely.
Anyway, these are all ideas for the next round, and for now I'll just wait for the boards to arrive and work on other projects in the meantime: it's time to learn about switched power supplies, so I can power all this 5V circuitry from the 12V RC battery pack without a needing a massive heatsink for my linear regulator.