Motor very unstable in foc_current mode

[albertomercurio]

I have a custom board (actually with an ESP32, but in the future I will use an STM32 MCU) which controls a motor with 0.1 Ohms of phase resistance approximately. I'm able to control the motor in voltage mode, the d and q currents are sinusoidal, and when the motor is static the d current goes to zero.

However, when I swtich to the foc_current mode the motor is very unstable, and also with very low PID parameters (P = 0.01 and I = 0) the motor makes an horrible noise. And I think I burned the mosfets or the drivers.

It is very strange because as long as I use voltage mode everything is fine.

[askuric]

Hey @albertomercurio, Which driver are you using?

The low resistance motors have to be managed very precisely unfortunately and with bad pid parameters or some alignment problems the motor currents can skyrocket.

When you use foc currents it is important to start in torque mode and tinder the pics for d and q current first, together with their low pass filters. You can do this efficiently using the simplefoc studio. And then once you have a smooth torque control, then you can go on to fine-tuning the velocity and position control. If you have food torque/current control you will be able to limit the current and not be able to kill anything due to the bad pid parameters of the velovity/position loop.

Now, I'm not sure what exactly was the problem, it could be few things:

• pid parameters for current lmd and q were too high
• not enough filtering on the d and q currents
• motor and sensor directions are not synced (aligned), this would produce the d and q currents what are sinusoidal (they have to be static DC currents)

Phase currents are sinusoidal, d and q currents should be DC currents. When you go to the positive direction the q current should be positive and in negative direction q current should be negative. D current should be regulated to 0 in foc current mode and kn voltage mode it should be some other value, but not sinusoidal, still a DC current.

I hope this helps a bit 🙂

[albertomercurio]

Thank you for your comment. Here you can see the d and q currents before and after holding the motor.

Here I used a low pass filter of 0.5 (maybe too high?). With lower values I can see some noise in the current outputs. Is it normal?

I'm using INA240 as current sensing (with 0.0005 Ohms shunt resistor) and UCC27282D as half-bridge drivers.

However, since I'm still testing the hardware, the current sensor are not in the same PCB of the shunt resistor (and all the power units).

[askuric]

Hey @albertomercurio, The currents seem a bit too slow (not dynamic enough) in the pictures, that is probably due to the filtering of 0.5. You should not have LPF_current_q.Tf and LPF_current_d.Tf higher that 0.01. Try lowering the PID_current_q/d gains, they are probably causing the noise. By over amplifying the noisy current measurements.

Is your shunt really 0.5milliOhms? It might be too low. 😕

[askuric]

Also, until you get some better performance, please test everything in the torque mode. This is purely current control. No additional velocity and angle PIDs or filtering or other motion control parameters that could be causing this.

[albertomercurio]

Is your shunt really 0.5milliOhms? It might be too low.

I was inspired by the VESC project, in which they use 0.5 / 3 mOhms resistors. Since I'm using my board for a 1KW ebike motor I thought 0.5 mOhms might be enough.

Now, I decided to plot the phase currents instead of Q and D currents.

To show the phase currents I added the following code in the for loop

PhaseCurrent_s current = current_sense.getPhaseCurrents();
Serial.print(current.a);
Serial.print("\t");
Serial.println(current.b);

In the first figure below both phase U and V currents are plotted in the velocity_openloop mode at 2 rad/s (with a current limit of 10 A). In this graph they are practically sinusoidal currents (is this noise normal?). In the second figure I plotted the phase currents in velocity closed loop at the same speed of the closed loop mode. Here the motor has no resistance, and the currents are practically zero (is this normal?). The last figure shows the phase currents with the velocity closed loop method, but making some hand resistance to the motor. Here I can see the phase currents, which are no more sinusoidal, but they seem to be trapezoidal-like (I imagine this is normal).

I hope this comment can be helpful. In the meantime I try to solve the problem.

[luzz94]

Hey @albertomercurio have you find the cause of this problem? I have a very similar setup and same situation.

[askuric]

Hey @luzz94,

Can you please give us a bit more info abot what is happening and maybe even a video of if What is the same situation that you have, unstable current control?

@albertomercurio Your images seem to be fine actually. The d and q currents are not supposed to be sinusoidal but DC currents. What is the time-scale of these images?

I am wondering.... Are you 100% sure that your current sensing phases are aligned with the motor phases. What I mean is if you put for example:

BLDCDriver3PWM(motA, motB,motC)

make sure that when you initialise the current sense

InlineCurrentSense(R,gain, I_motA,I_motB,I_motC);

That the I_motA measures the phase current of the A motor phase, I_motB of the phase B and so on. If that is not so, the d and q transformation will be wrong and the current control will not work.

We do have the auto-align procedure but for higher current motors and well designed boards (like VESC) I would not rely on it too much.

Can you verify that that when in voltage torque mode, in velocity control, when you stop your motor with your hand, the q current raises and d current goes to 0. And when the motor is freely spinning the q current is positive for positive velocities and negative for negative ones? d current in the voltage mode is considered to be 0, but in reality it will not be and it will raise with the velocity (the higher the velocity the higher the d current). Could you verify that?

This will I hope help us pinpoint the problem :smile:

[luzz94]

Hey @askuric thanks for the kind reply!

Sorry for the delay but I wanted to check the project and figure out what's going on.

1. Here the video of the velocity control with SimpleFOC library
2. Here the video of the velocity control with the VESC firmware

both videos were made with the same hardware setup without changing anything.

Starting from SimpleFOC firmware I understand from iq and id that, overall, the current sensing and their control loops are working properly (correct me if I'm wrong). At the moment the PID parameters are not perfectly calibrated but they are at a point where there is little space for improvement (There's a big overshoot right now, but compatible with the VESC video). I would therefore exclude that the noise and in general the control behavior is strictly related to the PID's parameters only.

For example, for any value, the "background noise" that the motor makes when it is at low RPM cannot be eliminated in any way, something that the VESC firmware doesn't have.

I found it difficult to correctly calibrate the torque control and then the speed control (VESC and ST MC suite have auto-tuning routine that works ok) but i think that is normal for those type of motor.

Anyway in the video the FOC current control works both in CW and CCW (+/- 150 rad/s max) and then I tested also the voltage mode but as you can see in the video it behaves well (i.e. it keeps id low) only in CW while in CCW it doesn't reach even half the speed compared to the other direction.

Here the performance of a previous version of my firmware in which i reach more or less 250 rad/s without so much noise or spikes, but unfortunately it have the same problem as shown in the video, it works only in one direction (voltage mode) as explained before.

I noticed several disturbances both on currents and speed, and in particular I suspect that the cause of this is the HallSensors class. I've modified it in order to avoid spikes in velocity (zeros and very high values, the workaround taken from the forum was not enough) but i think that this modification cause more noise on the variable passed from the getVelocity() function.

So inspecting the schematic of the VESC 6 I discovered that compared to version 4 have been removed low-pass filters placed on the inputs (but there are pull-up resistors) which I think make a huge difference in these big motors in which the back-emf (especially with motor under load) are a source of disturbance not negligible for the HALLs.

In fact i have a lot of false call to the callbacks of the interrup pins of the HALLs and by inspecting the direction variable it happen quite often that it change (incorrectly) suddently value.

Instead in the VESC firmware the problem it not emerges probably because it implement a sort of averaged value for the hall table. I found this thread that confirm my last reasonings.

I hope I was as clear as possible and didn't waste your time.

Any advice or comments would help me a lot,

Luca