Building ORBITGUARD: From TLE Data to Space Debris Collision Analysis

In my first post, I wrote about why I'm interested in the intersection of artificial intelligence and space technology.

This time, I want to talk about actually building something at that intersection.

Meet ORBITGUARD — a project I started while exploring one deceptively difficult question:

How can we help spacecraft operators understand potential debris encounters and make safer decisions?

What started as a space-debris analysis project gradually became an exploration of orbital mechanics, simulation, uncertainty, AI, and decision-support systems.

And along the way, I discovered something important:

Building AI for space isn't just about training a model.

You first have to understand the physics.

🛰️ The Problem: Space Is Getting Crowded

Earth's orbital environment contains operational satellites, inactive spacecraft, rocket bodies and enormous amounts of debris.

When objects travel at orbital velocities, even a small fragment can become dangerous.

That creates an interesting engineering problem.

Suppose we are protecting a spacecraft.

We need to answer questions such as:

Where will nearby debris objects be in the future?
How close will they come to our spacecraft?
When will the closest approach occur?
How fast are the objects moving relative to each other?
How uncertain is our prediction?
Should the encounter actually concern an operator?
If a maneuver is considered, could it accidentally create another dangerous encounter?

These questions became the foundation of ORBITGUARD.

The ORBITGUARD Pipeline

At a high level, the system follows this pipeline:

Orbital Data
↓
TLE Parsing
↓
SGP4 Orbit Propagation
↓
Position + Velocity Estimation
↓
Relative Motion Analysis
↓
Time of Closest Approach (TCA)
↓
Miss Distance
↓
Risk Assessment
↓
AI / Anomaly Analysis
↓
Operator Decision Support

Let's break it down.

1. Starting With TLE Data

The first thing ORBITGUARD needs is orbital information.

For my experiments, I worked with Two-Line Element sets, usually called TLEs.

A TLE contains parameters describing an object's orbit at a particular epoch.

Conceptually, it looks like this:

OBJECT NAME
1 XXXXX ...
2 XXXXX ...

The numbers encode orbital information including parameters related to:

inclination
eccentricity
right ascension of the ascending node
argument of perigee
mean anomaly
mean motion

Initially, TLEs looked like two mysterious lines of numbers.

Once I started understanding what each orbital parameter represented, the rest of the project became much easier to reason about.

For testing ORBITGUARD, I used the ISS (ZARYA) as a protected spacecraft and selected debris objects for encounter analysis.

1. Propagating the Orbit With SGP4

A TLE doesn't directly answer:

Where will this satellite be 20 minutes from now?

For that, the orbit needs to be propagated.

ORBITGUARD uses SGP4 — Simplified General Perturbations 4.

Using the Python sgp4 package, I can construct a satellite object from its TLE:

from sgp4.api import Satrec

satellite = Satrec.twoline2rv(line1, line2)

Then, for a chosen time, SGP4 estimates the object's position and velocity.

Conceptually:

TLE
↓
SGP4
↓
Position vector r = [x, y, z]
Velocity vector v = [vx, vy, vz]

Now both the protected spacecraft and debris object can be represented in the same orbital state space.

This is where the project starts becoming much more interesting.

1. Calculating Relative Motion

Knowing where two objects are individually isn't enough.

What matters for collision analysis is their position relative to each other.

If:

r₁ = spacecraft position
r₂ = debris position

then the relative position is:

r_rel = r₂ - r₁

Similarly:

v_rel = v₂ - v₁

The instantaneous separation can then be calculated as:

distance = ||r_rel||

In Python:

import numpy as np

relative_position = debris_position - spacecraft_position
relative_velocity = debris_velocity - spacecraft_velocity

distance = np.linalg.norm(relative_position)
relative_speed = np.linalg.norm(relative_velocity)

This gave ORBITGUARD two extremely useful quantities:

relative distance and relative speed.

But there was still a problem.

The current distance isn't necessarily the important distance.

Two objects might currently be thousands of kilometres apart while moving toward a much closer encounter.

So I needed to estimate the future closest approach.

1. Finding the Time of Closest Approach

This introduced me to one of the most important concepts in conjunction analysis:

TCA — Time of Closest Approach

TCA represents the time when two objects are predicted to be closest to each other.

A simple relative-motion estimate can provide an initial approximation.

For relative position r and relative velocity v:

t* = -(r · v) / ||v||²

But orbital trajectories aren't straight lines.

So instead of treating this estimate as the final answer, ORBITGUARD can use it as a starting point and propagate the objects around that time to refine the encounter.

The idea becomes:

Initial State
↓
Approximate TCA
↓
Propagate Around Candidate Time
↓
Measure Separation
↓
Find Minimum
↓
Refined TCA

This was one of the moments where the project shifted from simply processing satellite data to actually performing orbital encounter analysis.

1. Calculating Miss Distance

Once TCA is found, another critical quantity becomes available:

Miss Distance

Miss distance is the predicted separation between the two objects at their closest approach.

Conceptually:

Miss Distance =
|| r_debris(TCA) - r_spacecraft(TCA) ||

During one of my ORBITGUARD experiments, the system analyzed a selected group of debris objects and produced an encounter summary containing:

Protected spacecraft: ISS (ZARYA)

Objects analyzed: 10

Closest object:
NORAD 33768

Predicted miss distance:
~1889 km

Risk classification:
LOW

That particular encounter obviously wasn't a collision threat.

But that is actually useful.

A collision-analysis system shouldn't manufacture dramatic alerts.

It should distinguish routine orbital separation from genuinely concerning conjunctions.

1. Turning Orbital Physics Into Features

Once the physics pipeline was working, I started thinking about where machine learning could actually contribute.

Instead of feeding arbitrary orbital data into a model, I constructed features derived from the encounter itself.

Some of my initial features included:

features = [
initial_distance_km,
miss_distance_km,
time_to_tca_seconds,
relative_speed_km_s
]

This transforms each encounter into something like:

Encounter
↓
[Initial Distance,
Miss Distance,
Time to TCA,
Relative Speed]
↓
Machine Learning / Anomaly Analysis

I then experimented with feature scaling and anomaly detection.

The goal isn't:

Let AI decide whether satellites collide.

The goal is closer to:

Let physics calculate the encounter, then use AI to help identify unusual or important patterns.

That distinction became very important to how I think about AI systems.

1. Why I Don't Want AI to Replace the Physics

One of the design principles I want ORBITGUARD to follow is:

AI recommends. Physics verifies.

Imagine an AI system eventually recommends an avoidance maneuver.

It shouldn't simply output:

MOVE SATELLITE

and expect an operator to trust it.

Instead:

AI proposes maneuver
↓
Orbital simulator propagates maneuver
↓
Primary collision risk checked
↓
Secondary encounters checked
↓
Fuel / ΔV cost evaluated
↓
Mission constraints evaluated
↓
Recommendation explained

The physics layer therefore acts as an independent verification mechanism.

I think this becomes especially important when AI is involved in safety-critical systems.

1. The Secondary Collision Problem

Avoiding one object doesn't automatically mean the maneuver is safe.

Imagine:

Satellite
↓
Debris A detected
↓
Maneuver generated
↓
Debris A avoided

Great.

Except the new trajectory could potentially move the spacecraft closer to:

Debris B

Now we've solved one problem while creating another.

One future component I want to explore is therefore a Secondary Collision Firewall.

Before accepting a maneuver:

Candidate Maneuver
↓
Propagate New Orbit
↓
Re-check Surrounding Objects
↓
Any New Dangerous Encounter?
↙ ↘
YES NO
↓ ↓
Reject Continue

This turns collision avoidance from a single-object problem into a multi-object decision problem.

1. Accounting for Uncertainty

Real orbital predictions aren't perfect.

Measurements contain uncertainty.

TLEs contain uncertainty.

Future states contain uncertainty.

So instead of asking:

Where exactly will the debris be?

a more realistic system should ask:

What range of future trajectories is plausible?

A future ORBITGUARD version could simulate many possible trajectories:

Current Orbital Estimate
↓
Add Position / Velocity Uncertainty
↓
Generate Many Possible Futures
↓
Propagate Each Future
↓
Analyze Encounter Distribution
↓
Estimate Risk

This would move the system toward uncertainty-aware conjunction analysis rather than relying on a single deterministic trajectory.

1. Multi-Objective Maneuver Optimization

Collision avoidance isn't simply:

Move as far away as possible.

A maneuver could affect:

collision risk
fuel consumption
ΔV
mission orbit
future conjunctions
operational constraints

So the problem can eventually be formulated as:

Find maneuver M

that minimizes:

Collision Risk

• Fuel Cost
• Mission Disruption
• Secondary Collision Risk

Instead of producing one mysterious answer, ORBITGUARD could present operators with several alternatives:

Maneuver A
Lowest collision risk
Higher ΔV

Maneuver B
Balanced option
Moderate ΔV

Maneuver C
Lowest fuel usage
Slightly higher uncertainty

The operator remains part of the decision.

1. Explainable Maneuver Recommendations

If an intelligent system recommends Maneuver B instead of Maneuver A, I want it to explain why.

For example:

Recommended: Maneuver B

Reason:
✓ Reduces primary conjunction risk
✓ No dangerous secondary encounters detected
✓ 31% lower ΔV than Maneuver A
✓ Maintains mission-orbit constraints
✓ Robust across simulated uncertainty cases

This is where my interest in Explainable AI (XAI) connects naturally with space systems.

The goal isn't only intelligent automation.

It's intelligent automation that humans can interrogate.

What Building ORBITGUARD Has Taught Me

ORBITGUARD is still an evolving project, and there is a huge difference between a student prototype and an operational spacecraft collision-avoidance system.

But building it has already taught me something that I couldn't have learned from tutorials alone.

Physics matters.

AI can't compensate for an incorrect understanding of the system being modeled.

Data matters.

Understanding where orbital data comes from and what its limitations are is just as important as writing algorithms around it.

Uncertainty matters.

Real engineering systems rarely give perfectly deterministic answers.

Explainability matters.

Especially when algorithms influence safety-critical decisions.

Software engineering matters.

Even a good algorithm becomes difficult to use if the surrounding pipeline is unreliable or impossible to understand.

And perhaps most importantly:

Projects are one of the best ways to discover what you don't know.

Every feature I added to ORBITGUARD generated another question.

And those questions became things I wanted to study.

Where ORBITGUARD Goes Next 🚀

My current roadmap includes exploring:

uncertainty-aware trajectory simulation
conjunction probability estimation
multi-object encounter analysis
maneuver generation
ΔV-aware optimization
secondary-collision verification
physics-verified AI recommendations
explainable decision support
interactive 3D orbital visualization
larger-scale debris analysis

Eventually, I'd like ORBITGUARD to become less of a simple collision-analysis prototype and more of an experimental platform for studying AI-assisted autonomous space safety systems.

Final Thought

When I started ORBITGUARD, I thought I was building a space-debris project.

Instead, I ended up learning about orbital mechanics, coordinate systems, propagation algorithms, relative motion, optimization, uncertainty, machine learning and explainable AI.

And I'm still at the beginning.

That's probably my favourite part.

There are still a lot of things I don't understand yet — which means there are a lot of things left to build.

GitHub: ORBITGUARD
Topics: Space Technology · Orbital Mechanics · Python · AI/ML · SGP4 · Explainable AI