Measuring IPM Motor Parameters from Plots

[Pete9008]

Now the simulator seems to be working reasonably well the main obstacle to using it seems to be knowing what motor parameters to feed into it (small changes seem to have significant effects). While it's possible to use a LCR bridge/meter to measure Ld and Lq, and to spin the motor to measure flux linkage, there is scope for errors to creep in. It also needs the motor terminals to be isolated, ideally needs the motor shaft locking and there is still a small nagging doubt at the back of my mind as to whether the measurement we make is directly equivalent to Ld and Lq.

For a while I've been wondering for a while whether it would be possible to calculate the motor parameters from web plots of Vd/Vq and Id/Iq; in theory it should be. Now originally I believed high quality, high speed data would be needed (part of the justification for the high speed logging thread) but I've now come up with a slightly different approach which may be suitable to use with standard csv logs captured via the web browser interface.

Rather than integrate it into the simulator (as was the original plan) I'm instead going to do it as a separate program (Qt again). With the new approach there is much less common code so a separate app just seems easier.

The initial data is from bexander (viewtopic.php?p=51047#p51047) who has also taken motor inductance and flux linkage measurements for teh same motor so it should prove a good test for the technique.

This thread is intended to track the development of the app, collect data, and collate results. I'm hoping to start pulling the basic framework of the program together this evening.

Edit - it would obviously be quite nice to have the right values to put into the OpenInverter parameters too

[johu]

Loving it. So if you can do the math on a PC there is a chance we can eventually do the same math in the firmware

[Pete9008]

Loving it. So if you can do the math on a PC there is a chance we can eventually do the same math in the firmware

Should be possible but rather than analysing a log I think you would jack up the wheels and run a setup program that would learn the parameters.

Basic structure is done, at the moment it just reads a log file into data structures and plots them but now the data is in the program I can start the analysis side . Here is one of bexander's logs:

Doing this has made me realise that there is a value missing from the file though, we also need udc to allow the real motor voltages to be calculated from the uq/ud values.

@bexander, do you know what the battery voltage was during the runs? If you capture any more it would be worth adding udc to the csv file too.

[Ev8]

This is awesome work well done Pete

[Pete9008]

This is awesome work well done Pete

Don't speak too soon you'll jinx it! I reckon there is about a 50% chance of it working

[Pete9008]

Odds have improved a little, say 75%

Extra window now showing the model output:

Essentially I'm feeding the current into the model for each sample point and then asking it what the resulting voltage and motor speed should be. You can see the general trend is there but there are differences, particularly in the speed trace.

I think the next step is to reinitialise the speed throughout the run to prevent the drift that will accumulate and then sum the absolute errors over the entire run. Then run repeated runs while adjusting the unknown parameters to look for the best match. Might have to move car weight from know to unknown parameters as I think assuming it is an accurate figure may a mistake in most cases. Fairly sure that I am going to need a plot with real udc data before being able to get much further too.

[Pete9008]

This is looking fairly promising

First how it looks when the program is started:

You can then open a csv file (which also displays the file data in the top right plot):

And then hitting the 'Update Model Graph' button gives:

This feeds the motor currents into the model and plots the predicted motor voltages and speed for each point. These are shown on the middle right window. It also compares the measured and model data and shows the point by point error in the lower right window.

Then clicking the Tune buttons in turn adds the error plots on the lower left window:

This runs the data through the model with varying values for the parameter ranging from Delta % below the nominal value to the same above while plotting the resulting error. The Lq, Ld and Flux Linkage plots clearly show and error minima which corresponds to the best fit between the measured and modelled data (this is also shown in the 'Best Fit' fields). The Rs plot is fairly useless as its effect is obviously below the noise floor - not sure whether to move it out of the tuning section. Similarly the vehicle data has very little effect at the moment (not really surprising as the way I ended up doing it doesn't allow time for vehicle inertia to have an impact) - not sure whether to remove it or leave it in case it is useful in the future.

Finally you can use the best fit values to update the actual fields and re-run the model to see what difference it makes to the modelled data and the errors:

There are still significant errors there, and I would like to see a better fit, but then there will be be other factors affecting things (road gradients, battery voltage changes, possibly even IGBT/motor temperatures). I think it's good enough to find the values for Ld, Lq and flux linkage.

It is worth noting that the above is with a guessed Udc (360V) which is probably wrong and is is probably why the best fit flux linkage is a bit low. Really need a csv file with udc in it to check whether this is the case. Also worth noting that there is some interaction between flux linkage, Ld and Lq so the tuning is a little iterative but it does seem pretty robust in reaching a consistent endpoint. The three logs do give slightly different answers (around 0.4mH min to max), not too sure why (changing battery voltage?) which may need a bit more looking at if inclusion of udc dousn't address it.

With the guessed udc bexander's values come out at Ld=1.7mH, Lq=5.5mH and flux linkage of 90mWb so pretty close to his measurements.

Still a bit of tidying up required but fairly happy with the results so far.

Edit - just upped the assumed udc to 380V and re-run and the results are now Ld=1.8mH, Lq=5.8mH, flux linkage=95mWb.

Edit2 - thinking about it a bit more most of the errors are likely to be due to core saturation in the motor which means that the inductance actually drops a little as the winding current increases. Not a lot that can be done about that other than analysing a log that represents the type of driving that you would like to optimise things for. Although if we integrated algorithms into the OI firmware it might be possible to be a bit cleverer and actually measure at different load currents and compensate - not sure it's worth the bother though!

[bexander]

Wow, that was quick and impressive work!

I think the guess of 380Vdc is closer what it actually was.

I will ad Udc and create new logs.
Is it preferred with high speed (deep into FW) or low speed (no FW). I see you used the log with highest speed, so I guess thats the preferred speed?
I notice, the right graph axis unit is rpm, should be Hz, as it is ploting fstat.

[Pete9008]

Wow, that was quick and impressive work!

I think the guess of 380Vdc is closer what it actually was.

I will ad Udc and create new logs.
Is it preferred with high speed (deep into FW) or low speed (no FW). I see you used the log with highest speed, so I guess thats the preferred speed?
I notice, the right graph axis unit is rpm, should be Hz, as it is ploting fstat.

Thanks, I wasnt expecting the minima to be anywhere near that pronounced, it all worked pretty much first time which is a nice change

I used the largest file that also had a good variety of speeds, accel and decel. Not sure what's best until we have a bit more experience with it.

Well spotted, yes it should be Hz!

[nkiernan]

Impressive work Pete, love your approach to solving these problems, fair play

[mjc506]

'kin awesome

[Pete9008]

Thanks for the comments but this really came together much more easily than expected. Been wanting to have a go at it for a while but couldn't quite face it, however my brain seems to be starting to work properly again and bexander's data gave me the push to get on with it so here it is.

Hopefully get the code tidied up and pushed to github later this evening.

Bexander has kindly taken some more plots over here viewtopic.php?p=51123#p51123 which include udc and the program has now been modified to use it. Initial results are:

Log4 - Lq=5.4mH, Ld=1.65mH, λ=95.0mWb
Log5 - Lq=5.1mH, Ld=1.66mH, λ=96.4mWb
Log6 - Lq=5.2mH, Ld=1.66mH, λ=96.0mWb
Log7 - Lq=5.0mH, Ld=1.68mH, λ=97.0mWb
Log8 - missing udc
Log9 - Lq=5.75mH, Ld=1.77mH, λ=95.3mWb
Log10 - Rs = 145mR

This compares to measured values of Ld=2mH and Lq=6mH (wondering whether the reduction is due to core saturation in the motor due to the higher currents?).

Ought to explain log10. The Rs calculation didn't work on the previous plots, essentially its effect was tiny compared to everything else so didn't separate out. On log10 the car was held static on the brakes while the throttle was blipped. Because the motor is stationary most of the Vq and Vd terms disappear leaving just the resistive contribution and with that we get this (un-tuned, Rs=75mR):

And this when tuned (Rs=147mR):

That is a pretty good cancellation and minima curve indicating a Rs value of 147mR. Now bexander has measured this motor as being 75mR so why the poor agreement? Well the 147mR is based on what the firmware 'sees', which will include cables, IGBTs, diodes, deadtime, etc all averaged over varying currents (some of those are non linear). All it is really useful for is in trying to improve agreement between the real world and the simulator!

Just looking at why the values in log9 are different to the others. It's not enough to cause a real problem but would be nice to understand it so I'm going to modify the program so that the error is only calculated over a selected window. That should make it possible to see which part of the plot is responsible (guessing the fairly heavy regen but would like to be sure).

Edit - log9 included a drive up a gradient on the way from the flat test site, where all the other logs were done, back home so that it very likely to explain the discrepancy

[Bigpie]

Awesome, I'll have to remember to take some plots

[Pete9008]

Awesome, I'll have to remember to take some plots

Be great if you could. It would both provide a good test for how well it works on low inductance motors.

[Pete9008]

The build files are now on github https://github.com/Pete9008/IPMMotorCalc

The code is a bit hacky but it will do for now. This is what it looks like:

Most of it is fairly obvious but a few things are worth mentioning:

• You will need Qt to build the program.
• The program works by reading in a logged data file which must contain the fields Timestamp, udc, id, iq, ud, uq and fstat (order doesn't matter and other fields can also be present)
• When the 'Update Model Graph' button is pressed the program then uses a motor model and the known and guessed parameters to generate a set of modelled data. The measured and modelled data sets are then compared and an error calculated for each point.
• The 'Tune' buttons can be used to scan each guessed parameter between (guess - Delta%) to (guess + Delta%). For each value the error between the measured and modelled data is calculated and an error term produced. All the error terms are then graphed. If there is a clear minima on the graph (as seen above) then the minima is at the optimum value for that parameter. This best fit value is also copied to the 'Best Fit' field.
• The 'Copy' buttons allow the 'Best Fit' value to be copied to the 'Guess' field.
• The 'AutoTune' button will run four passes of the tuning for the flux linkage, Lq and Ld terms and then copy the results to the 'Guess' fields.
• The AutoTune does not try to find a value for Rs. Rs tuning must be done manually.
• If you zoom in on the top right plot (draw rectangle with mouse or +, - and arrow keys) then only the region shown will be used when tuning. The quickest way to revert to the full data set is to reload the file (although un-zooming will also work). Different regions will give slightly different answers but there shouldn't be large differences (using too small a region will give unpredictable results).
• Tuning of flux linkage, Lq and Ld should only be done on logs where the motor is mostly spinning. Regions where the car is stationary can affect the results (small periods being stationary are fine though).
• Tuning of Rs should only be done on logs where the motor shaft is locked.
• The values calculated include all parasitic components in the system. This affects Rs most and will include the resistance of cables, IGBTs, diodes, deadtime, etc. Rs can not be expected to match the reading taken on the motor with a meter but it is the value that should give the closest match in simulation.
• The correlation between the measured data and the modelled data isn't as good as I would like but I can't see a way of improving it. I'm guessing it is down to non-ideal (real!) motor behaviour rather than ideal/simplified models. It seems to be good enough to allow a best fit to be found though.
• All fields and window positions/sizes are persisted across program restarts. To delete the preferences data on Linux delete the ~/.config/OpenInverter/IPMMotorCalc.conf file. On windows the keys in the registry under OpenInverter/IPMMotorCalc must be deleted.
• Any results generated using this program need to be treated with caution and put through a sanity check. If the results don't look right DON'T use them!
• EDIT - try to minimise physical brake use while logging (regen is fine though). Similarly try to avoid hills.

Any problems let me know.

[Pete9008]

Couple more plots just because they are vaguely interesting.

First same as above but added again to make comparison easier, this just uses the sum of the absolute difference between the plots to calculate the error:

And the same data but this time but using the sum of the squares of the difference to generate the error:

Now I tried this because I wasn't happy with the large error spikes in the graph and was hoping that the power of 2 would make the algorithm give larger errors more weight and so bring them down. It does help with this but it also makes the errors worse at lower levels. It also reduces Ld and Lq by around 10% (flux linkage drops slightly but only by around2%). I think what this is showing is the change in Ld and Lq due to the core starting to saturate at higher currents.

Now what this suggests is that it should be possible to run the tune algorithm multiple times for different regions in the plot to produce an inductance vs current plot for the motor. Now while this might be vaguely interesting I don't think it is worth the bother but wondered whether anyone else could think of a good reason why it might be worth doing?

BTW - the sum of squares stuff has been binned and the repo version still uses the absolute difference. This means the program should be considered to be tuned more towards low current values. This can be influenced by the contents of the log processed though.

[mjc506]

I would assume the OEMs do the full parametisation to get that last few %% efficiency, but my humble suggestion would be that this is perhaps out-of-scope for the current firmware. Or rather, a huge amount of work to implement what will probably end up being a large lookup table (different motors will have different changes due to current/temperature/phase-of-moon) to get a couple % improvement if set up correctly. The vast majority of driving will be relatively low currents anyway... There are probably lower-hanging fruit?

I guess if you did want to try plotting Lq/Ld vs current, I think my approach would be to do a 'full' basic tune first, then play the data back with each parameter 'following' the local optimum. That'll leave plenty of datapoints to plot a nice (or horrible) curve with But slow. And if you start including temperature it gets more complicated...

Excellent work

[Bigpie]

Not had chance to look at building the code, but had to run out so grabbed a log. I left handbrake on and used the throttle in one log, and general drive in the other.

[Pete9008]

Not had chance to look at building the code, but had to run out so grabbed a log. I left handbrake on and used the throttle in one log, and general drive in the other.

Thanks for those, just put this through the calculator and the results are a little variable depending which part of the plot I analyse, three possibilities:

1. You aren't using the latest code which has the corrected syncadv algorithm (the error in the old version means the vq/vd voltages don't get reported correctly and this would invalidate the analysis).
2. I've guessed udc wrong, I used 380V (the log files are missing the udc data).
3. The calculator doesn't work well on low inductance motors.

Thoughts appreciated (I'm guessing on 1 or 3 as 2 should't affect consistency, probably 1 as some of the Vq readings while accelerating look a little odd too).

The results are 0.1-0.2mH for both Ld and Lq which is in the right ballpark, what's odd, and what suggests 1 to me is that Lq is sometimes smaller than Ld!

Flux linkage is pretty constant at 26mWb (although the real value of udc will affect this a fair bit).

Rs is 38mR, which seems very low but is probably just about possible (although 1 could affect it too).

[Pete9008]

A few sets of data have now been put through the calculator and thought it worth collating them here. The results seem pretty consistent with other methods of measurement and appear to give good results in both the simulator and real life so I'm going to consider it working/finished (for the time being at least).

Results to date:

Bexander's MGR: viewtopic.php?p=51153#p51153
Lq=5.2mH, Ld=1.66mH, λ=96.0mWb, Rs=145mR

Bigpie's Outlander front generator: viewtopic.php?p=51989#p51989
Lq=0.16mH, Ld=0.10mH, flux linkage = 26mWb, Rs=38mR

Ev8's Lexus Rx400h transaxle: viewtopic.php?p=52530#p52530
MG1: Lq=0.97mH, Ld=0.28mH, λ=57.2mWb, Rs=102.6mR
MG2: Lq=1.58mH, Ld=0.54mH, λ=100.0mWb, Rs=98.5mR

Dusty4's Leaf motor/inverter: (viewtopic.php?p=52875#p52875)
Lq=0.426mH, Ld=0.164mH, Flux Linkage=73mWb, Rs 23.4mR

FFMan's Outlander rear
Lq=0.36mH, Ld=0.20mH, Flux Linkage=60.83mWb, Rs 27mR

Thanks to everyone who took the time to take the logs

[Dusty4]

Hey Pete,
Been meaning to do this for a while now but home renovations have taken most of my spare time and the beetle hasn't been driven much. I've taken some logs of my leaf motor and inverter. See attached. I've got the following results.

Log10: Lq 0.341, Ld 0.12, Flux Linkage 73mWb
Log11: Lq 0.339, Ld 0.133, Flux Linkage 73mWb
Log13: Lq 0.426, Ld 0.164, Flux Linkage 73mWb
Log7: Lq 0.51, Lq 0.197, Flux Linkage 74mwb
Log8 Stalled Rs 23.3662

Logs 10 and 11 were in 3rd gear for a final drive of 5.5
Logs 13 and 7 were in 2nd gear for a final drive of 9
Logs 10,11, and 13 were on the same loop on fairly flat ground.
Log7 had some small slopes.

[Pete9008]

Hey Pete,
Been meaning to do this for a while now but home renovations have taken most of my spare time and the beetle hasn't been driven much. I've taken some logs of my leaf motor and inverter. See attached. I've got the following results.

That's fantastic, thank you!

What's good is that the inductances are a little lower than previously measured (which does make sense as measurements are done at very low currents). This should also explain why the power levels being reported in the simulator seem a bit low compared to Nissan's data. It may also explain why control loops for the Leaf motor seems harder to keep stable in the simulator than in real life

I know the feeling with house renovations!

Once again thanks for making the time to take these.

Edit - Have just run through the data and agree with all your numbers It's interesting how much difference the small slopes made and also the difference using a different gear makes. This does suggest that better parametrisation of the motor may pay dividends. I've also added your data to the summary above (used the 2nd gear data as those reading were in the middle).

Also noted that your resistance measurement is a fair bit lower than most of those seen before - are you using the Leaf inverter? Just wondering whether a lot of the resistance measured by the calculator is down to the IGBTs and the Leaf inverter ones are likely to be lower resistance than the Prius ones (note - Bigpie's numbers are low too but he's using MG1 and MG2 outputs paralleled).

Edit2 - just found your build thread, Leaf inverter. Very nice install there!

[Pete9008]

Discussion on another thread has made me wonder about the effect of motor CT calibration on the above. If the CT isn't reading exactly right it will affect the calculated values (e.g. a 10% under read on current will make the inductances and resistances seem 10% too big).

Now if the values calculated are then used on the same car that the logs were taken on (or one with exactly the same inverter and current gain parameters) all the errors cancel out and the settings will be right for that car (even if the gain parameters are wrong and the CT is under/over reading).

So if you want the values to be as close as possible it's worth doing your own logs and calculating the values from them as this will give the most accurate values for your car.

[johnspark]

Probably everyone thinks the lambda discussions are finished, but I am a bit slow. [While everyone is having main course for dinner/tea, I am still eating ice cream desert from lunchtime].

So I got this page out of the Evaluation of 2004 Toyota Prius
Hybrid Electric Drive System Oakridge pdf.

3rd paragraph: Vpeak to Vrms ratio > sqrt(2) because of harmonics content in the back-emf.

Does that help, or is it confusing?

Kind regards to all.

[Pete9008]

Thank you, that's a very good point!

Not sure what can be done about it though. The equations used by both the simulator and the calculator are only really first order approximations and don't include a lot of the finer detail of real motor behaviour like the non-linear behaviour as flux moves between poles (which is what I think causes the harmonic content).

I'm hoping the simulator and calculator are both at the point where 20% of the work has given 80% of the results (if you believe in pareto!). I'm still keen to identify any differences between real life and simulation though for two reasons. Firstly to identify whether there are any fundamental errors in the model that urgently need fixing but also so that we can try to understand the cause of any smaller differences and any associated implications on how we do things. The harmonic content is a great example of this and it does help to understand why there will always be differences in the results in the simulator and non-perfect correlation in the calculator.

As ever, all suggestions and thoughts welcome!