×

INDI Library v1.9.2 Released (14 Sep 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones.

Partitioning the Scheduler code

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.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
The following user(s) said Thank You: Wolfgang Reissenberger
2 years 4 months ago #38875

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

  • Posts: 841
  • Thank you received: 252
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
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC with Raspbian 10
2 years 4 months ago #38882

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

  • Posts: 1008
  • Thank you received: 297
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.
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
The following user(s) said Thank You: Hans, Wolfgang Reissenberger
2 years 4 months ago #38884

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

  • Posts: 1008
  • Thank you received: 297
(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.
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
The following user(s) said Thank You: Derek, Hans
2 years 4 months ago #38885

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

  • Posts: 841
  • Thank you received: 252
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
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC with Raspbian 10
2 years 4 months ago #38886

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

  • Posts: 69
  • Thank you received: 32
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
2 years 4 months ago #38887

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

  • Posts: 841
  • Thank you received: 252
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
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC with Raspbian 10
The following user(s) said Thank You: Hans
2 years 4 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.
2 years 4 months ago #38890

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

  • Posts: 1008
  • Thank you received: 297
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
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
2 years 4 months ago #38913

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

  • Posts: 403
  • Thank you received: 73
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
Celestron C11 iOptron CEM120 Atik 383L
HP8300 Elite i5 running Xubuntu, Indi, Kstars & Ekos
Roll off roof observatory
Battling Irish weather
github.com/dokeeffe
twitter.com/BallyhouraStars
2 years 4 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
2 years 4 months ago #38920

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

  • Posts: 1008
  • Thank you received: 297
The code lives in the auxiliary folder.

-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
The following user(s) said Thank You: Chris Rowland
2 years 4 months ago #38927

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

Time to create page: 2.628 seconds