So almost a year ago, I posted about how I started work on a field oriented control ESC:
Some people in the comments already said how they made their own or started work on different ESC's. I went through 5 iterations of the ESC after the post.
Unfortunately, I never got any hardware working reliably for pretty simple issues in the end, which is frustrating. Primarily, I could never get the buck boosters of the TI DVR830x to work reliably and there were issues with SPI voltage and behavor. This caused a failure of 8-9 out of 10 boards or sometimes an entire batch. To produce one batch here is expensive: 60% import costs, $40 shipping for 2 boxes (one boards, one components) and then there's the currency rate of R$3 to the $1. In the end, to produce one batch here feels like spending $1200 dollars if I were in the US.
Important: I'm not saying the booster of the chip doesn't work correct, but that it's probably something in the process of my production (the "pizza oven bake") or the design of the component values around it or routing of the board.
Anyway, moving on... I did huge amounts of research into field oriented control. I built a FOC simulator in python and there's some 150MB of documents related to FOC implementations, ranging from presentations of TI about the subject to application notes, research papers, etc, plus I include some remnants of the board designs. Obviously, no point including boards of failing hardware, so just the schematics...
From the image above, all blocks at the top are really easy. They're only conversions from 3-axis to 2-axis models using clarke/park transforms. The difficult part is the "angle and rpm estimator", which is where the magic really happens. Eroding all complexity... it's trying to figure out bemf magnitudes from the Ialpha and Ibeta currents (in a 2-axis view), so that over a couple of samples it can converge to an angle. Another piece of code then gets this angle estimate and figures out the rpm, which is fed back into the angle estimate, because the rpm doesn't change all that quick. All that's left is tuning and the correct L and R inputs for the motor you're using.
The repository is here, along with a README on where to find the stuff.
https://github.com/gtoonstra/foc_esc
Disclaimer: No guarantees that any of this stuff actually works...
Comments
I did use that A4960 chip, but had to dump it because it was taken off the market and also it's not suitable for projects that involve this kind of motor drive. What you could do is look for A4960 projects (they are around) and look into the source code there.
Personally, the ESC you're describing is already so much of a commodity, that I'm not sure why you'd build one yourself. The costs will surely be higher than buying one from China.
To get up to speed with how this could work, I recommend you find the BLDC controller thread on rcgroups.com, that's the best thread out there regarding BLDC control of all types with all kinds of technologies.
Hi Jure,
I noticed the freescale libraries later on. Part of the exercise was to implement this myself and if you look at the algorithm, it looks pretty trivial. The thing you do need is a good processor with floating point.
Symptoms of the failures:
A guy I know from a client helped me out to resolder the chips, he has a lot of experience with SMD. Alas, that didn't work and didn't have any result. It was a replacement chip even.
Philip, going to send you a private msg about that.
Gerard, do you have any interest in participating on the Pixhawk UAVCAN ESC project, I am sure you would be welcome. Let me know.
Btw, one of the things I didn't even get close to was a technique to further improve the efficiency of the ESC. Most implementations use a simple PWM scheme for the motor actuation. When vector control is already used, most of the computational complexity of Space Vector Modulation (SVM) is also solved, so you can wrap SVM actuation into the algorithm when going back from the 2-axis to the 3-axis model. (clark/park or park/clark, whichever). SVM actuation reduces switching losses.
I was also going to look at introducing the third harmonic into the sine wave table. The reason for that is that the regular sine wave actuation, you may not have as much max. torque vs. a straightforward back-emf null-crossing detector and a simple on/off scheme for the coil being actuated at the moment. Apparently you may lose as much as 15% torque. Introducing the third-harmonic returns most of that lost torque.
The ground pad was soldered. The docs contain the datasheets with additional info on the BoostXL board (the board that has the driver chip pre-soldered), which contains more info on how to route, solder and place components.
The chip was soldered through SMD paste in a "pizza oven", which certainly does get to the temperature. I manually eased the heating process by turning things on and off, so there's time for the heat to disspiate.
Obviously, this is still far from a controlled process, but I've seen people soldering this by hand.
On the recent boards, I made one larger hole at the back (where you're supposed to have vias anyway), to be able to inspect whether the solder has actually reflowed there, which it did.
good to know some update on px esc!
Thanks Gerard,
https://pixhawk.org/modules/pixhawk_esc
First Batch of v1.6 Hardware has been manufactured, waiting for the primary developers validation before making these more widely available. Expect their release very soon.
http://vedder.se/2015/01/vesc-open-source-esc/