×

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

Bi-monthly release with minor bug fixes and improvements

Partitioning the Scheduler code

  • Posts: 85
  • Thank you received: 40
I found that some weather related code blobs were commented-out, or completely missing (checkWeather() no longer exists).

That will be part of this scheduler repartitioning project. Not something we could do today like hopefully re-enabling what is there to shut down an observatory on bad weather.

-- Hans
4 years 10 months ago #38874

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

Great thanks!

I just pushed a commit that fixes the scheduler shutdown due to severe weather bug. Now I tested it and it works OK. I plan to release a maintenance KStars release (v3.2.2) this weekend and I think after that we'll start merging any scheduler partitioning work for the next release.
The following user(s) said Thank You: Wolfgang Reissenberger
4 years 10 months ago #38875

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

  • Posts: 1185
  • Thank you received: 370
Hi Jasem,
looks good, my tests with the simulator went fine. But it's not so easy to understand, how it works. Maybe this is another candidate for isolation.
- Wolfgang
4 years 10 months ago #38882

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

  • Posts: 1029
  • Thank you received: 301
From what I see, we should probably separate the observatory management from the Scheduler. That new tab with a shiny obsy icon would:

- Take care of running customized scripts, eventually simplify what was requested last year in terms of ssh access to external raspberries to control electricity.
- Control dome unparking and parking, eventually mount parking too (that's at the bottom of Scheduler currently).
- Report possible manual interactions inside the observatory (for observation logging purpose, or handle a panic button).
- Manage the CCD temperature in a less weird way as now (temperature setting is in capture, warmup is in scheduler).
- Manage and consolidate reports from weather devices (safety of course, and also outside temperature having an effect on CCD temperature).
- And there could be a good place for monitoring cameras too (controlled by INDI drivers of course) and observatory security as was discussed in the past.

To me it makes sense to at least move the whole "Ekos init/shutdown", that is, dome/mount parking, out of the scheduler to a new tab, thus to a new independent module.
That module should have the same status reporting as other modules, and Scheduler should handle interruptions just like Capture handles deviations from Guide.

If someone is up to this task, we could move code out. But we should probably define "good practices" so that all modules are structured more or less the same.
The following user(s) said Thank You: Hans, Wolfgang Reissenberger
4 years 10 months ago #38884

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

  • Posts: 1029
  • Thank you received: 301
(I separate this post from the previous one to mark the digression)

We need to confirm what is the role of Scheduler: currently it is the top-level controller of automated observation.
If we continue this way, on one hand other modules must be "slave" modules, and in return Scheduler must guarantee perfect robustness (yeah tests I see you).
When not being automated, "slave" modules are simply providing their capabilities through their UI.
Having a clearer and simpler header interface that doesn't involve UI will certainly help testing (UI testing is inherently hard).

To me the design of Ekos, and of the Scheduler in particular, is really neat.
Well, it is too much flexible for its own good, but the planning, the execution and the recovery, and the exchanges with other modules, make sense.
Obviously it should be modularized even more to ease maintenance, as we see in the case of the Scheduler.

Also there's something I want to discuss later on: INDI connection, as that could be separated too. But I just edited out that (further) digressing paragraph in my post, we'll see to this later.
The following user(s) said Thank You: Derek, Hans
4 years 10 months ago #38885

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

  • Posts: 1185
  • Thank you received: 370
Good point, Eric!
From my perspective, the Scheduler remains the top level controller, even if we separate for example the observatory management. All these other modules should work on their own with the Scheduler orchestrating them.

Maybe we should think the Scheduler in a more modular way. Currently, it is a set of capture sequences with a complicated set of additional attributes for focusing, guiding, etc. What about if it is see it more as a collaborative model with a capture sequence in the center surrounded by the modules that communicate.

An example that I have in mind is the way, how the mount handles meanwhile the meridian flip. It requests control from the capture module, executes the meridian flip and hands it back to the capture module. In the same way, we could for example execute regular focussing or alignment.

- Wolfgang
4 years 10 months ago #38886

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

  • Posts: 85
  • Thank you received: 40
In my opinion a weather/safety tab need to be able to guarantee safety, and thus stop or pause the scheduler (and park stuff) when conditions are not safe. As such it is the top level controller.
Safety includes manual sessions where the scheduler is not even used. When someone just manually uses the other tabs to open the observatory, point the telescope, etc.

-- Hans
4 years 10 months ago #38887

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

  • Posts: 1185
  • Thank you received: 370
I fully agree, that a safety relevant events need to force the scheduler to execute a controlled shutdown. With "top level" I meant, that the Scheduler is the orchestrator of everything and as such being the center for automation inside of EKOS. All modules communicate with the other modules with signals, where some signals might have top priority - like safety events.

- Wolfgang
The following user(s) said Thank You: Hans
4 years 10 months ago #38888

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

  • Posts: 554
  • Thank you received: 138
If I had a truly remote observatory I'd have a system to make the observatory safe that was totally independent of as much as possible. It would monitor safety things, such as heavy cloud, rain, wind, and, not least, power. When things were unsafe it would close the observatory. It should be possible to do this regardless of the position of the scope.

I would try to keep the imaging system informed of what is going on but if it continued to take images of the observatory ceiling, so be it.

I would not build it into the scheduler because one of the unsafe conditions is the scheduler or Ekos crashing.

This coud be a bit extreme for most applications where a system crash and the observatory being left open until it can be reset isn't a disaster but even with a portable scope on the patio I've had a few occasions where it got rained on.
4 years 10 months ago #38890

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

  • Posts: 1029
  • Thank you received: 301
From these posts, I understand that while Scheduler is the top-level controller orchestrating things, the observatory controller must be able to decide by itself when there is a security or safety issue.

To me that's a perfectly viable strategy: let's have the Scheduler request the Observatory (see now I use capitals for modules) to startup and open the roof, and the Observatory notify the Scheduler that it does not want to or is shutting abruptly down because of unsafe observing conditions. Orchestrator does not imply ruler. And if Observatory manages mount parking, it should be able to overcome situations were parking space is limited or requires a particular sequence.

I also consider the independence of safety controllers with Ekos to be a great point. But we have a watchdog INDI driver, we must use that.
Ekos crashes? Watchdog makes sure the fallback scenario secures the observatory. There's no point in continuing to observe if there is no more observer.
In this situation, Ekos can still be the one checking the weather to decide to terminate the observation, knowing that the crash scenario will terminate the observation anyway.

(side note: we should probably discuss the concept of redundant INDI servers some day)

That, obviously, does not prevent anyone from building an independent system to ensure the safety of the observatory.
Thus, the Observatory module should either be the controller, or delegate the control to the external system and translate its notifications to Scheduler.
We already sort of have the case with the various guiders supported, although those guiders all have a different interface.

-Eric
4 years 10 months ago #38913

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

  • Posts: 456
  • Thank you received: 76
For protection of ekos and kstars crashes ,there is the existing watchdog driver. This works well, I have experience once for my remote observatory when kstars crashed. It parked the scope, roof and ran a script to send me an SMS. All worked perfect.
Derek
4 years 10 months ago #38914

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

  • Posts: 554
  • Thank you received: 138
Where is the existing watchdog driver defined? I've looked and can't see any mention of it in any of the INDI standard definitions.

Chris
4 years 10 months ago #38920

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

Time to create page: 0.949 seconds