Plane: Stabilize modes effected by GPS Jamming

[Jman841]

Issue details

Even modes that do not rely on the GPS currently can go crazy and cause a crash if there is GPS Jamming or interference. From my understanding, Manual is the only mode that is currently not effected by the EKF if there is some sort of GPS Jamming.

This seems very dangerous, especially if the plane is out of line of sight and flying in Manual would be very difficult or near impossible. Is there a way that if the EKF is going crazy from GPS issues (Vertical and horizontal pozition errors) that a stabilize mode will only use the attitude control from the gyro/accel to fly and ignore the errors of the GPS so the plane can be manually flown and landed safely without the need for manual mode?

Also, if the GPS has issues the default mode to switch to is Circle mode, however, if circle mode is effected by the GPS issues as well, is there no fail safe for GPS interference issues?

Version

Arduplane 3.5.3

Platform

• [ ] All
• [ ] AntennaTracker
• [ ] Copter
• [X ] Plane
• [ ] Rover

  Airframe type

All Planes

Hardware type

Pixhawk

Logs

http://discuss.ardupilot.org/t/very-strange-unexplained-behavior-in-flight-please-help/9083

Comes from that issue and I have other logs if needed for further analysis.

[WickedShell]

Circle mode doesn't try to hold position, it just wants to hold a constant bank. Again though depending on how it's handled you could be suffering from a bad AHRS solution. I haven't really experimented with this aspect.

Couple of things regarding the BLOS scenario. Unless you have a video stream coming back from the aircraft, what does stabilize get you? (IE you still don't know where to aim the aircraft to fly it back). Also without a compass enabled this is a recipe for disaster, and would require the compass to be enabled and setup correctly.

[Jman841]

Right, but all assisted modes and circle mode if the EKF is going crazy seem to be affected as the attitude control is lost. The result from these flights was a hard pitch up that would cause a stall then the plane would crash because once in a stall in any assisted or auto mode there is no means of recovery for Arduplane. It seems like a very critical vulnerability and one that there is no means of detecting before takeoff and currently no prearm check to avoid.

I do not fully understand all of the workings of the EKF, but, it seems that GPS jamming should not be allowed to cause complete loss of basic flight control in any mode. Even in auto mode, if the GPS is going crazy the plane should still maintain basic attitude and stall prevention control.

I would also love to see a compass based dead reckoning flight mode to attempt to get an airplane back that has lost GPS. At least give a chance for the plane to return to be flown manually and landed instead of just stuck in circle mode until the battery runs out.

[WickedShell]

We don't have nearly the requisite level of sensors to do that for any period of time. If you lose GPS on this level of hardware then almost immediately you must ignore any reported position. It's not nearby good enough to shoot an approach with. On May 22, 2016 12:03 PM, "Jman841" notifications@github.com wrote:

Right, but all assisted modes and circle mode if the EKF is going crazy seem to be affected as the attitude control is lost. The result from these flights was a hard pitch up that would cause a stall then the plane would crash because once in a stall in any assisted or auto mode there is no means of recovery for Arduplane. It seems like a very critical vulnerability and one that there is no means of detecting before takeoff and currently no prearm check to avoid.

I do not fully understand all of the workings of the EKF, but, it seems that GPS jamming should not be allowed to cause complete loss of basic flight control in any mode. Even in auto mode, if the GPS is going crazy the plane should still maintain basic attitude and stall prevention control.

I would also love to see a compass based dead reckoning flight mode to attempt to get an airplane back that has lost GPS. At least give a chance for the plane to return to be flown manually and landed instead of just stuck in circle mode until the battery runs out.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ArduPilot/ardupilot/issues/4186#issuecomment-220849678

[Jman841]

Ah ok,

Here's some more logs if needed, 2 flights with the VTX where I switched to Manual and FBWA to get the plane landed and one log without the VTX where everything was perfect.

https://www.dropbox.com/s/eu0779jwl1bopjy/GPS%20Jamming%201.bin?dl=0

https://www.dropbox.com/s/qftziqptst7ufuo/GPS%20Jamming%202.bin?dl=0

https://www.dropbox.com/s/6y2c5g65spjxz3r/No%20VTX%20or%20issues.bin?dl=0

[iskess]

Tridge posted this 2 years ago in a response to my X8 flyaway and crash. http://ardupilot.com/forum/viewtopic.php?f=44&t=5808&start=10#p9880

_> I think we need to add a FS_GPS_ENABLE option that allows you to specify the action to take on losing GPS. I think this should behave much like FS_GCS_ENABL, and allow you to first start circling at FS_SHORT_TIMEOUT then to RTL at FS_LONGTIMEOUT. The RTL will be via dead-reckoning of course, but straight line dead-reckoning is usually OK as long as you have a compass. It should at least move closer to the return point than it would otherwise.

Of course we would never expect to shoot an approach via dead reckoning, but we should be able to achieve a heading towards home where you might be able to regain a visual or FPV reception.

[Jman841]

Here's a log from today resulting in a crash from the same issue. The GPS was moved to the very back most portion of the tail and the VTX is about a meter away to the front. We have multiple planes with this VTX without issues and with the GPS closer. I am beginning to suspect it is interference with a difference sensor, or, something with Arduplane 3.5.3 that the EKF errors are much worse than on 3.5.2 as that is the only difference from the other planes and this one. I will put 3.5.2 back on this plane and test once we repair the damages and I am going to put a switch on the VTX so I can turn it off while it's in the air incase there is issues.

https://www.dropbox.com/s/of91rbnshdw2zsr/24%205-23-2016%2012-16-16%20PM.bin?dl=0

[SlipstreamFPV]

"The result from these flights was a hard pitch up that would cause a stall then the plane would crash because once in a stall in any assisted or auto mode there is no means of recovery for Arduplane."

This end result sounds familiar to the issue I had (https://github.com/ArduPilot/ardupilot/issues/4066) due to a glitch. These are serious bugs. It's a shame because the rest of the new TECS works very well. Hopefully the smart ones can sort it out :)