Astra: an open-source fully autonomous robotic observatory control software

Source: arXiv:2607.12898 · Published 2026-07-14 · By Peter P. Pedersen, David Degen, Lionel Garcia, Urs Schroffenegger, Daniel Sebastian, Sebastián Zúñiga-Fernández et al.

TL;DR

Astra is an open-source, cross-platform Python software system designed to fully autonomously control robotic astronomical observatories without requiring external message-brokering infrastructure. By leveraging the ASCOM Alpaca HTTP/REST standard for device communication, Astra decouples high-level orchestration from platform and driver specifics. Key features include continuous safety monitoring via multi-layer watchdogs, a flexible JSONL-based action scheduler, plate solving with an online Gaia catalog fallback to a local Gaia–2MASS catalog, autofocus routines using a companion package astrafocus, and PID-based autoguiding directly on science frames. Astra also integrates a FastAPI web interface for live control, telemetry, and image previewing.

Deployed in production since January 2024 on six telescopes across three observatories—including SPECULOOS-South (Chile), SAINT-EX (Mexico), and ETH Zurich—Astra has demonstrated robust, fully unattended multi-week operation. Performance metrics from SPECULOOS-South show sub-arcsecond autoguiding precision with a median pointing scatter of 0.11 arcseconds and plate-solve failure rates below 1% for most telescopes, confirming that an open, standards-based approach can meet production reliability and precision demands for modern survey astronomy.

Key findings

• Astra has run continuously in fully unattended production since January 2024 across six telescopes at three observatories.
• At SPECULOOS-South, Astra achieves 0.11 arcsecond median autoguiding pointing scatter across four 1 m class instruments.
• Plate solving failure rates remain below 1% on three of the four SPECULOOS-South telescopes, and 3% on the narrowest-field telescope.
• The SafetyMonitor watchdog evaluates environment and device health on 1-second polls with a 15-minute rolling max_safe_duration to trigger observatory closure without false reopenings.
• Astra’s multi-process device model isolates each ASCOM Alpaca device subprocess, preventing faults in individual hardware from blocking observatory control.
• The JSONL schedule format allows robust, incremental editing and safe validation of nightly observing plans before execution.
• Autofocus routines leverage local Gaia-2MASS catalogs and multiple focus-measure operators for robust, analytic extremum detection across varying thermal/gravity conditions.
• The autoguiding approach uses image cross-correlation (donuts library) on science frames to generate real-time mount pulse guide commands, avoiding separate guide cameras.

Threat model

The paper does not specifically define a security-oriented threat model. Astra’s architecture assumes an operational environment where device faults or environmental hazards can occur, but adversarial attacks on the software or hardware are out of scope. The main threat mitigated is unintentional hardware or communication failure that could cause equipment damage or loss of observations, handled via software isolation and safety watchdog.

Methodology — deep read

1. Threat Model & Assumptions: Astra assumes adversaries are not explicitly modeled as it is an operational observatory control system. The main concern is robust fault tolerance and autonomous recovery from hardware and environmental failures without human intervention. Adversaries cannot manipulate device subprocess isolation or safety watchdog logic.

2. Data: The system operates in real-time on live observational data and environmental measurements. Telemetry includes device parameters, observed image frames, guiding residuals, and weather parameters logged into a SQLite database. Plate solving and autofocus routines leverage external astrometric catalogs (Gaia, 2MASS), with fallback to a local catalog copy.

3. Architecture/Algorithm: Astra is structured around a main Observatory process managing several managers (SafetyMonitor, ScheduleManager, etc.) and isolated device subprocesses for each ASCOM Alpaca device (Telescope, Camera, Dome, etc.). Device subprocesses poll their devices at configurable intervals (default 5 sec, 1 sec for safety monitors) and communicate asynchronously with the main process via multiprocessing.Pipe and Queue. The safety watchdog runs on a dedicated thread, evaluating both external safety monitor (via ASCOM SafetyMonitor interface) and internal per-parameter environmental constraints over rolling time windows to determine safe/unsafe states, triggering dome closures on unsafe conditions.

Scheduling uses a JSONL format representing sequential Actions with timing and device-specific commands, verified for viability (elevation, filters). The schedule runner dispatches concurrent device commands per paired device sets, enabling parallel actions. Plate solving is performed by detecting bright stars using DAOStarFinder, then matching star catalogs with twirl for WCS calculation, with fallback to local catalogs

Autofocus uses the astrafocus package which selects suitable stars from catalogs, performs focus sweeps sampling multiple focuser positions, and fits analytic or nonparametric curves using several focus-measure operators (HFR, FFT sharpness) to estimate optimum focus. The autoguider cross-correlates science frames against stored references to compute pixel shifts, converted to ASCOM pulse guide mount commands.

4. Training Regime: Not applicable—no training; sequential command execution based on hardware interaction and catalog lookups.

5. Evaluation Protocol: Operationally evaluated on real telescope networks: SPECULOOS-South, SAINT-EX, and ETH Zurich over continuous multi-week campaigns since early 2024. Key performance metrics include pointing scatter (0.11 arcseconds median), plate-solve failure rates (<1–3%), and zero aborted schedules attributable to Astra software. Data collected includes guiding residuals, error flags from devices, and telemetry stored longitudinally for monitoring.

6. Reproducibility: Astra is fully open-source (GitHub repository referenced), distributed as a PyPI-installable Python package targeting Python 3.11. Configurations and catalogs can be locally customized. All external hardware communication conforms to the ASCOM Alpaca HTTP/REST protocol. The paper details config file and schedule formats to enable reproducibility at other sites.

Concrete Example: An observation night at SPECULOOS-South runs a JSONL schedule with Actions targeting TOI-700. For an object action, Astra triggers camera cooling, performs a plate solve using Gaia catalog, if pointing error >0.1 arcsecond slews and retries up to three times, then starts autoguiding using donuts cross-correlation on updated science frames. The SafetyMonitor continuously evaluates environmental conditions every second; if limits breach (e.g. humidity), the dome closes automatically. FITS headers are asynchronously completed post-exposure fetching relevant instrument telemetry logged in SQLite.

Technical innovations

• A multi-process isolated device subprocess architecture prevents device faults from blocking main observatory control logic, enhancing robustness over monolithic driver approaches.
• Astra’s JSONL-based schedule format enables incremental, line-wise editing and partial validation, improving reliability and operational flexibility over monolithic JSON arrays.
• Integrated safety watchdog evaluating rolling time-window environmental and device health conditions to autonomously manage observatory enclosure state without false reopenings.
• Autoguiding implemented directly on science camera frames using efficient image cross-correlation (donuts) avoids the need for separate guide cameras.
• Plate solving hybrid method combining online Gaia catalog queries with local Gaia–2MASS fallback ensures reliability under intermittent internet connectivity.

Datasets

• SPECULOOS-South telemetry and image data — 4 × 1 m telescopes — proprietary operational data
• SAINT-EX observatory telemetry — 1 m telescope — proprietary operational data
• ETH Observatory telemetry — 0.5 m telescope — proprietary operational data
• Gaia DR2 / 2MASS catalogs — multi-million star astrometric catalogs — public data

Baselines vs proposed

• Autoguiding pointing scatter at SPECULOOS-South: legacy ACP system not reported / Astra: 0.11 arcseconds median
• Plate solving failure rates: commercial ASCOM monolithic systems not explicitly reported / Astra: <1% for most telescopes, 3% for narrow-field instrument

Figures from the paper

Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2607.12898.

Fig 2: Astra browser interface during an active observing sequence. The Summary panel shows live device states and

Fig 1: Astra system architecture. The dashed boundary marks the main process; each Alpaca device runs in a sepa-

Fig 3 (page 5).

Fig 4 (page 5).

Fig 3: Autoguiding performance and detrended transit light curve of TOI-6716.01 observed by SPECULOOS-South

Limitations

• No formal adversarial or security threat evaluation; system assumes benign hardware and network conditions.
• Evaluation limited to production performance metrics on three observatories; no controlled benchmark against alternative OCS frameworks.
• No in-depth analysis on recovery from extreme hardware failures beyond device fault logging and shutdown triggers.
• Internet independence depends on fallback catalog availability; updates to local catalogs may be manually managed.
• No open dataset or detailed logs released to enable community-wide reproducibility of performance results.

Open questions / follow-ons

• How does Astra perform under simulated network or hardware adversarial conditions, e.g. spoofed Alpaca commands?
• Can the scheduling and execution architecture adapt to dynamic, real-time transient alerts rather than pre-generated JSONL schedules?
• What are the scalability limits to operating larger networks of heterogeneous telescopes with Astra?
• How to integrate machine learning techniques for predictive maintenance or anomaly detection within Astra’s modular framework?

Why it matters for bot defense

While Astra is not directly related to bot-defense or CAPTCHA, its architectural principles of modular, isolated subprocesses communicating asynchronously with a robust supervision watchdog provide useful parallels for designing resilient automation and control systems. The use of cross-platform, open-standard communication protocols (ASCOM Alpaca’s REST API) demonstrates the viability of avoiding platform lock-in and minimizing external dependencies, lessons which can inform CAPTCHA service orchestration in distributed and heterogeneous deployment environments. The multi-threaded safety watchdog that evaluates rolling environmental and health conditions to enact protective measures can inspire similar fail-safe layers for CAPTCHA services defending against operational faults or abuse.

For bot-defense engineers, Astra’s comprehensive telemetry logging with SQLite and REST/WebSocket real-time exposure illustrates how observability at multiple system layers enhances automation robustness, enabling timely intervention and diagnostics—an approach translatable to CAPTCHA backend monitoring. Although the domain differs, Astra’s design to achieve fully autonomous, unattended operation under real-world constraints may inform the development of CAPTCHA systems with enhanced self-healing and failover properties.

Cite

@article{arxiv2607_12898,
  title={ Astra: an open-source fully autonomous robotic observatory control software },
  author={ Peter P. Pedersen and David Degen and Lionel Garcia and Urs Schroffenegger and Daniel Sebastian and Sebastián Zúñiga-Fernández and Brice-Olivier Demory and Elsa Ducrot and Michaël Gillon and Matthew J. Hooton and Clàudia Janó-Muñoz and James McCormac and Mathilde Timmermans and Amaury H. M. J. Triaud and Didier Queloz },
  journal={arXiv preprint arXiv:2607.12898},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.12898}
}

Read the full paper

• arXiv:2607.12898 (abstract)
• arXiv:2607.12898 (PDF)