Jits Doomen

Astrodynamics / Computational Conjunction Assessment

Investigating computational methods for satellite conjunction assessment.

PINOcam — an independent research and software project

PINOcam brings together orbital propagation, catalogue-wide spatial screening, numerical collision-probability calculations, and machine-learning-based estimation in a single computational research pipeline.

The Github Repository
PINOCAM v1.0.0 Astrodynamics Python PyTorch ONNX C++

Research Problem

Reducing computational cost without losing sight of the numerical reference

Satellite conjunction assessment involves several computational stages. Orbital objects must be propagated, potential close approaches identified, encounter geometry calculated, and collision probability evaluated. The cost of these operations becomes increasingly relevant when screening large catalogues.

PINOcam investigates whether a machine-learning surrogate can approximate two-dimensional collision-probability calculations at lower inference cost. The model is trained against numerical reference calculations and evaluated in logarithmic probability space.

The research question is not whether a neural network can replace astrodynamics. Orbital propagation and encounter geometry remain part of the computational workflow. The narrower question is whether one computationally expensive step—collision-probability estimation—can be approximated efficiently while retaining acceptable agreement with its numerical reference.

Pipeline Architecture

A sequence of astrodynamics and computational stages

The project is structured around the following workflow. The machine-learning model is one component within it; it does not perform orbit propagation or independently determine encounter geometry.

1 | Orbital Data

Retrieve orbital elements and propagate catalogue objects using SGP4

2 | Candidate Screening

Apply spatial filtering to identify candidate close approaches

3 | Encounter Analysis

Calculate relative states and encounter-plane parameters

4 | Probability Estimation

Evaluate collision probability using a numerical reference or the trained surrogate

5 | Evaluation

Compare estimates and investigate the limitations of the current assumptions

Implementation

The components of PINOcam

PINOcam includes the data-generation, screening, numerical, learning, and deployment components needed to investigate the research question. These components have different purposes and should not be interpreted as having the same level of validation or operational maturity.

1 | Model

Physics-regularized neural-network surrogate

A PyTorch multilayer perceptron estimates log10(Pc) from encounter and uncertainty parameters. Its training objective combines supervised error against numerical reference calculations with physics-based regularisation terms. The current implementation is an MLP, not a neural operator.

PyTorch MLP Log-Space ONNX
2 | Screening

All-vs-all conjunction screening

The screening pipeline propagates catalogue objects using SGP4 and uses a three-dimensional cKDTree for spatial candidate filtering. The purpose of this stage is to reduce the set of object pairs requiring more detailed encounter analysis.

SGP4 cKDTree Catalogue Propagation Python
3 | Numerical Reference

Two-dimensional Foster integration

A two-dimensional Foster collision-probability implementation provides numerical reference values for model development and evaluation. Its numerical accuracy and agreement with independent implementations remain important validation questions.

Collision Probability Foster Method Numerical Integration
4 | Data

Conjunction and CDM data generation

The project includes synthetic conjunction-scenario and Conjunction Data Message data-generation components. The generated data supports model training, but its scenario coverage and assumptions constrain how broadly the resulting metrics can be interpreted.

CCSDS CDM Data Generation Training Data
5 | Deployment

ONNX and native C++ inference

The trained model is exported to ONNX. A native C++ inference wrapper using the ONNX Runtime C API provides an alternative inference path alongside the Python implementation.

C++ ONNX Runtime CMake vcpkg
6 | Verification Utilities

Symbolic and dimensional checks

SymPy-based utilities check selected mathematical expressions and dimensional relationships used in the project. These checks support implementation review; they do not constitute formal verification of the complete software system.

SymPy Symbolic Mathematics Dimensional Analysis

Preliminary Model Results

Reported performance on the current evaluation dataset

The v1.0.0 project materials report the following held-out evaluation metrics for the model's collision-probability estimates against the project's two-dimensional Foster reference implementation.

1 | Log-MAE

0.1811

Reported mean absolute error in predicted log10 collision probability.

2 | Median Log Error

0.0623

Reported median absolute error in log10 collision probability.

3 } Median Relative Error

14.23%

Reported median relative error against the numerical reference values.

These are project-reported metrics, not independently reproduced results. They describe the stated dataset and evaluation procedure; they do not establish generalisation to operational conjunction populations. Interpretation depends on the test-set construction, scenario distribution, covariance assumptions, and numerical reference implementation.

Related Research

Encounter-plane and collision-avoidance analysis

Alongside the main screening and probability-estimation pipeline, the project contains an ongoing analytical collision-avoidance research component. It investigates encounter-plane geometry, uncertainty information, and orbital state-transition modelling in the context of impulsive manoeuvre analysis.

This work is distinct from the collision-probability surrogate. It should be treated as a research component under development, rather than as a validated operational manoeuvre-planning system.

EOP CAM

Analytical manoeuvre analysis

The implementation explores the relationship between encounter geometry, orbital dynamics, and candidate impulsive manoeuvres. Further verification and independent evaluation are required before drawing conclusions about solution quality or operational use.

Astrodynamics B-Plane LVLH Optimization Research

Scope And Limitations

What the current implementation does not establish

The current results are bounded by the assumptions used in the screening pipeline, synthetic data, and model evaluation. These limitations affect the conclusions that can reasonably be drawn from the project.

1 | Uncertainty

Covariance treatment

The live screening implementation currently applies a static diagonal LVLH covariance matrix. This does not represent a general time-varying covariance propagation model. More complete uncertainty propagation is future work.

2 | Screening Assumptions

Formation-flight filtering

Co-located objects and tight formation flyers are filtered before B-plane projection under the current screening assumptions. The effect of these filters must be considered when interpreting the set of events retained by the pipeline.

3 | Training Distribution

Synthetic encounter geometry

The current synthetic CDM generator is described as producing circular, equal-altitude encounter scenarios. This limits the represented geometry. Extending coverage to more varied orbital regimes, including GTO and HEO cases, remains planned work.

4 | Generalisation

Evaluation coverage

Performance on a held-out synthetic test set does not establish performance on independently sourced operational CDMs or on encounter populations outside the training distribution. Broader validation is required.

5 | Numerical Validation

Reference implementation

The Foster implementation is used as the project's numerical reference. Independent comparison against established implementations and test cases is necessary to quantify reference error separately from model error.

06 / OPERATIONAL USE

No operational qualification

The project has not established the validation, reliability, or qualification required for operational collision-risk assessment or manoeuvre decisions.

Dataset

Training data and reproducibility

The v1.0.0 project materials describe a pre-generated conjunction dataset of approximately 630 MB. The dataset is distributed separately from the source repository because of GitHub's per-file size restrictions.

A public download endpoint is not configured on this page yet.

Source Code

Implementation and project structure

The repository contains the main screening implementation, model export and inference components, and supporting utilities for training, data generation, benchmarking, numerical evaluation, and mathematical checks.

Main Screening Pipeline

all_vs_all_screening.py

Exported Model

conjunction_pino.onnx and conjunction_pino.onnx.data

Model Parameters

normalization_params.txt

Training and Benchmarking

train_pino.py and benchmark_pino.py

Numerical Evaluation

pc2d_foster.py and validate_pc.py

Symbolic and Dimensional Checks

verify.py

Native Inference

main.cpp, pino_inference.cpp, and CMake configuration

The file names above reflect the v1.0.0 project structure. Consult the repository for the current implementation and revision history.

Disclaimer

Independent research software

PINOcam is an independent research and software project. It is not an operational safety system and is not intended to support real-world collision-avoidance decisions. The reported metrics describe a particular project evaluation setup; they do not demonstrate operational suitability, certification, or general predictive accuracy.

Any use beyond research and development would require independent numerical validation, representative data, uncertainty-model assessment, and review by qualified conjunction-assessment specialists.

The project documentation discloses the use of large language models as development assistance.

PINOcam | V1.0.1

Astrodynamics, numerical computation, and scientific machine learning.

About Jits Doomen →