×

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

Bi-monthly release with minor bug fixes and improvements

Internal guider questions

  • Posts: 643
  • Thank you received: 62
Hi!

So (somewhat later than I intended), here are two logs. In the PHD2-file, there are 2 runs of about 10 mins. The Kstars log is shorter. It seemed that there were no corrections at all, again. Now I switched back to PHD2, and it works nicely again. What might I do wrong here....?

Magnus
2 years 10 months ago #71360
Attachments:

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

  • Posts: 984
  • Thank you received: 160

Replied by Alfred on topic Internal guider questions

I can confirm Magnus' issue. Tonight there were just a few holes in the clouds so I was chasing stars that disappeared within minutes. Accordingly, my logfiles aren't very helpful and a mess to wade through. Nevertheless I was able to gather a few calibration attempts and as it was the case with Magnus' G11, the mount didn't move in DEC. 



You can see the 5 iterations (500ms pulse) in RA and a couple more on the way back. When DEC calibration starts, the mount basically doesn't move. I suspect the minor movement that you can see here is the result of awful seeing plus polar alignment error.

Another attempt, same result:

 

It's 100% overcast now so I am unable to investigate further.
KStars and Indi compiled from GIT today.
Last edit: 2 years 10 months ago by Alfred.
2 years 10 months ago #71472
Attachments:

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

  • Posts: 984
  • Thank you received: 160

Replied by Alfred on topic Internal guider questions

A few other quirks that I spotted during testing:

1. I started with SEP-multistar. After clicking "Guide" to start calibration, an error message "failed to select an auto star" appeared (as just one bright enough star was in the field of view) even though "Autostar" was not ticked. I find this confusing. In case SEP-multistar always selects the guide star on its own (I'm not sure), the "Auto Star" box should be ticked and greyed out automatically once SEP-multistar is chosen.

 

2. Since SEP-multistar didn't find proper stars to guide on, I reverted to SEP. Once I clicked "Guide", the calibration process started. However, the (0,0) reference point that Ekos chose was the position of the red marker rather than the actual position of the guide star. Instead of accepting a previously marked position as a reference point, Ekos should ask the user to mark the guide star every time "Guide" has been clicked (provided Autostar is inactive). Secondly, once the guide star is marked, Ekos should take one frame to determine the actual position of the guide star and mark it as reference point before sending the first RA pulse. As it is now, results may look like this:

 
Last edit: 2 years 10 months ago by Alfred.
2 years 10 months ago #71515
Attachments:

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

  • Posts: 984
  • Thank you received: 160

Replied by Alfred on topic Internal guider questions

Today I had another try and to my utter astonishment everything went perfectly. I got crystal clear calibration including DEC. I have no idea what has changed as I did not touch the rig since my last attempt.

 

SEP with subframe did work very well, too. WTF!

 
Last edit: 2 years 10 months ago by Alfred.
2 years 10 months ago #71565
Attachments:

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

  • Posts: 268
  • Thank you received: 72
Hi all
Are there any updates in the matter? I'm struggling currently with the same symptoms Magnus an Alfred describe while trying to guide internally on KStars 3.5.3 stable.  The "behaviour" of the guide-module seems very erratic especially with 'SEP-Multistar', but sometimes with "Smart"-Pofile too!
Last edit: 2 years 9 months ago by Toni Schriber.
2 years 9 months ago #72542

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

  • Posts: 268
  • Thank you received: 72
Alfred post=71515 userid=2597
A few other quirks that I spotted during testing:
1. I started with SEP-multistar. After clicking "Guide" to start calibration, an error message "failed to select an auto star" appeared (as just one bright enough star was in the field of view) even though "Autostar" was not ticked. I find this confusing. In case SEP-multistar always selects the guide star on its own (I'm not sure), the "Auto Star" box should be ticked and greyed out automatically once SEP-multistar is chosen.


Hi Alfred
You are right: Mode 'SEPMultistar' always uses 'Autostar'. I was able to write a small patch that corrects the display of the 'Autostar' checkbox. It is now checked and greyed out if the guider is in 'SEPMultistar' mode. I hope it will be merged in KStars-3.5.5.
The following user(s) said Thank You: Alfred, Juergen Terpe
Last edit: 2 years 7 months ago by Toni Schriber.
2 years 7 months ago #74599

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

  • Posts: 36
  • Thank you received: 3
I really like the internal guider, especially the MultiStar guiding. However, I have had mixed experiences with the guiding quality. It works, but I cannot really control the guiding quality, because there are a lot of unknown variables:

- the guiding pulse duration
- the proportional gain

Both are very technical aspects of the guiding mechanics behind the scene. I cannot really describe the problem with all this - it just feels less natural from the thinking I'm doing. On the other hand it seems that my NEQ6 introduces some problems, at least with pulse guiding. Until now, I'm back to PHD2 using an ST4 cable. Not because the internal guider is not good enough, but I'm still new to KStars/Ekos and the best results I got with the ST4 cable and PHD2 - here I get a nearly flat graph, if I have a good polar alignment and the seeing conditions are not so bad. And I have some easy to understandable controls to control aggressiveness and hysteresis for both axes. These are things I just can bring into relation to what I want, the hysteresis for overcompensations and the aggressiveness for reactiveness. Thinking in pulse duration (when I not even know how long the pulse should go) and a proportion factor is much harder to express how I want to control the curve, it's a less mathematical and more technical perspective of nearly the same thing. What I'm missing from PHD2 guiding with Ekos is the visible feedback from the camera, it is really soothing to see the stars matched inside their boxes - so if I would be able to have better control over the internal guider I really would prefer using it (needless to say: not having the control over it is just a user feeling :-) ). 

I would really appreciate if we could see some improvements in the UI and perhaps the logic of the internal guider in KStars 3.6 or so - understanding that it is not as easy as it might seem, but good things might take a while.        
2 years 7 months ago #74606

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

  • Posts: 1208
  • Thank you received: 559
Juergen,

Yes, a revamp of the guider UI has been on my plate for quite a while. Hopefully it will get done in the next few months. Until that happens, though, let me try to describe what is going on.

Guiding can be split into (a) estimating the current error--how far and which direction the scope has moved from its target position in the sky, and (b) generating and producing a correction pulse.

SEP MultiStar is used for "a". I believe you are more concerned with "b", which is described below.

We send correction pulses to RA and DEC motors, so the scheme needs to understand what those motors do. Calibration is the process that measures, for each motor, how far "the target moves" when that motor is pulsed for N milliseconds, and in which direction it moves. This is complicated by backlash, but let's ignore that for now, and also assume calibration is "good enough".

So, given we have estimates for the RA and DEC directions in image space, and for RA and DEC's "arc-seconds of movement per millisecond of pulse" we can apply a control algorithm to correct the guiding error.

[Please forgive me if I'm over-explaining something you already know below, just wanted to be as clear as possible.]

Say we measured 2 arc-seconds error West in the RA direction, and 100ms pulses --> 1 arc-second of movement. A full RA correction pulse might be 200 ms East. Of course, it's not a good idea to full correct the pulse, so there's a gain associate with that, and if the gain is 0.6, then the correction pulse would be 0.6*200=120ms. That's a basic proportional control. That's what's going on with DEC and RA guiding (when not using GPG), with the exception that instead of entering 0.6 or whatever, you control the proportional gain by changing the values of the "Proportional Gain" row in the table on the "Control" sub-tab on the lower right of the Guider tab, where the RA and DEC values default to 133. Increasing the value (above 133) increases the proportional gain.

Why 133 you ask? Not sure, this pre-dates my involvement in the project, but I believe that 133 means "provide 133ms of pulse for a 1 arc-second error". That is, it is NOT using any calibrated measure of your mount. So, if your mount required 266ms/arc-second, then the effective proportional gain is 0.5. There is also a min-pulse field (e.g. don't send any pulses lower than, e.g. 30ms) which implements a type of hysteresis, and a max-pulse field which is a type of protecting for things going out-of-whack on a bad measurement. [BTW, there is also an Integrated gain implemented (defaulting to 0)--I haven't been able to improve my guiding performance when using it.]. That's it (if you're not using GPG). Thus, this guiding scheme does NOT use the calibrated "arc-seconds of movement per millisecond of pulse" values, but rather relies on the user to enter the appropriate numbers. It does use the calibrated directions for RA and DEC, of course.

If you are have enabled GPG guiding (which only applies to RA), then the situation is a bit better. The calibration measurements are used, and the gains are input in a traditional 0.0 -> 1.0 way. Ignore the "Proportional Gain" and "Minimum Pulse" fields in the RA column of the "control sub-tab", and instead use the settings in the Guider tab's Options --> GPG RA Guider menu. There you will find a traditional control gain (which does use the calibrated movement value) and minimum move value (now in arc-seconds). You also get a prediction gain, as the GPG scheme is predicting what the next error value will be and preemptively correcting for it. It's basically that, but slightly more complicated, see the code in: invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L341 and invent.kde.org/education/kstars/-/blob/m...alguide/gpg.cpp#L221

BTW, I'm happy to take concrete suggestions for improvements and, even better, work with you and provide you with custom versions of Ekos you could evaluate and provide feedback for.  However, this latter interaction would require that you compile Kstars from source (cloning and git pulling from a forked repo of mine).

Hy
The following user(s) said Thank You: jiberjaber, Rafael Schlegel, Juergen Terpe
2 years 7 months ago #74621

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

  • Posts: 984
  • Thank you received: 160

Replied by Alfred on topic Internal guider questions

Hy,

many thanks for taking the time to explain the details of Ekos' guiding. I use the guider for years and never got my head around why I would have to type in a value for proportional gain when the guider does its own calibration and should know these values very well.

In my maybe naive thinking calibration measures how the mount moves when a certain pulse duration to the N,E,S or W is applied. Once the "learning" has been accomplished, the software knows the pulse lengths that have to be sent to the mount to counter a measured error.

Reality, according to your explanation, is much different though. The first thing that strikes me is the fact that calibration does not measure backlash. IMO calibration should do this for both axis and subsequent guiding should compensate for it.

The second thing I am scratching my head about is this: Although calibration measures movement per ms pulse duration for all four directions, it never uses all of them. It rather (at best) uses two, one for RA and one for DE (i.e. the two proportional gain values). Mounts are not perfect and as it is the case with my G-11, a 100ms pulse to the W will move the mount almost twice as much as a 100ms pulse to the E. I know that should not happen and maybe something is wrong with my gear or motor. But Ekos, despite measuring these differences, ignores them. It sends the same RA pulses to the E and the W which leads to over-correction in one direction or under-corretion in the other. Guiding should make optimum use of all the information that has been gathered during calibration.

In my opinion guiding is right at the heart of any astronomical imaging software as it (besides factors like seeing that are out of our control) decides the quality of our raw images. I'd be more than happy to help improve this most critical aspect of the software.

Alfred
Last edit: 2 years 7 months ago by Alfred.
2 years 7 months ago #74633

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

  • Posts: 1208
  • Thank you received: 559
- Calibration currently measures the movement-per-millisecond-pulse in RA and DEC. Though, admittedly it moves in both directions for each motor, it currently only calculates the "out" direction (whatever direction results from positive pulses). I suppose that an imbalance in the efficiency of the pulses could be due to scope balance, and could change depending on where in the sky one was pointed, and calibration is intended to work across large parts of the sky?  Because of that, I'm not sure that it makes sense to distinguish the directions. ​Of course, if it made sense, it could be modified to measure the average of the in & out directions for RA (and 2 for DEC), or perhaps all 4 as you say, but right now it's just measuring "out".  

-Feel free to research and propose a backlash scheme--in enough detail to be implemented ;)
I'd be haappy to hear your ideas

 
2 years 7 months ago #74634

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

  • Posts: 984
  • Thank you received: 160

Replied by Alfred on topic Internal guider questions

Calibration currently measures the movement-per-millisecond-pulse in RA and DEC. Though, admittedly it moves in both directions for each motor, it currently only calculates the "out" direction (whatever direction results from positive pulses).

I propose we measure 6 values: RA in, RA out, DE in, DE out, RA backlash, DE backlash. I have an idea how we could measure all these values in one go. Ekos guiding should then compensate for backlash and in addition provide distinct pulse durations for all four directions thus compensate for mechanical imperfections of any mount (or even scope imbalance). These 6 values can be measured and can be applied during guiding. It would further improve the quality of guiding so why should we not use them?  I'll write to you in more detail about it after the weekend.

<em>I suppose that an imbalance in the efficiency of the pulses could be due to scope balance, and could change depending on where in the sky one was pointed, and calibration is intended to work across large parts of the sky?</em>


That was my first suspicion, too. More often than not, balance IS the cause of the problem. Since I am well aware of my mount's problem, I pay utmost attention to scope balance. So far, all my testing has lead me to believe that balance is not the root cause of the problem. I took everything apart and found that in some (that's what makes it extra tricky) cases my RA transmission gearing moves easier in one direction than the other. I suspect the motor is not strong enough to completely overcome the extra resistance. I'll switch (RA<->DE) motors first and gears later and see what happens.

I'm looking forward to discussing the details with you.
Alfred
 
Last edit: 6 months 3 weeks ago by Alfred.
2 years 7 months ago #74635

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

  • Posts: 109
  • Thank you received: 8
Hi all,
sorry to get involved but I wanted to understand things a bit better.
For how I know guiding, backlash in RA is meaningless as you never reverse. Or you shouldn't. RA is always moving, so the motor is always working against a weigh. Now, the guiding pulses should always be accelerating or slowing the motor, but never running in the opposite direction, as is the case with DEC. So that's why you shouldn't bother with backlash in RA.
Now, even in DEC, you shouldn't either. DEC errors account for polar alignment inaccuracies. In a perfect world, a perfectly aligned mount would leave the DEC motor off for the entire session. Of course this being impossible to achieve, the next best thing should be figure out where the DEC drift is heading (N or S) and correct only in the opposite direction, disabling the unwanted direction. The DEC should only have a drift, hence why you need to correct in one direction only.

Please verify what I'm saying is right, I always like to learn :)

Also, question to Alfred: are you positive the same amount of pulse moves your mount differently in RA+ and RA-? If so, please check that your mount have maybe a different guiding speed per direction? It sounds strange but you never know.
2 years 7 months ago #74642

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

Time to create page: 0.484 seconds