×

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

Bi-monthly release with minor bug fixes and improvements

INDI, dome control

Move the dome implies action and thus input. It can be WO or RW. I'll add more details to the table later on.

In the dome driver, there is "Active Devices" properties which snoops other drivers, like the mount. So the dome monitors the mount target location and syncs itself accordingly.
Last edit: 7 years 9 months ago by Jasem Mutlaq.
7 years 9 months ago #8980

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

  • Posts: 333
  • Thank you received: 92

Replied by han on topic wINDI, DOME_ABORT_MOTION

Honestly, I find this a weird behaviour. If the dome is facing north or is at at a marker, the operator via client just wants the sync the dome to north or marker. Why would he want snooping between the telescope mount and the dome?. Secondly how to control this process. I can't find any describtion of this. Both drivers need the capability to do snooping and where is the logging going?. How to debug if it doesn't work. How to convert reliable from the equatorial position from the mount to azimuth and maybe in future altitude? You can't trust the mount to provide reliable azimuth or it is not possible and you have to include in the equation four extra parameters, the latitude, longitude, time and time zone which many mounts will not tell you. Also summer time/daylight savings could spoil it. What if you sync the mount, will the dome follow?

I would leave this intelligence to the client & operator and keep the devices simple slaves similar as in Ascom initiative. Note my profession is process control and automation engineer.
Han
Last edit: 7 years 9 months ago by han.
7 years 9 months ago #8985

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

The description is in the link in my last post.
7 years 9 months ago #8986

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

  • Posts: 193
  • Thank you received: 46
It's been a while since I was working with the dome class code, and I expect to be back to it in the very near future, I've been buried in client projects with no time to look at indi lately.

The indi dome class already provides dome synchronization in a manner similar to how the ascom POTH gadget works, ie once configuration is in place, dome slit will automatically track where the telescope is pointed, with all the math to deal with offsets handled transparently under the covers. The setup is contained within the dome specific driver which looks after translating azimuth co-ordinates into hardware specific co-ordinates, be they degrees, tick counts, or what have you. The relationship between 'real world' and hardware co-ordinates is typically handled by the home sensor, and is a one time setup in the dome configuration.

As I mentioned, I haven't been working in this area for a while, but what I do remember, the indi base dome class currently doesn't provide properties for altitude, it treats the slit as an 'open / closed' item. I plan to change that in the not to distant future as the domes we are installing here have the ability to run with partially open shutters and we plan to use that capability.

I haven't started committing code for the NexDome yet, it'll be coming in the near future after we have had a chance to test it all on live operating domes, which aren't fully built yet, but should be over the next couple of weeks, waiting on a contractor to finish a foundation right now, and that project has been delayed by seriously bad weather over the last 10 days.

As for why snooping between telescope and dome, that's done for the exact same reason the ascom folks wrote all the math into POTH. Once the dome is set up and configured for the local installation, any client that can point a telescope will inherit correct dome pointing, without ever having to know about the dome. The dome is slaved to the telescope and the slit will remain in front of the telescope objective as long as it's slaved. This allows for programs that have no knowledge of how to point a dome to still run the telescope and it all 'just works'. FYI, just doing a translation from RA/DEC directly to azimuth will NOT correctly orient a slit dome if the telescope is on a GEM mount. The pointing math under the covers needs to account for all of the mount offsets, which are again, site specific variables. the only one that works correctly in the simple case is a fork mounted system where the attach point to the forks is precisely at the center of the dome sphere, all other configurations require more complex math to correctly orient the slit. I know of no planetarium style programs that incorporate that math for dome slit orientation, hence the need to bury it into the lower layers.
The following user(s) said Thank You: han
7 years 9 months ago #8988

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

  • Posts: 333
  • Thank you received: 92

Replied by han on topic INDI, dome control

Gerryr,

Thanks for sharing this pratical information. Now I see the reason behind. Yes I see the GEM mount will never been in the center of the dome.Especially for a small dome compared to a large telescope. I have to know the offset in mount height from the center of the dome, mount RA, mount DEC, center coordinates of the RA axis, length of declination axis and dome diameter. This becomes rather complicated math (and interface) which will be very rarely used in amateur applications.

Looks like I have to limit in my effort to make a dome slit animation in HNSKY and keep it simple. A few questions:

1) Will I be able to send the telescope azimuth and altitude to the dome and will the dome driver compensate for all extra parameters mentioned above or will it all be included in the telescope & dome driver snoop communciation and the client doesn't need to bother about ?
2) Can I read the corrected azimuth an altitude back from the dome driver to visualize the dome slit with respect of the telescope field of view ?

For 2) it will allow dome visualisation in a planetarium program. :)

Thanks again for sharing this pratical insight and hope to hear more of your pratical experience with dome automation.

Han
Last edit: 7 years 9 months ago by han.
7 years 9 months ago #8992

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

  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI, dome control

Sorry it took so long to get back to you, I've been buried in 'real work' for a while, no time to look at fun stuff.

1) The way it is normally done, you dont send anything to the dome other than open/close commands. Once the dome is open and synchronization is enabled, it will pick up the RA/Dec from the telescope, then do all the translations internally to come up with alt/az, then another math layer to correct from telescope co-ordinates to dome requirements for those co-ords.

2) In the current implementation, I believe the dome only returns azimuth as it assumes a full slit. That will change in the near future as I will introduce altitude properties into the base dome class once I get caught up on real work, and can start working again on this stuff.

For a planetarium program, I'm not sure what you are trying to do with the dome slit information, but, the issue of 'which perspective' does indeed come into play in that case. Take the simple real example, a 2.2 meter dome with an 80cm slit that is stationary. If one is standing in the center of the dome, you see a specific patch of sky thru the slit, but, if you then move to the north wall, you see a totally different patch of sky thru that same stationary slit. So to correctly visualize the slit in a planetarium, it depends entirely on where the viewpoint is based on _inside_ the dome. That's the exact same problem as the dome / telescope orientation problem handled by the dome drivers, but the driver math gets a bit more complex in the case of a GEM mount, because the location of the telescope is changing over time. When pointed in one direction, telescope will be east of the mount (which may not be in the center of the dome to begin with), then after a meridian flip, it will be west of the mount by that same distance. If your planetarium is trying to produce a display as 'seen by the telescope' with regards to the dome slit, it would have to do all the same math, not just to get the azimuth of the dome, but to go a step further and see which patch of sky is visible at the time from the perspective of the telescope.
7 years 8 months ago #9128

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

  • Posts: 333
  • Thank you received: 92

Replied by han on topic INDI, dome control

Gerryr,

Thanks for the feedback. I understand the perspective problem. The math is difficult and will be rarely used so I removed the shutter simulation in my planetarium program. My Indi client is now in it's first incarnation and will focus on that.

Han
7 years 8 months ago #9132

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

Time to create page: 0.856 seconds