×

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

Bi-monthly release with minor bug fixes and improvements

New EKOS Observatory module

  • Posts: 34
  • Thank you received: 9
There is clearoutside.com that provides global weather forecast that could be embedded in web pages or apps.

Sebastien
4 years 10 months ago #39425

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

  • Posts: 1185
  • Thank you received: 370
Here comes the next iteration: I implemented a simple status model of the observatory:



- Wolfgang
The following user(s) said Thank You: Ferrante Enriques
4 years 10 months ago #39438
Attachments:

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

  • Posts: 554
  • Thank you received: 138
Just a thought, the way I've thought about the observtory status is with two states, safe to Observe and safe to Open.

Safe to Observe controls the imaging and this is designed to pause imaging if something happens to make imaging impractical, such as a patch of cloud. The observatory would stay open, the camera cool, the scope tracking etc., while it waited. when this becomes true the system can quickly resume the observing process.

Safe to Open controls the observatory safety, the observatory could stay open through thin cloud but close for heavy cloud. This could warm the camera, park the scope and close/park the observatory.

HTH
Chris
4 years 10 months ago #39443

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

  • Posts: 1185
  • Thank you received: 370
Good point, but not that easy, because safety has two aspects. From the observatory perspective, it means that the weather is appropriate. From the imaging perspective it means additionally, that the dome is unparked, the shutter is open etc.

This is also the problem with the readiness I just introduced. Technically, the observatory is ready as soon the mechanics are in place. From the imaging perspective, weather is also an aspect.

Any ideas, what the right definition is?

- Wolfgang
4 years 10 months ago #39450

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

  • Posts: 249
  • Thank you received: 62
hi Wolfgang,
I was wondering if the observatory status is useful also as a command to activate the whole observatory.
For RoR, it is redundant, they already have unpark to get the same result.
For domes, it could be dangerous to issue two commands (open shutter and unpark) at the same time. Actually would be more dangerous to do the opposite: close shutter and park.

I would leave the observatory status issuing no action, just showing the status. Any action should be managed by a more complete procedure that is customizable. Like: first unpark dome, wait 10sec, open shutter.
Again, this approach would make more sense in case of a shutdown than wake up.

Ferrante
The following user(s) said Thank You: Wolfgang Reissenberger
4 years 9 months ago #39640

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

  • Posts: 1185
  • Thank you received: 370
Hi Ferrante,
thanks for the feedback, I deactivated the button.
- Wolfgang
4 years 9 months ago #39658

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

  • Posts: 1185
  • Thank you received: 370
As a next step I would like to link the Scheduler module by status events to the Observatory. What do you think about the following behavior:
  • OK --> WARNING: Let the Scheduler pause, i.e. complete a running capture and then suspend
  • OK/WARNING --> ALERT: Shutdown
  • ALERT --> WARNING: Start
  • WARNING --> OK: Resume paused schedule
The following user(s) said Thank You: Ferrante Enriques
Last edit: 4 years 9 months ago by Wolfgang Reissenberger.
4 years 9 months ago #39670

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

  • Posts: 249
  • Thank you received: 62
hi Wolfgang,
to me it makes sense.
I'm thinking of a use case where the weather gets bad (warning) and the sequence is stopped and the shutter is closed but the cooler still on and mount not parked. If the weather gets worse (Alert / danger/*) mount is parked, camera warmed up and INDI stopped.

Are you thinking to place the logic (the steps) for suspend / resume and shutdown / start up in the Observatory on in the Scheduler? as you know i'm in favor of the Observatory because it could be used even if one is not using the Scheduler. For example if a standalone Capture is running.

* somewhere else in INDI / Ekos it has been used 'Danger' or other words instead of 'Alert' (e.g. in Weather interface). I think any word is fine but it should be kept the same all over the place.

ferrante
4 years 9 months ago #39680

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

  • Posts: 1185
  • Thank you received: 370
Yepp, exactly. At least is that the target picture. Technically, I am thinking of an acknowledgment mechanism, i.e. the Observatory sends out for example a "WARNING" and waits with its actions until it get's an acknowledgement back from the Scheduler (or maybe also the Capture module and even the Mount module).

Sounds reasonable, but I think it needs some further investigation. If we add both to the Observatory and the Scheduler the ability to define and run sequences, it might become confusing for the user. Currently Eric and I discussing this here .

- Wolfgang
4 years 9 months ago #39681

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

  • Posts: 554
  • Thank you received: 138
One thing to bear in mind is that in the warning state, where imaging is suspended but the mount continues tracking, it may not be possible to close the shutter if this is the roof of a roll off roof observatory. The roof would only be closed after the mount has been parked and that would be done when the system enters the ALERT state.
This would probably need to be configured by the user on a case by case basis.

Similarly for going from ALERT --> WARNING, some observatories will need to open the roof before unparking the telescope and slewing to the object.

Chris
4 years 9 months ago #39682

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

  • Posts: 1185
  • Thank you received: 370
That's exactly the point, observatories are far more diverse as mounts and CCDs and have to be configured individually. The question for me is, what is the common denominator and what is an appropriate way to define the individual breakout points.

Would it make sense to add warning and alert scripts instead of simply triggering actions to the dome or the shutter?

- Wolfgang
4 years 9 months ago #39685

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

  • Posts: 554
  • Thank you received: 138
I'd be uneasy about just having a script for each state change because that's abdicating the development to the user. Most use cases can be met with a few options such as specifying the priority for scope park and Roof/shutter close.
But having a script option for complex systems is a good idea.
4 years 9 months ago #39686

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

Time to create page: 0.732 seconds