Topics

APPM Plate Solving Alternatives (again)


Xentex
 

I have read the prior threads and believe I understand the state of affairs with APPM and ASTAP (i.e., still in the exploratory stages).

I expect a Mach2 in my hands this month and the plate solving approach that seems to make the most sense to me is SGPro (using ASTAP).  I already use ASTAP (mostly through NINA) for my existing plate solving and am very comfortable with it.  It's already on my imaging PC.  (I don't recall ever having a plate solve fail that wasn't truly unsolvable because of clouds, etc.)

After installing SG Pro and looking at it a bit I see that SGPro uses a REST interface for the API.  It also appears to be documented pretty well.  But I don't know whether 1) this is the only API SG Pro offers, and 2) if that's how APPM is communicating with SG Pro to do the plate solves.

That made me think, if the REST API is how APPM is doing plate solves through SG Pro, I don't actually need SG Pro.  I can just create a REST wrapper for ASTAP that uses the same protocol (which SG Pro documents well enough).

Has anyone else ever looked down this path?

Going a step further, given that NINA is open source the thought occurred to me to cobble something together for NINA.  That might be more trouble than it's worth since my understanding is I'd probably have no other reason to run APPM and NINA at the same time.  But to the extent anyone else wanted to benefit from this approach, they wouldn't have to install a separate wrapper written by some random dude on the internet.

My goal is less about about the money than the unnecessary complexity of using SG Pro as nothing but a simple wrapper to ASTAP.

PS:  I don't expect any kind of APPM or AP support for this approach.  The idea is that APPM wouldn't know the difference.  It would look exactly the same to APPM. I think that's the value of using REST APIs.  But if there's a reason it won't work (like APPM isn't using the REST API) then that would be helpful to know.  By the same token, if APPM doesn't have to know what's on the other side of the REST interface then any imaging program (NINA, Voyager, APT...) could add APPM compatibility.  Dare to dream, maybe an ASCOM module some day (since I understand ASCOM supports REST).


Xentex
 

Well, I see that 5 minutes after I posted this that Ray says ASTAP will be supported in the next version of APPM.  So I guess for all practical purposes my question is moot.

Although I do think it would be nice for ASCOM to eventually have a plate solving interface.


Dale Ghent
 

On Dec 6, 2020, at 13:10, Xentex <michael@widner.me> wrote:

That made me think, if the REST API is how APPM is doing plate solves through SG Pro, I don't actually need SG Pro. I can just create a REST wrapper for ASTAP that uses the same protocol (which SG Pro documents well enough).

Has anyone else ever looked down this path?

Going a step further, given that NINA is open source the thought occurred to me to cobble something together for NINA. That might be more trouble than it's worth since my understanding is I'd probably have no other reason to run APPM and NINA at the same time. But to the extent anyone else wanted to benefit from this approach, they wouldn't have to install a separate wrapper written by some random dude on the internet.
Hey, a NINA dev here :)

I've considered the same - just making a wrapper program that listens on the SGPro API server TCP port and speaks the commands needed to solve an image via ASTAP (or other solver). This plus ASCOM Camera in APPM itself would decouple APPM from requiring a large surrogate app like SGPro or TSX (which is what I've been using to build models).

Users of 10um mounts are in a similar situation, only their modeling program can call ASTAP directly, it does not talk to cameras in any way - it also relies on having SGPro available to it to operate a camera. One NINA dev has such a mount and he has implemented a subset of the SGPro API in NINA to service this purpose. I am in the process of adding the API endpoints that APPM needs (the solving parts) to it. But....

But with Ray's announcement here that direct ASTAP support will be in the next major release of APPM, that makes APPM a self-suffiicient app that doesn't rely on "heavy" external software to do any part of its imaging or solving, and we can now just have APPM and ASTAP installed, and that's it! Good news. Not sure if this means I'll finish my SGPro endpoint work or not, as the NINA devs are unanimous in that we would rather put such API energies into our own design.

/dale