Copter: sudden bad GPS position leads to Loiter flying off (GPSGlitch)

[samacumen]

Hi,

I have been working in wireless networking with Arducopter. It so happens that GPS works at a carrier frequency of 1.575 GHz. It receives less than nanowatts of power (-127 dBm). Any signal stronger than this at nearby frequency on board (even harmonics of a source, which are not unusual) can kill the GPS signal entirely (even noise in microwatts). I am using a camera on board and it is the killer of GPS - when I start the video shoot.

When this happens during Loiter, (GPS signal is killed - no power problem, both are powered separately - and I have reproduced and verified the GPS loss and camera with spectrum analyzer), the copter loses its position accuracy immediately, and goes haywire. I have ferrite beaded + Cu wrapped but it still happens at odd times.

This problem cannot be avoided and can lead to heavy losses with expensive on-board equipment. This must be acknowledge and taken note of it in software (esp. on what action to take 'immediately' when the GPS count diminishes suddenly in a matter of seconds - as this is not normal and not seen by all but when it happens it is ALL GONE, as happened in my case).

Currently, we wait for 5 seconds loss of GPS fix. What I am talking about is an immediate measure when GPS signal reduces drastically within blink of an eye even for a second.

Thanks, Shyam

[bstott]

* 1.575 GHz is the frequency of GPS - That is a standard. *

This is our issue as flyers not a code programmer issue. We should be using the DIY forum but, here are three methods:

1) Try a bandpass filter. 2) Move your A/V Tx and antennae away from the GPS. 3) Don't use a 1.2-1.3 GHz A/V Tx/Rx. Use 900 MHz, 433 MHz, or 5.8 GHz.

We are the designers don't operate equipment that is going to interfere with your flight systems. Again, this is not a developer issue.

Note: I have the same frequency A/V and will be trying methods number 1, 2 and 3 if need be.

[rmackay9]

Yes, other devices that give off EMI can interference with the GPS like BStott says. Here's an example of another sensor that I've found kills the GPS much like Samacumen's: http://www.youtube.com/watch?v=DjWXzrz-n7w

We've added GPS Glitch protection into AC3.1. The release candidate is available through the mission planner's firmware screen's "Beta Firmwares" link. Can you give that a try and see if it helps? There are two parameters that affect the GPS Glitch protection: GPSGLITCH_ACCEL : the maximum acceleration of the vehicle in cm/s/s. 1000 (i.e. 10m/s/s) is the default. GPSGLITCH_RADIUS: the radius in cm within which the gps position will always be accepted. The default is 1000 (i.e. 10m). Making these numbers lower will mean the glitch protection will reject bad positions better but it could also lead to false positive.

So I believe this issue is resolved in AC3.1 but I'd like to hear feedback before I close this issue.

[samacumen]

Thank you BStott and Randy for the acknowledgement.

I saw the video on youtube and indicates a very exact (or similar) problem that I faced with the Raspberry PI camera and some other tested equipment, which I verified is a clear jamming problem.

@bstott : Thanks for the suggestions however I do not completely agree you. What I had mentioned was a failsafe in such scenarios which need to be handled in software. Moving away the equipment can still cause issues (if spurious signals emerge, which is not in our control) and can lead to a copter crash. @rmackay9 :+1: I think your solution in s/w seems very logical. I will test this within the next few days and get back to you with my feedback.

Two suggestions:

1) As I understand, the ublox GPS carries a 'jamming protection parameter'. If this could be used in s/w in a near-future version (GPS logging alongside as ERROR) will help users identify those rare glitches. 2) Switch to an altitude hold or stabilize mode during these GPS glitches or LAND immediately if the rate of change GPS satellite count/ hdop deviates too much away in a given time duration will certainly save good money by saving those equipments on board :)

[rmackay9]

Yes, I've experimented with pull in the GPS jamming number using u-center. It does seem to be able to indicate when the GPS is being jammed so it's a good idea to allow people to see that number through ArduCopter/Plane/Rover so they can more easily discover if their equipment is jamming the GPS.

[samacumen]

Thanks Randy. That is a good update ;) Makes flying safer under exceptional exceptions! I will be testing my flight in two days time from now. Will keep you posted here.

[rmackay9]

I'd like to hear if the GPS Glitch protection is working or not....but I think I'll close this issue if that's ok because the development has been done and it's in the AC3.1 release. If you did manage to test it (which is difficult because you never know when a glitch will hit) and find problems, please bring it up on the AC-3.0.1 thread.

[samacumen]

Hi Randy,

I've seen the issue is closed. Fair enough, I didn't get back to you on time. I did try to test the GPS glitch over the previous week in the Loiter mode in RC5, however as I had a different dipole orientation of the camera cable it was a bit uncertain on when the problem will reoccur. When it reoccurs I will post the log on AC-3.01 thread.

Could you tell me: 1) In RC5, is the gps glitch (jamming) logged and is visible via MP? 2) When will be the tentative date for AC-3.1 official release?

Thanks, Shyam

[rmackay9]

Shyam, 1) we don't capture the jamming number from the Ublox. I've added an enhancement request for that here. https://github.com/diydrones/ardupilot/issues/640 2) the AC3.1 release is getting close but might still be two weeks away or so. It really depends upon how cleaning up the last few issues and I've also got to merge in the traditional helicopter changes.

[FatBeard]

Hi rmackey, just in response to point 1, surely you don't need to read this number from the ublox (but would be nice), if your new glitch protection algorithm kicks in, you could simply log it?

Regardless, though thanks for the fix, i believe i'm experiencing this problem too. Could it occur when changing from stabilise to alt hold? It's happened to me twice, once when switching to auto from stabilise, the other to alt hold from stabilise ( but the copter disappeared so fast and i was in a frenzy i may have hit something instead of alt hold)

[rmackay9]

FatBeard, The GPS Glitch shouldn't affect stabilize or altitude hold modes except if you have the fence enabled. If you have the fence enabled with AC3.0.1 then actually any really bad GPS glitch which causes the copter to think it's outside the fence can cause it to fly off. Yes, in terms of the jamming number, if we add it, it probably wouldn't be used as part of the glitch protection, it would probably be there more as a pre-arm check and to help people track down the cause of bad loiter, rtl, auto.

[samacumen]

@rmackay9 Read this on uBlox white paper. They have come up with uBlox 7 with added features which may be useful in giving further dimension to 3DR autopilot. You may already be aware, however, for ublox 6, here is what it says:

An added bonus of the latest upgrade addresses the proliferation of inexpensive GPS jammers. It enables the ability to detect the presence of a jamming signal which can add a significant level of security, especially when dealing with vehicle theft or asset tracking. u-blox 6 GPS receivers now can add intelligence to positioning systems by being able to detect if a possible jamming signal is present, and report it to the host processor. This could, for example, put the system into an “attempted theft” condition, and activate an alarm or alert signal, or initiate a backup location system such as one based on GSM cellular positioning (CellLocate).

E.g. The buzzer can beep on GPS jamming on PX4. Just a suggestion for future releases :)

[rmackay9]

Samacmen, thanks for the info. There's an enhancement request raised just recently to make the jamming value visible in the mission planner. https://github.com/diydrones/ardupilot/issues/640

I think the most common cause of jamming is actually people's FPV equipment on their copters but whatever the cause, having it visible would be useful. Unfortunately I can't promise when I'll get to this request. Maybe someone else will take it on and do it though.

[samacumen]

@rmackay9: Ya sure, I understand. This adds to additional observation for end user to narrow down the problem. So, of course its just an extra feature!

PS: I can also help add this feature of getting down the ublox jamming# via APM and send via MaVlink to Mission Planner display screen. Let me know if i can be of help!

Regards, Shyam

[rmackay9]

samacumen, You are more than welcome to have a go at adding the feature to show jamming through the mission planner. my personal to-do list is endless so any help is greatly appreciated. If you do pick this up please check that it doesn't slow down other messages from the ublox. I think getting a jamming never even every few seconds is more than enough.

[samacumen]

Hi Randy,

Let me take this up. When do you wish to target this for the release, any specific deadline?