From Code to Constellations: My first project as a space engineer

#space #gnss #satellites #engineering

Introduction

I've always seen myself as a problem-solver. For a decade, those problems lived in electronics and code. But a spark ignited during my master's in GNSS, where I had to bridge two worlds: my background in software and robotics, and the complexity of satellite constellations.

This project is that bridge. It's my first attempt to build a system that takes a rover's trajectory data and satellite data (from GPS and Galileo) and estimates its positions to see how close it gets to "reality." It might sound abstract, but this is the very heart of reliable autonomous navigation.

And, like any first attempt, I hit a wall quickly. It wasn't a specific bug; it was the sheer overwhelm of everything new. Suddenly, I was:

Deciphering the sparse, esoteric structure of RINEX files.
Navigating different coordinate reference frames, trying to understand how to convert one into another.
Wrestling with how the rover's own attitude influences GNSS estimates.

It was like learning to read all over again, but with a dictionary written in a language that was only vaguely familiar. The temptation to give up whispered in my ear, but the problem-solver inside me said, "This is just another system to understand."

The Internal Debate: Choosing the First Tool

My software engineer instinct screamed: "Research, compare, choose the optimal tool!" I knew the end goal was to implement a Kalman Filter, the gold-standard tool for this job. But I also knew you don't start by running a marathon; you learn to walk first.

So, what was my decision? To start with a simple Lagrangian interpolation.

It's not the most glamorous solution, but it's a solid foundation. It allows me to understand the data flow, validate the inputs and outputs, and, most importantly, establish a baseline. This baseline will be crucial for measuring the improvement once I implement the Kalman Filter later. Sometimes, the best choice is the one that lets you make progress today, not the perfect one you might build tomorrow.

The Current State: The "It Works!" Moment

Right now, the project is in what I'd call a "promising alpha" stage. The code runs. It can generate GNSS measurement estimates, produce Line-of-Sight (LOS) and Position (POS) files, and plot the initial results.

The most rewarding part? Seeing the results fall within the expected orders of magnitude. That first plot, the one that actually resembles reality, is the biggest motivational boost you can get. It’s a tangible sign that you're on the right path.

The Open Question: Looking Ahead

The foundation is laid. Now, the path forks into multiple optimization branches. The Kalman Filter is the obvious next step, but I know there's more to robustness than just one algorithm.

So, I'd like to open the floor to those who have walked this path before. If I could ask one thing to an expert:

"Beyond implementing the Kalman Filter, what single improvement had the most significant impact on the performance or robustness of your sensor fusion system when you moved from a working prototype to a robust solution?"

Was it a specific outlier detection method? A particular way to model sensor errors? A data fusion architecture that proved exceptionally resilient?

I'm all ears for your war stories and wisdom. Let me know in the comments.