Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird behaviour in DeadReckoning mode while GPS outage is not constant #10588

Open
tipoman9 opened this issue Jan 11, 2025 · 13 comments
Open

Weird behaviour in DeadReckoning mode while GPS outage is not constant #10588

tipoman9 opened this issue Jan 11, 2025 · 13 comments

Comments

@tipoman9
Copy link

INAV/SPEEDYBEEF405WING 8.0.0 Jun 28 2024 / 00:18:11 (60a4b71)
Got GPS lock on the ground, though not as many satellites as usual.
Took off and immediately lost GPS - there were two symbols "ES" instead of satellites count on the lower right.
Didn't want to risk in these circumstances, so circled the plane overhead in LoS control.
Decided to test RTH without GPS, the plane has a magnetometer, calibrated carefully.
Both times the plane started porpoising with audible motor bursts, so I had to disengage for fear of not getting it stalled (it's an ArPro on the heavy side with 10x21700 cells).
During the flight, the GPS coordinates were constantly changing. There were moments when the GPS lock was recovered for several seconds, then lost again for minutes. The speed changed from 70km/h to 10km/h in a second.
Can these sparse GPS coordinates at irregular intervals cause some problem with inertial navigation?

LOG00064_ArPro_GPS_Outage_DeadReckoning.zip

https://youtu.be/dDb1sNGmgcI

BlackBox log provided.

@Jetrell
Copy link

Jetrell commented Jan 12, 2025

The logs a bit messed up.. Seeing random jumping from 5 to 35 Sats with HDOP being all over the place. Is indicating a lot of GNSS band interference, which would be causing the speed related issue you're seeing.

Both times the plane started porpoising with audible motor bursts, so I had to disengage

That part is related to this known issue.

@stronnag
Copy link
Collaborator

Pretty much "game over" for the log ....

Screenshot From 2025-01-12 09-26-37

Given the location, there is also the possibility of external GNSS interference.
Screenshot From 2025-01-12 09-30-51

The jumps in location during the replay are quite disconcerting.

@tipoman9
Copy link
Author

I mapped the recorded coordinates and the results are ... weird. If I read them carefully, it seems I landed 1.5km away from the take-off location, while in reality I landed on the same spot where I'd taken-off.
During last summer I've experienced spoofing here, but the last few months have been relatively free of GPS problems.
In fact I thought the cause of the GPS troubles I had came from the VTx PowerAmplifer being set to very high power levels (I did increase it before the flight) that make it work in saturated mode.
After I landed, I turned it off and got 19 satellites in less than a minute.
So I won't attribute this to intentional GPS spoofing, it was rather my plane jamming itself.
But in this case I think the GPS should stop provide data, rather than provide wrong coordinates
This seems to impact INAV stabilization somehow - look at the AHI drift at the landing
image

BTW.
If you are interested, here is how intentional gps spoofing looks like - Seems I live in an interesting location for testing GPS
https://youtu.be/2yU2Ft2V39c
Log files for the video above - just look where my humble plane was suddenly teleported...
Crazy_GPS_in_flight.zip

@Jetrell
Copy link

Jetrell commented Jan 12, 2025

GNSS spoofing would explain it.
I thought it was odd to see such a high satellite count, with a poor HDOP. Yet the EPH was relatively good.. It seemed like a contradiction. Even for localized GNSS interference from the models hardware.

This seems to impact INAV stabilization somehow - look at the AHI drift at the landing

That is expected. GNSS VELNED is used to augment accelerometer drift correction. And being that there is also another issue effecting this too. Then's not unexpected when your model has a reasonable level of vibrations.

Without having more information. Like seeing a picture of your plane and the setting DIFF. Its hard to give anymore feedback.

@tipoman9
Copy link
Author

So, seems there are two issue I'm facing.

  1. When navigation mode is engaged, pitch oscillations occur - this seems the be addressed here Inav 8.0 RC3 Airplane bumpiness #10536
  2. In case of GPS outage (or maybe spoofing), inertial navigation may get affected.

My main issue is to be able to direct my plane towards home in case GPS is not working and I start losing video or RC link, so that I can reestablish them when it gets closer.
But it seems that even working dead-reckoning is not enough for the task, since if there is AHI drift, it will probably not not be able to maintain correct bearing or even altitude for a decent time.
Maybe the only option is to use the switch intended to test Dead-reckoning, that will disable GPS (if I have RC link at least).
This will exclude the source of interference for the inertial navigation.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Jan 15, 2025

The Pitch oscillations should be fixed in RC4 if Position_Z controller default values are used.

regarding the dead reckoning. If the GPS is interfered or spoofed from the launch, it is very likely that the last recorded heading and/or speed is completely off when DR engages. In this case there is not much you can do. Heading and Speed could be recovered if you have an airspeed sensor and a compass but it still might cause the last position to be wrong and therefore DR going on the wrong course already.

@tipoman9
Copy link
Author

@b14ckyy
The issue with "unreliable" GPS is not dead-reckoning, but just preventing INAV to crash your plane :-)
This seem likely to happen if inertial navigation gets fooled and pitch or roll axis get offset by 30 degrees - as you can see in my video.
So maybe in such cases it is better to completely turn-off GPS data input to INAV in order to protect the latter from getting "disoriented" in space.

@b14ckyy
Copy link
Collaborator

b14ckyy commented Jan 15, 2025

Oh yeah indeed if the GPS freaks out the AHRS G-Force Compensation could be messed up too. Good point.

But to be fair: your tune is also all over the place. It even jumps around in angle mode like crazy when you get slow. Loks like a complete off-tune FF and rates.

@tipoman9
Copy link
Author

Well, I do agree that maybe the tune is not optimal, but it is not that bad imho.
Take look here - this is the previous flight of the same plane.
https://youtu.be/UIl2ZlZwFA8?t=38
If there were even slightest prop vibrations, at 6x zoom they will be visible as jello. If the PIDs params are wrong, the plane will oscillate or bump during maneuvers, which was not the case...
If I get it correctly, I can try to decrease the GPS data weight in inertial navigation by changing these params
ahrs_gps_yaw_weight, ahrs_inertia_comp_method, inav_default_alt_sensor, inav_w_xy_gps_p, inav_w_xy_gps_v, inav_w_z_gps_p
but I risk of totally messing the controls.
Simple option seems to shut-down GPS and safely return to land, while INAV can keep the plane steady and straight.

@anti-vaxxer
Copy link

So from what I comprehend the dead reckoning should work if GPS module stops working or if it is jammed and loses fix.
But if it is spoofed and reporting wrong coordinates then it will mess up dead reckoning.
I'm just a layman but from what I learned u-blox modules have a message UBX-NAV-STATUS spoofDetState. Does INAV utilize this message? Could INAV utilize this message, and when the module reports spoofing detected then INAV will ignore the coordinates provided until the reported spoofing clears?
https://content.u-blox.com/sites/default/files/u-blox-M10-SPG-5.10_InterfaceDescription_UBX-21035062.pdf#%5B%7B%22num%22%3A1744%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C59.527%2C198.913%2Cnull%5D
spoofDetState
https://gpspatron.com/ublox-m8t-gps-spoofing-test/#Conclusion
Screenshot Evaluating the Vulnerability of a UBLOX M8T GNSS Module to Spoofing GPSPATRON com

@MrD-RC
Copy link
Collaborator

MrD-RC commented Jan 15, 2025

The other question is should INAV use this setting. As the only place you'll encounter spoofing is in a warzone. INAV as a project has already stated that no changes will be made that only affect warzones or are for military use.

@anti-vaxxer
Copy link

The other question is should INAV use this setting. As the only place you'll encounter spoofing is in a warzone. INAV as a project has already stated that no changes will be made that only affect warzones or are for military use.

I just don't know how you would substantiate that the only place you'll encounter spoofing is in a warzone. As a hobbyist I have encountered GPS jamming or spoofing, regular people have experienced it too.

Even if someone used INAV in a warzone they could be using it for finding survivors for all you know.

With dead reckoning instead of crashing the model it will at least come back toward the pilot which gives a much higher chance of regaining control, that makes INAV more safe.

@MrD-RC
Copy link
Collaborator

MrD-RC commented Jan 15, 2025

GPS spoofing and jamming is illegal. You may get jamming spilling over from warzones. But you should definitely not encounter spoofing. Any deliberate jamming for testing purposes is strictly limited and NOTAMs issued well in advance. There is too much risk to manned aviation for this not to be the case.

The Black Sea has a lot of Russian warships. Due to the attack on Ukraine by Russia.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants