MTPA support

[nitrousnrg]

With this addition vesc can introduce a negative id current to increase the torque on IPM machines.

This has been addressed in #91 but that branch is becoming quite difficult to merge with the newer firmware versions with dual motor support, and MTPA involves very few lines of code. In this branch we fixed some sign errors in the code, basically it didn't work when motor direction was inverted.

This represents pretty much the complete picture of an IPM machine:

The controller will follow the maximum torque per amp trajectory (red trace) to reach higher torque levels (orange trance) for the same phase current. In this particular plot it gets 4% more torque and 10% more speed.

The code does this math:

Other controllers approximate this by using a beta angle (a straight line) but this uses the full math.

The only configuration parameter needed is the Lq-Ld difference which determines how "tilted" the MTPA trajectory is. Torque increase depends on Ldiff and flux linkage, in a motor with high saliency it can yield a 40+% torque increase (nissan leaf motor) and the % gets bigger with more amps.
It also increases significantly the base speed at full load because of the extra torque and the negative id current.

MTPA is calculated from iq_target so at full throttle and no load there is some id that increases the end speed while iq can't increase due to the voltage ellipse limit. This means at high rpm, no load the operation point deviates from the most efficient MTPA trajectory, but maximizes the machine performance by increasing base speed, power and available torque at all times, even under sudden load changes that field weakening PID may not be able to track. If FW works really well we may want to calculate mtpa from motor_state.iq so mtpa always sticks to the MTPA trajectory, but so far I got better and more solid performance by using iq_target.

A dyno run looks like this:

Driving id current comes with the warnings of a fault at high speeds creating a BEMF that increases DC Link voltage beyond the powerstage ratings, its not as bad as FW, but its there. We take this into account when we calculate the voltage rating of our powerstages, but to avoid users setting random Ldiff values the feature could be limited or disabled for specific hardware configurations.

I'm attaching a motor config xml for VESC Tool that enables the Ld-Lq field under FOC->Advanced. In the near future we should rename it as Lq-Ld instead because Lq is supposed to be the bigger value.
parameters_mcconf_MTPA.zip

Since VESC has Ldiff detection (HFI code) and MTPA, #73 could be closed when MTPA is merged.

[supercrazysam]

This is very exciting! Is there any instructions on how to get it to work?
Are there any GUI support of this feature on vesc tool?

which version of firmware and vesc tool should I use?

[nitrousnrg]

This is very exciting! Is there any instructions on how to get it to work?
Are there any GUI support of this feature on vesc tool?

which version of firmware and vesc tool should I use?

You need to build VESC Tool with the .xml attached in this conversation. It will add the new Ldiff field:

But first you need to know what you are doing and know your Lq-Ld difference value. Id current can damage mosfets.

[vedderb]

Very nice! I will start testing it in the next days.

Is it really better to calculate MTPA from the target iq rather than the measured one? The current controller will give priority to setting id, which would affect how the motor runs at full speed without load when just changing the target current.

[nitrousnrg]

If we have a well tuned field weakening I think its best to calculate id from the measured iq instead of the target iq, but until Field Weakening is ready, using the target iq provides smooth and solid accelerations with a bit higher end speed. Speed increase in regular non-salient motors would be very low, and if the system has an IPM machine the drive should be already dimensioned to support higher than base speed operation.

In any case, changing from iq_target to measured_iq is a one-liner change and I would totally agree if you prefer to merge it that way (moving apply_mtpa() inside control_current()). I am developing a drive that works nicer with iq_target and I can tweak the code on my end, just having the Ldiff field present in Vesc tool would save me a lot of work.

When I said MTPA deviates from MTPA trajectory, it looks like this:

And I can tell that it feels weird hitting "a" max speed at 10% throttle and getting higher speed by pushing more the throttle when the load is constant. The extra speed was worth it for now though and dynamics inside the area of operation were solid.

What we really want is that when the user commands 50% throttle (which would ideally mean 50% torque target) the motor would move this way, following the torque locus:

That way it would reach max speed smoothly at low throttle inputs, but I couldn't tame the dynamics of this yet. We'll get there eventually.

So let me know which way you prefer it and I can make the change if needed.

[vedderb]

Merged, made some small fixes and made a quick test on my rig with two regular RC outrunners. Also added the ld_lq_diff parameter to VESC Tool.

The field weakening effect of using the target current on full modulation is clearly noticeable, which is kind of nice for some applications. It messes with duty cycle control though the way it is implemented, as the target current then always is the maximum current, which probably decreases efficiency. I tried to spot any difference in efficiency by running one motor as a brake and the other one in speed control with MTPA, and I think I saw a slight improvement. Hard to tell though, as the efficiency also would decrease as the motors heated up. Nice work! Excited to get field weakening implemented now as well

[nitrousnrg]

Nice to hear!

Yes, when FW is ready it will take care of the extra speed and MTPA will be calculated from measured iq.
I don't know how long FW will take though, its simpler for non-salient machines, but on IPM machines I realized the popular closed loop FW approach produces more torque than commanded on a salient machine. I wanted a full feedforward approach to rely on machine parameters and avoid PIDs but solving the voltage ellipse/torque curve intersection is just crazy, crazy expensive. And even when we get that sorted out, FW needs an option to short out motor phases in case of a DC link overvoltage.

For the record, in the first screenshot MTPA was under test at 400A (phase amps), but we regularly tested at 800A:

That motor has large saliency, and the torque increase was substantial. Its not easy to tune because inductance measurement doesn't work well on axiom so lots of trial and error to find Ldiff.

[rushi-jariwala]

Hi Marcos,

Can you answer this doubt of mine?

As you mentioned, the base speed will increase in MTPA operation as we have -ve Id current. But what happens when the commanded current reference goes to 0? This will make Id go to 0 suddenly - back-emf will be more than the applied voltage and the motor would brake. I remember reading in some conversation that you tried using a slow ramp-down rate for Id current but that did not help much.

Can you let me know how this issue has been solved?

[nitrousnrg]

I've been told (I don't remember going through the math behind this) that in a id collapse event, the current flowing through the body diodes is equal to the id that was flowing. Depending on your application this could be a rather low braking current. If its too much breaking, in a failure event you would have to disconnect the battery and let the voltage increase, in which case the powerstage should be rated for that fault voltage.

So with the current code (no ramp) if you release the pwm beyond base speed with id=20A, the motor will brake with id current until base speed, and then it will coast to 0 rpm (instead of coasting all the way).

As a design principle, if you are running an IPM motor you should size the powerstage accordingly assuming an sudden id collapse, for example in a battery disconnection event. A software ramp won't protect you against some failure modes.

A ramp could help smooth the transitions, but I think that code should be part of a FW pull request. When that happens we can change mtpa to only use measured iq instead of target iq, so mtpa alone will have a lower impact on the max no-load speed.

The ramp is tricky, if you set for example id=20A and iq=0A, you would think that the motor will produce no torque and coast to 0rpm, but in practice it keeps spinning forever at very high rpm. So what's safer? slow the motor too hard or use a ramp that for a moment keeps producing torque? This gets well into FW topic I think.

[rushi-jariwala]

Hi,

Thanks for the reply. I tried some simulations this week and I have got MTPA and FW working.

1. The ramp-down rate for Id helps a lot both in MTPA and FW zones.

2. FW works well with PID controllers. I remember you or someone else mentioning that in IPM motors - the torque would increase once you go to FW. That is exactly what I observed. I also checked a couple of controllers - the torque does increase but it does not feel any weird while riding (EV application).

3. Also, all the controllers I checked use PID for Field Weakening. And it seems to also be working in my simulation. This avoids any dependence on parameters. Even if you use the Feed-forward method, you will have the same issue of torque increasing. The problem is - Id current is allowed to go to the max value even when you give only 10% throttle for example (through equations or PID). If you do not want an increase in torque, then you would have to limit your Is to 10% - but you will have different problems there. If your command becomes 0% all of a sudden - then Id will go to 0 and you would not want that to happen in MTPA or FW zone.

Thanks for sharing all your work! It helped me a lot.

[thejoker0123]

Hey! I've been trying implement this on a VESC, but I can't figure one thing out. After compiling the VESC Tool with the .xml file, the option for the MTPA appears, but I can't write it to the ESC because the firmware is different. Am I missing something?

Thank you!

[jrm00]

@nitrousnrg what equation are you using to plot the voltage ecllipse?

[nitrousnrg]

@nitrousnrg what equation are you using to plot the voltage ecllipse?

The ellipses are derived from this equation