DEV Community: Harshita Venkatesh

Building ORBITGUARD: From TLE Data to Space Debris Collision Analysis

Harshita Venkatesh — Mon, 07 Sep 2026 15:46:09 +0000

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Why I’m Building at the Intersection of AI and Space Technology

Harshita Venkatesh — Mon, 07 Sep 2026 14:59:14 +0000

Why I’m Building at the Intersection of AI and Space Technology

Technology has always fascinated me, but two fields keep pulling me back more than anything else:Artificial Intelligence and Space Technology

At first, they seemed like two completely different worlds.

One deals with algorithms, data, models, and intelligent decision-making.

The other deals with spacecraft, orbital mechanics, satellites, robotics, and exploring environments far beyond Earth.

The more I started learning, however, the more I realized something:

The future of space exploration will increasingly depend on intelligent systems.

And that intersection is exactly where I want to build.

A Little About Me

I'm a Computer Science student at VIT Chennai, while also studying Aeronautics and Space Technology through IIT Madras.

My interests currently span:

Artificial Intelligence and Machine Learning
Space Technology
Autonomous Systems
Quantum Computing
Competitive Programming
Robotics and Sensor Fusion
Research

That's a lot of fields — and I'm definitely not an expert in all of them.

I'm learning.

I'm experimenting.

And most importantly, I'm building.

This blog is where I want to document that process.

Why Artificial Intelligence?

What fascinates me about AI isn't simply the ability to train a model.

I'm much more interested in the question:

How can we build systems that make useful decisions when the real world is uncertain?

Real engineering problems rarely provide perfect information.

Sensors have noise.

Predictions have uncertainty.

Conditions change.

Sometimes several objectives have to be balanced simultaneously.

That makes areas such as machine learning, anomaly detection, explainable AI, optimization and autonomous decision-making** particularly interesting to me.

And then I started thinking about where these capabilities could have some of their most exciting applications.

That led me to space.

Why Space Technology?

Space is one of those fields where almost every engineering decision becomes more challenging.

Communication can be delayed.

Resources are limited.

Environments are extreme.

Failures can be incredibly expensive.

And spacecraft often need to operate with significant levels of autonomy.

That means future space systems won't just need better hardware.

They'll need better intelligence.

Imagine systems capable of:

detecting dangerous orbital situations,
reasoning about uncertain trajectories,
assisting spacecraft maneuver decisions,
allowing lunar robots to navigate when visibility disappears,
detecting anomalies before they become failures,
or helping autonomous spacecraft make decisions without constant human intervention.

These aren't simply AI problems.

They're AI + physics + engineering problems.

That's the combination I find exciting.

One of My Projects: ORBITGUARD

One project that pushed me further into this intersection is ORBITGUARD.

I started exploring the problem of space debris and satellite collision risk.

There are thousands of objects orbiting Earth, and understanding whether two objects could approach dangerously close requires much more than looking at their positions on a screen.

While developing the project, I started learning concepts such as:

Two-Line Elements (TLE)
SGP4 orbital propagation
Time of Closest Approach (TCA)
Miss distance
Relative velocity
Orbital mechanics
Collision-risk analysis

I then began exploring how computational and AI techniques could complement the physics layer through concepts such as anomaly detection and uncertainty-aware analysis.

One lesson became very clear:

AI shouldn't replace physics in safety-critical engineering systems.

Instead, AI can search, detect patterns and assist decisions while physics provides an independent layer of verification.

That idea has heavily influenced how I think about intelligent engineering systems.

Beyond ORBITGUARD

I'm also interested in problems where traditional sensing may fail.

One direction I'm exploring involves Non-Line-of-Sight lunar rover docking.

Imagine a lunar rover trying to return to a docking or charging station.

Normally, cameras or other optical systems could help guide it.

But what happens when visibility becomes unreliable?

What if darkness, terrain or lunar dust interferes with the line of sight?

This leads to an interesting engineering question:

Can multiple sensing methods and intelligent sensor fusion help a rover dock when vision alone isn't enough?

It's still something I'm exploring, but these are exactly the kinds of questions I want to investigate.

And Then There's Quantum Computing

Another field I'm beginning to explore is Quantum Computing.

I'm particularly interested in its possible intersection with machine learning and explainable AI.

Quantum machine learning is still a developing research area, which makes it both challenging and exciting.

For me, this isn't about attaching the word "quantum" to an AI project.

I want to understand the fundamentals first:

What problems could quantum approaches genuinely help with?

Where would classical machine learning still be better?

Can quantum models become interpretable?

Those are questions I hope to explore through future projects and research.

Why I'm Starting This Blog

It's easy to show a finished project on GitHub.

What's harder to see is everything that happened before the final commit.

The failed experiments.

The bugs.

The concepts that initially made no sense.

The design decisions.

The approaches that didn't work.

And the moment when something finally did.

That's what I want this blog to capture.

I'll be writing about things such as:

Space Technology

Orbital mechanics, spacecraft systems, autonomous space systems and projects I'm building.

AI/ML

Models, experiments, datasets, mistakes and what I'm learning while developing intelligent systems.

Programming

Python, competitive programming, algorithms and software engineering.

Quantum Computing

My journey from fundamentals toward quantum machine learning and research.

Research

Interesting questions, papers I'm studying, experiments and research projects.

Hackathons

How projects evolve under tight deadlines, what goes wrong and what I learn from building with a team.

Where I Want This Journey to Go

I don't know exactly what I'll be building several years from now.

And I actually like that.

Right now, my goal is simpler:

Learn deeply. Build constantly. Ask difficult questions. Document the process.

I want to become someone who understands both the algorithms running inside a system and the engineering principles governing the world that system operates in.

Because some of the most interesting problems of the future won't belong to a single discipline.

They'll exist at the intersection of many.

For me, one of those intersections is:

AI × Space × Engineering × Research.

And this blog is where I'm going to document the journey.

Thanks for reading.

This is only the beginning.