OrbitML corrects a satellite's orbit predictions with a small neural network. Two weeks out, the error of SGP4 (the standard model) drops from about 2 km to 750 m. Some steps of the project are visualized with the Aurora rendering engine.
Where it started
OrbitML grew out of a gap in my CV: several of the final-year internships I was interested in involved machine learning, and none of my projects really did.
I also wanted something visual, to make use of Aurora. Satellites ticked both boxes, and two papers by Peng and Bai[1][2] provided a concrete problem: predict an orbit with SGP4, then learn to correct its error.
Picking a satellite
The first step is to pick a satellite whose exact position is public (or at least known far more precisely than SGP4's error). The European Sentinel satellites fit the bill.
So I started with Sentinel-1A, but a problem showed up quickly: the satellite made dozens of manoeuvres in 2024. The trouble with manoeuvres is that they can't be predicted. You have to work around them, which makes the task harder and probably degrades the data.
So I switched to Sentinel-6A: at an altitude of 1,336 km, it only manoeuvred 4 times that year.
Sentinel-1A's semi-major axis in 2024, with the 75 clearest burns.
The method
I didn't reproduce either paper as is. The 2018 one[1] works on simulated data, a layer of complexity that added little here. The 2019 one[2] uses real data, but with SVMs (Support Vector Machines), whereas my goal was to work with neural networks.
The project combines the two: the method and real data of the second, the network of the first.
Overfitting
My first models all ran into the same problem: overfitting. That was what surprised me most. I pictured models as boxes you feed as much data as possible, and they figure things out on their own. Instead, they just memorized the data.
The error is measured in three directions: radial (too high or too low), along-track (ahead or behind) and cross-track (off to the side).
The fix came down to fewer inputs (and better-chosen ones), proper validation, and stopping training at the right moment.
The error keeps falling on the training set, but climbs back up on the test set after a few epochs.
Longitude
Even after all that, the models still weren't very good. Digging into the remaining error turned up a 12-hour period, tied to the Earth's rotation. SGP4 ignores the longitude below the satellite, yet gravity varies from place to place.
The map below shows the error depending on where the satellite is above the Earth. It reveals that the equator isn't a perfect circle: the Earth is slightly oval, hence the two lobes.
Adding longitude as an input cuts the along-track error from 63% to 39%, and the radial error from 36% to 13%.
The mean radial error, before the network knows where the satellite is.
Results and limits
Over 14 days, the final network leaves 13% of the radial error, 39% of the along-track error and 18% of the cross-track error. A rewrite in PyTorch reaches the same scores.
SGP4's drift at 14 days, from 96 TLEs held out for testing.The same cloud after correction, in green.
These numbers have their limits: one satellite, one year… Complex physical effects such as solar radiation pressure, or that oval equator (the C22 term), would be worth digging into.
Other satellites and other years would be the logical next step, but that would be more orbit determination than machine learning, and neural networks were what I set out to work on.
References
[1] H. Peng and X. Bai, Artificial Neural Network–Based Machine Learning Approach to Improve Orbit Prediction Accuracy, Journal of Spacecraft and Rockets, 55(5), 2018.
[2] H. Peng and X. Bai, Machine Learning Approach to Improve Satellite Orbit Prediction Accuracy Using Publicly Available Data, The Journal of the Astronautical Sciences, 2019.
OrbitML corrige les prédictions d'orbite d'un satellite avec un petit réseau de neurones. À deux semaines, l'erreur de SGP4 (le modèle standard) passe d'environ 2 km à 750 m. Le moteur de rendu Aurora est utilisé pour visualiser certaines étapes du projet.
Point de départ
OrbitML est né d'un manque sur mon CV : des stages de fin d'études qui m'intéressaient portaient sur le machine learning, et aucun de mes projets n'en faisait vraiment.
Je voulais aussi un sujet visuel, pour tirer parti d'Aurora. Ce sujet sur les satellites coche les deux cases, et deux articles de Peng et Bai[1][2] donnent un problème concret : prédire une orbite avec SGP4, puis apprendre à corriger son erreur.
Choisir un satellite
La première étape est de choisir un satellite dont la position exacte est publique (ou du moins connue bien plus précisément que l'erreur de SGP4). Les satellites européens Sentinel sont dans ce cas.
On choisit donc Sentinel-1A, mais un problème apparaît rapidement : ce satellite a effectué des dizaines de manoeuvres en 2024. Le problème des manoeuvres, c'est qu'on ne peut pas les prédire. On doit alors travailler autour, ce qui complique la tâche, et probablement dégrade la qualité des données.
On choisit donc Sentinel-6A : à 1336 km d'altitude, il n'a manoeuvré que 4 fois dans l'année.
Le demi-grand axe de Sentinel-1A en 2024, avec les 75 poussées les plus nettes.
La méthode
On ne reproduit aucun des deux articles. Celui de 2018[1] travaille sur des données simulées, une complexité qui n'apportait pas grand-chose ici. Celui de 2019[2] part de données réelles, mais utilise des SVM (Support Vector Machine), alors que mon but était de travailler sur des réseaux de neurones.
Le projet croise les deux : la méthode et les vraies données du second, le réseau du premier.
Le surapprentissage
Les premiers modèles que j'entraîne souffrent tous du même problème : le surapprentissage. C'est ce qui m'a le plus surpris. Je voyais les modèles comme des boîtes à qui on donne le plus de données possible et qui se débrouillent. Mais les modèles apprennent les données par coeur.
On mesure l'erreur dans trois directions : radiale (trop haut ou trop bas), le long de l'orbite (en avance ou en retard) et hors du plan (décalé sur le côté).
La solution passe par moins d'entrées (et des entrées réfléchies), une vraie validation et un entraînement arrêté au bon moment.
L'erreur continue de baisser sur l'entraînement, mais remonte sur le test après quelques passages.
La longitude
Mais même après tout ça, les modèles ne sont toujours pas très performants. En analysant l'erreur restante, on trouve une période de 12 h, liée à la rotation de la Terre. SGP4 ignore la longitude du point survolé, alors que la gravité varie d'un endroit à l'autre.
La carte ci-dessous montre l'erreur en fonction de la position du satellite au-dessus de la Terre. On y voit que l'équateur n'est pas un cercle parfait : la Terre est légèrement ovale, d'où les deux lobes.
Ajouter la longitude en entrée du modèle fait passer l'erreur le long de l'orbite de 63 % à 39 %, et l'erreur radiale de 36 % à 13 %.
L'erreur radiale moyenne, avant que le réseau sache où se trouve le satellite.
Résultats et limites
Le réseau final laisse 13 % de l'erreur radiale, 39 % le long de l'orbite et 18 % hors du plan sur 14 jours. Une réécriture en PyTorch retrouve les mêmes scores.
La dérive de SGP4 à 14 jours, à partir de 96 TLE gardés pour le test.Le même nuage après correction, en vert.
Ces chiffres ont leurs limites : un seul satellite, une seule année… Des phénomènes physiques complexes tels que la pression de radiation solaire, ou cet équateur ovale (le terme C22), pourraient être approfondis.
D'autres satellites et d'autres années seraient la suite logique, mais ce serait davantage de l'orbitographie, alors que je voulais avant tout travailler sur les réseaux de neurones.
Bibliographie
[1] H. Peng et X. Bai, Artificial Neural Network–Based Machine Learning Approach to Improve Orbit Prediction Accuracy, Journal of Spacecraft and Rockets, 55(5), 2018.
[2] H. Peng et X. Bai, Machine Learning Approach to Improve Satellite Orbit Prediction Accuracy Using Publicly Available Data, The Journal of the Astronautical Sciences, 2019.
