I am planning to automate my observatory. The first step was to be able to detect clear skies and I have found that using my all-sky camera and a bit of blob-detection is a good way to do this.
Now I want to have the observatory "wake up", roll off the roof, align the mount, initialize the guider, take some guided images of an object and shut down when it is not clear any more. It seems that EKOS can do this in principle, but as far as I understand this requires kstars to be running directly on my RPi which controls everything. I can easily make some small scripts which will open/close the roof, detect clear skies and so on.
My questions are:
1. Is ekos/kstars on the RPi a good and stable solution for this or is this combination not really meant for this completely autonomous operation?
2. I can easily interface the all-sky camera using indi/bash scripting. Are the interfaces for mount and guider just as easy to use? (i.e. does some simple commands exist for unparking, parking, aligning using plate solve, starting the guider and so on) If yes, then I guess this is a viable alternative to no. 1.
3. Any other alternatives? I see there are some python docs, but they seem to be requiring one to write complete drivers and not use indi in the "high level" that I actually want
Thanks in advance for all suggestions and clear skies to y'all
Thanks for the video. I did see this, but it appears to me that kstars/ekos in the video running on an external device (not the RPi in the observatory) and what then happens when this external device is shut down? Will the "queue" of objects still be imaged by the Pi, the obs. shut down when it becomes cloudy and so on? This I why in my proposed soluton 1 I wrote that I need ekos/kstars running directly on my RPi inside the observatory for example to be accessed via VNC. Is this a viable option? kstars seems to use a lot of juice even when minimized to the taskbar...
In order to use Ekos on an external computer (like my case), then you need a very reliable connection. You can still run it on the RPi but as you pointed out, it consumes quite a bit of resources but can still run and perform its functions. I've been adding options to reduce its memory footprint on embedded devices.
I have also been working (slowly) towards something like this. I would like the observatory to startup with no human intervention if conditions are suitable and it has a schedule of work. This is in order to make the most of the generally bad weather conditions I have in Ireland.
Detecting clear sky with an all sky camera is an interesting idea. I built a custom weather station using an IR sensor to measure the temperature of the sky which seems to work.
Here is what I have so far.
1) A local network in the observatory which has internet access via 3G/4G
2) A weather station, always on, monitoring cloud and rain, connected to the network.
3) A RPI always on which acts as an SSH jump-host for me to gain access to the network from my home.
4) A desktop pc, normally off. This PC runs kstars and indi and is connected to all equipment.
Normally I power on the PC using wakeonlan once I ssh into the RPI.
Here is what I plan, and have done very limited testing on
1) The RPI detects clear sky from the weather station.
2) Once clear and conditions are OK, The RPI sends a wakeonlan to wake the PC
3) The PC starts and kstars starts automatically on boot.
4) A script on the PC runs to issue 2 DBUS commands to kstars. First to load an EKOS schedule file from dropbox, second to click start on the EKOS scheduler.
5) EKOS takes over and manages opening the roof, unparking, scheduling and shutdown procedures.
6) A final script gets called from EKOS on shutdown to do some cleanup, check roof closed, send an SMS and start data-reduction. (I dont have this part tested yet)
Yes I could do that, I think it should work too. The main reason is that I also use the PC to do data-reduction with astropy (ccdproc) to reduce the amount of data I need to send home over the 4G network. That work can be heavy enough lifting so I thought a full PC was better
All the bits on their own are working as expected, but I'm not brave enough to let it run 100% autonomously yet
Maybe safety is the main thing to be aware of. I was testing starting ekos using dbus last year and I nearly crashed the scope into a closed roof!! I was doing this remotely too which is dangerous. Lucky I was watching the security camera and was quick enough with the abort button....
I need to do more testing on-site to gain more confidence in all the parts. Also if you do update kstars/indi I would recommend some sort of basic regression test to run when you are on-site and close to a stop switch.
Why not just run two Pi's in the Observatory. One running INDI and managing things, and a second one that runs nothing other than KStars/Ekos? Nothing says you are limited to just one Pi. in fact, maybe you should run 3.14 Pi's in your observatory.