Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[INFO/WISH] server API and headless setup #683

Open
GuLinux opened this issue Apr 3, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@GuLinux
Copy link

commented Apr 3, 2018

Hi,

I'm currently working on a lightweight web application for handling devices and generating sequences via INDI. The goal is to be able to start an astrophotography sequence by using only your browser, and it's particularly useful for users with embedded systems (Raspberry Pi, Odroid, etc). Most of these users are currently using a VNC server, which will increase network latency and drain batteries faster.

My project is still in very early stages (right now there's a fully functional INDI control panel, but no sequences support yet), you can have a look at the code here: https://github.com/GuLinux/StarQueW

Now for the PHD2 related question:
Personally I don't use an autoguider as I'm more into wide/mid field photography (<300mm), but I can see more and more users will probably want autoguiding as a feature.
And browsing the docs about your server API it seems that PHD2 has almost everything to be a guiding backend application.

I think the most important missing parts are:

  • APIs for setting up gear, retrieving images to display and more fine tuning in general of the guiding process
  • a non-gui version of the app

Do you think this could be possible? Or am I missing something?

Kind regards,
Marco

@agalasso

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2018

HI Marco,

We primarily envision PHD2 as something that a user sets up interactively, but then, once it is setup, it can be controlled and monitored either interactively or through the server API. You can see that the server API allows for control and monitoring of guiding by imaging apps, but essentially requires manual setup of an equipment profile.

I think it will be difficult to avoid the manual setup. The initial setup steps almost always require manual intervention (equipment connection, calibration, polar alignment.) However, once the setup is done (over VNC?) then automatic operation is expected and fully supported.

APIs for setting up gear,

not likely based on comments above

retrieving images to display

we currently have an api for that: save_image

and more fine tuning in general of the guiding process

we currently have API's for setting/getting guiding parameters, but, if phd2 is working properly parameter tuning should not be necessary (and we discourage it). PHD2 Best Practices

a non-gui version of the app

again, not something we be likely to pursue at this time, however we would be absolutely interested in making sure the server API has everything you need to control and monitor phd2 after the initial interactive equipment setup is done

Andy

@GuLinux

This comment has been minimized.

Copy link
Author

commented Apr 4, 2018

Hi,
That makes sense, of course.
And in fact, delegating the setup/configuration to PHD2 would ease my work a lot, as I'd have to create less UI and use less APIs for autoguiding.

But thinking about it, another solution, probably better and more useful, would be to create a daemon/frontend protocol, internal only to PHD.
This way PHD2 would still be configured by PHD2 UI, but using serialization over network. I did something like this with PlanetaryImager (although I had the advantage of Qt5 offering some interesting tools for serialization out of the box, not sure if there's anything like this on WxWidgets).

This would not be a public API (which needs more validations, docs, etc), but a private protocol, and might be useful to anyone using PHD2 remotely.

What do you think?

Thanks,
Marco

@agalasso

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2018

another solution, probably better and more useful, would be to create a daemon/frontend protocol, internal only to PHD. This way PHD2 would still be configured by PHD2 UI, but using serialization over network.

I'm not quite getting that. Could you elaborate? What would be serialized over the network?

(If you want to take discussion of github you can email me at andy.galasso@gmail.com; but ok to continue discussion here too)

@GuLinux

This comment has been minimized.

Copy link
Author

commented Apr 5, 2018

Not sure.. until we get too technical I guess it might be ok to continue here, it's all the same to me anyway :)

Well, serializing all the calls between UI and core classes, assuming there's already a fair separation between them (mine wasn't that much ready, but it didn't take too much to refactor it).

I produce three binaries in my build: the main PlanetaryImager, executable with no network serialization, where, say, the connect camera method from the UI is directly sent to the core class, and frontend and backend executables, where the connect camera method is sent to a serializer, through TCP, and then deserialized and sent to the core.

This of course really depend a lot on both the technology used in PHD2 (I know nothing about wxWidgets) and the internal design of the project

@jpaana

This comment has been minimized.

Copy link

commented Apr 19, 2018

This would be beneficial for setups running indiserver and PHD2 on Raspberry Pi and KStars on Windows for example who would like to run guiding locally but without running X just for PHD2. I have run such arrangement myself as well and after the initial setup didn't really have to touch PHD2, but still had to run VNC session to start it. Having it start as a daemon automatically on boot would be ideal for this particular use case.

@d33psky

This comment has been minimized.

Copy link
Member

commented Apr 19, 2018

I agree it would be good to have a headless PHD2 that can be controlled completely via API.
Serializing the UI <-> PHD2-Core comms sounds like a good first step to me.
It will be quite some work of course but would open up very interesting possibilities.

@GuLinux GuLinux referenced this issue Oct 12, 2018

Open

Autoguider #33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.