Interoperability proposal

[Hy Murveit]

Don't forget doc. As part of your MR, please create a new section under
Ekos in the handbook (source is in kstars/doc/ and some info about
"compiling the doc" is in the KStars README--even though it's a weird new
"language", writing by using examples of other doc isn't too bad).

Also, please remind me what you mean by "plug-in" (I guess, write some
paragraph that will eventually wind up in the handbook). BTW, just
checking...is plug-in the right word?

Thanks for doing this--I think writing the doc early will help explain what
you're up to.

Hy


On Mon, Mar 11, 2024 at 12:53 PM Ed Lee <ed at thefamilee.co.uk> wrote:

> Hi all,
>
> Here's a progress update on this topic as I have made a start into
> implementing this.
>
> *GUI*
> I've put the plugin interface on the Manager ui like this...
>
>
>
> This was for two reasons:
>
>    1. A plugin could be relevant to any one or more Modules.
>    2. I'm using the preview window as the receiver for the live stacked
>    image from Siril.
>
> *Application interface*
>
> I have the DBus interaction working in both directions and log pass
> through from the QProcess that holds the plugin.
>
> *Plugin design*
>
> I've designated a new plugins sub-directory of the KStars
> AppLocalDataLocation (on my machine ~/.local/share/kstars/plugins). On
> start of INDI in the Manager UI this is searched for plugins that have a
> valid configuration file (see below) and optionally an icon file. The
> validated list populates the ComboBox.
>
> The configuration file must contain a minimum_kstars_version string that
> is checked against the KSTARS_VERSION so plugins can't be used on earlier
> unsupported versions. My plugins also check this matches internally.
>
> *Plug in progress*
>
> I've finished the firecapture_launcher plugin. It works as I described.
>
> I've tested all the individual parts of the siril_eaa plugin. I can set up
> Siril in headless mode for live stacking, watching the save directory set
> in a Capture job, and receive the live-stacked result back into the Capture
> preview window on the Manager UI. I just need to do all the conditional
> tests and logic.
>
> *Outstanding*
>
> I'm not sure of the best way in which to distribute the plugins once the
> facility is integrated. I've got them in github under my own account at the
> moment but if this ability is well received and other plugins are produced
> we may want a more centralised repository. I think it should be kept
> separate from the KStars codebase as there are no direct dependencies.* I'd
> like to hear any other thoughts on this, and indeed any other aspect of
> this proposal.
>
> Lots of testing is required. This won't be ready for 3.7.0. but hopefully
> could be for the following release.
>
>
> *Some enums are copied over for status flag monitoring on DBus. I couldn't
> utilise the xml DBus directly as there are custom types that are defined in
> with other stuff (for instance in ekos.h) that results in a cascade of
> dependencies.
>
> Regards
>
> Ed Lee
>
>
>
>
> On 23/02/2024 13:56, Ed Lee wrote:
>
> Hi Wolfgang,
>
> I'll have a bit of a hack about with a view to scoping the pros and cons
> with different approaches.
>
> Kind regards
> Ed Lee
>
> On 23/02/2024 13:04, Wolfgang Reissenberger wrote:
>
> Hi Ed,
> is there a benefit keeping Kstars alive when the handover to FireCapture?
> Or is the only requirement when Kstars terminates that the INDI server is
> running?
>
> For the latter it’s a lot simpler to start the INDI server remotely,
> because in this case the INDI server stays alive when Kstars terminates.
>
> What about thinking the other way round and build an orchestration client
> that starts Kstars and the required steps, stops it when its tasks are
> finished and launches FireCapture to continue.
>
> Kstars has a fairly good (but insufficiently documented) DBus interface
> for scripting, which could be used that way.
>
> You hear, I‘m slightly sceptical about integrating such an approach into
> Kstars. We have done substantial progress in terms of modularisation, but
> our core modules are part of the application and not exchangeable plugins.
>
> - Wolfgang
> --
> Wolfgang Reissenberger
> www.sterne-jaeger.de
>
> Am 23.02.2024 um 09:51 schrieb Ed Lee <ed at thefamilee.co.uk>
> <ed at thefamilee.co.uk>:
>
>  Hi Wolfgang,
>
> Some more details regarding the second idea...
>
> In FireCapture, the imaging camera is handled directly for maximum
> throughput. Other equipment must be connected via INDI (or ASCOM). The
> other equipment in this case can be mount, filter wheel and focuser. There
> is no need, from FireCapture's perspective, for KStars/Ekos, only INDI. So
> it's possible, but clunky, to launch an INDI server handling all the kit
> from the command line before starting FireCapture.
>
> My current preferred workflow for a planetary capture is:
>
>    - Start KStars/Ekos
>    - Polar align using Ekos plate solving
>    - Train a quick mount model using Ekos plate solving
>    - Rough focus in Ekos (I'm manually focussing with a Bahtinov mask)
>    - Slew to planetary target in KStars
>       - In INDI control panel, disconnect imaging camera
>       - Launch FireCapture from the Desktop
>    - In FireCapture, connect to INDI, focus, adjust settings, capture,
>    close FireCapture
>       - In INDI control panel, reconnect imaging camera (if attempting
>       another target in the session).
>
> So I'm using KStars/Ekos for setup and INDI server management, and
> FireCapture for capture and guiding. When FireCapture is active it's vital
> that KStars/Ekos is in an idle state, so in this case the button would only
> be active when the scheduler is not running, guiding is not active and no
> capture job is running. The plugin would just handle the three indented
> actions above. I wouldn't intend to manage the capture session in any way
> (guiding/focus/flip), that's the job of the capture control system - in my
> case FireCapture.
>
> Hope that helps in understanding my intent?
>
> Kind regards
>
> Ed
>
> On 22/02/2024 22:27, Wolfgang Reissenberger wrote:
>
> Dear Ed,
> very interesting ideas!
>
> The first idea should be feasible.
>
> Regarding the idea interacting with FireCapture I’m not sure if I
> understand the intention behind. Is there the idea to use KStars for
> positioning the scope to the target, but then switching (at least
> capturing) to FireCapture? Should guiding continue running for example?
> What about meridian flip? Or Refocusing? There are many features of other
> modules that lead to interaction with the Capture module.
>
> Cheers
> Wolfgang
>
> Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com>
> <mutlaqja at ikarustech.com>:
>
> Hello Ed,
>
> That's a great idea. Perhaps something like "Plugins" that could be used
> to add extra functionality? KStars can be scripted by DBus though the
> documentation & level of support for this can be improved.
>
> --
> Best Regards,
> Jasem Mutlaq
>
>
>
> On Wed, Feb 21, 2024 at 5:35 PM Ed Lee <ed at thefamilee.co.uk> wrote:
>
>> Hi,
>>
>> Although KStars is growing ever more capable there are other programs
>> that I like to use in conjunction, mostly for convenience.
>>
>> It occurs to me that my workflow could be made easier and the system
>> capabilities extended by providing a generalised means to call other
>> programs from within KStars/Ekos. At present there is already a specific
>> occurrence of this where the scheduler can call start up / shut down
>> scripts.
>>
>> Two examples of how I would like to use a generalised call:
>>
>>    - Add a button to the Capture module that launches an external live
>>    stacking application (for example Siril), pass it the necessary commands to
>>    start receiving images from the current selected camera, and then start
>>    repeating captures. Stop capturing when the external process closes.
>>    - Add a button to the Capture module that disconnects the current
>>    selected camera from the INDI server and then launches FireCapture for
>>    planetary imaging. Reconnect the camera when the external process closes.
>>
>> Abstracting the external program calls via scripts would allow user
>> customisation and avoid any dependencies on / promotion of specific
>> software. Sample scripts could be provided. It may also make the
>> implementation simpler - an abstraction of the current scheduler script
>> processing with additional control processes within KStars.
>>
>> Before I start working on this I wanted to ask for any thoughts on this
>> proposal, both regarding the implementation and also whether this would be
>> perceived an acceptable route for KStars.
>>
>> Kind Regards
>>
>> Ed Lee
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20240311/945b35a5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2nJLQiag0ZZeBHK2.png
Type: image/png
Size: 631728 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20240311/945b35a5/attachment-0001.png>