# Factors of VESC motor detection and operation with 3rd Party Hardware

14 posts / 0 new
shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55
Factors of VESC motor detection and operation with 3rd Party Hardware

Myself, @vadicus, @bgdwiepp, and @TechAUmNu have discussed some common observations on our hardware when using the VESC firmware. We observed several factors that affect the quality of motor detection and motor operation for FOC. I will do my best to summarize our findings here.

1. L detection is and miss with HFI detection method. You make five measurement and then maybe choose the one with the most hits. The previous method was using a lot more current so it was at least consistent/predictable. Parasitic inductances in 3rd party hardware may be more significant than in original VESC hardware especially if using traditional leaded MOSFETs. Using high current for measuring L & R could help saturate these parasitic inductance. Proposed solution is to either allow for adjustable current for L measurements or allow the option of using the old measurement process.

2. The R and L, and even lambda detection values are varying with voltage and therefore switching rise/fall times. L is most affected, R and L can change insignificantly but do change. It may be because there was no consideration of operation above 80v. Proposed solution is to add a logic to track the supply voltage and adjust the test result accordingly.

3. Current filters. I(vadicus,) found no significant difference changing current sensor filters within 10-300khz cutoff range. It seems like hall sensors behave way differently (slower, less accurate) compared to resistance shunt. My resolution is pretty low, at around 2mv/A to allow up to 700A measurement. It generally works at above 10A where the current signal is stable. However, at around 0-3A or so there is a lot of jitter that makes things like HFI not work correctly.

4. Power supply inductance can add to the error in readings if it isn't compensated for; if you are using an applied voltage - rise time method and your input voltage sags due to power supply inductance you can get incredibly poor results, even just using a linear ramp of input voltage for V0 and Vfinal to compensate can offer huge accuracy improvements.

5. Observer gain accuracy seems impact operation of large motors. Calculation of observer gain in older VESC Tool versions seem inaccurate but also seem to be gradually improved on with new VESC Tool versions. Unfortunately the VESC Tool versions with improved observer gain calculations also have the new L measurement process that is problematic.

So the factors involved here seem to be parasitic inductances in the power stage, MOSFET switching rise/fall times, supply voltage, current sense measurement type, and observer gain accuracy.

I invite @Paltatech, @DerelictRobot, @benjamin, and anyone else who would like to contribute their findings or discuss the issues at hand. Any advice here will help hardware developers understand what is going on and potentially discover improvements that could be made to the VESC project.

benjamin
Offline
Last seen: 4 days 10 hours ago
Joined: 2016-12-26 15:20
Posts: 378

1. L detection is and miss with HFI detection method. You make five measurement and then maybe choose the one with the most hits. The previous method was using a lot more current so it was at least consistent/predictable. Parasitic inductances in 3rd party hardware may be more significant than in original VESC hardware especially if using traditional leaded MOSFETs. Using high current for measuring L & R could help saturate these parasitic inductance. Proposed solution is to either allow for adjustable current for L measurements or allow the option of using the old measurement process.

I just tried it with my 100V version of the 75/300, and at 12V I get 3.21 uH and at 80V I get 3.18uH on the same motor. When the voltage is the same, the result is the same on all digits every time.

I think the reason you get inconsistent results is that your current sensors are too slow and/or noisy at steps. For the inductance measurement to work, the current sensors need to have a fast step response. The old inductance measurement was using longer pulses with higher current, which probably is a bit more forgiving to slow current sensors. What you can try is to set the switching frequency to 5 kHz, and use the terminal command

measure_ind <duty>

to measure the inductance. The more duty, the longer pulses and higher current it will use. You should be able to get similar results to the old method, but be careful to not use too much current to prevent damage.

In general, inductance measurement is the trickiest part for the hardware, and if the current measurement is slow it might not be possible to do it properly at all. Even if the old method gave more consistent results, there were probably not correct.

2. The R and L, and even lambda detection values are varying with voltage and therefore switching rise/fall times. L is most affected, R and L can change insignificantly but do change. It may be because there was no consideration of operation above 80v. Proposed solution is to add a logic to track the supply voltage and adjust the test result accordingly.

This is due to dead time distortion, and expected. IGBTs will probably be much worse here, as they give distortions from additional factors. The only compensation that is mathematically correct here is dead time compensation. It might be better to add a switchable low pass filter on the phase voltage measurement, and use the filtered measured voltage instead of the calculated one from the bus voltage and modulation. I'm currently experimenting a bit with that.

3. Current filters. I(vadicus,) found no significant difference changing current sensor filters within 10-300khz cutoff range. It seems like hall sensors behave way differently (slower, less accurate) compared to resistance shunt. My resolution is pretty low, at around 2mv/A to allow up to 700A measurement. It generally works at above 10A where the current signal is stable. However, at around 0-3A or so there is a lot of jitter that makes things like HFI not work correctly.

That is probably the case, and the reason why accurate inductance measurement is difficult or impossible. Again, the approach above should give you similar results to the old method. For me the current filters make a big difference on very low inductance motors such as the EDF in my video, but for more common motors it matters less.

4. Power supply inductance can add to the error in readings if it isn't compensated for; if you are using an applied voltage - rise time method and your input voltage sags due to power supply inductance you can get incredibly poor results, even just using a linear ramp of input voltage for V0 and Vfinal to compensate can offer huge accuracy improvements.

The bus capacitors should swallow the high frequency changes easily, and the low frequency variations are compensated for by measuring the input voltage during the measurements. I don't think the power supply causes an issue, unless it can't deliver enough power at all and drops towards undervoltage faults.

5. Observer gain accuracy seems impact operation of large motors. Calculation of observer gain in older VESC Tool versions seem inaccurate but also seem to be gradually improved on with new VESC Tool versions. Unfortunately the VESC Tool versions with improved observer gain calculations also have the new L measurement process that is problematic.

Observer gain calculation is important, and it should be much better in FW5.00. If you haven't given it a try yet, please do; just be careful:

https://vesc-project.com/node/1640

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

@benjamin I really appreciate you taking the time to respond in such a detailed manor. I will try your suggested approaches to help slower hardware to detect the motor properly. I do intend to test the FW5.00 as I have hardware that can benefit from the improvements. I will post my findings related to this thread's topic here as well provide my the summary of my analysis on the beta thread.

Offline
Last seen: 1 week 1 day ago
Joined: 2018-05-02 21:29
Posts: 3

When can we expect the 100/250 vesc to hit the market?

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

@benjamin I tried your suggestions and they seemed to improve matters. Detecting the motor at 5kHz switching freq provided more accurate and consistent results. My current sense solution is the same as the Stormcore.

I think possibly my switching rise/fall times and dead time could be affecting the current sense "window" to sample. I have noticed better motor detection and operation with faster rise/fall times but I have them a slower in order to reduce L*dI/dt spikes.

UPDATE: MOSFET rise/fall times definitely affect motor detection accuracy and operation. Seems like the current sampling needs to have some sort of adjustable offset to allow for slower switching rise/fall times. Some hardware designs need to switch slower to mitigate ringing, spikes, mosfet self turn on, ect.

Offline
Last seen: 1 hour 33 min ago
Joined: 2018-08-17 07:26
Posts: 198

@shaman, can you provide some details on your 5kHz measurements? How much are the R and L apart between measurements? Do the measurements at 5kHz still change with voltage, let's say 30 vs. 60v? What are your gate resistance values and rise/fall times?

If it works well at 5kHz, what I would do is force that frequency during the detection in the fw but then roll back to the normal frequency for drive mode.

benjamin
Offline
Last seen: 4 days 10 hours ago
Joined: 2016-12-26 15:20
Posts: 378

Today I discovered one thing: inductance measurement does not work well if high current sampling is activated. That is fixed in todays FW5 beta build though. I also updated the flux linkage measurement and fixed a scaling bug on the inductance measurement. If you haven't already, give todays version a try!

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

The motor detection process seems to rely on the really fast MOSFET rise/fall times of the original VESC hardware. Slower rise/fall times such as in more traditional power stage design techniques (like the Axiom) seem to cause issues in the accuracy of motor detection. An engineer from Axiom team has noticed this and I have as well in my own hardware that I have been designing. Many more hardware developers across this forum and others forums seem to have experienced similar issues. There are advantages to switching slower such as reduced issues from high dI/dt in high-current applications.

It is believed that accommodating slower rise/fall times for accurate motor detection could be solved in the firmware. Has anyone else noticed this issue? Do you think that this issue could be given some attention? I wish I knew enough about the detection code to try and fix it myself but unfortunately I am limited in that regard.

@vadicus I'll need to return to this experiment to provide details on the differences in detected parameters. I'm able to adjust gate drive strength on the fly since I'm using the DRV8353RS. My rise/fall times were about 180ns as seen in the post below.

https://forum.esk8.news/t/some-new-focers-84v-vesc-6-based-controllers/1...

Offline
Last seen: 1 hour 33 min ago
Joined: 2018-08-17 07:26
Posts: 198

It sounds like we need some correction variable(s) to account for hardware differences. I am not positive that rise/fall times are the only things to account for. Other things like current sensors response times, etc. may affect the detection results.

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

yeah it appears that anything that contributes to overall delay is a factor. The 10kW controller I'm working on uses high bandwidth op amps with high slew rates as current sense amps. This is to get the settling time down to as fast as possible. Still though, beefy power stages shouldn't be required to switch in 50ns or less. I may leverage the "current sense filter" switch feature that is in the original VESCs as a way to switch in lower gate resistor values during detection for faster rise/fall times. These switches would engage during operation to bring in higher value gate drive resistors so I can still have my dI/dt mitigation and ringing reduction.

This table accounts for system delays for space vector modulation. It suggests that MOSFET rise/fall times doesn't contribute nearly as much as dead time or filter delay yet it seems to in reality.

@benjamin do you have any comments on MOSFET rise/fall times when it comes to motor detection and operation?

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

@benjamin

Also, any progress with the phase voltage filter experiments?

Offline
Last seen: 1 hour 33 min ago
Joined: 2018-08-17 07:26
Posts: 198

I've observed something interesting after upgrading from version 4 to 5.1. I've tested this on MKIII.

With 4.1 version installed, the measured inductance was 73mH for my motor. With 5.1, it dropped to 48mH. The measured flux linkage also went down from 32mWb to 26mWb.

In both cases, the detection was done at 48v. I am not sure which values to trust as I was using that to compare with detected values for my hardware.

With my hardware, I was also testing detection at different frequencies. It seems like the lower the frequency, the lower the inductance value. For example, at 5Hz, the measured inductance is around 100mH but at 3Hz, it's around 80mH.

shaman
Offline
Last seen: 2 months 2 weeks ago
Joined: 2018-12-09 15:59
Posts: 55

@vadicus I've experienced similar things on my hardware when upgrading to FW5. From what I've seen so far, the FW5 detected parameters are better and the quality of motor control is better. Still seeing discrepancies that are dependent on MOSFET rise/fall time though. I'll also be trying out a very high bandwidth and slew rate current sense amp in my newest hardware. This is to get the settling time down to as fast as possible. I want to see if that helps/