×

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

Bi-monthly release with minor bug fixes and improvements

"Dome parking / Telescope parking" policy

  • Posts: 311
  • Thank you received: 42
If changes were to be made to the indi Dome code, having a third telescope option would be useful: ignore wait or block.
Park both dome and mount at the same time or wait on the telescope might depend on what is mounted. With a small refractor I have no collision issue, with an SCT it needs protecting.
3 years 8 months ago #56654

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

  • Posts: 311
  • Thank you received: 42
Wolfgang,

I ran a 2 tests using the scheduler and simulators. Both test were run twice once with the Observatory set to park dome on alert and once with that unchecked. I did not see a difference whether or not the Observatory was involved.

Test 1 the telescope used the "Dome Parks" policy and the dome used the "Ignore Telescope" property. With this combination when the alert was triggered both telescope and roof parked together. So that was the same result as
when the scheduler was not involved.

Test 2 the dome was changed to telescope blocks. With this combination the when the scheduler sensed the alert the telescope started parking and the roof output a warning that it could not park. Same as the none scheduler case, but when the telescope had parked the roof driver output a message indicating a changed of telescope status had been sensed. I then proceeded to park the roof as hoped for.

So using the scheduler along with policy combination worked well to provide whichever behavior was wanted.
Not extensive testing but promising.
The following user(s) said Thank You: Eric
3 years 8 months ago #56693

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

  • Posts: 554
  • Thank you received: 138
You appear to have said "I then proceeded to park the roof as hoped for.". Do you mean that you were watching things and that you clicked on the park dome button to park the dome? Or was there a tiny typo and you intended to say "It then..." meaning that the system parked the roof once the scope was parked with no intervention on your part?

I wouldn't normally nit pick about typos but in this case it could be significant.
Last edit: 3 years 8 months ago by Chris Rowland.
3 years 8 months ago #56694

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

  • Posts: 311
  • Thank you received: 42
Chris,

Sorry about that should read it before posting. Yes it parked the roof after the mount had been parked as part of handling the alert. I kind of expected the Observatory to interfere but it did not seem to make a difference. Only ran once through each combo but hopefully results can be consistenly reproduced.
3 years 8 months ago #56695

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

  • Posts: 554
  • Thank you received: 138
Thanks.
I don't seem to see this behaviour.

Using telescope dome and weather simulators.
Telescope dome policy set to both.
Dome telescope policy set to telescope locks
Dome auto park set to Enable
Ekos Observatory Alert has Park Dome but not close shutter.

setting rain to 10 to trigger alert.
Dome sees this and would like to park but this is inhibited because the telescope is not parked.
Nothing else happens. The scope continues tracking, the dome remains open. The rain continues to pour down on it all.

If I set Close Shutter in the Ekos Observatory then the Observatory reports the alert and 5 seconds later (my delay parameter) the scope starts parking and the shutter starts to close at the same time. In the sim the shutter finishes moving before the scope has finished parking. This doesn't seem safe, while the scope and dome both end up parked the shutter could break the scope before it's finished parking.

I haven't found a way to cause the scope to park and the dome/ror not to move until the scope has completed parking.

Is there some setup that would do that? There are a lot of possibilities, I make it 64 different possible set ups.
3 years 8 months ago #56710

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

  • Posts: 311
  • Thank you received: 42
To clarify, your description is what is seen if, telescope blocks dome is used, and just indi participating. The dome is blocked by the telescope. Wolfgang's request to do a test was to involve the client by using the scheduler's weather alert detection to initiate both telescope and roof parking. Your description did not mention the scheduler.

In my case it is a rolloff roof, so you have the additional complexity of the dome to deal with. Not clear about how the shutter relates to the roof open/close and the dome park/unpark.
3 years 8 months ago #56716

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

  • Posts: 1185
  • Thank you received: 370
Without Scheduler, almost certainly NO. Using the Scheduler, almost certainly YES. You need to check the weather constraint (see my posting above) and select a shutdown procedure with mount and dome checked.

Regarding the synchronization of shutter and dome movement, I would not rely on the Simulator. I'm quite sure that this is manufacturer dependent.
3 years 8 months ago #56724

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

  • Posts: 554
  • Thank you received: 138
I also tried using the RoRSimulator. This doesn't have a shutter, just a roof park property. In that case it is the same as in the first case, with the shutter not set to close. In fact there is no close shutter option in the Ekos Observatory module. The dome/roof park function is inhibited by the telescope dome policy and so the roof can't park and because of this the telescope does not park so the roof can't.

That's how the simulator behaves. A real roof could be made to work by implementing it as a dome. The 'shutter' property would just simulate a shutter but not move anything but its 'movement' would trigger the telescope to park. And when the telescope was parked the dome would close the roof. This only seems to work with Ekos, the observatory seems to see the weather change and closes the shutter, this triggers the telescope park and that triggers the dome park.
3 years 8 months ago #56725

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

  • Posts: 1185
  • Thank you received: 370
I ran a quick test with the scheduler, having dome and telescope set to ignore each other. I changed the weather in the simulator to an alarm state and the following happened:
2020-07-11T10:24:47 Job 'Capella' capture is in progress...
2020-07-11T10:25:32 Caution: weather conditions are in the DANGER zone!
2020-07-11T10:25:32 Starting shutdown procedure due to severe weather.
2020-07-11T10:25:32 Parking mount in progress...
2020-07-11T10:25:56 Mount parked.
2020-07-11T10:25:57 Parking dome...
2020-07-11T10:26:05 Dome parked.
2020-07-11T10:26:07 Shutdown complete.

As you could see, the dome started to park as soon as the mount parking is finished. This was a test completely without the Observatory settings.
3 years 8 months ago #56726

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

I'm actually thinking that this whole discussion highlights that this management of what shutdown first should be completely left out of the drivers. The INDI drivers should be minimal and do their job. Right now, we have communication between drivers that are trying to perform some complex interlocking shutdown procedure. This should be definitely left out to clients to handle in my opinion. Maybe the whole thing should be removed from INDI drivers.

Nevertheless, there is ONE specific drivers that's whole purpose is to protect these drivers, it's the Watchdog driver. Currently, the watchdog driver performs a complete shutdown if it loses connection with the client. I suppose this driver can be extended to snoop weather data as well. This way, you don't really have to use Ekos (if you want to) to perform shutdown and just let the watchdog driver handles it for it. It would remove all the complex interlocking scenarios we have to account for. Such options could be left out the clients, whether that client in INDI Watchdog driver, or Ekos or CCDCiel ...etc.
The following user(s) said Thank You: Eric
3 years 8 months ago #56740

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

  • Posts: 554
  • Thank you received: 138
I see your point but isn't the whole Indi snoop system designed to allow drivers to interact at the driver level? This seems to be useful for interactions such as telescope/dome synchronising.

Responding to weather also seems to be in this category because it is the sort of thing that should be running all the time, regardless of what applications are running.

What we have at present seems to be partially implemented in indi, and partially implemented in the Ekos Observatory and Scheduler modules. This is where I think it has difficulties. It is difficult to know where and how to set it up. It also seems only to be fully active when a sheduler task is running.

What we have in the drivers at the moment seems close. but what I'd do is make each driver only responsible for actions to it's own hardware, something like this:
The Dome driver snoops on weather and telescope and has a dome policy property which specifies when the dome/roof can be parked. This manages the dome parking depending on the snooped states of the weather and telescope.
The Telescope driver snoops on the weather and dome. The only property is needs is a boolean to say if it must park when the weather is bad. It doesn't need to wait for anything. When the weather reports bad it parks.
The Weather driver handles generating the warnings and alerts. If delays to prevent false alerts because of transient events are reuired these are implemented here because this driver is aware of the weather properties it is monitoring. For example it may want to delay because of a cloud event but definitely not if it starts raining.
That's it.
When a weather alert is raised the telescope sees this and parks. The dome/roof also sees this. It can close immediately if its policy allows or it will wait until the telescope is parked as well before parking.

Ekos need not be involved at all although there's noting to stop it handling things for itself, in particular the routine close down at the end of a session.

The main change seems to be to add weather snooping to the telescope and the associated telescope park if the weather is unsafe. The dome driver may not need changing at all.

Not sure how Jasem's watchdog driver should be involved, it seems to be a combination of a driver and a client. When it's trigggered it sends park commands to the drivers. It could have weather snooping added, becoming a fourth way to manage shut down.
The following user(s) said Thank You: Jasem Mutlaq
3 years 8 months ago #56743

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

I am working now on the updated Watchdog driver, which is indeed driver/client combination. I believe with this driver, it removes the whole orchestration complexity required for this shutdown procedure due to weather. I will share the driver once done.
3 years 8 months ago #56744

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

Time to create page: 1.312 seconds