OpenAstro Roadmap¶

Three stages. Each one is independently valuable and builds the foundation for the next.

Stage 1: Existing Data Pipeline¶

Goal: Prove the calibration + combination pipeline works. Produce real scientific output with zero recruiting.

No live telescope network required. Pull from public archives. Validate the entire tech stack.

Data Sources¶

AAVSO — richest source. Millions of observations, API via astroquery.aavso, already flux-calibrated by observers with equipment metadata. Variable stars, exoplanet transits, supernovae.
ETD (Exoplanet Transit Database) — amateur transit submissions, timing data, good for TTV pipeline validation
MPC (Minor Planet Center) — structured amateur asteroid astrometry, standardized format
AstroBin — raw/processed FITS with equipment info; API access; not a science archive but large and accessible
Astrometry.net — plate-solved FITS with WCS headers; incidental archive

Pipeline Architecture (Modular)¶

Each stage is a standalone module with a clean process(input) → output signature. Swap stages independently.

INGEST → [raw FITS / light curve CSVs] per source adapter
   ↓
NORMALIZE → WCS check (plate-solve fallback), deduplicate, standard header
   ↓
CALIBRATE → zero-point vs. Gaia/APASS, color term correction, per-instrument registry
   ↓
COMBINE → flux-normalized SNR-weighted co-addition across heterogeneous instruments
   ↓
SCIENCE → light curve builder, Lomb-Scargle period search, TTV timing, n-body inference
   ↓
OUTPUT → calibrated FITS archive + instrument registry + light curves + paper

Instrument Registry¶

Database of characterized amateur instruments. Key fields: - instrument_id, observer_code, aperture_mm, sensor_model - zero_point, color_term_B_V, noise_floor_mmag - Populated by running the calibration engine against known fields

Every new data source you calibrate updates the registry. By the time Stage 2 starts, you'll know how to handle data from hundreds of instruments before they've submitted a single live observation.

First Science Target (to be chosen — candidates)¶

Known Mira / bright Cepheid period refinement — straightforward, clear success metric, AAVSO has decades of data
Exoplanet TTV from archival ETD — harder but directly relevant to core science; demonstrates the n-body pipeline
AGN variability long-baseline — interesting, less crowded literature niche

Pick one. Produce a paper. Even informal/arXiv. This is the proof of concept.

The Reverse N-Body Problem (TTV → Planet Parameters)¶

TTVs are deviations from a perfect transit period caused by gravitational perturbation from a second planet. The core question is: given the timing residuals, what can we infer about the perturber?

Forward problem: Given planet masses and orbits → simulate TTVs. Fast, deterministic.
Inverse problem: Given observed TTVs → infer perturber mass, period, eccentricity. Requires MCMC over a high-dimensional parameter space (hence BOINC/distributed compute relevance from the dump files).
Estimating n: The number of n-body components you need to fit — usually starts at n=2 (known transiter + one hidden perturber), but degenerate solutions may require fitting n=3. Bayesian model comparison (BIC/AIC) selects the right n.
Existing tools: TTVFast (Deck et al. 2014), allesfitter, juliet — all Python-accessible

This is a unique contribution. Most amateur networks collect transit times. Few run the full inverse inference. A pipeline that produces "here are the transit times AND the inferred perturber parameters" is a step above.

Stage 2: Volunteer Telescope Network¶

Goal: 10–50 active sites running the client, coordinated campaigns, first live multi-site paper.

Reducing Friction for Volunteers (from friction file)¶

Plate-solve-based pipeline: "point anywhere, we'll figure it out" — no polar alignment required for short exposures on alt-az mounts
Co-authorship incentive: 50 hrs accepted data = acknowledgment; 200 hrs = co-author
Passive mode: dark/flat frames on cloudy nights — keeps habit alive, produces data you need
Push alerts: "transient in your sky, 40 minutes to catch it" — turns routine into urgency
Raspberry Pi kit: pre-flashed, one cable, auto-starts at nautical twilight, observer never opens a laptop
"Adopt a star" ownership: each participant is the primary observer for a specific target
Seasonal campaigns (4–6 week bounded commitment) instead of indefinite year-round obligation
Morning digest: what the network achieved last night, your contribution %
Power users subsidize casuals: scheduler shows "94% coverage tonight without you — rest"
Live world map: social proof, recruitment pipeline built in

Outreach Targets¶

Cloudy Nights forum (Time-Sensitive Astronomy subforum)
AAVSO membership
r/astrophotography, r/telescopes
BAA and regional club mailing lists
Twitter/X astronomy community
AstroBin community

Science Campaigns for Stage 2¶

First priority: Multi-chord occultation (5+ sites across a shadow path) — immediate publishable result
Parallel: Continuous TTV monitoring of a high-interest exoplanet system
Opportunistic: Rapid transient follow-up on ZTF/Gaia alerts

Stage 3: OpenAstro-Owned Low-Cost Hardware¶

Goal: A backbone of network-owned robotic telescopes at strategic geographic locations that are always on and always available.

Why This Stage¶

Volunteers have weather, motivation, and availability gaps. Owned hardware fills critical longitude coverage and runs without human intervention.

Hardware Strategy¶

Low-cost CMOS cameras (security sensors like Sony Starvis — researched in massive info dump.md)
Small aperture robotic mounts (no-polar-alignment plate-solve setup)
Raspberry Pi clients pre-flashed with OpenAstro software
Hosted at astronomy clubs / dark sky sites / partner institutions in exchange for data access
Priority deployment locations: longitude gaps in volunteer coverage (currently unknown — map when Stage 2 data shows gaps)

Scale Target¶

5–10 owned nodes filling critical coverage gaps
Each node should be self-sustaining: auto-open/close dome or roll-off, weather sensors, watchdog restart

Milestone Timeline¶

Milestone	Stage	What It Proves
Calibration pipeline running on AAVSO data	1	Core tech works
Instrument registry with 20+ characterized instruments	1	Heterogeneous normalization works
First period measurement / TTV result	1	Scientific output is real
arXiv / ADS paper submitted	1	Legitimizes platform for recruiting
5 volunteer sites running client	2	Network is real
First multi-chord occultation	2	Unique science only a network can do
20 volunteer sites	2	Ready for serious campaigns
First owned node deployed	3	Network resilience
50+ combined sites	3	Publishable at scale

What You're NOT Building Yet¶

User account system / login (API keys only)
Real-time websockets or live streams
Machine learning for scheduling or classification
Perfect photometric pipeline (good enough beats perfect)
A pretty frontend (dashboard after pipeline works)

Practical Node Bringup Phases (from `massive info dump.md`)¶

A proven modular sequence for going from zero to a working multi-node network:

Phase 1 — Local Simulation: Set up one telescope and learn to control it completely (Ekos/INDI or Python + Alpaca client). Crucially, use a hardware simulator (most control software includes one) to test the full scheduler logic without touching the actual mount. This lets you debug the software stack in daylight.

Phase 2 — Two-Node Synchronisation: Get access to a second node (rented pier, a friend's telescope, or a second simulator on a remote server). Write the handover logic and WCS/reprojection code to successfully merge data from two nodes. This proves the core concept before scaling.

Phase 3 — Global Scaling: Integrate the third, fourth, and subsequent nodes. At this point, shift focus entirely to cloud-native scheduling and data warehousing (AWS/GCP/Azure for the central scheduler).

Feasibility tip: Spend 900f early effort making the software autonomous. A remote telescope is only practical if it can handle weather, safety, target acquisition, and data download with zero human intervention for weeks at a time.