Research · 2025
Space Traffic Digital Twin
There are more than ten thousand active satellites in low Earth orbit, and reality only plays forward at 1×. A digital twin is the way around that: a copy of the sky in software, fed by the same tracking data operators use, that can be fast-forwarded, interrogated, and experimented on. The demo below builds one from live data, in your browser, in three steps.
What a digital twin is, in one idea
A digital twin is a virtual copy of a physical system that stays synchronised with the real thing through live data — close enough to reality that you can ask it questions you can't ask reality. You can't fast-forward the sky to see whether two satellites collide tonight. You can fast-forward a good copy of it. That asymmetry is the entire value: the twin takes the risks, runs the rehearsals, and burns the compute; the real fleet only ever flies the manoeuvre that already worked in software.
The demo above walks that loop end to end. Mirror: the globe starts as a live map of the real catalog — every dot is a real object, drawn from the same public tracking data (CelesTrak GP elements) real operators consume, with the ISS tagged so you have a landmark. Predict: the twin sweeps the next three hours of orbits and ranks the closest approaches it finds, before they happen. Act: you nudge one satellite by a few centimetres per second — a realistic collision-avoidance burn — and watch the predicted miss distance open from hundreds of metres to kilometres. The real satellite never moved.
The data is real
Positions come from CelesTrak's general-perturbations catalog — the publicly distributed orbital elements for every tracked object — fetched live through a small caching proxy and propagated in your browser with SGP4, the standard model used for exactly this data. If the live fetch fails, the page falls back to a bundled snapshot and says so in the corner badge: the demo never pretends stale data is fresh. When the list says two Starlink spacecraft pass within 900 m at 14:32 UTC, those are real spacecraft on their current elements.
How it works
Two implementations share one architecture, in one repository
(space_traffic_digital_twin):
a Python research sim (src/, Dash dashboard) and the browser twin you just used
(web/, identical to the copy this site serves). Module for module:
- orbital_mechanics/ — Kepler + J2 propagation in Python; SGP4 on real elements in the browser, with positions computed at fixed substeps and interpolated for rendering so playback speed never distorts the physics.
- conjunction_detection/ — KDTree range queries in Python; a uniform spatial hash here, plus an analytic closest-approach solve between substeps so a 14 km/s crossing can't slip between two frames unnoticed.
- risk_assessment/ — collision probability from miss distance and a position uncertainty that grows with prediction lead time (a simplified Foster-style estimate).
- sensor_simulation/ — "researcher mode" in the sandbox: time-correlated (Ornstein–Uhlenbeck) tracking noise, and a tally of close passes the noisy twin missed or hallucinated versus truth — the original research question of the project.
- manoeuvre planning — the what-if burn uses the Clohessy–Wiltshire equations: an along-track impulse drifts a satellite off its old timeline at roughly −3·Δv per second of lead time, which is why centimetres per second are enough.
Honest limitations
Screening uses point estimates rather than propagated covariance ellipsoids, the collision probabilities are order-of-magnitude indicators rather than insurable numbers, and the browser tracks a subset of the catalog (up to 2,500 objects of ~15,000) to stay smooth on ordinary hardware. The shortcuts are chosen to preserve the architecture, not to hide the hard parts — the README in the repo maps each simplification to what an operational system would do instead.