How to unify EKF position output and RAW GPS position output in sitl

hello, I hope to simply simulate the GPS spoofing by changing the values of gpsDataNew.pos and gpsDataNew.hgt in the NavEKF2_core::readGpsData() function. But this will cause the separation of EKF position output and RAW GPS position output during sitl simulation. I also tried to modify the outputDataNew.position in the NavEKF2_core::calcOutputStates() function in the EKF calculation process, but this will have the same problem. How should I solve the problem of separation of EKF position output and RAW GPS position output display, or is there a better way to simply simulate GPS spoofing?
The problem is shown in the figure, red is the EKF position output, blue the RAW GPS position output.
image

It looks like ArduCopter ignores the spoofed signal, because it thrusts the accelerometers more than the GPS. I wonder what happens in a longer flight with a higher level of spoofing. When with the EKF match the spoofed signal?

Subsequent flights will always maintain this state of separation. The red aircraft will still fly on the planned route, and the blue aircraft will fly at a distance from the red aircraft. As shown in the figure below.
I don’t know where I can use EKF to match the spoofing signal. Could you please give me some suggestions?

The spoofed gps signal is a single input, position estimation is an output that involves a number of other inputs and states.
I’m not sure there’s actually a problem here.

The subsequent position fusion will use a position information calculated using IMU data from the delayed time horizon to predict the state, which seems to have an impact on the red aircraft. It seems that the ekf operation seems to ignore the gps spoofing signal I injected

if the gps position innovation is too high then the ekf doesn’t fuse it. Even if the spoofed signal is within the innovation limits, and hence it’s data is accepted, the ekf global position will still differ from the raw gps position due to the influence of the inertial sensors. So there’s no surprise in what you’re seeing, in my view.

If I want to solve this problem, what should I do, can you please give me some suggestions.

You need to describe exactly the problem you want to solve, and why you think it’s a problem.
The fact that ArduPilot’s position estimation is robust against gps spoofing is good, not bad!

I found that in gazebo the drone will deviate from the planned route like the blue drone in sitl (RAW GPS position output).

It’s the same flight code. I don’t use gazebo.