×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

INDI for accessing astrometric solving (plate solving)

  • Posts: 333
  • Thank you received: 92
As you maybe know, the ASTAP program is available for Linux (AMD64), Raspberry PI (armhf) and MacOS. Part of the program is an astrometric solver (plate solver). Access is available via the command line . The command line is universal and easy to implement.

At the moment, I'm asking myself, would there be any benefit of implementing an additional INDI interface in ASTAP for accessing the solver.. The number of potential clients will be limited. What you could do is provide a web service similar as nova.astrometry.net but INDI driven. Note that ASTAP is also a viewer and stacking program.

At the moment only CCDCIEL has ASTAP command line interface implemented. I expect one or two Window image acquisition applications to implement the command line interface soon.

Any thoughts on this INDI solver interface? Is an INDI binary transfer fast enough?

Han
5 years 3 months ago #32117

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
At the moment, there is an INDI driver to handle the command line of astrometry.net. I believe that Jasem implemented it at a high enough level so that it may be reused for another solver. Of course, he was not required to make it generic, so probably there might be a few tweaks to add.
Now, the largest work is probably to have Ekos use ASTAP as a remote solver.

-Eric
5 years 3 months ago #32154

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
That looks like the way to go. One of the outputs of ASTAP is a WCS file (= solved fits file header only) with the solution which should be compatible with Astrometry.net output. Looking around in the forum, the interface looks very compatible:

www.indilib.org/media/kunena/attachments...0-31alas11.26.55.png

Rather then the path to solve-field you have to enter the path to the astap executable. The parameters are also different.

I'm exclusively programming in Object Pascal, so I have to leave the tweaking of the existing driver "c" code to others.

Local access in Kstars will be more work. There is no astrometry.cfg file.

www.indilib.org/media/kunena/attachments...10-29at2.02.26PM.png

Han
5 years 3 months ago #32179

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
Could you no "cheat" and just replace the existing platesolver EXE with a script and then parse the command normally intended for Astrometry - isn't the command line exposed in the solver module (seen parameters just never bothered to see if the program name was there or not). You would have to parse the output too so that the solver module is "fooled" the details came from Astrometry platesolver. That would leave the problem/changes in your hands Han (you are the creator right ?) something like the Platesolver2 route you did.

Maybe talking rubbish here - just a thought :-)

I would have thought such large scale changes ,to a non generic module,could not be justified by Indilib team IMHO - too many other things to do :-)

But then I am not the Indi developers - their choice :-)

Now interfacing the stacker that would be another thing - one module I haven't found on Indi - or have I just missed the module ???
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
Last edit: 5 years 3 months ago by Clive Stachon.
5 years 3 months ago #32185

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92

Probably a script could work, but there seems no need for since you can specify path, solver name and parameters in the remote Astrometry.net setup. That 's what I understand from the screens shots. In principle if the input is a fits file, it would only require the fits file name as command line parameter. Other details like field of view, initial position will be extracted from the fits file header. So the complete command line could be something like

/opt/astap/astap -f ~/fitsfile.fits

The parameters (binning, search field...) can be configured in the program and will be saved if you leave the program via file, exit.

At the moment, I have no INDI setup (only Windows & ASCOM) so testing using INDI is a little difficult. I could setup my raspberry PI3 for testing but at the moment it is only used as a development tool.

No INDI interface was ever foreseen or planned for the stacker part of the program. The solver engine was developed as an essential part for the stacker. It can be used for mosaic building. Since it works so well, a solver command line interface was added to the program.

Han
Last edit: 5 years 3 months ago by han.
5 years 3 months ago #32189

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
If I may, I would comment that keeping "accessory" elements of configuration saved away from the running operation is bound to produce issues. Unless the engine is optimizing its own operation based on these options, doing this will probably cause weird dependency issues.

-Eric
5 years 3 months ago #32193

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
Hans,

IMHO it would make more sense just to use ASTAP with HNSKY/CCDIEL and just talk to Indiserver with no Kstars/Ekos involvement if that's what you want :-)

Haven't used CCDiEL for a good while but it ran Ascom and/or Indiserver connection ok but I only did quick test.

To complement IndiLib,as another alternative option, rather than be integrated into it - but as I say that's my personal preference.

I will let you talk with Eric and keep my nose out - it was the thought of getting you stacker that wetted my interest - good look with your discussion. :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
5 years 3 months ago #32197

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 92
There is no need to upgrade CCDCIEL => ASTAP interface. That works fine. Adding INDI device driver between could add remote solving but there is no need for. Both programs can run locally in one system like PI3 or Linux laptop/desktop. An INDI device will most likely also delay the solving since the file will be transferred as a binary package.

After this discussion, I tend now to leave any INDI device driver development to the developers of Kstars/Ekos or MacOS applications (if they have interest). Introducing ASTAP as solver will beneficial for having an alternative to Astrometry.net and secondly in most cases ASTAP will solve faster if the image center position is known within maybe 10 degrees.

Han
5 years 3 months ago #32201

Please Log in or Create an account to join the conversation.

Time to create page: 1.807 seconds