GNSS Resilience with Septentrio #13009
Conversation
|
Let me know when that PX4 PR gets merged |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/px4-dev-call-aug-06-2025-team-sync-and-community-q-a/46826/2 |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/px4-dev-call-aug-06-2025-team-sync-and-community-q-a/46826/1 |
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/px4-dev-call-aug-13-2025-team-sync-and-community-q-a/46972/2 |
|
@HTRamsey, hello. The PX4 side was merged this week. Can this pr be reviewed again ? |
There was a problem hiding this comment.
Pull Request Overview
This PR adds GNSS resilience support with interference detection and authentication features for GPS receivers, particularly targeting Septentrio hardware integration. The implementation provides real-time monitoring of jamming, spoofing attacks, and authentication status through new toolbar indicators and vehicle telemetry.
- Adds new GPS fact fields for spoofing state, jamming state, authentication state, and various quality metrics
- Implements two new toolbar indicators for GPS interference and authentication status display
- Integrates GNSS integrity message handling from MAVLink development dialect
Reviewed Changes
Copilot reviewed 14 out of 16 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Vehicle/FactGroups/VehicleGPSFactGroup.h | Adds new fact properties for GNSS resilience monitoring |
| src/Vehicle/FactGroups/VehicleGPSFactGroup.cc | Implements GNSS integrity message handling and fact initialization |
| src/Vehicle/FactGroups/GPSFact.json | Defines metadata for new GPS resilience facts with enums |
| src/UI/toolbar/GPSInterferenceIndicator.qml | Creates interference status indicator with jamming/spoofing display |
| src/UI/toolbar/GPSAuthenticationIndicator.qml | Creates authentication status indicator with color-coded states |
| src/FirmwarePlugin/FirmwarePlugin.cc | Registers new toolbar indicators in the UI |
| translations/qgc-json.ts | Adds translation strings for new GPS fact descriptions |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@HTRamsey thank you for the review, I have applied the suggested changes |
|
Looks good to me but I'll get Don to double check. Only comment I have (and it's not required but would be nice) would be to use an enum and switch in the QML files kinda similar to how this is done in RemoteIDSettings.h/RemoteIDSettings.qml |
|
Actually can't you just return the enum string from the fact in qml for spoofingState, jammingState, and authenticationState? |
…state text mapping
|
Thank you, I applied the suggestion. Let me know if it looks better now. I have limited access to hardware to test these new changes, but if you confirm the code is fine, I’ll test the final version on hardware and let you know that everything works as expected |
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 13 out of 15 changed files in this pull request and generated 4 comments.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| "name": "spoofingState", | ||
| "shortDesc": "Signal Spoofing State", | ||
| "type": "uint8", | ||
| "enumStrings": "Unknown,Ok,Mitigated,Detected", |
There was a problem hiding this comment.
The enum strings for spoofingState and jammingState don't match the strings defined in the C++ code. The C++ code uses 'Disconnected,OK,Mitigated,Ongoing' while the JSON uses 'Unknown,Ok,Mitigated,Detected'. This inconsistency could cause display issues.
Copilot uses AI. Check for mistakes.
| "name": "jammingState", | ||
| "shortDesc": "Signal Jamming State", | ||
| "type": "uint8", | ||
| "enumStrings": "Unknown,Ok,Mitigated,Detected", |
There was a problem hiding this comment.
The enum strings for spoofingState and jammingState don't match the strings defined in the C++ code. The C++ code uses 'Disconnected,OK,Mitigated,Ongoing' while the JSON uses 'Unknown,Ok,Mitigated,Detected'. This inconsistency could cause display issues.
Copilot uses AI. Check for mistakes.
| "name": "authenticationState", | ||
| "shortDesc": "Signal Authentication State", | ||
| "type": "uint8", | ||
| "enumStrings": "Unknown,Initializing,Error,Ok,Disabled", |
There was a problem hiding this comment.
The enum strings for spoofingState and jammingState don't match the strings defined in the C++ code. The C++ code uses 'Disconnected,OK,Mitigated,Ongoing' while the JSON uses 'Unknown,Ok,Mitigated,Detected'. This inconsistency could cause display issues.
Copilot uses AI. Check for mistakes.
| mavlinkChannel(), | ||
| &msg, | ||
| timeTick++, // time since boot | ||
| timeTick++, // time since boot |
There was a problem hiding this comment.
Why the changes to MockLink?
|
@Tory9 Not really interested in adding two more slots into the toolbar for GPS. That's a lot of real estate. Can you provide screenshots of what this looks like with all GPS stuff in the toolbar explaining what it all means. Including the UI changes to the existing gps indicator. Then I'll think about how to organize UI. |
…g, jamming, and authentication state metadata
|
@DonLakeFlyer thanks for the review, I get your point. I’ve attached a short PDF explaining the current approach. I would appreciate your suggestions for a more acceptable alternative |
|
Perfect @Tory9. Give me a bit to think about this. |
|
So from looking at the mavlink spec for GNSS_IDENTITY it seems like that messages is not a "fused" message like the other GPS messages which combine multiple GPS into one. It seems like in the cases of multiple GNSS on a vehicle you will get multiple GNSS_IDENTITY telemetry each with a unique id. If so, then stuff these values into the the GPS fact group (which are fused values) seems wrong. Each unique GNSS telemetry is going to stomp over each other in the one gps fact group. Am I reading that wrong? |
|
You’re right, if there are multiple receivers supporting this message, each will indeed send its own separate GNSS_IDENTITY telemetry. I also find it a bit confusing how potentially different resilience data from multiple GPS instances could be interpreted as a single |
|
So what I would do is fuse the telemetry from multiple GNSS together on the QGC side. Keep an array of GNSS_INTEGRITY messages by id in the gps fact group. Update the array when the data comes in. Then walk the array taking the "worst" value across all values. Stuff that "worst" value in the Fact if it differs from current value. My other question would be from a vehicle side standpoint how does the firmware use this information to make decisions? The idea would be to replicate how the vehicle side deals with multiple sets of this information. |
|
For now, the firmware doesn’t really use this information for decision-making. It’s mainly passed to the GCS to provide environmental awareness and because it can be useful or interesting for the operator. I suppose this data could eventually be used to adjust the reliability weighting during sensor fusion, but that part isn’t implemented yet |
|
Ok, so then I would do the QGC side fuse thing. I'm also waiting to hear back from the PX4 Firmware folks about how they handle Mavlink Development dialect stuff. In QGC we've put this stuff behind an #ifdef keeping it only in debug builds. Given the fact that development dialect message can change out from under you. Not sure if we should change that or not. |
|
Got it, thanks! Yeah, with this message still being in development there will definitely be some complications. I believe a PR to move it into the common dialect should be opened soon. The next release isn’t coming soon, so hopefully it can make it into common before then |
5 participants
Add support for GNSS receiver resilience information
Depend on this PX4-Autopilot PR : PX4/PX4-Autopilot#25012
Original PR : #11781
Description
This PR is mostly taken from @chiara-septentrio and @flyingthingsintothings PR.
The code is mostly the same, I have improved a little code structure and move some files to update code structure
If you want to have resilience information, you should use this PR of PX4 : PX4/PX4-Autopilot#25012
And set
CONFIG_MAVLINK_DIALECT="development"to yourdefault.px4boardTest Steps
I have used a Septentrio emulator that emulate Jamming, Spoofing and Authentication attacks which was impossible to test before.
The functionality run smoothly in all cases, tell me if you need a video of demonstration or something's else to merge the PR 😃
Checklist:
Related Issue
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.