×

INDI Library v1.9.1 Released (26 Jun 2021)

Bi-monthly INDI Library v1.9.1 is released bringing a few new drivers and improvements to existing drivers.

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.
11 months 1 day ago #59089

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

  • Posts: 731
  • Thank you received: 56
No.
kubuntu 20.04
700d, eq6, t7m
Last edit: 11 months 1 day ago by alacant.
11 months 1 day ago #59090

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

  • Posts: 585
  • Thank you received: 279
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
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser
ZWO ASI1600, OAG & Filterwheel, Astronomik Filters, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on RPi4 w/SSD
Ekos Projects: Terrain Backgrounds, Polar Alignment, Analyze, Linear Focuser, SEP MultiStar & GPG Guiding, FITS autostretch.
11 months 1 day ago #59120

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

  • Posts: 731
  • Thank you received: 56
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
kubuntu 20.04
700d, eq6, t7m
11 months 1 day ago #59123

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

  • Posts: 25
  • Thank you received: 1
Any good news on this topic ?.
4 months 2 weeks ago #68698

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

  • Posts: 585
  • Thank you received: 279
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
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser
ZWO ASI1600, OAG & Filterwheel, Astronomik Filters, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on RPi4 w/SSD
Ekos Projects: Terrain Backgrounds, Polar Alignment, Analyze, Linear Focuser, SEP MultiStar & GPG Guiding, FITS autostretch.
4 months 2 weeks ago #68737

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

  • Posts: 61
  • Thank you received: 10
Maybe add option that if there was no guiding for 5-10 min trigger align?
4 months 2 weeks ago #68744

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

  • Posts: 25
  • Thank you received: 1
My temporary solution is to use CCDciel instead of Ekos.
2 months 2 weeks ago #71321

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

  • Posts: 61
  • Thank you received: 10
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
1 month 3 weeks ago #72151

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

  • Posts: 1008
  • Thank you received: 297
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
HEQ5-Pro - Atik 314E - Orion ED80T - DMK21 on Orion 50mm
DIY 3D-printed Moonlite and FWheel RGB/LPR
KStars and indiserver on two Atom 1.6GHz 1GB RAM Linux, VPN remote access
1 month 2 weeks ago #72242

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

  • Posts: 55
  • Thank you received: 10


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?
1 month 1 week ago #72384

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

  • Posts: 758
  • Thank you received: 216
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
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | Moravian G2-8300 + ASI 1600mm pro | KStars/INDI on Raspberry Pi 4 with Raspbian 10
The following user(s) said Thank You: Scott Denning, Ron DeBry
1 month 1 week ago #72390

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

Time to create page: 1.037 seconds