Estimated_current and velocity mode: high current at standstill

[o_lampe]

When I use that setup and velocity is zero, the motor still wants to position itself “on the cogging point”. Which means there is a significant Iq of ~340mA at standstill, result of a nonzero Vq.
The sign of the current changes when I manually move the motor “over the hump”.
I tried that mode with digital and linear halls, but it doesn’t make a difference.

Can I set Vq to zero, when velocity/motor.target is zero? I would rather like to understand what’s the cause.

[dekutree64]

  // Don't try to stop between cogging steps
  if (motor.controller == MotionControlType::angle) {
    const float c = _PI_3/motor.pole_pairs;
    target = floor(target / c + 0.5f) * c;
  }

[dekutree64]

I didn’t have time to write a proper response, but I did have code that I know works, so I thought maybe you could adapt it to the velocity case. But now that I think about it, that would only work for pseudo-velocity mode using angle_nocascade and incrementing the angle like velocity_openloop. Regular velocity mode should be satisfied if the rotor isn’t moving.

Are you using dev branch, and have you updated it lately? There was a bug where velocity would never fully go to zero [BUG] Velocity doesnt go to 0 when stationary · Issue #533 · simplefoc/Arduino-FOC · GitHub

[o_lampe]

I am using the dev branch since I was testing the 120° linear hall implementation. I’ll update it to the latest and test again.

<edit Doesn’t make a difference. Here’s a screenshot with Iq and Vq while toggling the shaft over the cogging hump ( digital halls and Smoothing)

[dekutree64]

Hmm, you may have found a true bug in the PID.

src/common/pid.cpp

Since error and prev_error should both be zero, integral just gets set to integral_prev, i.e. it’s probably sitting there non-zero commanding torque, but since the motor is unable to move due to stiction/cogging, nothing ever causes it to change. But it looks like it’s been that way since the beginning, so I don’t know how it could have gone unnoticed for so long, nor do I have enough experience with PID controllers to propose a solution.

Try printing out motor.PID_Velocity.integral_prev to verify this is the problem. Comment out protected: on line 41 of pid.h so all the variables are accessible by outside code.

[o_lampe]

Setting I=0 did the trick, but now comes the hard part. How to change the I-behaviour?

One way would be to skip integral_prev
float integral = I*dt*(error + error_prev);
Adding up (error+error_prev) is already an integration, no?
I will ask “BigBrother”, it usually clears up my mind

[o_lampe]

Here’s what ChatGPT had to say about my issue:

“The current PID implementation is mathematically correct. However, a velocity controller has no concept of an idle state. Once the velocity error reaches zero, the integrator preserves whatever torque was accumulated, which can result in unnecessary holding current (e.g. due to cogging torque) even when the application does not require holding torque. This isn’t really a PID issue but an idle-state policy issue. Perhaps SimpleFOC could support configurable idle behavior or integrator retention policies (hold, leak, reset, freeze), leaving the default behavior unchanged for applications that do require holding torque.”

What the integral part does: it keeps memorizing the torque/current it takes to overcome the cogging point, which helps reacting to a new velocity target faster.
If that holding torque isn’t necessary, it’s up to the user to take measures (eg. target == 0 > motor.disable). There were other suggestions, how to implement different motor.idle modes.

• leaky integral = slowly forgets the holding torque
• reset integral = immediately sets I=0
• reduce holding torque after a given idle time (that’s what RRF does with 3D printer steppers)

I can share the whole conversation, if anyone is interested.

[dekutree64]

We’ll have to defer to @Antun_Skuric on this one. Changing the PID is serious business.