Just wondering if anyone has experience using KStars/Ekos to run a remote observatory automatically? Remote here meaning many hours traveling away. And automatic as in load a series of targets in the scheduler and let the system start/stop automatically each night, handle emergency stops etc.
If so, what were reasons to choose KStars/Ekos over usual suspects such as Voyager, Prism, NINA, etc.?

KStars/Ekos has been at the heart of my imaging for many years, including the occasional use of the scheduler. But so far always just meters away from the rig, just in case....

Yeah, been there done that

Fully automated and remotely with Ekos and a couple of smart power plugs.

Probably it would be better if you have any specific question about the whole project that we could help, cause there are many and different parameters and needs for anyone.

Thanks Euripides, great to hear you have used it successfully. Main background of my post was to gather experiences from users that are actually using KStars for robotic imaging. Do people use it that way, and if so, what do they like and what would they like to see different. As I will setup a rig in a remote hosting observatory, should I keep using KStars, or better looking for an alternative?

Some areas of concern that I would have right now are:

Reliability. How often did you experience interruptions, due to failed autofocus routines, crashes of a driver, or the whole app, updates, etc. In my current non-remote setting, all these happen from time to time, but as I’m usually following what’s happening, I can often quickly correct and move on. But in the planned robotic setting, I may not look at it for a couple of days, so if something goes wrong on day 1, that would be a lot of imaging time lost.

Robotic scheduling. What is your experience with the scheduler? How well does it work in ‘robotic’ mode, so run startup activities lets say an hour before dawn, switching equipment on using dragonfly, start imaging at Astronomical night, image from a list of targets, figuring out priority based on visibility, moon distance, distance around meridian, % completion, manually set importance, etc., and switch equipment back off in the morning and go to sleep until the following evening. I am not a programmer, so writing scripts would not be an option for me.

Are you still operating remotely? And still with KStars?

Many thanks for your thoughts.

Willem Jan.

Willem Jan,
I've been using EKOS since 2016 fully remote. The observatory is about 50min drive from where I live.
ballyhouraobservatory.github.io/

I can give you my experience of remote observing with EKOS for the last few years as well as answer your questions from my point of view.

Reliability. How often did you experience interruptions, due to.....
For me, this depended on equipment more than INDI/EKOS. I used to have a cheap celestron mount but in 2019 I bought an iOptron CEM120 and its very very reliable and rock solid. Also my home-made focuser was unreliable at the start but its good now. On the INDI/EKOS side. One thing that caused reliability problems was doing updates. Now I *never* do updates if the sky is going to be clear. I only update indi/kstars on days where I can retest during the day (all remotely again). Updating has caused me some pain and lost time when I did an update in the evening before a clear sky. Recently, I don't update kstars for maybe 6 or 9 months. I use a desktop PC to run Kstars and everything is plugged into that. It was a cheap second-hand office PC that I wiped and installed Ubuntu on. I think a desktop may be more reliable than a small SBC like a raspberry PI but I can't say for sure. I just went with an x86 desktop because I knew it would be cheap and reliable.

Robotic scheduling. What is your experience with the scheduler? How well does it work in ‘robotic’ mode,

I am pretty happy with the scheduler. I use my scope to do photometry of variable stars and have a script that downloads the observing alerts and objects that need observation from AAVSO. This generates a schedule file for the scheduler. The schedule may have 20 or 30 targets in it. Depending on weather I can usually get to collect data on close to 20 targets a night.
My workflow with the EKOS and the scheduler is as follows
1) I ssh into a raspberry PI which is running 24/7 in the observatory.
2) I power on the main desktop PC and all equipment with a script
3) Then I use teamviewer to log into the main desktop PC. Open Kstars and open the generated schedule file.
4) I click start and monitor it for a while. Sometimes I start it in twilight and EKOS will wait until it gets dark.
4) EKOS starts up the observatory. Opens the roof, unparks the mount, slews, focuses on the first target, starts guiding etc etc.
5) I watch it work for a while and once the first couple of targets seem ok i close the PC and go to bed. Sometimes the first focus attempt can be a problem and may require manual intervention but other than that, Its very good.
6) EKOS works through the schedule and monitors the weather while I sleep. If it rains or gets cloudy or dawn, It runs the shutdown procedure. Parks the mount, closes the roof. Warms the CCD and then powers off all the equipment.
7) I wake up and check the security camera inside the observatory to make sure all is ok. There has never been a case where I needed to phone someone (yet)

You mentioned that 'writing scripts would not be an option for me.'. I recommend learning some basic scripting. The scheduler can call a startup and shutdown script. You can do anything you need in there too.

You mentioned that you are planning to use a remote telescope hosting. This would reduce some of the reliability problems related to a roof and weather monitoring as it will be managed by the site. I haven't used one of these but I assume they just close the roof when conditions are unsuitable. They probably have some notification system that you could hook into with an INDI weather scripting gateway but you will need to learn how to write scripts here I'm sure people here can help though.

Derek

I have been running and testing my observatory fully remotely for approximately a year, a little less for imaging.

After the beta testing period:

Reliability:
I had an issue only once and this was due to my eagerness to software update my system. My one and only tip, just like Derek already said: Never, never, never upgrade when you have clear nights.
Besides that night, I never had an issue with autofocus (John does a tremendous job in that field www.youtube.com/@johneevans1), with meridian flip, with filter wheel, etc.

No crashes, no driver issues nothing. One additional tip is to have hard-wired anything you can, for example, my iOptron GEM28 is capable of being controlled via WIFI. I choose to control it via USB attached to my mini PC (gear on my signature). I do want the best out of the internet connection, so that's why I choose to use an Ethernet cable instead of WIFI.


Scheduling:

I personally use multiple TPlink smart plugs in my home, so I've done the same to my observatory. Power plugs and my surveillance cameras, controlled from my iPhone. Just like any other smart device, I can schedule them to power on/off, etc. Ekos Scheduler is capable of doing many things to cover your needs, as soon as you understand the logic.

In fact, I have an active set at the moment.





SO right now

Derek, thank you so much for sharing your experiences. This was exactly the type of feedback I was looking for.
Regarding reliability, yes I agree, this depends as much, or even more, on the equipment than the software. And I'm sure some of the reliability issues I have encountered over the years had to do with setting up and breaking down the system each time. As much as you do it the same each time, a cable snag, a loose screw, or a differently plugged USB cable is always around the corner and can cause issues. That would be much less of course in a remote observatory. Not upgrading, or only rarely and only during off-time is another very good suggestion.

As far as automation goes, you have worked out a nice setup. Like you say, for the last 10% or so, writing scripts is probably the way to go. It makes a lot of sense, just another thing to keep in mind. The 'monitoring it for a while' before letting go automatic is exactly how I use it now as well. Interesting you mention that first autofocus run needing a bit of tweaking, as that is exactly what I experience as well. But the goal would be to build the setup such that this initial monitoring is not necessary. Perhaps too optimistic?

Indeed weather monitoring is done centrally, so that takes some complexity out of the equation. But still need to respond to an incoming boltwood file that indicates a (temporary) closing roof.

Again, thank you very much for sharing your experiences, much appreciated.

CS, Willem Jan.

Thank you Euripides, your feedback and experiences are also hugely appreciated! And again the crucial advice: don't upgrade. Do it rarely and only during off-time.
Yes, John has done a tremendous job, both in the algorithms that he added, as well as the support to debug and improve them. I've had some interaction with him during an early release of the Linear 1 Pass algorithm, when we discovered a bug related to backlash settings, which he corrected super quickly.
Hard wiring is indeed the way to go, and that is in the plan.
Using regular home automation is an interesting tip as well. Although coupling it to actual imaging sessions (you only turn camera on when the sky is clear and roof is open) will then probably require some scripting again.

Thanks again for sharing your experiences, much appreciated.

CS, Willem Jan.

"Interesting you mention that first autofocus run needing a bit of tweaking, as that is exactly what I experience as well. But the goal would be to build the setup such that this initial monitoring is not necessary. Perhaps too optimistic?"

Accumulating temperature is crucial for that. Right now I am opening my observatory 45 minutes - 1 hour earlier. Since then, I had no further issues with that.

indilib.org/forum/ekos/13682-suggestion-...autofocus.html#94833

Yes, you are right, temperature has a big impact on it. But the same happens if you image one night at 15 degrees and another night at 5 degrees.

The ambient temp could be 5 or -15, but which is the temp on your scope? Inside those optics? Optics needs time for that.

That's why as time passes, and the optics cool down, accumulating the ambient temp we can see in my example above those donut-shaped stars. That's why the autofocus algorithm has to run again.
Till the moment that I opened my observatory 1 hour earlier my imaging session, I never had any issue in my first captured frame.

Imagine that when I am imaging with my Maksutovs I should wait even 2 hours before my sessions.

My approach is to set my limits for HFR.

I am thinking of going in this direction so, in anticipation, I am starting to try running as if I were remote. I just bought some Kasa smart plugs and will begin working to have a suite of targets teed up and see how it all goes while still walking to my scope in the backyard and taking off the telegizmos cover. Eventually I would like to get a Robodome of equivalent so I can image when I am out of town. This way I can debug things in advance and see if I need to switch to another control system.

My main concern is my filter wheel sometimes gets stuck and I have to unscrew the cover and jog the spring, hard to automate… The recently added focus feature that try’s to predict focus at start of focus run might help with the missteps on first focus but it is still experimental and doesn’t seem totally dialed in.