POCS indi support thread


#1

Hi all,

Following a suggestion from @james.synge I am starting this thread with the hope it will help to build support for INDI devices either by me, or POCS developper.

I have a complicated history with POCS, I find it to be an awesome project, designed by very talented people. But because of some legacy code that I wrote, and did not wanted to get rid of, I decided to introduce (lots of) pocs code into mine, instead of restarting from a pocs fork.

Getting back to the current state of my Indi support in my modified version of POCS, it is rather poor, because:
-very few devices class have been implemented: mainly camera, and mount. (focuser in project), dome filterwheel in medium term goal and maybe AAG cloudwatcher in a far future, but not sure.
-Among those classes, few features are actually implemented (mainly goto synchronize, take image). But I would say that the base integration boilerplate code is there
-Everything is untested (withing the pytest framework) or mostly untested (in real conditions).

I still have a lot of work to do in order to improve this integration, and the process will go along the build of my own setup and observatory (that may span over 2+ years).

As the time span is quite long, I though developer here may want to benefit from some of my work without needing to wait for that long to get everything well integrated and tested. And I could definitely help.

Lets start with a few questions/remarks that may guide the integration:

  1. Distributed aspect. The magic of indi is that it provides an API that allows to control an arbitrary number of devices, hosted on an arbitrary number of hosts. That open doors for potentially controlling a big observatory with multiple equipments like multiple mounts, each equipped with multiple telescopes/sensors. In this regard, I saw that POCS make use of ZeroMQ, but from what I saw, it is mainly used for PAWS<->POCS<->Arduino or PAWS<->POCS<->AAG communications, not so much for controlling multiple units at once ?

  2. Easy testing. POCS does features a set of simulators, I must admit that I have never been using because, I was really impressed by the quality of Indi simulators (and I decided to use those).

  3. Guiding/spectroscopy. OpenPHD2 has an API that is compatible with indi, so one should be able to automate guiding, that would be particularly useful for spectroscopy (in my opinion). Indi has also support for some spectroscope. I can’t tell how awesome it would be for me to be able to do automatic acquisition of both photometric and spectroscopic data with multiple equipements.
    Example: https://github.com/tlemoult/spectroDb/blob/02b6ea1ea72d14ba29e2eb5a7c0b50894be16f2f/telescope/indi/guide.py

  4. Maintenance. I would like to advertise POCS in my local network of amateur/semi pro astronomers, In the hope it would drive more people to help develop it. However, I would like to do so only if I think the project as a whole will benefit a large community, so in my mind, this imply people also writing drivers for indi, and not low level serial interface that will be hard to take apart from POCS in case the project is no longer maintained. I am especially thinking about spectroscopy, because there seems to be a huge need for such automation/scheduling tools to observe transient/periodic phenomena in spectroscopy in amateur/pro cooperation projects.

  5. Dependency hell. Part of the success of POCS I guess, comes from the fact that proper testing has been done on local code. and this is especially important as the project seems to be growing, and more and more expensive gear is being run in real world conditions. I would perfectly understand that one does not want to introduce indi because of that.

  6. Fun. Goes along with maintenance, but really, I think the indi ecosystem keeps evolving and so many cool applications are being, and will keep being developed by astronomers. I have been working on integrating for instance part of this project for real time rendering of astronomical gear in a virtual environment, for simulation purpose: https://github.com/geehalel/npindi/blob/master/docs/screenshots/mount3D.png

  7. POCS forks. I am far from being aware of the latest development / cool forks of POCS, although I know that @ahorton has been doing some very cool work with POCS. Maybe part of the abovementionned points have already been tackled and I am not aware of that.

Ok, now please let me answer (if I can) any question you have about a potential integration of indi inside POCS.
We can also jump on the more technical aspects with examples of code, or actual issues that INDI integration triggers (mainly interfaces, that are much higher level in indi than in pocs for mounts and camera).


#2

Lots of food for thought (and discussion) here. A few quick(ish) comments:

  1. The huntsman-pocs add-on for POCS, used by the the Huntsman Telescope, includes a distributed system based on the Pyro4 library. Huntsman has an array of cameras, each with an associated focuser (and, soon, filterwheel), all on one telescope mount. huntsman-pocs allows each camera + focuser to be controlled by a separate Raspberry Pi, with observatory level functions (mount, dome, scheduling, weather, etc.) running on a central control computer. It’s a rather ad-hoc solution though, and is certainly very clunky at present. I do know @wtgee has long term plans to turn POCS into a proper distributed system using the ZeroMQ messaging system already in limited use within POCS.

  2. Testing of the hardware specific code is a known issue with POCS. The simulators we have work at the level of a generic camera, generic focuser, etc. This enables thorough unit testing of the base class for each hardware type and the higher level code that interfaces with that type of hardware, but leaves code in the hardware specific classes uncovered. The only way to improve on that would be to implement lower level simulators, at the driver level. I’ve worked on a project that did just that (the replacement of the Anglo-Australian Telescope’s telescope control system), and while it was extremely successful it was an enormous amount of work.

  3. POCS has limited support for automated guiding, through the interface with Software Bisque mounts controlled by TheSkyX software. I’m sure INDI supports many more configurations, though.

  4. Coincidentally there was a discussion on Twitter recently where the idea of pulling out the hardware interface aspects of POCS into a standalone library was raised, for just these sorts of reasons. It’s something we’re looking at. Even more coincidentally part of the reason for the interest in the POCS code was dissatisfaction with the performance of the corresponding INDI driver… (for ZWO ASI cameras) Hard to follow, multiply branching Twitter thread starts here: https://twitter.com/vacant3rdman/status/1093365476179075074

  5. INDI would certainly be a big, new, external dependency. It would also be a major change for POCS, which is already in use by several observatories. Because of that it we would need to continue maintenance of the existing POCS in parallel with development of the INDI version, at least until the new version was ‘production ready’. I’m not saying that this is sufficient reason not to do it, but we’d want to be clear that the benefits are worth the effort, and that we have the developer resources needed to pull this off in a reasonable period of time.

  6. That does look fun!

  7. Perhaps relevant to note that huntsman-pocs started off as a fork of POCS, but quickly diverged from the base fork to the point where merging anything in either direction became an almost impossible task. It took drastic surgery by @wtgee to get us back to a workable situation. huntsman-pocs is now not a fork, but an add-on, containing only the additional states and classes required for Huntsman specific functionality. As a development model this has been working out really well. https://github.com/AstroHuntsman/huntsman-pocs