×

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: 278
  • Thank you received: 17
How great that you are testing this, thanks from my telescope and me !!! And cool observatory :-)

Is there an option in ekos or indi to e.g. send an email or run a shell script if the parking fails ( your 1) ) ? If not, then consider this a feature request :-)
The following user(s) said Thank You: Gilles Gagnon
3 years 10 months ago #53278

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

  • Posts: 294
  • Thank you received: 54
Thanks.

Fortunately I can do all those tests without destroying anything, which I almost did when I tested the roof closure with the scope in the 'home' position. I hope they will provide useful information.
Last edit: 3 years 10 months ago by Gilles Gagnon.
3 years 10 months ago #53287

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

Can you please create an issue for this in Github? I'm thinking we might fund this issue via IssueHunt and see if anyone steps in to fix it.
3 years 8 months ago #56387

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

  • Posts: 294
  • Thank you received: 54
As, among other things, I needed to implement fail safe features to my observatory (close call), I am (very) late with the testing of the dome and telescope parking policies which I need to finish. Sorry about that.

I can look into adding the issue to the IssueHunt to attract interest into solving the problem, hoping that it can be a rapid fix to what can be an hazardous situation, for the equipment.
3 years 8 months ago #56423

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

  • Posts: 250
  • Thank you received: 3
Sorry I got the wrong post for my answer.
Last edit: 3 years 8 months ago by Porchet.
3 years 8 months ago #56556

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

  • Posts: 2247
  • Thank you received: 223
Someone point me in the right direction of the drivers please, or code responsible for the parking. I am no coder but I can ask a friend and/or see if I can find something odd.
3 years 8 months ago #56569

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

  • Posts: 311
  • Thank you received: 42
Just took a look on the Dome side it seems like the implementation is in indidome.cpp Dome::ISSnoopDevice
Expect there will be something similar on the Telescope side. First glance it might not be so much a bug as a not implemented as assumed. Needs someone familiar enough with the code in depth to be able to make a relatively quick modification. Or time to study the interactions and use cases to not screw up actual Domes expected behavior with side effects.

Looking at it from an external view based on the work with the test cases. Can the desired behavior be described. And are any additional property values or snooping options needed to describe the rules.
3 years 8 months ago #56570

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

  • Posts: 294
  • Thank you received: 54
From what I remember when I looked at the code, there are 2 file sets (.h and .cpp) to look into. As 'wotalota' mentionned, there is "indidome.h and .cpp", as well as "inditelescope.h and .cpp", in the ".../libindi/libs/indibase/" directory, on the mount side. I could not find the way policies are executed in those files or how the park messages are passed to one another, or from another driver (e.g. weather related).

Logically, if a dome/roof park command is issued (from user or weather station), the driver should make sure that the mount is parked before parking and if not, a park command shall be issued to the mount and completed before the dome/roof is closed. From what 'Gonzothegreat' and me have observed, it seems that the order is not respected.

As I mentionned in another related thread, I unfortunately do not have the expertise to dig into the problem efficiently and come up with a solution quickly but I would hope the solution is not too far away.

Thanks for everybody's input and help.
3 years 8 months ago #56573

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

  • Posts: 311
  • Thank you received: 42
Need to test again to see that the roof respects "telescope blocks" and "auto park disable" settings. It might be that the roof could benefit from a "wait to park on the telescope being parked" option. If so that seems doable. I think the next thing to look at is the telescope snoop code. It will probably be getting information from the roof. Does it receive enough information from the roof to determine a weather alert is in effect and/or the roof would really like to close but can not until it gets itself parked. If its rule settings allow why does it not respect the "Dome parks" setting. When that is sorted then go back to the roof and make sure there is a mechanism to determine that the telescope is now parked and it can continue.
The caution comes from this being at a level above the individual mount and dome driver so any changes will possibly impact all telescope and roof characteristics.


Unless something else moves us along, I think I'll investigate along these lines and see how far I can get with this particular use-case.
Last edit: 3 years 8 months ago by wotalota.
3 years 8 months ago #56575

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

Please note that drivers cannot command other drivers. Each driver can snoop the properties of others drivers and act accordingly. So the dome/roof driver cannot tell the mount to park. One way to make this happens would maybe to use the state of the TelescopeClosedLockTP property. The mount driver can be set to listen to the dome TelescopeClosedLockTP property, and if that property is set to IPS_BUSY for example, it should signal the mount driver to begin parking process. That's one way of approaching this. Another would be to use another new property to snoop on. The mount needs to know that parking is required.

However, doesn't Ekos observatory module park mount then parks dome when weather is ALERT?
3 years 8 months ago #56586

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

  • Posts: 294
  • Thank you received: 54
Thanks for the clarification and for correcting my comment re: use of 'command' instead of 'snoop'.

So, if I get it correctly, mount and dome/roof should snoop on one another to make sure no action is taken that could create a dangerous situation. Could we use a "Collision Avoidance" snoop property that could be set for roofs (or domes) that do not have the appropriate clearance to park without problem? This could help set the correct sequence of events when unparking/parking.
3 years 8 months ago #56588

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

  • Posts: 1185
  • Thank you received: 370
Nope, the Observatory does not take care of the mount currently. I already have the UI controls in place, but the functionality is not present yet.

If I remember well, the two of us discussed it whether parking of the telescope make sense to add this to the Observatory. The decision was that we should leave it to the Scheduler. But I might be wrong...

I did the tests for the two scenarios with simulators for dome and telescope. From what I see is that the only option that makes trouble is the scope option "dome parks". It works in principle, but as already mentioned in this thread, the dome does not wait with parking until the scope is parked and is parking in parallel. That is a risky behaviour, I fully agree.

But all the other combinations seem to work as designed, but I fully agree, not all combinations make sense.

We could add two actions to the Observatory:
  • Shutdown Scheduler
  • Park mount
But here we have the old problem, that part of the users use the Scheduler, others don't. For those not using the Scheduler, it would be straight forward that the Observatory parks the mount. But those using the Scheduler I think would prefer if the Scheduler controls the Observatory and not vice versa - which as far as I remember is already working for the weather alerts.

Implementing this behaviour in the Observatory should not be that complicated - as soon as we not how we want to have it.

Wolfgang
p.s.: I've attached a spreadsheet with my test cases I've been talking of.

File Attachment:

File Name: parking_te...xlsx.zip
File Size:8 KB
3 years 8 months ago #56589
Attachments:

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

Time to create page: 0.716 seconds