Occasional Spin-up DRDRDRD for 750kv motor (BLDC mode)

[sergeil]

Hi All,

I'm running a custom STM32F446-based design with a 7-pole 750kv motor, operating at 16V. The "kv" command gives me 5100, which is pretty much exactly right.

When starting the motor from stop, it usually works fine -- but occasionally seems to go into a stable "wrong direction" mode, where a lot of power is used to barely spin the motor. Here's an example: (command of 0.1 duty cycle followed by brake several times. Last time it does the bad thing)

Screenshot from 2017-06-02 20_25_59.png (149.71 KiB) Viewed 940 times

Screenshot from 2017-06-02 20_25_56.png (171.4 KiB) Viewed 940 times

(Note that in reality in the last run it's actually spinning in the opposite direction, while making DRDRDRDR sounds).

This mode happens *always* when trying to start from still in RPM mode with high enough gains. So it seems to have to do with how spinup works before there is a reliable BEMF signal.

Any hints? Would be hugely appreciated!!

[sergeil]

Here are my settings:

Screenshot from 2017-06-02 20_24_52.png (167.72 KiB) Viewed 939 times

Screenshot from 2017-06-02 20_24_49.png (156.2 KiB) Viewed 939 times

Screenshot from 2017-06-02 20_24_46.png (173.98 KiB) Viewed 939 times

[sergeil]

Still stumped by this. Managed to get the BEMF plot to work (with the more recent Chibios 16.1.8, had to run the Sampler Thread at NORMALPRIO , NORMALPRIO-1 never fired)

Seems that on startup I end up in a situation where the commutation keeps happening at the wrong time. This is both in "delay" and in "integration" mode.

Any pointers?

Good startup:

good_start.png (150.07 KiB) Viewed 884 times

Bad startup:

bad_start.png (133.4 KiB) Viewed 884 times

[pf26]

Do yo really have to use the RPM mode ? I think you better use Duty Cycle mode instead.
But if you really need a precise RPM control, then you probably have to spend some time playing on Speed Control PID parameters (which is not easy especially when you have motors with low inertia).

I think the RPM control code should be reviewed so that the RPM reference is first translated into a dutyCycle reference, and then from the RPM error measurement, the DutyCycle ref would be fine tuned: DutyCycleRef = k1 x RPM_Ref + k2 x RPM_error
A basic proportional control of the RPM error should be enough with high efficiency motors.
This approach requires ramped RPM references, otherwise the motor will accelerate very quickly (=with max current.)

[sergeil]

Thanks for the RPM control hints!

We got it working now by removing the "if (v_diff > 0)" condition on the cycle integration. Without that condition it seems to start well, every time, and also run at higher RPMs.

I'm using a heavily modified RPM controller with a feed-forward term as pf26 mentioned. However the startup stutter was also happening in duty cycle mode, so I think it's one level before that.

Any hints for why the (v_diff>0) condition should or shouldn't be there?

[pf26]

From your "Bad startup:" phase voltage graph, we can see that the motor is going the wrong direction, because the monitored phase voltages decrease instead of increasing (normaly, they should increase up to the point when the integrated sum of voltages goes above a calculated threeshold, and then the VESC decides to commutate - as in the "good" graph).
I think removing the "if (v_diff > 0) condition" helps because it will integrate negatives voltages, and thus delay commutation, most likely to the point that the motor can stop and start again in opposite direction ?
In your "Bad startup" graph, it is hard to understand why commutation occur when they actually do.

I think the preferred method would be to play with your integrator parameters limits (in BLDC tab) and get it to work - but most likely you 've done that already. So now if removing the conditions helps for your motor, why not just use it ? I doubt it can cause other issues.

[sergeil]

Thanks pf26

Removing the integrator condition does also affect timing -- in general I think it delays commutation across the board. I'm guessing this doesn't not fit the auto-identified integrator parameters well and will result in inefficiency if not worse.

Beyond that, I'm guessing someone had a reason for having the v_diff>0 condition in there in the first place -- I'd definitely sleep better if I understood the logic behind why that condition was there in the first place.