Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPM motor support #73

Open
nitrousnrg opened this issue Feb 27, 2019 · 13 comments · May be fixed by #91
Open

IPM motor support #73

nitrousnrg opened this issue Feb 27, 2019 · 13 comments · May be fixed by #91

Comments

@nitrousnrg
Copy link
Contributor

Most automotive applications use Interior Permanent Magnet motors.

These motors have a permanent-magnet inside the rotor that generates magnetic saliency. This saliency
produces a reluctance torque from the difference between the direct-d axis inductance and the quadrature q-axis inductance. The maximum efficiency of the IPM motors can be achieved by proper selection of the current vector ratio between magnetic torque current and reluctance torque current in the total current.
Hence, a basic FOC control on an IPM machine could be losing as much as 30% of the available torque.

This control scheme is known as Maximum Torque Per Amp (MTPA)

image

And here is some implementation detail with control examples.
http://www.ti.com/lit/an/spracf3/spracf3.pdf

This is a placeholder so we don't forget to implement this feature. Benjamin, feel free to assign this issue to me or to powerdesigns organization.

@nitrousnrg
Copy link
Contributor Author

Benjamin, we have support for IPM motors with MTPA running promisingly well in the simulator. It also covers Field Weakening (#76), and l/q axis decoupling. We are going to field test it next week.

I will need to change the user interface because currently it only shows motor inductance, but an IPM motor will have Ld and Lq.

What I propose is to add a new field to the General FOC tab so the user can tune both Ld and Lq.
During parameter detection we will run the same inductance-detecting code and store Ld=Lq. That way no saliency torque will be calculated and the control algorithm will behave exactly the same as before.
Those who run a big IPM machine can just take Ld and Lq from the nameplate.

Would you be okay with such GUI change?

As a side note, I've been told outrunners do have a bit of saliency torque that could be extracted with this new control algorithm, like 5% or more. And FW can improve torque figure when you're close to base speed.

@vedderb
Copy link
Owner

vedderb commented Apr 28, 2019

That sounds like a good plan and proposal. If you make a PR I will have a look and test it a bit, and merge the code if it works well. Thanks again for the effort and contributions!

@nitrousnrg nitrousnrg linked a pull request May 3, 2019 that will close this issue
@vedderb
Copy link
Owner

vedderb commented Jan 30, 2020

As we can measure ld and lq now, it would be nice to look into this again. Best is probably to keep the inductance parameter, and add another parameter for ld-lq. By default that parameter can be 0, which disables MTPA. I will set up a rig where I can test this properly soon and see if there are efficiency gains from MTPA.

@nitrousnrg
Copy link
Contributor Author

Yeah, yesterday I played a bit with the new inductance detection.
I am currently working on a very small IPM motor that measured 120uH and 35uH Ld-Lq difference.
We also have 2 big leaf motors on the dyno, its not using fw 4 yet but we did measure some substantial efficiency improvement by changing the resolver offset, which indirectly creates some id.

I will take a look at this once my small IPM is working well, I need to debug some observer issues.

@nitrousnrg
Copy link
Contributor Author

nitrousnrg commented Jan 30, 2020

Oh and this is our big dyno with a back-to-back nissan leaf motor:
https://www.youtube.com/watch?v=oLP35Ps0X4A

With a couple of external power meters we should be able to get some good insights for MTPA analysis, although we don't have a way to measure torque at the shaft yet.

@vedderb
Copy link
Owner

vedderb commented Jan 30, 2020

Another good way is probably to drive a propeller at constant rpm, and measure the input power with and without MTPA.

I will start playing with your controller soon too. We got a bit delayed since I have to make a battery pack and BMS, but we are making good progress there. I will hopefully get it to work well once I can play a bit with the observer using IGBTs.

@nitrousnrg
Copy link
Contributor Author

After resolving a few conflicts I have locally merged the latest master to the FW/MTPA branch for a clean PR. I'm hoping to test the code on the bench this week then push it to the remote branch.

Don't hesitate asking me about the controller setup. You are likely wanting to change a couple of components to increase current sense filtering. BMS integration is important in our end as well, I'd be super interested to hear more about that if its being integrated into vesc codebase.

The HFI is awesome groundwork for MTPA!

@hbch609
Copy link

hbch609 commented May 11, 2020

The Method for supporting IPM motor is

微信图片_20200511221851
@nitrousnrg @vedderb

@nitrousnrg
Copy link
Contributor Author

Not sure what are you talking about, but we are currently testing the MTPA trajectory in our dyno:
https://www.youtube.com/watch?v=CcFCPq4gO3s

There were a couple of minor errors on both TI app note and in vesc code, we hope to make the pull request for mtpa alone soon, I've been using mtpa on my bike for a while now.
It would be a new pull request because the mtpa code is very very short and #91 is getting though to keep updated.

@hbch609
Copy link

hbch609 commented May 12, 2020

I talk about how to contruct position estimator for IPM motor

support IPM motor.pdf

but the estimator contain speed information.

@nitrousnrg
Copy link
Contributor Author

Oh, I see, its math for an observer.

For what is worth, Ortega's observer seems to be working well for me even if its designed around assumptions of surface mount permanent magnet motor. I struggled to get sensorless IPM working on my motor with my own hardware, but I think its because vesc firmware doesn't like detecting motor parameters when the mosfets switch slower than Benjamin's hardware.

It would be interesting if you can provide an implementation in C code, the firmware could be adapted to include a new observer. I coded a different observer designed for IPM and it was tracking well, except that it had a constant offset that I couldn't figure out why was there, and then I got Ortega's working on my setup so I dropped it.

@hbch609
Copy link

hbch609 commented May 12, 2020

I use IPM motor parameters and fan load for simulation. When the initial pole position (pi / 3, 5 * pi / 3) is within the range, the position estimation fails. This expansion may not be suitable. I am looking for an algorithm that supports IPM motors, it is best to support zero speed.

@hbch609
Copy link

hbch609 commented May 12, 2020

The reason why Ortega's observer works well may be that the Ld and Lq of the motor you are using are relatively close, and the parameter I simulated is Lq = 2 * Ld. The parameter is Rs=4.765, Ld=0.007, Lq=0.014, psim=0.1848, no. of poles is 4, rated current is 3.06A, rated speed is 3750 rpm. Can you provide your motor parameter?

@nitrousnrg nitrousnrg mentioned this issue Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants