RS4 / PC4-Paranoid: 96% GPS Spoofing rejection & <120ms Structural Fault Detection (SITL Validated)

Doctor_Piter · March 30, 2026, 1:04pm

Hi ArduPilot Community,

Standard EKF3/UKF implementations are highly vulnerable to non-Gaussian noise, coherent GPS spoofing, and sudden physical changes (frame/prop damage). I want to share a brain-inspired Integrity Layer called RS4 / PC4-Paranoidthat acts as a transparent pre-filter for Kalman estimators.

We’ve validated this in ArduPilot SITL and the results significantly outperform standard innovation tests.

What it solves:

GPS Spoofing: Achieves a 96% reduction in RMS estimation error compared to standard EKF3.

EW Resilience: Maintains stability under noise jamming, meaconing, and drift injection (87–94% error reduction across 6 EW attack types).

Structural Integrity: Detects propeller/frame damage or payload drop in 60–120 ms — which is 10–50x fasterthan standard EKF innovation tests.

How it works (The Engineering behind it):

RS4 is not a replacement for EKF, but a “paranoid” immune system. It uses four sequential stages:

Phase-Consensus: Uses the Kuramoto order parameter r(t) to measure cross-sensor coherence . If sensors disagree, trust collapses instantly.

Innovation Gate: A physical feasibility check that rejects coordinated spoofing if the implied rate of change exceeds the drone’s mechanical bandwidth.

Asymmetric Trust: Implements “Paranoid Hysteresis” — trust drops in milliseconds (K↓=0.8) but recovers cautiously (K↑=0.02) .

Dual-Mode Estimation: A Theta/Gamma architecture where a stable “anchor” (Theta) holds the state during high-threat periods.

Computational Efficiency (Low SWaP-C):

The algorithm has an exact complexity of O(N) (2N+12 scalar operations).

Execution time: < 11 µs on an ARM Cortex-M4 (168 MHz) @ 400 Hz.

CPU Impact: < 0.5%.

Memory: No dynamic memory allocation, fully deterministic.

Validation Data:

Next Steps: I have formal proofs for stability and boundedness. I am looking for developers interested in testing this integrity layer on real-world flight logs (ULog/TLog) from missions with sensor anomalies or structural failures.

Download formal spec/preprint:

Osipov, A. (2026). PC4-Paranoid Filter: Adaptive Physics-Constrained Sensor Fusion Dataset (v1.0) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.18131659

Andrey Osipov, MD, PhD

NDev · March 31, 2026, 3:41am

Hi Andrey @Doctor_Piter, if this is the case, please provide a repo with your implementation so that myself or others can take a look and judge the method. That would be the best way to go about this.

As it stands the repo you posted and the preprint I could find leave a lot to be desired. Need more to work with.

Thank you.

Doctor_Piter · March 31, 2026, 11:35am

Hi Dev,

As requested, I have prepared a repository with the full implementation of the PC4 (Integrity Filter) and a representative flight log for evaluation. Since the binary log file is quite large, I have hosted the complete package on Google Drive.

Repository Link: https://drive.google.com/file/d/11a1es6_H6NYbImoB3vA52RUG54psr8RF/view?usp=share_link

The archive (PC4_Implementation.zip) includes:

code/pc4_final.py: The core filter logic implementing real-time trust metrics.

code/pc4_attack.py: The script used to simulate the 20m altitude spoofing attack during the experiment.

code/pc4.param: ArduPilot parameters used for the test setup.

logs/00000049.BIN: The specific flight log demonstrating successful anomaly suppression under an active spoofing attack.

plots/PC4_RESULT_FINAL.png: A visualization of the sensor conflict and the filter’s performance.

This package provides everything necessary to reproduce the experiment and verify the results in a SITL environment. I look forward to your technical feedback.

Best regards,

Andrei Osipov, MD, PhD

PC4_Code_Implementation.zip (4.7 KB)

NDev · March 31, 2026, 10:39pm

I was hoping you would post a github repo or something like that with your modification to ArduPilot for the sake of transparency… that is how we expect folks to work around here. Either way I took a look at what you’ve provided, since I’m personally interested whenever someone has something to say about Kuramoto models.

Even then, from the evidence that you’ve provided, I’ve concluded that what you claim is not at all representative of what you’ve presented:

In the “attack” python script, you’ve tried to inject wind and GPS disturbances but to no real effect on the SITL sim in the included .bin file. The max offset was less than 2 meters at any point. Even for the portion where you were looking to disable the GPS, in the SITL sim the faux GPS measurements were still being delivered to the SITL vehicle… so at worse you may have nudged the GPS measurement by a small bit.
The other two python scripts seem to be calculating something, I presume your PC4 control, but they don’t connect with the SITL agent in anyway. All you seem to be doing is measuring PWM output from the agent to do some math, but that object’s output is not routed back to SITL in any form.
The actual math in the PC4 object takes motor PWM, normalizes it to a -1:1 interval, takes an average of those numbers and maps it to polar coordinates, and I assume you’re using a kuramoto like coupling law to say something about their coherence… so its fun mathematically speaking to talk about how coherent or decoherent a set of signals are but meaningless unless being used for some purpose. Here, there does not seem to be a point to it, as shown.

image1563×344 75.8 KB

Please refrain from posting more like this unless its well treated and the code modifications to ArduPilot are provided so we can judge for ourselves their effect, rather than through some bold claims. Thank you.

Doctor_Piter · April 1, 2026, 3:58pm

Hi, NDev!

Thank you very much for your detailed and honest feedback — I truly appreciate the time you took to review my work.

I realize now that I misunderstood an important aspect of how SITL integration should be demonstrated. My background is in medicine, and I came to this topic from studying the architecture of the human brain, particularly how it processes and reconciles multiple noisy sensory inputs. Based on that, I became interested in whether similar coherence-based principles could be applied to complex multi-sensor technical systems such as UAVs.

Because of that background, I initially focused on validating the mathematical behavior of the model (RS4 / PC4) on logs, rather than ensuring that it was properly integrated into the control loop of ArduPilot.

You are absolutely right — in the current form, my scripts act only as an external observer and do not influence the SITL system. That is a critical limitation, and I acknowledge that my claims were ahead of what was actually demonstrated.

My intention is to explore whether a coherence-based approach (inspired by Kuramoto-like models) could serve as an integrity layer for multi-sensor fusion, especially in situations where sensors become mutually inconsistent.

The next step for me is to properly test this in a closed-loop setting.

I will now work on:

constructing stronger and more realistic failure scenarios (true sensor conflicts rather than small perturbations),
and integrating RS4 directly into the estimation pipeline so that it can actually affect sensor usage or measurement acceptance.

If you are willing to advise, I would be very grateful for guidance on the correct integration point within ArduPilot.

From my current understanding, a reasonable approach might be to implement RS4 as a pre-filter or gating mechanism before EKF measurement updates — for example:

rejecting or down-weighting measurements based on cross-sensor inconsistency,
or dynamically disabling unreliable sensors.

Could you please advise:
where in the ArduPilot codebase would be the most appropriate place to implement such a pre-filter?
(e.g., before FuseVelPosNED, inside measurement update logic, or elsewhere in EKF3?)

I would like to redo the experiments properly and share results that reflect actual system behavior rather than external analysis.

Thank you again — your feedback is extremely valuable and helps me move this work in the right direction.

Best regards,
Andrey

NDev · April 1, 2026, 5:50pm

FYI, credentials shouldn’t really mean anything here, so I don’t know why you keep repeating them on all of your material and here with your profile too… for the record I have a PhD as well. If anything, I know that it places a burden on us to be principled in how we conduct our work and we should expect greater scrutiny for ourselves.

The moment you got challenged on the claims and provided (some) evidence that showed it to not be the case, you’ve folded and claimed ignorance to what you’ve done and your own understanding of it…this is a bit of a miscarriage in the scientific process, wouldn’t you think? All I’m asking for is honesty. And maybe less reliance on LLMs to think and write on your behalf.

If you have enjoyed playing around with ArduPilot SITL encouraging, please keep going with it, we are very happy with that. But I expect more responsible science on your part if you’re going to continue to make very bold claims.

Edit: To answer your specific question I had missed earlier, you should study the AHRS library which does state estimation if you want to make modifications in the direction you’re thinking of, and for disabling/reenabling sensors for the EKF, it is not all that easy since, to put it loosely, the EKF expects consistent signals over time based on the tune for its state estimation to work. You can try to change parameters for the EKF online during flight like you tried with your scripts to mock changes to sensors for their use in the state estimation as a starting point, but be mindful some parameters are flagged to require a full board reset and reinit when changed to take effect.