[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: Interoperability proposal
From: Ed Lee <ed () thefamilee ! co ! uk>
Date: 2024-03-11 19:52:55
Message-ID: 49aee177-9fe9-41c9-a1cd-2aef9d342e08 () thefamilee ! co ! uk
[Download RAW message or body]
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@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
>>> o In INDI control panel, disconnect imaging camera
>>> o Launch FireCapture from the Desktop
>>> * In FireCapture, connect to INDI, focus, adjust settings,
>>> capture, close FireCapture
>>> o 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@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@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
>>>>>
>>>>
>>>
>
[Attachment #3 (multipart/related)]
[Attachment #5 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi all, <br>
<br>
Here's a progress update on this topic as I have made a start into
implementing this. <br>
<br>
<u>GUI</u><br>
I've put the plugin interface on the Manager ui like this...<br>
<br>
<img src="cid:part1.wWWujfnX.RIfCrf04@thefamilee.co.uk" alt=""
moz-do-not-send="false" width="1024" height="768"><br>
<br>
This was for two reasons:<br>
<ol>
<li>A plugin could be relevant to any one or more Modules.</li>
<li>I'm using the preview window as the receiver for the live
stacked image from Siril.</li>
</ol>
<p><u>Application interface</u><br>
</p>
<p>I have the DBus interaction working in both directions and log
pass through from the QProcess that holds the plugin.</p>
<p><u>Plugin design</u></p>
<p>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.</p>
<p>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.</p>
<p><u>Plug in progress</u></p>
<p>I've finished the firecapture_launcher plugin. It works as I
described.</p>
<p>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.</p>
<p><u>Outstanding</u></p>
<p>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.<br>
</p>
<p>Lots of testing is required. This won't be ready for 3.7.0. but
hopefully could be for the following release.</p>
<p><br>
</p>
<p>*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.</p>
<p>Regards</p>
<p>Ed Lee<br>
</p>
<p><br>
</p>
<br>
<br>
<div class="moz-cite-prefix">On 23/02/2024 13:56, Ed Lee wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4e0432dc-66fa-46cd-8a59-b4d32bac5124@thefamilee.co.uk">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi Wolfgang, <br>
<br>
I'll have a bit of a hack about with a view to scoping the pros
and cons with different approaches.<br>
<br>
Kind regards<br>
Ed Lee<br>
<br>
<div class="moz-cite-prefix">On 23/02/2024 13:04, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E4C4CB2F-C73E-4908-8C1D-F21A45B3A1D5@openfuture.de">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Hi Ed,
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Kstars has a fairly good (but insufficiently documented)
DBus interface for scripting, which could be used that way.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- Wolfgang</div>
<div>
<div dir="ltr">--
<div>
<div><span
style="background-color: rgba(255, 255, 255, 0);">Wolfgang
Reissenberger</span></div>
<div><span
style="background-color: rgba(255, 255, 255, 0);"><a
class="moz-txt-link-abbreviated"
href="http://www.sterne-jaeger.de"
moz-do-not-send="true">www.sterne-jaeger.de</a></span></div>
</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">Am 23.02.2024 um 09:51 schrieb Ed
Lee <a class="moz-txt-link-rfc2396E"
href="mailto:ed@thefamilee.co.uk" \
moz-do-not-send="true"><ed@thefamilee.co.uk></a>:<br> <br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<font face="Arial">Hi Wolfgang, <br>
<br>
Some more details regarding the second idea...<br>
<br>
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. <br>
<br>
My current preferred workflow for a planetary capture
is:<br>
</font>
<ul>
<li><font face="Arial">Start KStars/Ekos</font></li>
<li><font face="Arial">Polar align using Ekos plate
solving</font></li>
<li><font face="Arial">Train a quick mount model using
Ekos plate solving</font></li>
<li><font face="Arial">Rough focus in Ekos (I'm manually
focussing with a Bahtinov mask)</font></li>
<li><font face="Arial">Slew to planetary target in
KStars</font></li>
<ul>
<li><font face="Arial">In INDI control panel,
disconnect imaging camera</font></li>
<li><font face="Arial">Launch FireCapture from the
Desktop</font></li>
</ul>
<li><font face="Arial">In FireCapture, connect to INDI,
focus, adjust settings, capture, close FireCapture</font></li>
<ul>
<li><font face="Arial">In INDI control panel,
reconnect imaging camera (if attempting another
target in the session).</font></li>
</ul>
</ul>
<p><font face="Arial">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.</font> 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.<br>
</p>
<p>Hope that helps in understanding my intent?</p>
<p>Kind regards</p>
<p>Ed<br>
</p>
<font face="Arial"><br>
</font>
<div class="moz-cite-prefix">On 22/02/2024 22:27, Wolfgang
Reissenberger wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EAB7C3FB-E763-4EEC-AFA7-750B25B4674B@openfuture.de">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Dear Ed,
<div>very interesting ideas!</div>
<div><br>
</div>
<div>The first idea should be feasible.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Wolfgang</div>
<div>
<div><br>
<blockquote type="cite">
<div>Am 21.02.2024 um 15:50 schrieb Jasem Mutlaq <a
class="moz-txt-link-rfc2396E"
href="mailto:mutlaqja@ikarustech.com"
\
moz-do-not-send="true"><mutlaqja@ikarustech.com></a>:</div> <br \
class="Apple-interchange-newline"> <div>
<div dir="ltr">Hello Ed,
<div><br>
</div>
<div>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. </div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--</div>
<div>Best Regards,<br>
Jasem Mutlaq<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Feb
21, 2024 at 5:35 PM Ed Lee <<a
href="mailto:ed@thefamilee.co.uk"
moz-do-not-send="true"
\
class="moz-txt-link-freetext">ed@thefamilee.co.uk</a>> wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div> <font face="Arial">Hi,<br>
<br>
Although KStars is growing ever more
capable there are other programs that I
like to use in conjunction, mostly for
convenience.<br>
<br>
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. <br>
<br>
Two examples of how I would like to use
a generalised call:<br>
</font>
<ul>
<li><font face="Arial">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.<br>
</font></li>
<li><font face="Arial">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.</font></li>
</ul>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">Kind Regards</font></p>
<p><font face="Arial">Ed Lee<br>
</font></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
["2nJLQiag0ZZeBHK2.png" (image/png)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic