Dans98 klipper velocity pid

[bwnance]

upstream PR: Klipper3d/klipper#6272

[dans98]

@bwnance do you want me to directly submit a pr here for fixing the calibration code?

I'm pretty much done with upstream at this point.

[bwnance]

@dans98 that would be awesome :)

[dans98]

@bwnance i'm working on converting over to dangerklipper but i hit an error that makes no sense to me.

https://github.com/DangerKlippers/danger-klipper/issues/49

[dans98]

@bwnance

I will have a pr ready tonight or tomorrow for the updates for pid_calibration, do we need to follow this commit format/policy here?
https://dangerklippers.github.io/danger-klipper/CONTRIBUTING.html#format-of-commit-messages

[bwnance]

@dans98 ah, we should update that. We've been pretty lax with it, so don't worry about it :)

[dans98]

@bwnance It's been submitted, sorry it took so long!
https://github.com/DangerKlippers/danger-klipper/pull/62

[dzid26]

This is convoluted way of limiting the integral term.
You would have achieved the same by explicitly subtracting the remainder after the PWM saturation from the integral memory.

[dans98]

This convoluted way of limiting the integral term. You would have achieved the same by explicitly subtracting the remainder after the PWM saturation from the integral memory.

The velocity algorithm is pretty much a standard in the motion control industry.

you can see an example of it derived here.
https://www.youtube.com/watch?v=vHHOlJMac4c

[dzid26]

The velocity algorithm is pretty much a standard in the motion control industry.

Indeed this originates from motor control where second derivative of the desired position corresponds directly to commanded torque (or current) and thus useful.

Statements that this PID form is more susceptible to noise is wrong as the integration at the end removes the second derivative. This again probably stems from confusing this with motor control.

In practise, all this controller adds is a rudimentary anti-windup (which could have been added in normal PID form as well). This is nice, but not well communicated.

Instead there is this false claim:

In some scenarios Velocity control will also be better at holding the heater at its target temperature, and rejecting disturbances. > The primary reason for this is that velocity control is more like a standard second order differential equation. It takes into account position, velocity, and acceleration.

Aside from filtering you added, mathematically both PID forms are the same. This sounds like misinterpretation of https://www.controleng.com/articles/the-velocity-of-pid/ .

Oh indeed @dans98, seems that companies like Rockwell call this a Velocity Form and explain well the benefits of the implementation.

But I think in the software like this a single implementation is enough and the end user should not care.

Instead of switching between implementations, the user could just have a choice to "Saturate integral term".

Also "Derivative kick" prevention on P term doesn't make sense for the heater control and I think it should be removed for the faster response.

Just my 2cents.
Feel free to point out any inaccuracies.