Integral Understanding in Heat and Cool PID

Mike_Treadway · February 5, 2020, 6:19pm

Any idea why the integral value (0.01 and -0.04) would be different between the Cool and Heat PID?

Bob_Steers · February 5, 2020, 7:32pm

I didn’t write the firmware calculations, so any explanation would involve some educated guesses.

Is this a theoretical question about PIDs in general, or about this particular implementation?

Mike_Treadway · February 5, 2020, 7:39pm

This particular implementation. I would have expected the values of P over time to drive the values of I (just like P drives the value of D). Since P is the same for both PIDs, I would have expected the values of I to be the same as well. In my setup, I’m seeing the same P and D values (left column of each panel), but the I’s are different. I suspect there’s a bug somewhere, which is why I’m raising the question.

Bob_Steers · February 5, 2020, 8:02pm

P is not the same for both PIDs here, nor is Kp.

The top left value is the error, which will indeed be equal. To find the discrepancy in Integral I’d personally check behavior during overshoot (is delta integrator the same for positive and negative error?)

For a definitive answer you’ll need @Elco

Mike_Treadway · February 5, 2020, 8:22pm

Oh, right. I said P, but didn’t mean P. I’m sorry, I meant the calculated Error, Integral, and Derivative (far left column). I would have expected all 3 to be the same for both PIDs.

Bob_Steers · February 5, 2020, 8:37pm

I checked the actual calculations, and the Integral is indeed clipped to never cross 0 (never negative if Kp > 0, never positive if Kp < 0).

If (for example) the setting is some unattainably high value, you’d see the heating integrator steadily climb until max, and the cooling integrator remain at 0. Both values being != 0 indicates the error has been hovering around 0.

Edit: this does of course not rule out bugs in the implementation. It merely indicates that it is not unlikely for the cooling integrator to differ from the heating integrator.

github.com

BrewBlox/brewblox-firmware/blob/2b8fe93427b35f76834e0e3fd7f5e53c0a2cb302/lib/src/Pid.cpp#L111


                            if (m_i < 0 && m_p < 0 && m_i < 3 * m_p) {
                                antiWindup = 0;
                            }
                            if (m_i > 0 && m_p > 0 && m_i > 3 * m_p) {
                                antiWindup = 0;
                            }
                        }
                    }
                }


                // make sure integral does not cross zero and does not increase by anti-windup
                integral_t newIntegral = m_integral - antiWindup;
                if (m_integral >= 0) {
                    m_integral = std::clamp(newIntegral, integral_t(0), m_integral);
                } else {
                    m_integral = std::clamp(newIntegral, m_integral, integral_t(0));
                }
            }
        }
    }
}

Mike_Treadway · February 5, 2020, 8:41pm

OK, that makes sense and also explains why they could be different. Thanks!

Elco · February 13, 2020, 2:22pm

Integral anti-windup can also play a role here.

There are a few measures to prevent the integral from growing when it is unlikely to be desired behavior:

The actuator is already clipping to the limits
The actual value of the actuator is different from the desired value

Anti-windup prevents overshoot caused by the integrator.