einride / pid-go Goto Github PK

Not having any experience with PID controlelrs I need a nudge to get this going.

I have a water heating system that has a pump to push water through a set of solar panels to heat up a large tank. I thought I could employ this controller to manage the pump speed based on the temperature of the hot tank vs the temperature of the water coming off the solar panels. My problem is that I don't really understand how I should be using the controller.

I set the ReferenceSignal to the difference in temperature I am looking for, e.g 3.0 Celsius. Then I set the actual value to the observed difference in the two measured temperatures. I am sampling every 5 seconds.

Is this correct or am I completely missing the point?

Once I get the result by asking for the State, how should I interpret it? Should I use the ControlSignal to adjust the pump speed? Obviously it would need to be capped at 100% but should that somehow be fed back tot he controller?

Please forgive my ignorance here.

Hi !
It would be nice to add JSON tags to the conf structure to automate controller configuration. In my case this required me to create a structure with tags and cast it into your, I think this could be simplified by adding it to yours.

Here's my suggestion:

// ControllerConfig contains configurable parameters for a Controller.
type ControllerConfig struct {
	// ProportionalGain determines ratio of output response to error signal.
	ProportionalGain float64 `json:"kp"`
	// IntegralGain determines previous error's affect on output.
	IntegralGain float64 `json:"ki"`
	// DerivativeGain decreases the sensitivity to large reference changes.
	DerivativeGain float64 `json:"kd"`
}

Best regards.

I think I've found a bug with the package with AntiWindupController (I think it works for the others as well, didn't check)

If the control of the physical process fails (due to unrelated to the package reasons, ofc) and the feedback values are always giving the error (let's assume it stabilized at an offset from the setpoint), it would always accumulate *.State.ControlErrorIntegral. It's generally ok, but if the process is constantly offset, it accumulates error until it overflows and becomes NaN. In this case, the *.State.ControlSignal is not clamped as in normal operation. It may result in unexpected behaviour.

In my case I just clamped the actual control signal additionally with checks (the approach)

if math.IsNaN(Controller.State.ControlSignal) || math.IsInf(Controller.State.ControlSignal) { // the last one is "just in case"
  actualSignal = Controller.Config.MaxOutput // or minimum
} else {
  actualSignal = Controller.State.ControlSignal
}

Not sure if it should be considered an issue, but I think it's worth mentioning.