I'm a bit puzzled. As far as I can understand from the wikipedia page the integrative gain amplifies the oscillations and the derivative gain is the one that is smoothing the oscillations. Am I getting this wrong ?

Take a look at this: en.wikipedia.org/wiki/PID_controller#/me...nsation_Animated.gif

"The proportional gain is there but IIRC, the integral or derivative gains are not used at all."

That hurts!

After all the hours I have spent fine-tuning integral and derivative gain and convincing myself on how important they are...

Crushed!!!

((

Jo,

Don't dispair, there's hope! Though I have no clue as to how the internal guider works, your comment at least got me to search the source.
If you look at kstars/ekos/guide/internalguide/gmath.cpp at the method process_axes(), you can find the following lines:

// process axes...
for (int k = GUIDE_RA; k <= GUIDE_DEC; k++)
{
...
qCDebug(KSTARS_EKOS_GUIDE) << "delta [" << k << "]= " << out_params.delta[k];
qCDebug(KSTARS_EKOS_GUIDE) << "drift_integral[" << k << "]= " << drift_integral[k];

out_params.pulse_length[k] =
fabs(out_params.delta[k] * in_params.proportional_gain[k] + drift_integral[k] * in_params.integral_gain[k]);
out_params.pulse_length[k] = out_params.pulse_length[k] <= in_params.max_pulse_length[k] ?
out_params.pulse_length[k] :
in_params.max_pulse_length[k];

qCDebug(KSTARS_EKOS_GUIDE) << "pulse_length [" << k << "]= " << out_params.pulse_length[k];

and process_axes() seems to be called by perform_processing()

So, I can't be sure, but it seems to me that at least the proportional and integral gains are both used to compute the pulse length in the internal guider (no so much the derivative gain).
Turn out debug logging for the internal guider and look in your log for that "delta", "drift_integral" and "pulse_length" log line, and if you find them, this is probably the case.

Hy

Thanks, Hy! Like Jo, I use to tune both parameters and in my experience they clearly both have an effect.

Thanks Hy!

Will do next time I have a chance, cloudy here again and I will be out of town for a few days.

Is there another section in the code where the drift integral is calculated? If that is not calculated and is always set to a default value of 0, then any setting of the integral gain would also == 0 according to how I understand that section of the code you posted here.

But the debug logs should show that, so will turn those on and report back once I have more data.

Jo

"I'm a bit puzzled. As far as I can understand from the wikipedia page the integrative gain amplifies the oscillations and the derivative gain is the one that is smoothing the oscillations. Am I getting this wrong ?

Take a look at this: en.wikipedia.org/wiki/PID_controller#/me...nsation_Animated.gif"

Absolutely correct of course. In PID controllers, the response is determined by the effect of all three parameters together. It is a lot more difficult to get stable operation if you have more parameters to dial in. The differential part of the controller is sensitive to noise, and could create erratic operation. The integral part averages noise. It will also bring the error in the control system to 0, something which a P controller can't.

Absolutely agree with you Wim. The integral term is essential to arrive at an error of zero. Although even if there exists an error, it is static (i.e., the guide star is shifted from the 'set' position). This therefore should in principle not influence the guiding, since, once the system is settled, it is constant.
I've started to take a look at the source as well and found the same as HY. Only the P and I terms are incorporated. Does anyone here know what is the reasoning behind this?
Indeed the D term is sensitive to the slope (dT/dx) of the measured value (where x is the position in the respective control direction). I wonder if sensitivity to noise would be the reason for this.

By the way, here is a really nice explanation of a PID loop (on a microcontroller), and how to add several nifty things to make it respond better: brettbeauregard.com/blog/2011/04/improvi...rs-pid-introduction/

The internal guider is derived from lin-guider, so best try to ask the developer. My guess is, that the D term is sensitive to noise and doesn't add enough to the solution. As I mentioned before, you'd want to make sure that any combination of the PID parameters that are allowed, can't cause catastrophic behaviour of the mount. Oscillations may be cool in math, but I wouldn't like to see my mount swing. Also remember that any practical solution has to work for all possible mount and load combinations. And rather than make the D term less sensitive to noise, there are better solutions, such as the minmo parameter in phd.

In this posting Jasem explained the internal guider like this:

"Ekos guide code was based on lin_guider code from a couple of years ago. The algorithm acts like a Proportional-Integral (PI) controller . I'm not going to discuss control theory here, but the proportional gain (133.3x) is multiplied directly by the deflection value (+/- arcsecs) which is the difference between the actual star position minus the locked position. The integral term (sum of errors) is added to that, but the integral gain is zero is by default the integral term is not used. This produces the pulse that gets sent to the mount. So:

Pulse[ms]@T = deflection@T (arcsecs) * PropGain + sum(deflections from 0 up to T)/50 * IntegralGain"

This explanation is 100% in line with what I experience using the internal guider. The proportional gain is the "aggressiveness" actual deflections are treated with and integral gain is something that is added to it. I use integral gain when my mount tends to lag, which means vitually all points in the drift plot deviate from the center to one side. So integral gain IMO can be explained as a "correction of EXPECTED deviation (derived from past performance)".

Thanks Alfred, but this is exactly where matters are unclear. Read the following sentence:

"The integral term (sum of errors) is added to that, but the integral gain is zero is by default the integral term is not used."

This sentence is grammatically incorrect and ambiguous. I can interpret it in two ways. If Jasem meant to say:

"... but the integral gain is zero by default AND THUS the integral term is not used." then that part of the term ==0 and any integral gain setting we are using is irrelevant, as it is replaced with the default value of 0.

Or he could have meant:

+... but IF the integral gain is zero, by default the integral term is not used." Meaning that only if integral gain is ACTUALLY 0 (not just by default), only proportional gain will be applied.

Which is the correct meaning of the sentence? Only Jasem can tell us, OR you can. Can you upload a verbose debug log of the guide module which shows the "delta", "drift_integral" and "pulse_length" log lines (as Hy asked for in his reply), then we should be able to deduce that.

I cannot provide these numbers as I am going out of town and the weather here is not cooperating at the moment anyway.

As far as I'm concerned, both the P and the I terms are incorporated.
From gmath -> process_axes :
"
out_params.pulse_length[k] =
fabs(out_params.delta[k] * in_params.proportional_gain[k] + drift_integral[k] * in_params.integral_gain[k]);
"
Apparently, PI controllers are commonly used in speed control applications www.quora.com/Which-controller-is-better...on-of-the-controller
The I term will make sure there is no residual error.

Hey how about instead of setting a time value --[Guide Settle] 'Wait this many seconds after guiding is resumed to stabilize the guiding performance before capture'--, just start guiding after guiding has settled below a certain error (perhaps in percentage) or after the first undershoot. Where the integral sum = 7 points in the image.

Cheers!
Bart

I'm afraid I won't get to see any stars anytime soon. www.meteoblue.com/en/weather/outdoorspor...main_germany_2925533
The formula that Jasem had posted (the one I quoted) indicates that both parameters are used (unless they are set to zero). So I think your latter interpretation should apply.