MIRA: a data management and education platform connecting students to robotic telescopes

Source: arXiv:2607.14801 · Published 2026-07-16 · By Peter P. Pedersen, Lionel Garcia, Mahshid Alimi, David Degen, Florian Lienhard, Didier Queloz

TL;DR

MIRA (Mentored Investigations using Robotic Astronomy) addresses the challenge of scaling hands-on telescope experience to larger student groups while exposing them to authentic professional research workflows. Unlike many educational platforms that provide only fragmented access to telescopes, MIRA incorporates the full observation lifecycle: proposal drafting, peer review by mentors, automated scheduling, execution on robotic telescopes, automatic data reduction, and archival access with accompanying tutorials. The platform integrates educational front-ends with industrial-grade telescope controls via Astra and ASCOM Alpaca, enabling students to engage with astrophysical data acquisition and analysis resembling real observatory operations.

The authors contribute a dynamic programming–based scheduling algorithm that optimally sequences observations considering physical feasibility, transit timing, weather forecasts, and airmass constraints. On simulated synthetic nights, this exact Bellman planner scheduled more observations and secured a higher fraction of time-critical exoplanet transit observations than greedy or heuristic baselines, while maintaining competitive mean airmass. The platform automates FITS calibration, astrometry, and photometry and presents data through a downloadable searchable archive plus Python/Jupyter notebooks for guided analysis. MIRA therefore forms an integrated, mentor-guided workflow to train secondary and undergraduate students in observational astronomy with a research-grade pipeline.

Key findings

• Bellman dynamic programming scheduler scheduled on average 7.0 observations per 9-hour synthetic night over 100 simulations, outperforming astroplan priority (6.5), astroplan sequential (6.2), and SCOPES beam search (4.0).
• Bellman planner captured 79% (125/158) of time-sensitive exoplanet transit observations; astroplan priority captured 77%, sequential 37%, and SCOPES beam 16% (including empty schedules).
• Mean airmass ratio relative to Bellman planner medians: astroplan priority 0.976 (slightly better), astroplan sequential 1.011, SCOPES beam 1.127, demonstrating Bellman planner competes well in observation quality.
• Scheduling uses a reward function combining proposal priority (wp=1), orbital phase proximity (wφ=1), airmass penalty (wa=0.5), and weather weighting (ww=0.35), tuned for observational priorities.
• The platform automatically reduces raw FITS data including astrometric calibration and aperture photometry matched against Gaia catalog sources, storing products in a searchable web archive.
• Python/Jupyter tutorials accompany archival data to enable students to conduct guided scientific analysis replicating the observatory workflow.
• MIRA architecture separates web app (SvelteKit), workflow engine (Apache Airflow and Celery for scheduling and reduction), and telescope control (Astra over ASCOM Alpaca), supporting modular development and simulated operation.
• Simulation included 100 synthetic nights with variable weather (0–2 intervals of 30–120 min unsafe), 6–10 observations per night, and 20% transit candidates to mirror realistic constraints.

Threat model

n/a — The paper is primarily about an educational platform facilitating legitimate student proposals and observations using robotic telescopes. It does not model adversarial attackers or threat scenarios, focusing instead on operational scheduling and data workflows under normal environmental constraints.

Methodology — deep read

1. Threat Model & Assumptions: MIRA assumes an adversary is not directly modeled as it is an educational platform; the focus is on enabling students and mentors to interact collaboratively with autonomous telescopes in a controlled environment. The system assumes trustworthy mentors who review proposals and that telescope control software and data reduction are reliable. Environmental constraints (weather, altitude limits) and astrophysical constraints (transit windows) govern observation feasibility. Adversarial manipulation of schedules or raw data is not considered.

2. Data: The platform ingests student-drafted proposals specifying targets (via SIMBAD coordinate resolution), filters, exposure parameters, and scientific/technical justifications. Observing plans are tracked through states: draft, submitted, approved, or rejected. Simulations use synthetic nights of 9 hour duration starting 19:00 UTC, with 6–10 candidate observations, durations 20–90 minutes, randomly timed near meridian. Time-sensitive exoplanet transit candidates form 20% of proposals, requiring scheduling within specific orbital windows. Weather is simulated as clear with 0–2 unsafe intervals of 30–120 minutes to model realistic conditions.

3. Architecture / Algorithm: MIRA includes three containerized components: a web application (SvelteKit + SQLite/Drizzle ORM) for user interface, proposal management, and archive browsing; a workflow engine (Apache Airflow + Celery) orchestrating scheduling and automated data reduction tasks; and a telescope-control service (Astra integrated via ASCOM Alpaca) that interfaces with hardware or simulator.

The core scheduling algorithm uses exact dynamic programming (Bellman recursion) at one-minute resolution to find the optimal set and sequence of observations maximizing a reward function: reward(j,t) = wpPj + wφΦj,t - waAj,t + wwWj,t where Pj is proposal priority, Φj,t rewards timing relative to transit phase, Aj,t is mean airmass penalty, and Wj,t encodes forecasted weather. The planner avoids scheduling during unsafe weather or outside target altitude limits. This non-preemptive planning yields schedules with minimal dead time and adherence to transit constraints.

4. Training Regime: Not applicable as MIRA is a platform; however, scheduling optimizes nightly sessions. Simulations use fixed weights: wp=1, wφ=1, wa=0.5, ww=0.35; γ=0.999 discount factor; idle cost=0.01. No ML training but heavy computational dynamic programming is employed.

5. Evaluation Protocol: The Bellman planner is compared to three baselines: astroplan’s PriorityScheduler (greedy priority), astroplan’s SequentialScheduler (fixed queue), and SCOPES (beam search heuristic). Metrics are mean airmass ratio (compared per night over own schedules vs Bellman), number of scheduled jobs per night, and transit capture fraction (fraction of transit observations correctly scheduled).

Evaluation uses 100 synthetic nights with scenario variability in candidate numbers, durations, weather interruptions, and transit timing constraints. Analysis examines median and mean performance, coverage of transit windows, idle time, and scheduling robustness.

6. Reproducibility: Code components rely on publicly available frameworks: SvelteKit, SQLite, Apache Airflow, Celery, Astra observatory software (open source), and ASCOM Alpaca protocol. A custom Alpaca observatory simulator is used for validation, generating synthetic FITS images. While full source code release is not explicitly stated, simulator code is referenced publicly. Dataset includes synthetic scenarios, not real user data. Platform designed for modular deployment and planned on ETH Zurich 0.5m telescope.

Technical innovations

• An exact dynamic programming scheduling algorithm for robotic telescope observations incorporating time-critical transit constraints, weather forecasts, altitude limits, and multiple weighted objectives.
• An integrated educational platform combining proposal drafting, mentor review, automated scheduling, execution, data reduction, and archival access in a unified workflow.
• Architecture separating educational web interfaces from observatory control services via ASCOM Alpaca and Astra, enabling modular simulation and deployment.
• Automated data reduction pipeline performing astrometric calibration matched to Gaia catalog and aperture photometry, delivered with interactive Python tutorials for student-led analysis.

Datasets

• Synthetic observing nights — 100 nights simulated with 6–10 candidate observations per night, including 20% time-sensitive exoplanet transit targets — synthetic/simulator-generated

Baselines vs proposed

• astroplan PriorityScheduler: mean scheduled obs/night = 6.5, median mean airmass ratio = 0.976 vs Bellman planner 7.0 obs/night
• astroplan SequentialScheduler: mean scheduled obs/night = 6.2, median mean airmass ratio = 1.011 vs Bellman planner 7.0 obs/night
• SCOPES beam search: mean scheduled obs/night = 4.0, median mean airmass ratio = 1.127 vs Bellman planner 7.0 obs/night
• Transit capture: Bellman planner 79% (125/158), astroplan priority 77% (121/158), astroplan sequential 37%, SCOPES 16%

Figures from the paper

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

Fig 1: The plan editor for an exoplanet-transit proposal. The student identifies the target star and its transit parame-

Fig 2: The class view used by supervisors and administrators, listing enrolled members and their roles, the review

Fig 5: The archive view, searchable by target, telescope, user, and date, showing the reduced image for each completed

Limitations

• Evaluation is limited to synthetic simulated nights rather than real-world telescope operations with live weather and hardware fault conditions.
• No user studies yet to measure educational effectiveness, engagement, or learning outcomes from the MIRA platform workflows.
• Scheduling algorithm exactness scales exponentially with candidate observation count O(2^N), which may limit scalability to very large nightly queues.
• Data reduction pipeline results on real data remain to be validated; current tests use simulated FITS images which may lack all real instrumental effects.
• Weather forecasts in simulations are simplified and do not model realistic temporal or spatial stochasticity fully.
• No adversarial robustness or security evaluation regarding data integrity or platform misuse.

Open questions / follow-ons

• How will the scheduling algorithm perform in real telescope deployment with live and uncertain weather, hardware faults, and dynamic queue updates?
• Does the integrated workflow improve students’ understanding of astrophysical observation and scientific research practice compared to traditional teaching?
• How can scheduling reward weights be adaptively tuned using operational data to balance priority, transit coverage, airmass, and idle time?
• What is the optimal scale and scope for mentor review to maintain educational value while enabling larger student cohorts?

Why it matters for bot defense

While MIRA focuses on educational use of robotic telescopes rather than direct bot defense or CAPTCHA applications, it offers valuable design insights for platforms requiring mediated, permissioned access to shared resources. The mentoring and proposal review workflow parallels human-in-the-loop verification that could inspire layered authentication or human moderation in bot defense pipelines. Further, MIRA’s scheduling approach balancing multiple constraints and priorities objectively may inform adaptive challenge scheduling for CAPTCHA systems. The platform’s modular architecture separating user-facing front-ends from low-level controls and automated processing pipelines exemplifies scalable system design applicable to large-scale, secure user interaction services.

Cite

@article{arxiv2607_14801,
  title={ MIRA: a data management and education platform connecting students to robotic telescopes },
  author={ Peter P. Pedersen and Lionel Garcia and Mahshid Alimi and David Degen and Florian Lienhard and Didier Queloz },
  journal={arXiv preprint arXiv:2607.14801},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.14801}
}

Read the full paper

• arXiv:2607.14801 (abstract)
• arXiv:2607.14801 (PDF)