I'm pretty new to KStars and Ekos, so please forgive me if my question is too uninformed. I am setting up my AP gear to use Stellarmate OS / Pi4. I like the idea of running a very empowered KStars planetarium/planning config on my laptop, but I'd ideally prefer to run Ekos (scheduler and device control) on the Pi4. When KStars/Ekos runs entirely on the Pi4, the Pi4 takes a bit of a computing hit due to KStars graphics viewed over VNC. It's also not quite as responsive as when run on a laptop/tablet. Finally, it also implies that a local laptop/tablet can't be put to sleep once image sequencing starts. It would seem that an ideal workflow would allow for any planning/planetarium functions to be done local to the laptop/tablet (i.e. KStars local), and any scheduling or device control tasks be "pushed" remote to the Pi4 (Ekos+INDI remote).
So, my question: when you are in the profile editor and you select a (Mode): remote host, what is actually happening under the covers? Is KStars running locally while Ekos/Indi run remote? Or are KStars and Ekos always running together on the same host? What are the "Mode" local/remote tradeoffs ? I don't quite understand what I've read in the docs and understanding the underlying architecture and implications would help. Thanks....
RASA 11 + Celestron CGX-L, ASI EAF
ASI183mc pro + ASI290mm mini guidecam
Stellarmate OS/Pi4, PPB
kstars/ekos is a lot to grasp! In your local (laptop) ekos profile, when you select remote host, any indilib request for hardware by ekos or kstars (or any indilib client) be it a camera, telescope mount, gps, weather sensor, etc, are all forwarded over the network to the remote instance of indilb. kstars and ekos are still running locally.
If you had all your hardware directly connected to your laptop, you would then select local, and all the indilib device requests would be handled by the local indilib server.
I noticed the same thing as you. A VNC connection to the pi4 with kstars was not the best and performance really suffers. I removed kstars from the startup script on the Pi4, no need to have it running for my needs.
Think of it like this, there are three pieces to this ecosystem, Indilib, Ekos, Kstars. Indilib handles anything to do with physical hardware, mounts, cameras, etc. Ekos is at its heart, controller/monitor of this hardware. Its the piece that lets you deal with focus, guiding, aligning, and scheduling. Kstars is really just planetarium software. Its a little more complicated than this because Ekos is integrated into Kstars and not a separate piece of software that you can run independently, but logicically they are very distinct in function.
I'm sure I'm oversimplifying this but hopefully this helps.
In further digesting your questions, with regards to running scheduled jobs in kstars/ekos locally on your laptop and all the hardware connected to the remote Pi4, I believe that putting the laptop to sleep would stop the processing of those jobs. As I understand it, the processing of those jobs would be done locally on the laptop. I'm sure someone else will clarify this.
Regarding your comment about removing KStars from the startup script on the Pi4, I think that means that you (mostly) don't need to VNC to the Pi4 because there's no KStars nor Ekos running on the Pi4. It however also means that you can't put your laptop/tablet to sleep because imaging would halt. You've solved the performance issue with VNC'd KStars graphics, but seemingly at the price of not being able to sleep your laptop/tablet? That trade is unfortunate from my perspective . It kinda kills the excitement of having a Pi4 in the loop doesn't it? Given that as the choice , I can see why folks just run everything on the Pi4 and accept a bit of performance hit. The performance isn't too bad....
Maybe my question is better stated as a "wish" for Ekos to evolve towards a server architecture so that real-time planetarium/planning functions could be fully separated from remote scheduling/sequencing/device control. These two functions really do seem best solved on different computing platforms....laptop/tablet (astronomer) and remote Pi4 (telescope/gear) respectively. Maybe someday, after I get more familiar with the development environment, I can look at the "Tool" definition for Ekos within Kstars and play with this concept. On the other hand, by the time we have Pi-5/6, the performance will be so good that it won't matter any more. Until then, thanks for the chat and....clear skies...
Yes! I was thinking about this after re-reading your question. Some of the functionality really needs to be more Client/Server oriented. It would be great if the scheduling functions could simply point to a database on the pi, and a process on the Pi that would monitor jobs in the database. Feature request Jasem?
I use vnc to a RPI 3 running Indi+kstars/ekos and think it works great! If you think the RPI 4 is too slow to run kstars/ekos, you could just switch it with something more powerful, say an old laptop or desktop with Ubuntu.
Answering the question about architecture, here are the basics.
This is the way the requests from the client travel from source to destination.
In any case:
- The INDI server, the driver and the hardware are always on the same machine. The drivers communicate with the hardware through USB. The INDI server communicates with the drivers (which are standalone programs) through pipes (pipes are files in memory used for data exchanges). You can chain several INDI servers in cascade. One server becomes the master and the others are enslaved to this master. In this configuration, INDI clients connect to the master.
- The INDI client (EKOS ie), source of the orders, communicates with the INDI server through a TCP/IP connection. So the client can be on the same machine as the server and the hardware, or the client can be on a distant machine.
- VNC clients connect to the machine where the INDI CLIENT and the VNC server run. So you can connect with a tablet running a VNC client to a laptop running Kstars/Ekos connected though Tcp/Ip to the INDI SERVER on a third machine to which the devices (mount, cameras, focuser etc...) are attached.
On the little scheme below, you can see only one driver is started to connect to several pieces of hardware. INDI driver B pilots hardware Y and Z.
That means in the Ekos profile editor, you only need to specify the driver once. ex: you have two ASI cameras one for imaging, the second one for guiding, you just need to specify the ASI driver in "CCD:". No need to put in also in "Guider:", as the two use the same driver.
Thanks, the info you've provided is consistent with what I understand about INDI server/client architecture from previous work experience. My question was really about how tightly coupled KStars and Ekos are, but realizing that Ekos is the INDI client is informative and helpful. It's not as fun as I had originally hoped that KStars and Ekos are tightly coupled, but it's all good. I think I've found a way to manage around what I was originally thinking of doing, which is to allow KStars planetarium based wishlist/session planning on a laptop, and reserve sequencing execution and device control for the Pi4. Now if I can just get a laptop generated Wish List (future Session Plan) file to a shared Pi4 space, I might find Nirvana!