×

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

Bi-monthly release with minor bug fixes and improvements

Desperately needed feature: better guide star loss recovery.

  • Posts: 554
  • Thank you received: 138
This has been coming up on the SGP group as well. What seems to happen, at least with PHD2, is that if the guide star is lost behind a cloud for a few minutes the mount cn drift sufficiently that when stars reappear a different one is detected and guided to the same place. After all all stars look the same.

What I've been wondering is if this could be managed in the guider by collecting a pattern of stars over the frame and comparing the pattern. If the pattern shifts then the guider guides it back to the correct position as part of the re centering process. Using multiple stars may also improve guiding by reducing the star position noise. I'm not sure if there's enough processing power to do this every guide frame though.

The scheduler/image collection process only sees a message from the guider that guiding has failed and pauses image acquisition. The guider only signals that guiding has resumed when the mount has been moved to the correct position. The scheduler/image acquisition modules shoud have nothing more to do.
3 years 6 months ago #59089

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

  • Posts: 969
  • Thank you received: 94
Last edit: 3 years 6 months ago by alacant.
3 years 6 months ago #59090

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

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

We think alike. You have just described the algorithm already implemented in SEP Multistar!

See
invent.kde.org/education/kstars/-/blob/m...guide/guidestars.cpp
invent.kde.org/education/kstars/-/blob/m...arcorrespondence.cpp

I had originally implemented it to be totally unconstrained, so that it could conceivably recover from large shifts,
but when testing with @alacant (Steve), I found his setup, when looking at dense star fields, for some reason could trick it.
I wound up compromising and having SEP Multistar not accept a guide-star detection if it was outside the guide reticle (which you can set up to 128x128).
Perhaps I should allow that reticle to get larger, or allow SEP Multistar to locate its guide star further away.
The other issue that could come up is that guiding currently has a check that causes it to fail if the guide error (distance from desired guide star location to located guide star location)
is too large. Of course, we could experiment with disabling this check too, but for all things like these, it's hard to guess the side effects.

Hy
3 years 6 months ago #59120

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

  • Posts: 969
  • Thank you received: 94
causes it to fail if the guide error (
Hy, everyone
Please at least make it an option. Disabling something which helps guiding on less than perfect mounts perhaps isn't gonna bring many benefits.
Cheers and clear skies,
Steve
3 years 6 months ago #59123

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

  • Posts: 27
  • Thank you received: 2
Any good news on this topic ?.
3 years 1 week ago #68698

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

  • Posts: 1208
  • Thank you received: 559
I did add something several weeks ago
invent.kde.org/education/kstars/-/merge_requests/221
just after 3.5.2 was completed (i.e. will be released in 3.5.3) which should make the guider a little more robust to losing the guide star.
This is something along the lines of what I described above.
Still, if a cloud comes by and obscures the image for several guiding cycles, guiding will fail.
In that scenario, the scheduler needs to come to the rescue, and I trust Wolfgang and Eric's wisdom on those issues.

Hy
3 years 1 week ago #68737

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

  • Posts: 349
  • Thank you received: 107
Maybe add option that if there was no guiding for 5-10 min trigger align?
3 years 1 week ago #68744

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

  • Posts: 27
  • Thank you received: 2
My temporary solution is to use CCDciel instead of Ekos.
2 years 10 months ago #71321

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

  • Posts: 349
  • Thank you received: 107
What if we just run plate solver on each exposed frame and queue realign on next frame if we drift too much from target?
The following user(s) said Thank You: Scott Denning
2 years 9 months ago #72151

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

  • Posts: 1029
  • Thank you received: 301
This thread is still in the pipe for Scheduler changes, but unfortunately don't expect a quick update to the code here. We still have things to fix in CI prior to this.

-Eric
2 years 9 months ago #72242

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

  • Posts: 211
  • Thank you received: 31


So far, the Capture module has satisfied my needs, so I'm a total noob with the scheduler. We are apparently in store for a few passing bands of clouds tonight, so I'd like to give this a go.

Let's say I want to capture a single target for the whole night. I set a capture sequence of 45x60", and put it on "Repeat until terminated" or "until time" and set time for a bit after dawn twilight. In order to get recovery if guiding is lost from clouds, does it make sense to use "Re-schedule errors" with a wait of something like 5 minutes?
When it tries to restart, will it re-focus, then align, then restart guiding or does that full process only happen if it has completed the full 45 exposures?
2 years 9 months ago #72384

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

  • Posts: 1185
  • Thank you received: 370
Definitely, that's exactly the intention behind this feature. I have it set to 2 minutes.There are two types of restarts. If guiding fails, the scheduler tries to restart a couple of times. Only if this fails, it aborts the job. Now the restart feature steps in. If an aborted schedule job is restarted, the starting procedure with focus, align, etc is executed.

I personally do not use initial focusing but use the "refocus after ..." feature of the capture module. When there are problems with clouds etc., it could happen that a job is restarted and focusing fails. Then it could happen that the focus is so off limits that the next focus attempt will fail. For me it seems a robuster strategy focusing after a certain period of time and not at the beginning. At the beginning of a night, I start focusing manually.

HTH
Wolfgang
The following user(s) said Thank You: Scott Denning, Ron DeBry
2 years 9 months ago #72390

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

Time to create page: 1.612 seconds