Can 100,000+ computing satellites share low Earth orbit without crashing into each other?
A plain-language guide to the AI Mega-Constellation Explorer
Open the interactive model Read the technical report (PDF) Source code on GitHub
What this is about
Several organizations are proposing to move data centers into space: fleets of tens of thousands of satellites doing AI computation in orbit. Computers produce heat, and in space the only way to get rid of heat is to radiate it away from large panels. Large panels make large targets. This tool started with a simple question: if you fly 100,000 satellites, each the size of half a tennis court, in the same band of low Earth orbit, how often would they collide? It has since grown into an end-to-end systems model: the same parameter set sizes the cooling system, the solar arrays and batteries, and the attitude control, adds the debris already in orbit, and shows how every design choice feeds back into collision risk.
The headline answer
Each satellite would have roughly a 6% chance per year of being hit. This is the "natural" rate: it measures how hard the collision-avoidance autopilot must work, not how many collisions actually happen. With avoidance that succeeds 99.9% of the time, actual losses drop to about 3 per year.
Four consequences follow from the physics, and they do not depend on fine details:
You cannot fix this with geometry. Spreading the fleet across a thicker band of altitudes dilutes the risk, but to reach one collision per year you would need to fill space out beyond the geostationary belt, 40,000 km up. No realistic orbit design makes the problem go away; only active steering, smaller satellites, or fewer of them do.
The stakes compound. At this density, the debris from a single breakup is likely to cause further collisions over the following years, each producing more debris: the runaway known as the Kessler cascade. You cannot dodge debris too small to track, so prevention and the reliable disposal of dead satellites carry nearly all the weight.
Bigger deployed area means more collisions, in direct proportion. Twice the area, twice the collision burden; and the burden grows with the square of the number of satellites. And the radiator is not even the biggest surface: the solar array that powers the computers is several times larger (about 716 m² for an 80 kW satellite in an eclipse-prone orbit). Counting it raises the collision workload roughly sevenfold, to about 21,000 per year. Every additional unit of computing power in orbit carries a proportional collision tax, and it is charged on the full wingspan.
Where and how fast matters. Collisions concentrate at high latitudes, where the orbital planes cross, and typical impact speeds are 10 to 15 km/s, around twenty times faster than a rifle bullet. Almost any hit is destructive.
How the model works, in one paragraph
The core contains two physical models. The first treats satellites like molecules of a very thin gas bouncing around a spherical shell, a classic approach from the 1970s. The second respects real orbital mechanics: every satellite follows an orbit, and at any point in space only certain velocities are possible. The second model is the trustworthy one; the first is the benchmark. Their agreement within about 25% is itself a finding, and the orbital model was checked against a brute-force simulation that tracked thousands of orbits and counted every close approach: prediction and count agreed within 3%. Around that core sit engineering models for cooling (a pumped two-phase loop sizing the radiator from chip temperature), power (solar arrays and eclipse batteries), attitude control (the torques and momentum the big wings create), and the debris already in orbit. Two independent published analyses have since cross-checked this work: one rebuilt the collision model from scratch and matched eleven of our numbers to three or more digits, and a JPL spacecraft-economics study independently anchors our solar-array sizing within 5%. The Validation tab shows the comparison live.
What the extended model found
The convenient orbit is the riskier orbit. Sun-synchronous orbits keep the sun at a fixed angle, which thermal and power engineers love. They also make every orbital plane near-polar, crossing every other plane at steep angles: the collision rate rises about 39% over a mixed constellation.
Hotter chips, safer fleet. Radiated heat grows with the fourth power of temperature, so running the processors hotter shrinks the radiator quadratically, and the collision target with it. Chip temperature turns out to be an orbital-safety variable.
Some debris cannot be dodged. Beyond collisions between the satellites themselves, the fleet flies through existing debris. Trackable objects add workload the autopilot can handle; the centimeter-class fragments too small to track cannot be avoided at all, and at this fleet size they would strike about 6,800 times per year. Only damage tolerance in the design (segmented radiators, shielding) reduces what those hits cost.
Attitude control is not the blocker. Despite 33-meter wingspans, the satellite's inertia is about half that of the Hubble Space Telescope, which points with ordinary reaction wheels. Standard wheels handle this vehicle with healthy margins; the structure costs agility, not control.
How to explore the problem yourself
Open the interactive model. The left panel sets the scenario, the cards at the top update instantly, and the 3D view shows a sample of the constellation: satellites are light blue where calm and flash red where the local collision risk concentrates; a 💥 marks a collision at the model's natural rate in simulated time.
| Try this | What you will see |
| Drag "N satellites" up or down | Collisions scale with the square of fleet size. |
| In the Thermal tab, drag GPU temperature (enable "drive A from Thermal") | Hotter chips shrink the radiator and the collision rate follows it down, live. |
| In Parameters, tick "count PV area in collision cross-section" | The solar array joins the target area and the collision workload jumps about sevenfold: the full deployed-area tax. |
| Switch "Orbit regime" to all Sun-synchronous | The thermally convenient orbit raises the collision rate about 39%, because all near-polar orbital planes cross each other at steep angles. |
| Move "Avoidance failure" | The difference between natural workload and actual residual losses. |
| Open the External Debris tab | What the environment does to the fleet: avoidable trackable encounters vs the centimeter-class hits nothing can dodge. |
| In the ADCS tab, switch radiator configuration | Folding the same area into a compact stack cuts the control problem almost fourfold. |
| Set "Radial profile" to a single thin shell | Concentrating everyone at one altitude multiplies the rate about 30 times. |
| Open the "Satellite scale" view in Collision Avoidance | The satellite next to a city bus, a tennis court, an ISS solar wing, and Hubble, to make the size concrete. |
| Open the Validation tab | Our numbers against two independent published analyses, as a live ratio chart: green bars on the 1.0 line are exact matches. |
What this model does not say
It does not say orbital computing is impossible; it says the viability rests on operations, not on orbit geometry. It does not predict any specific company's system; parameters are adjustable precisely so assumptions can be questioned. It simplifies: circular orbits, randomized orbital planes, an idealized avoidance system summarized by a single reliability number, and a deliberately simple cascade criterion. And it is an AI-generated model under verification: treat every number as provisional until checked. The mathematics, assumptions, and validation are documented in the technical report.
Feedback
If you spot a bug, disagree with an assumption, or have comments or feedback, please write to golkar@tum.de. The complete source code, including the Python engine, the Monte Carlo validation, and this site, is open at github.com/agolkar/orbit-collisions (MIT license).