So almost a year ago, I posted about how I started work on a field oriented control ESC:

Redesigning multirotor ESC's

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

Views: 2318

Comment by Martin on July 12, 2015 at 12:26pm
Comment by Phillip Kocmoud on July 12, 2015 at 5:46pm

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.

Comment by Federico Boldori on July 13, 2015 at 4:04am

good to know some update on px esc!

Comment by Jure M on July 14, 2015 at 6:21am

Question, how did you solder DRV830x's? It is importaint to solder exposed pad to ground plane, otherwise it will not work properly.

Comment by Gerard Toonstra on July 14, 2015 at 6:38am

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.

Comment by Gerard Toonstra on July 14, 2015 at 6:51am

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.

Comment by Phillip Kocmoud on July 14, 2015 at 7:18am

Gerard, do you have any interest in participating on the Pixhawk UAVCAN ESC project, I am sure you would be welcome. Let me know.

Comment by Jure M on July 14, 2015 at 8:03am

What were the simptoms of the failures? I hand-made ~5 or 6 boards and had no problems with any of them.

Have you considered using libraries for FOC? I am using Freescale's and got motor turning over a weekend.

Comment by Gerard Toonstra on July 15, 2015 at 6:09am

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:

  • I'd get 5V at the LDO regulator to produce 3.3v. Then when I put a load on 3v3, 5V collapsed to 0.8v.
  • The majority of the failures of the first couple of runs (DRV8301) were related to SPI not working. So the power supply would be ok, but the chip was unusable because it did not respond to SPI commands.
  • So I moved on to DRV8302 instead.
  • Other issues were actually related to how GND was connected to the chip and the MCU and how the routing is done from the current shunts (resistors) to the chip. That is very tricky to get right and requires a lot of attention. So in the first batch it was a rather naive route, which caused 1.8V noise on the current sensing line due to amplification of the noise. To put this into context, if you want to build long endurance ESC's with current sensors, 20mV is the ripple and 1A with a 0.001 resistor gives you 1mV signal, which needs to be amplified 40x before it goes to the MCU. So any design decisions on the current sensor eventually dictate the range (current wise) your ESC is useful for (it's not just the mosfets anymore). Obviously that was fixed in the 2nd batch with 0.004 resistors and now 0.008 ones.

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.

Comment by Jure M on July 15, 2015 at 10:05am

FPU is good as you can write code with SI units (e.g. you can have current in amperes, voltages in volts, speed in RPM etc), which is not really efficient on fixed point uCs, but if you use manufacturers libraries for FOC, which are optimized to take full advantage of uC features and you don't obsess with having variables in float/SI units, then in my opinion there is no difference between FPU and no FPU.

Sorry to hear you had so many issues with DRV830x, for me it has been working well - only problem I have is lack of time to continue with development :). I am planning to make a test stand with two motors, connected back to back, because it's scary (and dangerous) having 15 inch CF prop rotating at 5000 RPM three feet away...

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service