Space Connect

Space Connect is air traffic control for spacecraft, mapping what’s out there, how data can move between worlds, and what infrastructure we need to build the future space internet.

Comment

Project title

Space Connect Space Connect is a dynamic mapping, routing, and infrastructure-design platform built to explore one fundamental question: how do we keep humanity connected as we expand beyond Earth? Inspired by air traffic control and the architecture of the terrestrial internet, Space Connect uses real public orbital data to track spacecraft, satellites, planets, and their trajectories as they move through the Solar System, transforming those constantly changing positions into a dynamic communications network. Instead of assuming that two spacecraft can communicate simply because they are nearby, Space Connect evaluates the physical and technical conditions required for a connection, including orbital geometry, line of sight, light-time, contact windows, link budgets, radio capabilities, bandwidth, storage, and network capacity. From those possible connections, the platform constructs a time-dependent network mesh and uses delay-tolerant routing to determine how information can travel across it, including routes that do not exist now but become available in the future. Space Connect goes beyond visualizing theoretical paths by simulating the delivery of actual files: payloads are divided into chunks, stored and forwarded across available relays, reassembled at their destination, and verified end-to-end using SHA-256. Machine learning is used throughout the platform to help analyze the network, rank possibilities, and search large solution spaces while physics-based calculations remain the source of truth. Most importantly, Space Connect does not stop when a route is slow, unreliable, or impossible. Its infrastructure-design layer can identify network bottlenecks, evaluate potential relay infrastructure, rebuild the network with proposed additions, and test whether those changes actually improve the mission. Together, these capabilities form the four pillars of Space Connect — Track, Connect, Route, and Design — creating a framework not just for seeing the Solar System as it exists today, but for exploring how it could become an interconnected network tomorrow. As humanity returns to the Moon, travels farther into the Solar System, and ultimately establishes a permanent presence beyond Earth, communication will become foundational infrastructure. Space Connect is our attempt to build the map, routing intelligence, and design layer that can help humanity stay connected and prosper wherever we go next.

The project's organizing idea is a truthfulness grade attached to every number the system reports — REAL_VERIFIED, REAL_INCOMPLETE, ESTIMATED, SYNTHETIC, or UNKNOWN — so the UI never silently blurs a real measurement into a guess. Earth and Mars positions are REAL (JPL DE421), validated against JPL Horizons to within ~0.2–0.8 km. Relay spacecraft are SYNTHETIC and labelled as such. When the system doesn't know something (e.g. a tracked object's freshness has expired), it says UNKNOWN rather than inventing a plausible-looking value.

On top of the physics layer sits a machine-learning piece: an exact reliability oracle enumerates every relay-failure scenario and computes true delivery reliability and expected time by replanning routes under each one. Because that's expensive, a gradient-boosted surrogate model learns to rank which candidate relay placements are worth evaluating with the full oracle — but every number ever shown to a user is the oracle's, never the model's guess. A held-out evaluation (whole orbit families excluded from training, so genuinely unseen orbit shapes) shows the surrogate-guided search beating random search at an equal evaluation budget: mean regret 0.073 vs. 0.193 over 15 trials, winning 12 of 15 (p = 0.003) — and the honest twist is that the surrogate's own numeric predictions are mediocre on those unseen orbits (rank correlation 0.34); it still wins because choosing what to check only needs a roughly-right ordering, not precise numbers. Full methodology and limits: docs/ML_RESULTS.md.

The problem we're solving, and who it serves

Planning a space communications relay network is a geometry and physics problem before it's anything else: a link only exists during the window when two nodes have clear line of sight and enough signal budget, and a message's actual delivery time depends on waiting for the right sequence of those windows. Tools that fake this (always-on links, hand-waved "it'll probably route fine") give mission planners, students, and hackathon judges a false sense of confidence, and they can't be used to reason about failure — what happens if a relay goes down?

Space Connect serves two audiences at once: mission/network planners who need to ask "where should we put a relay, and how much does it actually help if X fails?" and get an answer backed by exact computation rather than intuition; and students/evaluators who want to see a real worked example of physics-constrained delivery timing, honest data provenance, and a rigorously-evaluated ML component, all in one small, inspectable system.

Team roster

  • Ishaan Acharya — data, ephemeris, ML (reliability oracle, placement sampler, surrogate ranker, evaluation harness)
  • Kris Lawrence — orbital geometry, satellite communications logistics, RF link analysis, performance analysis (physics, contacts)
  • Grayson — routing, messaging, API
  • Colson Herrin — UI, Idea, Tech Stack, Architecture , Demo, Video Presentation

Main track and side challenges

Main track: AI/ML

Side challenges entered: Shock Tracker: Zero Data — Space Connect has no accounts, sign-in, tracking, or stored personal information by design: it only ever touches public-source ephemeris/tracking data (JPL, CelesTrak) and synthetic simulation data, never anything about a person. That's the same reason the "test credentials" section below has nothing in it — there was never anything to collect.

(None of the other sponsor challenges — ElevenLabs, Tiger Data, Replit, Gemini, Vultr, Solana, Auth0, GoDaddy, Photon, or the Mercedes computer-vision challenge — use technology that's actually part of this project, so we're not claiming them.)

Public GitHub repo

https://github.com/pie-and-cat/space-connect

The README covers architecture, what's real vs. synthetic, run instructions, and known gaps.

Working demo / run instructions

No hosted demo link — this runs locally (it's a physics simulation with a local API + web app, not a hosted SaaS).

Windows, fastest path: double-click START-HERE.bat in the repo root. It sets up the Python virtualenv, runs the test suite, checks Node, and tells you how to start the API and web app.

Manual run:

python -m pytest -q                         # expect ~195 passed
# Terminal 1 — API
cd services && uvicorn api.main:app --reload --port 8000
# Terminal 2 — web app
cd apps/web && npm run dev

Then open http://localhost:5173.

Full walkthrough with timings: docs/DEMO.md.

Demo video

[FILL IN link, or note "pending" if not uploaded yet]

Technologies, APIs, datasets, and sponsor tools used

  • Backend: Python, FastAPI, NumPy, scikit-learn (HistGradientBoostingRegressor for the ML surrogate), pytest
  • Frontend: TypeScript, React, Three.js / @react-three/fiber (3D orbit visualization), Vite
  • Real data sources:
    • JPL DE421 ephemeris (via the de421 PyPI package) — real heliocentric Earth/Mars positions, validated against JPL Horizons
    • CelesTrak GP/OMM element sets — real tracked-object orbits (SGP4 propagation), with freshness/validity checking so stale elements are reported UNKNOWN rather than used silently
  • Synthetic/assumption-driven components (explicitly labelled as such in the UI and docs): relay spacecraft designs, radio/storage presets, relay failure probabilities, and cost units — documented in docs/ASSUMPTIONS.md
  • Sponsor tools: none — no sponsor API, SDK, or platform credit is used anywhere in the stack

Disclosure of anything made before Hacklanta

Nothing in this submission predates Hacklanta — the physics core, the ML pipeline, the API, and the UI were all built during the event. [If this changes — e.g. the team UI's base template predates the event — replace this line with the specifics; say which files/folders and when they were created.]

Test credentials or special instructions for judges

No accounts, API keys, or credentials are needed to run or evaluate the project — everything runs locally against public-source data (JPL DE421, CelesTrak) and synthetic/simulated components, with no external sign-in anywhere in the stack.

A few things worth knowing before evaluating:

  • The web app at http://localhost:5173 is the primary way to see it; docs/DEMO.md has a timed walkthrough.
  • The "Propose relay placements (ML)" panel takes ~30–60 seconds to warm up the first time (it's pre-scanning a fixed candidate library of contact windows in the background) — if it says "Warming up…", give it a moment rather than assuming it's broken.
  • python scripts/qa_flows.py is a no-UI fallback that prints a PASS/FAIL table of the same core flows (delivery, failure handling, relay suggestion) in about a minute, useful if the UI can't be run in a judging environment.
  • docs/VALIDATION.md and docs/ML_RESULTS.md have the measured numbers (validation against JPL Horizons, the ML evaluation results) if you want to check our claims rather than take them on faith — that's the point of the truthfulness-grading system.

Built With

Share this project:

Updates

Submission history