Research · 2025

Space Traffic Digital Twin

Low Earth Orbit is getting crowded. This is a simulation of a thousand-satellite fleet that flies forward in time, watches for any pair of satellites about to come dangerously close, and shows the result on a 3D dashboard. It's a sandbox for asking how reliable a collision-warning system would be if it ran on noisy sensors instead of perfect knowledge.

Research Python Poliastro Astropy Dash
Fleet scale1,000+
Tick rate1 Hz
Conjunction scan<50 ms / 1000 sats
Default threshold5 km proximity

What it is

Every satellite in low orbit flies the same circle, just at slightly different angles and altitudes, which means their paths cross constantly. Most of those crossings happen a long way apart — but some come within a few kilometres of each other, and at orbital speed that gap closes fast. Operators care about predicting those near-misses (called "conjunctions") before they happen.

The interesting question isn't the physics of the orbits — that part is well-understood. It's how well a warning system holds up when the data feeding it is noisy and delayed, which is the realistic case. The simulation tracks both the "true" state of every satellite and a noisier sensor view, so you can see how those degraded inputs change which conjunctions get caught.

How it works

Six modules wired into a single tick loop:

  • orbital_mechanics/ — Keplerian + J2 propagation per satellite per tick.
  • spatial_indexing/ — KDTree rebuilt each tick for sub-50 ms proximity queries against 1,000+ satellites.
  • conjunction_detection/ — Tracks proximity events across ticks so an ongoing close-pass is one event, not a stream of duplicates.
  • risk_assessment/ — Three published collision-probability methods, weighted by mission criticality.
  • sensor_simulation/ — Adds noise and latency to the truth state so the dashboard isn't seeing a perfect feed.
  • dashboard/app.py — Dash on localhost:8050, 3D Earth + fleet, active conjunction list, time-step controls.

Stack: Python 3.8+. Poliastro and Astropy for orbital mechanics, NumPy/SciPy for the math, Plotly + Dash for the dashboard. State lives in memory; no database. The "digital twin" framing is what justifies running both the truth and the sensor view in parallel — that decoupling is the point of the project.

Where it's at

End-to-end working prototype. The fleet is synthetic — realistic orbital elements, not a real catalog. Only J2 perturbation; drag and solar pressure aren't modelled, so long-horizon predictions drift. The three collision-probability methods agree to within an order of magnitude — fine for ranking which conjunctions are worth attention, not for pricing insurance.