Home - skybadger/PyObsHub GitHub Wiki

Welcome to the PyObsHub wiki!

Purpose

The objectives of this tool are to support getting the most out of your expensive instruments , either by maximising your own return on usefulness or making spare time available to others. 0. Users can run their own instruments on their own scopes directly through the GUI and/or managed by an optimised schedule of observations to run the system to obrain complete sets of observations, whether images, spectra, video.

  1. Users can run multiple scopes against the same targets, controlled and synchronised centrally manually or though the scheduler.
  2. Users can setup up observation target lists, defining what aspects of the target they are interested in, with priority and timeliness which are automatically scheduled according to a number of user, instrument and target parameters.
  3. Multiple scopes and instruments can be allocated and scheduled through the internal scheduler which operates across all users in parallel to obtain maximum output from registered hardware.
  4. Observation timings can vary from alert-response quick look to long duration imagery, activity monitoring and survey
  5. Users can configure to receive system alerts on obecjts of interest such as novae, Be stars etc and stations can elect to be suitable first responders with appropriate equipment.

Scope

Initially this will support devices available only by IP such as Alpaca and then Indi. There will be no attempt to support local devices using local drivers.. Where functions need local support such as guider software the intent is again for that software to be supported over IP - for example this means ktools and Phd2 rather than implementing a very long distance guider loop on the server back to the telescope. Other components will include focus optimiser tools, planetaria ( not provided by this tool ) and local observation conditions tools like SQM, rain, weather, temperature tools.

User Roles

Who are the intended Users ? The smallest scale targeted is the amateur with a single scope and associated equipement and this is already catered for in lots of equipment such as Nina, Voyager, Maxim, The Sky and Prism . Even the multi camera problem is catered for when the target is a long running one since you can normally run two instances of the same local software talking to each of the camers, at the same time. The issues start to arise when you want to run two cameras without loss of images due to one mount performing an offset dither, focus and filter wheel shakes, between-target moves for shorter targets etc while the second camera is still imaging and has no control. More speciallised tools like Voyager and Prism support multiple cameras in the 'array' feature but dont support the sequencing when using Array and donlt support multiple mounts acting in synchrony. Nina supports sync between dither for two instances using two different cameras but no more.

At the more advanced amateur level, that user wants to run more than one program of work on their (expensiv) multiple scopes, maybe one for variable stars or exo planets, and another for spectroscopy, even while doing manual visual on their third. Who doesn't want to do some real science ?

At the club level, persistent ( i.e. observatory-housed kit that isnt being used by the owner due to pressures of work or life can be made available to club projects or club shared use

At the largest scales, around the world, amateur ( ie non-paying) kit can be made available relatively simply through this tool for users to sequence quite complex sets of observations over multiple cameras, timezeones and spectral bands.

So I propose there are these potential Users

  • System administrators - configure this system
  • Site owners - own the configuration and hardware for a site and responsibility for a site and its tools, including making them available to the server with any dependencies
  • Instrument configuror - Owns the detailed knowledge and configuration aspect of individual instruments on a telescope port.
  • Observer - wants to schedule an observation on their own kit and other telescope ports on other people's kit if available.

Modes of operation

This app will support : A Single Scope on a mount for manual use over a gui interface ( python capable host required) or via an observing schedule run by the server. More than one instruments on a single mount with synchronised image/data acquisition per target via an observing sschedule run by the server More than one mount with instruments on it, of which some instrunents are tasked to coopoerate on imaging/data acquistion via an aobserving schedule run by the server.

Multiple servers operating a distributed scheduling capability over the peered networks for a follow-the-sun operation

##Instruments This tools supports different types of instruments for which different acquisition and operatins scripts will be developed as the defeault position for operating but these will be able to be overriddden on a per-instrument basis through device configuration. The initial spec starts at an port with an imaging device with filter wheels, rotators and focuser. The port may be specified to be a guide port. Extension of this to specoscopy will include the defition of a cobination of ports to provide guide, image and wavelength control as well as focuser for the main imager.

Architecture.

The system architecture is RESTful micro-services implemented in Python which are acessible over HTTPS or http to authorised users. Users are integrated into a peered authorisation system which requires each site to enable users to be validated for access requests. Supported Devices must implement the ASCOM Alpaca interface ( roadmap target 1 ) followed by INDI ( roadmap target 2).

Technology

The server is hosted at my house until such a time as the scaling extends beyond a simple network and requires extended reliability, at which point it will be moved to hosting on cloud services.

Support

Feel free to fork or download Please contact to become a collaborator - its not a small project but there are giants shoulders to stand on. Raise an issue to get attention.

Limitations

All components need to be accessible over IP from the central server All components need to be available and powered or provide powerup and powerdown processes that are remotely executable as part of a station's configuration