×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Greedy scheduler is very unreliable for me

  • Posts: 96
  • Thank you received: 25
I've been fighting with the scheduler for the last few days and I haven't been able to get it to properly start some low priority jobs of escalating priority until it gets to the real business, eg. gather on M8 until C27 comes out from behind the trees, switch to C27 for a while, and once 56Cyg clears the obstructions, go there until the sun comes up.

I created a few sequences M8, C27, Pelican Nebula. I tried to get M8 to start automatically at nautical twilight as well as a specific time... it didn't.
It's not at all clear how to get the scheduler to just keep retrying. On both Friday and Saturday night the scheduler stopped inexplicably after a few photos. Why?
Occasionally it gets cloudy for a few hours... I don't care. How do I get the guider to just keep trying to reacquire, possibly with some realignment if necessary, until the sun comes up?
Also the time selector is a annoying. It won't let me just hit backspace a few times to delete past the colon.

What's wrong with this config?
Last edit: 1 year 9 months ago by Chris Kuethe. Reason: additional detail about my schedule
1 year 9 months ago #84669

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

  • Posts: 1224
  • Thank you received: 566
It is difficult to debug without a log file, and without knowing roughly where you are located (which I guess is in your log file). Please send a log and I'll look further if the below doesn't clear things up.

I could see a few things, though:

- The greedy scheduler does not use the priority numbers (please note it is greyed out when you select greedy, sorry if this was not made clear, if/when the classic algorithm is removed, the priority box will be removed as well). The priorities for Greedy are simply the order they are given in the table (i.e. first row is highest priority). So, given your .esl file, the highest priority is pelican, and next is NGC6888/C27, and last priority is M8. Yet, you entered the priority numbers the opposite way (probably you entered them while you were in Classic Scheduler mode, since you can't enter them in Greedy). I guess your idea of the priorities was exactly opposite of what the Greedy scheduler was using.

- For my geography and for today, the start-at time for m8 is before the twilight restriction, so that job fails the twilight test and won't be scheduled. Note, you can change the twilight restriction in KStars Settings -> Ekos -> Scheduler --> dusk offset. I can't tell if you changed that or not.

- For your jobs in my geography (west coast USA) and starting it up before sunset, it should first attempt pelican (because the highest priority Pelican has a start-at of 22:46, then switch to Pelican at 22:46 and run on that for the rest of the night (as pelican has 96 4-minute exposures scheduled).

- My recommendation would be to not use start-at times, but simply use startup condition ASAP, and if you want to try and control start times for obstructions, use altitude, or better, make yourself an artificial horizon.

Hy
1 year 9 months ago #84680

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

  • Posts: 96
  • Thank you received: 25
You're correct that I'm on the west coast of North America, not far from San Francisco.

I did define priorities when I was setting up the schedule in classic mode, and observed that those were grayed out in greedy mode which is fine. I've been experimenting with it. I also saw the attached output from the scheduler so I could see start/stop times being recomputed as I adjusted my criteria (eg. number of captures, start time, ...)

I did try ASAP as the scheduler start time, which was one of the cases that failed this weekend: Start with M8 at nautical night, and switch to the pelican nebula when it gets late enough... Unfortunately I got one exposure on pelican, and then the scheduler shut down without any clear explanation.

My local horizon is quite the mess, which is why I'm trying to be a little bit lazy and just using time-based scheduling. My horizon isn't symmetrical either, so constraining a job to elevation alone doesn't work - it would be nice to be able to specify start and end elevations separately. Additional laziness, I just went with 96 exposures since it seems like a nice number. I know that the sequence won't complete, and there's a good chance that the first and last few exposures might be throwaways: trees, neighbor's barbecues, getting a little too close to sunset/sunrise - those are all fine. I'd rather throw out a few exposures in the morning because they're poor quality than miss any potential imaging time.

The startup script handler has some rather undesirable behavior: it won't run the startup script if ekos is already running. It'd be nice if there was a way to just dismiss or ignore any prompts after a bit. In my world there is never a time where it's better to block waiting for filter confirmation than it is to just take pictures.
1 year 9 months ago #84722
Attachments:

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

  • Posts: 1224
  • Thank you received: 566
You seem like a perfect candidate for a Terrain Background and Artificial Horizon
indilib.org/forum/ekos/9035-new-feature-...grounds.html?start=0

If you set that up and click the artificial horizon scheduling options, then the scheduler respects that and avoids shooting targets when they're blocked.

Also, I've sent you a forum private message.

Hy
The following user(s) said Thank You: Chris Kuethe
1 year 9 months ago #84726

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

Time to create page: 0.200 seconds