×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Internal autoguide in EKOS makes thins worse

  • Posts: 126
  • Thank you received: 16

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.
4 years 3 weeks ago #50400

Please Log in or Create an account to join the conversation.

  • Posts: 985
  • Thank you received: 160
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)".
The following user(s) said Thank You: Jose Corazon
Last edit: 4 years 3 weeks ago by Alfred.
4 years 3 weeks ago #50411

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

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.
Last edit: 4 years 3 weeks ago by Jose Corazon.
4 years 3 weeks ago #50427

Please Log in or Create an account to join the conversation.

  • Posts: 163
  • Thank you received: 26
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
4 years 3 weeks ago #50434
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 985
  • Thank you received: 160
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.
4 years 3 weeks ago #50439

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182


The theory is clear, Bart, and so is that section of the code (at least as far as I understand it). The question is whether somewhere else in the code the integral gain is set as a global value that ==0. I wonder whether that is what Jasem may have meant to say when he said that the integral gain is not used. I will test whether that is the case as soon as I get a chance.
4 years 3 weeks ago #50444

Please Log in or Create an account to join the conversation.

  • Posts: 163
  • Thank you received: 26
Thanks for clearing that up Jose.

I'm having the same trouble as Herrhausen (I'm living in The Netherlands). It was a terrible winter and it doesn't seem to get any better soon.
4 years 3 weeks ago #50459

Please Log in or Create an account to join the conversation.

Time to create page: 0.606 seconds