In order to support N arbitrary cameras in Ekos, I'm beginning to toy with the idea of simplifying the system and reducing complexity.

So I'm planning to create the optical_train Git branch to test this idea. Basically, you will no longer be able to select any camera, focuser, filter wheel, rotator, or scope in Ekos. Instead when you create your equipment profile, you will be asked to create optical trains.

The equipment profile will also undergo significant changes to allow selecting multiple mounts, focusers..etc. You will no longer be limited to only a set number of devices in the profile. You can add 10 cameras if you desire so.

For most use cases, you would have at minimum the primary image train. In each train, you will be asked to select the devices in the train itself (including passive devices like focal reducers). Once the train is saved, it will be used throughout Ekos. In Capture/Focus/Guide/Align, that's the only selection you make. This would require significant re-structuring of Ekos code, which might take a year or so.

So I'm just throwing this idea out here to get your preliminary feedback on this approach and to see if there any major flaws in the idea that I perhaps overlooked.

It sounds like there are some development benefits to this idea, but what are the practical end user applications for this? Multiple imaging rigs run at once? Or multiple telescope capture in a single interface?

The immediate benefits are:

1. Simplify the workflow. You no longer select a camera, filter, focuser, ...etc. in each Ekos module. You just have selection which is the train.
2. It can support multiple cameras to work at the same time.
3. Any number of devices supported, not limited to the current 12 limit in the profile editor.

This looks like a good idea and should make things simpler both for development and the user. I've always thought that the Mount and the optics should be separated.

I'm not convinced that passive components such as focal reducers, Barlow lenses, eye piece projection, diagonals etc., should be included. Calculating the focal length by allowing for all the optics is tricky because the power of a focal reducer or Barlow depends on it's spacing. The focal length of a scope with a moving mirror such as a SCT will also vary depending on the mirror position. I see a vast amount of complexity for something that could generate more problems than help.

One thing is the guiding system. A separate guide scope is clearly a separate optical system but what about a combined guider and imaging systen? Either an OAG with a separate camera or a camera with a guide camera integrated.

The optical train/mount arrangement would be EKOS specific I suppose, there wouldn't be much if any change to how the INDI drivers operate, although some things, such as the OTA properties in the mount drivers ,would become obsolete.

Chris

Regarding the focal reducer, I thought about it as a simple modified to focal length. So Ekos would calculate the final focal length instead the user. But it's not necessary and we can live without that (make the user enter the focal-reducer effective focal length like they do now.

The system should also cater for OAG, it's the same train as the primary imaging system. You're right, the OTA info would be obsolete and will probably be removed from INDI mount drivers in the future.

Perhaps you could break it up into certain packages. For example:
1) The mount, optionally with GPS/ weather station. Maybe also dew heater controller. Essentially all things independent from optics/ imaging train.
2) Telescope with all optics such as focal reducer/ flattener/ coma corrector. I would also like to include the dew heater parameters/ focuser/ shutter with flat-field illumination in this 'package'.
3) Guide scope assembly with dew heater parameters and camera.
3) Imaging module with optionally filter wheel/ OAG camera/ adaptive optics/ ADC.

I think the overall idea is a niche though.

This is a pretty good Idea. Actually we had this discussion one year ago, if you remember, Jasem .
The idea of one optical train/Ekos is excellent. But for what I understand, you'll need to start several instances of Ekos (One per optical train) in order to achieve that, am I right ?
So maybe this is all about completely separating Ekos from Kstars, which would give more flexibility and simplicity.
Here's an example : When I start one instance of Kstars (alone, no Ekos) it drains 7.6% of processor time and 3% memory. If I need to drive 4 rigs from a single computer, I waste 3x7.6% and 3x3% memory in useless Kstars, as one would be sufficient if it could monitor my 4 rigs.
Plus, the separation would let the possibility to use any planetarium software along with Ekos. That should increase the number of potential users of Ekos, every one having his own preference on that matter... From this point of view, Kstars and Ekos would act as 2 completely separate clients of the INDI server.

And for those who don't see the practical interest in all this:
- You're in the field imaging with one rig, while watching with the second one. (And you have plate solving/autoguiding for both)
- You're imaging with 2 cameras: one in color (RGB) The other one used for getting luminance (Ha, etc) Both at the same time.
- On a distant observatory suppose you need to double some gear for security purpose. (weather station or dome opening/closing for example)

And think about astronomy clubs, schools, observatories, etc...

- Marc

I expect that an instance of EKOS would have one mount that has multiple Optical Trains (OTs). Ekos would manage synchronising the mount activity with the combined OT activity. Multiple mounts would require multiple instances of EKOS, ideally running on separate systems.

Chris

I would rather think of separating EKOS from KStars as @Marc2b suggested in this thread. Multiple EKOS instances should be allowed though.
I believe that such an approach would get us back to the roots of GNU/linux. Every utility should simply do just one thing, best way it can.
Having said that, I'm against the idea EKOS handling multiple optical trains. It should handle a single train the best it can. Multiple EKOSes should handle multiple trains.

Perhaps Jasem and the other developers should take one step at a time? First make the optical train change happen, then see if and how Ekos can be disconnected from KStars?


Wouter

So this is actually pretty simple. A train is just a collection of devices/OTA/accessories together. So instead of selecting camera and filter wheel and rotator..etc. You just select "Imaging Train" and Ekos know what devices are on it. So if it has a rotator, and you are in alignment module, it can change the rotation angle to match a target. If you select another train without a rotator, it will not even attempt to do that.

So it's a simple logical grouping to make sure everything acts correctly in unison. That's the primary idea.

The other idea is to make arbitrary mounts/cameras/aux/OTAs..etc and have the user define any number of trains. Then in principle you can have Ekos manage synchronization of multiple trains in parallel. This is quite complex, but the train idea above would allow for it as a starting point. So perhaps we can start with simply the train aka logical groups idea and then proceed from there.

I really don’t see the difference between a set up profile or a set up imaging train... and maybe there are more important things to be moving forward with, rather that re inventing the wheel, at this point.... it seems that as soon as people get a good stable working system that they have learned to use, then it all changes... just my opinion