In this paper we present pyINDI, a web-friendly python port of the widely adopted Instrument Neutral Distributed Interface (INDI) protocol. The INDI model separates the GUI or “client” from the software that communicates directly with the hardware or “driver.” pyINDI includes tools for building a client or driver and is compatible with any INDI compliant software. On the client side, a JavaScript library communicates with the INDI driver. The client side also includes HTML and CSS tools to auto generate a GUI based on the INDI properties. A developer could also use the HTML and CSS tools to build a custom GUI. The driver and client APIs utilize python's asyncio library for low overhead concurrency. We will summarize the range of current pyINDI drivers and clients at the Bok, Kuiper and MMT observatories. We will then pivot to potential uses and expansions of pyINDI.
The telemetry data pipeline for the MMT Observatory (MMTO) describes the flow of data sampled from diverse hardware devices within MMTO subsystems, through logging into various databases, to user interfaces and monitoring services. Subsystems within the pipeline include the telescope mount, primary and secondary mirrors, instruments, and environmental sensors. Data acquisition services within the pipeline post new data with a uniform data structure to a master Redis server. These incoming data are transported in real-time to replicated Redis servers where they are logged into local MariaDB relational databases. Database tables for logged data from the subsystems are highly optimized for data storage, allowing the archival of billions of data points for thousands of parameters over the past 10-15 years. Because of ever increasing difficulty in supporting legacy servers and software, a large-scale containerization effort is underway of the various components of the telemetry pipeline and underlying cyberinfrastructure. These critical servers and services are single points of failure that could result in up to weeks of operational downtime. Containerization helps to reduce the risk of potential hardware failure, operating system upgrades, and software incompatibilities. Containerizing a service defines all the software requirements for that service, including the code, runtime, system tools, system libraries, and settings. It allows rapid and reliable redeployment of new and legacy services with minimal concern for the underlying hardware. Finally, a summary of the ongoing and planned future work is presented.
The Arizona Robotic Telescope Network (ARTN) project is a long term effort to develop a system of telescopes to carry out a flexible program of PI observing, survey projects, and time domain astrophysics including monitoring, rapid response, and transient/target-of-opportunity followup. Steward Observatory operates and shares in several 1-3m class telescopes with quality sites and instrumentation, largely operated in classical modes. Science programs suited to these telescopes are limited by scheduling flexibility and people-power of available observers. Our goal is to adapt these facilities for multiple co-existing queued programs, interrupt capability, remote/robotic operation, and delivery of reduced data. In the long term, planning for the LSST era, we envision an automated system coordinating across multiple telescopes and sites, where alerts can trigger followup, classification, and triggering of further observations if required, such as followup imaging that can trigger spectroscopy. We are updating telescope control systems and software to implement this system in stages, beginning with the Kuiper 61” and Vatican Observatory 1.8-m telescopes. The Kuiper 61” and its Mont4K camera can now be controlled and queue-scheduled by the RTS2 observatory control software, and operated from a remote room at Steward. We discuss science and technical requirements for ARTN, and some of the challenges in adapting heterogenous legacy facilities, scheduling, data pipelines, and maintaining capabilities for a diverse user base.
We describe a complex process needed to turn an existing, old, operational observatory - The Steward Observatory’s 61” Kuiper Telescope - into a fully autonomous system, which observers without an observer. For this purpose, we employed RTS2,1 an open sourced, Linux based observatory control system, together with other open sourced programs and tools (GNU compilers, Python language for scripting, JQuery UI for Web user interface). This presentation provides a guide with time estimates needed for a newcomers to the field to handle such challenging tasks, as fully autonomous observatory operations.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.