×

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

Bi-monthly release with minor bug fixes and improvements

INDI, dome control


I'm not sure I understand. You use REL_DOME_POSITION to manually move the dome "relatively". If you want the dome to auto sync, you enable slaving.
7 years 9 months ago #8955

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

The idea is that the client controls both the telescope and dome. Then there is no need of a direct link between the telescope and the dome. A problem could occur when the dome has an offset while following the telescope. I can sync the telescope but I can't sync the dome using INDI. So I'm missing two commands compared with ascom:

1) SyncToAzimuth, Synchronize the current position of the dome to the given azimuth.
2) SlewToAltitude , Slew the dome to the given altitude position.

Here a small piece of history from ASCOM webpage:

The Dome Interface Standard
Also during 2002 and 2003, discussion began toward a dome control driver interface. Robotic control of telescopes enclosed in a dome clearly needed to be tied to the dome rotation, and control of the dome shutter(s) was clearly needed for weather safety during automated operation. A rather large group of people became involved in discussing the dome interface, and the discussion became contentious at times. The goal of eliminating device-specifics from the interface appeared out of reach given the variety of "shutter" configurations in use. An elegant solution was finally reached by including both azimuth and altitude inputs for shutter positioning, leaving the dome controller to simply "make a hole big enough to see through". The standard was finally adopted in August 2003.

I think it will be elegant and pratical for the INDI standard to follow the ascom methods for interchangebility. Will also help in adaptation.

I don't see how the AUTOSYNC_THRESHOLD could solve an offset in azimuth

Han

Later more seems missing:
INDI: PARK Park the telescope to HOME position, UNPARK Unpark the telescope

Home is celestial north or south. However I'm missing a SetPark commando as:

ASCOM: 3) SetPark, Sets the telescope Park position to the current telescope position.
Last edit: 7 years 9 months ago by han.
7 years 9 months ago #8956

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

Regarding parking, there were a couple of undocumented properties I added to the Telescope Standard Properties list. Regarding the dome, the dome already monitors the mount motion and syncs itself. The client can manually sync the dome to a specific azimuth if desired. The autosync threshold is the minimum diff in azimuth that would trigger a dome motion.
7 years 9 months ago #8957

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


I noted I can read the dome absolute position however it is not clearly indicated in the standard properties.
Can you share these undocumented features? I like to sync the dome.


I have still problems with Kubuntu in Vmware, so testing is cumbersome till I have the indi_simulator_dome working in a other Linux version. See
www.indilib.org/forum/general/1324-indi-...-windi.html?start=30

Han
7 years 9 months ago #8963

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

It is clearly mentioned in the standard properties in the Dome Standard Properties . Use ABS_DOME_POSITION

Regarding INDI, as an end-user, you don't need to compile anything. Either install libindi1 from the Software Center in the OS you're using , or from the command line:
sudo apt-add-respository ppa:mutlaqja/ppa
sudo apt-get update && sudo apt-get install indi-full

You only need to compile stuff if you need to develop INDI drivers.
7 years 9 months ago #8972

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


This is documented in the standard properties:
ABS_DOME_POSITION, DOME_ABSOLUTE_POSITION, Move dome to DOME_ABSOLUTE_POSITION absolute azimuth angle in degrees.

Where does it say that you can read the value DOME_ABSOLUTE_POSITION. i would expect a column telling me this value can be written and read. I would expect that for all variables unless it valid for all.

Sorry I'm totally lost here. How can the dome monitor the mount??? To sync the dome, the dome needs a new position and a sync instruction from the operator&client. For me the telescope synchronisation is understandable but not for the dome. Why not simple apply the same describtion and command as for the telescope?

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

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

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.

Time to create page: 1.143 seconds