Resetting the Integral seems to destabilize the algorithm?

[RobTS]

Hi there, in my quest to find a good autotune library, I have come upon this gem and started using it for control as well as autotune (as a TypeScript port for now, before moving PID control from the frontend to the ESP32). It works like a charm and the range of choices is great, however, I have come upon a quirk that I am not sure is correct:

Whenever the algorithm stabilizes PID control, it knocks it out of balance soon after (as seen in the attached graph, green being setpoint, red being the temperature sensor, yellow the heater power). When looking more closely at the problem, it seems to be induced by the logic resetting the integral here: https://github.com/lily-osp/AutoTunePID/blob/main/src/AutoTunePID.cpp#L182C6-L187C10

If I replace that section with just the _integral += _error * dt; statement, things work out beautifully. When looking at the data output, it seems the integral usually stabilized at a number far away from 0 (such as 65 or 70 in my case) when the error starts approaching 0, so resetting it causes readaptation of the algorithm.

Is this simply a typo and intended to be a similar logic to this block, or does this serve a different purpose I am unable to figure out?

I am by no means a PID expert, merely a curious user, so any help in understanding this further would be appreciated. The project in question is a DIY coffee roaster, btw: https://github.com/RobTS/reyaeger

[1999AZZAR]

Hi there!

First of all, thank you so much for the incredibly detailed issue report, the graphs, and for using the library in your DIY coffee roaster project (ReyAeger looks awesome!).

You hit the nail right on the head. Your analysis is 100% correct. The logic that reset the integral to zero when the error became very small was indeed a flaw. As you correctly observed, in a system like a heater, when the error approaches zero, the controller still
needs to output a continuous, steady-state power to maintain that temperature. This steady-state bias is held entirely by the accumulated integral term. Resetting it to zero wipes out that bias, causing the heater output to drop and forcing the algorithm to
constantly "readapt" and oscillate.

Your suggested fix of simply letting the integral accumulate naturally (_integral += _error * dt;) is exactly the right solution and aligns perfectly with standard PID theory.

I have just pushed a commit that removes this premature reset logic and implements your suggested fix.

As a bonus, the library has also just undergone a massive under-the-hood refactor to become fully AUTOSAR C++14 compliant (strict type safety, better float handling, etc.), which should make it even more robust for your upcoming ESP32 transition.

Please pull the latest changes from the main branch. It should work beautifully for you now without any of those sudden drop-offs.

Thanks again for the great contribution to the library! Feel free to close this issue once you've had a chance to verify it works on
your end.