Septentrio: Add GNSS resilience reporting #31040

Tory9 · 2025-09-04T13:12:48Z

What does this PR do?

This PR implements support for collecting GNSS resilience data from Septentrio receivers and relaying it to the Ground Control Station (GCS).

Why is this change needed?

GNSS resilience information—such as spoofing, jamming, and authentication states—is crucial for operational safety and informed decision-making. Providing this data to the GCS enhances an operator's situational awareness, allowing for better flight planning and in-flight control.

How is it implemented?

The Septentrio driver has been modified to:

Auto-configure the receiver to output the SBF blocks containing resilience information (if auto-config is enabled).
Parse these new SBF message types.
Map the extracted data to the MAVLink GNSS_INTEGRITY message.
Add the GNSS_INTEGRITY message to the STREAM_EXTENDED_STATUS to ensure it is sent to the GCS.

Related Work & Context

PX4 Autopilot: An analogous PR has been open: PX4/PX4-Autopilot#25012
QGroundControl: GCS support is ready and waiting to be merged mavlink/qgroundcontrol#13009
Mission Planner: Implementation is forthcoming.
MAVLink Message: This feature uses the GNSS_INTEGRITY message from the development dialect.

How has this been tested?

The feature was validated on a CubeOrange+ using a replayed SBF log file that was recorded in an environment with active jamming and spoofing.

peterbarker

Nice to see some effort being put in to report this stuff.

libraries/AP_GPS/AP_GPS.cpp

peterbarker · 2025-09-05T11:22:32Z

libraries/AP_GPS/AP_GPS.cpp

+    uint8_t id = instance; 
+    uint32_t system_error  = get_system_errors(instance);
+    uint8_t authentication = get_authentication_state(instance);
+    uint8_t jamming        = get_jamming_state(instance);
+    uint8_t spoofing       = get_spoofing_state(instance);
+    uint8_t raim_state     = UINT8_MAX; //not implemented yet 
+    uint16_t raim_hfom     = UINT16_MAX; //not implemented yet
+    uint16_t raim_vfom     = UINT16_MAX; //not implemented yet
+    uint8_t corrections_quality     = UINT8_MAX; //not implemented yet
+    uint8_t systems_status_summary  = UINT8_MAX; //not implemented yet
+    uint8_t gnss_signal_quality     = UINT8_MAX; //not implemented yet
+    uint8_t post_processing_quality = UINT8_MAX; //not implemented yet


Don't bother making these locals, just throw them straight into the packet; add comments to indicate which field is being passed where things are unclear.

peterbarker · 2025-09-05T11:22:43Z

libraries/AP_GPS/AP_GPS.cpp

+    uint8_t systems_status_summary  = UINT8_MAX; //not implemented yet
+    uint8_t gnss_signal_quality     = UINT8_MAX; //not implemented yet
+    uint8_t post_processing_quality = UINT8_MAX; //not implemented yet
+    GCS_SEND_TEXT(MAV_SEVERITY_INFO, "gps %u with auth %u and spooof %u", id, authentication, spoofing);


Diagnostics to be removed :-)

peterbarker · 2025-09-05T11:24:50Z

libraries/AP_GPS/AP_GPS.h


+    /// GPS error bits. These are kept aligned with MAVLink by 
+    /// static_assert in AP_GPS.cpp
+    enum GPS_Errors {


Can we make these enum-class and contained within the AP_GPS class? Would allow for dropping the extra namespacing.

peterbarker · 2025-09-05T11:26:12Z

libraries/AP_GPS/AP_GPS.h

+    enum GPS_Authentication {
+        AUTHENTICATION_UNKNOWN =       0, ///< The GPS receiver does not provide GPS signal authentication info


Suggested change

enum GPS_Authentication {

AUTHENTICATION_UNKNOWN = 0, ///< The GPS receiver does not provide GPS signal authentication info

enum Authentication {

UNKNOWN = 0, ///< The GPS receiver does not provide GPS signal authentication info

... and move to within AP_GPS:: namespace. This reduces a lot of duplication.

The enumeration you're modelling this on is one of three enuemations we use for status type in ArduPilot - but it's also the one I believe we're trying to remove!

peterbarker · 2025-09-05T11:29:04Z

libraries/AP_GPS/AP_GPS.h

        return state[instance].gps_yaw_configured;
    }
+
+     // general errors in the GNSS system


I'm not sure we really need these accessors, but if you do want to keep them please make them private.

peterbarker · 2025-09-05T11:29:36Z

libraries/AP_GPS/AP_GPS.h

+    uint32_t get_system_errors() const {
+        return get_system_errors(primary_instance);
+    }


I don't think this is used?

We have a no-dead-code policy which we mostly enforce....

Similarly for other "primary_instance" methods

peterbarker · 2025-09-05T11:31:44Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+        if (RxError & INVALIDCONFIG) {
+            state.system_errors |= AP_GPS::GPS_Errors::CONFIGURATION;
+        }


I wonder if a static const data structure here which is iterated over might make this a bit nicer / simpler to extend later / more compact byte-wise.

peterbarker · 2025-09-05T11:38:01Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+        }
+        state.jamming_state = AP_GPS::GPS_Jamming::JAMMING_OK;
+        for (int i = 0; i < temp.N; i++) {
+            RFStatusRFBandSubBlock* rf_band_data = (RFStatusRFBandSubBlock*)(&temp.RFBand + i * temp.SBLength);


This construct makes me unhappy.

At the very least you can (a) create a pointer you can index into and (b) use a reference for each of the entries in the array for pulling things out.

But I'd really also like to see a belt-and-bracers check that we don't step outside the packet here. When pointer games go wrong vehicles get lost. Right here if temp.N is corrupt (which can happen if the packets gets through the checksumming while invalid, or if the GPS device itself puts a bad value in) we could try to access memory we don't have access to and fall out of the sky. We had a similar problem with massive packet loss in this driver that we fixed with #29399

peterbarker · 2025-09-05T11:40:17Z

libraries/GCS_MAVLink/GCS_MAVLink_Parameters.cpp

 static const ap_message STREAM_EXTENDED_STATUS_msgs[] = {
    MSG_SYS_STATUS,
    MSG_POWER_STATUS,
+    MSG_GNSS_INTEGRITY,


I don't know whether we will want to stream this message by default. Telemetry bandwidth is actually one of those things that doesn't seem to be growing for a lot of users!

Users can get the autopilot to start streaming the message in many ways if we don't decide to stream this by default.

Tory9 · 2025-09-09T11:36:10Z

@peterbarker , thank you for a detailed review. I have considered your suggestions and applied some changes. I have a question about streaming this message by default. Since I'm new to ArduPilot, could you mb hint at the best way to introduce this to the community?

MattKear · 2025-09-17T07:18:39Z

libraries/AP_GPS/AP_GPS.h


+#if AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED
+    // general errors in the GNSS system
+    uint32_t get_system_errors(uint8_t instance) const {


Not a blocker but one suggestion that was raised on the dev call that that it might be worth combining all of these get functions into one function as they are all called in once in the same currently.

MattKear · 2025-09-17T07:21:03Z

A general comment that was made on the dev call was that it would be good if an accessor variable can be added. If the GPS is sending the relevant information then the variable is set true. That way any get functions could return early if the accessor if false.

rmackay9 · 2025-09-24T07:18:01Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+#if AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED
+        if (temp.Flags==0) {
+            state.spoofing_state = static_cast<uint8_t>(AP_GPS::Spoofing::OK);
+        }


nitpick: the brackets and else should be on the same line

rmackay9 · 2025-09-24T07:20:42Z

Could you double check that each commit only affects a single subsystem? Also each commit should be prefixed with the subsystem affected. E.g. "AP_GPS: add xxxx"

Finally could you rebase on master to get rid of the "merge" commit?

peterbarker · 2025-09-24T07:25:13Z

https://ardupilot.org/dev/docs/contributing.html

peterbarker · 2025-09-24T07:26:53Z

https://ardupilot.org/dev/docs/mavlink-requesting-data.html

Georacer · 2025-09-24T08:55:28Z

Discussion on today's Dev Call:

Peter: The feature should be define-fenced for 1M flash boards.
Randy: Please split the commits into one for each subsystem.
P: What is the size-cost to the output binary when the feature is left undefined? It would be nice to have this as small as possible, ideally zero.
R: It’s very zero for small boards, it’s a lot for larger boards.
P: A couple dozen bytes extra when the feature is turned off is okay. Anything larger is a problem.
R: We also need a build option for the build server, in the build_options.py file.
Victoria: I’ve added the message on the EXTRA_3 stream, but I don’t see it in QGC.
P: Adding the message ID on the stream ID list is one way to have the message sent.
Another is to have the GCS request for this message on-demand.
QGC probably doesn’t have compiled-in
You can add a SEND_STATUSTEXT macro before the place where you try to send the message and see if this code path is being traversed.

R: If the feature is off by default, we should be streaming the message in this case.
P: Agreed.
Matt: We can have it off by default, we don’t know how much usage this feature will get.
P: It also needs a change in our Wiki, to document this feature.

… function definition

…d options

Tory9 · 2025-10-08T15:07:28Z

Hello @peterbarker,

I was thinking about the issue of memory being occupied by this feature even if it's not used, which is a problem for boards with smaller flash memory. However, on the other hand, requiring a custom build—even with the great web tool ArduPilot has—might discourage some users from using the feature.

Thus, I've implemented the following solution:

The feature's code is excluded at compile time for boards with less than 1MB of memory.
For boards with more memory, the feature code is included, but if the connected receiver is not a Septentrio receiver, then the message is not streamed.
If users with smaller flash on their controller want to include the feature, they can still do so with a custom build.
Please let me know if this approach is okay and if I correctly made the custom build implementation

peterbarker

Looking pretty good now!

peterbarker · 2025-10-16T11:15:38Z

libraries/AP_GPS/AP_GPS.cpp


+#if AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED
+void AP_GPS::send_mavlink_gnss_integrity(mavlink_channel_t chan, uint8_t instance) {
+    if(state[instance].has_gnss_integrity) {


Suggested change

if(state[instance].has_gnss_integrity) {

if (!state[instance].has_gnss_integrity) {

return;

}

... just return early if there's nothing to do

peterbarker · 2025-10-16T11:16:41Z

libraries/AP_GPS/AP_GPS.cpp

+void AP_GPS::send_mavlink_gnss_integrity(mavlink_channel_t chan, uint8_t instance) {
+    if(state[instance].has_gnss_integrity) {
+
+        mavlink_msg_gnss_integrity_send(chan, 


indenting problem here...

peterbarker · 2025-10-16T11:17:29Z

libraries/AP_GPS/AP_GPS.h

    bool have_gps_yaw_configured(uint8_t instance) const {
        return state[instance].gps_yaw_configured;
    }
+


stray whitespace change

peterbarker · 2025-10-16T11:17:56Z

libraries/AP_GPS/AP_GPS_config.h

 #ifndef AP_GPS_GPS2_RTK_SENDING_ENABLED
 #define AP_GPS_GPS2_RTK_SENDING_ENABLED HAL_GCS_ENABLED && AP_GPS_ENABLED && GPS_MAX_RECEIVERS > 1 && (AP_GPS_SBF_ENABLED || AP_GPS_ERB_ENABLED)
-#endif
+#endif


Stray whitespace change

peterbarker · 2025-10-16T11:18:14Z

libraries/AP_GPS/AP_GPS_SBF.cpp

 constexpr const char* AP_GPS_SBF::_initialisation_blob[];
 constexpr const char* AP_GPS_SBF::sbas_on_blob[];

+const AP_GPS_SBF::SBF_Error_Map AP_GPS_SBF::sbf_error_map[] = {


Suggested change

const AP_GPS_SBF::SBF_Error_Map AP_GPS_SBF::sbf_error_map[] = {

static const AP_GPS_SBF::SBF_Error_Map AP_GPS_SBF::sbf_error_map[] {

peterbarker · 2025-10-16T11:24:11Z

libraries/AP_GPS/AP_GPS_SBF.cpp

                            (unsigned int)(RxError & RX_ERROR_MASK), (unsigned int)(temp.RxError & RX_ERROR_MASK));
        }
        RxError = temp.RxError;
+        if ((ExtError & EXT_ERROR_MASK) != (temp.ExtError & EXT_ERROR_MASK)) {


So since these changes are outside the new AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED, I guess these must be changes to existing behaviour?

These changes are not pulled out as a separate commit, and you haven't mentioned them anywhere, I think?

If the extent of the changes comes to "Print external error changes as they come in" then we can probably let that slide.

One thing here, 'though, is that our send-rate here is limited only to the rate at which we get messages from the external unit. That risks flooding telemetry links and making vehicles choke up on other telemetry... pre-existing in this driver, so also not a big deal.

peterbarker · 2025-10-16T11:27:00Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+    case RFStatus:
+    {
+        const msg4092 &temp = sbf_msg.data.msg4092u;
+        check_new_itow(temp.TOW, sbf_msg.length);


Again, change unrelated to new functionality. I think this is probably benign, but it might just be neater to not know about the message when we're not doing integrity stuff?

peterbarker · 2025-10-16T11:39:25Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+        const uint8_t *packet_end = (const uint8_t *)&temp + (sbf_msg.length - 8);
+
+        for (uint8_t i = 0; i < temp.N; i++) {
+            if (p + temp.SBLength > packet_end) {


Please also check that (p + temp.SBLength) -(&temp.RFBand) is < sizeof(sbf_msg).

We do not want to implicitly trust this packet to not be corrupt, even if it does pass a checksum. If temp.SBLength or tmp.N are wild then we run the risk of falling out of the sky. Which is bad.

... also, you can probably make this a lot neater by casting (const uint8_t *)&temp.RFBand to const RFStatusRFBandSubBlock &rf_band_data and incrementing that to move between the N entries, rather than adding temp.SBLength to a uint8_t*. You can use pointer subtraction on p and the &temp.RFBand similarly to my suggestion above to work out whether you're going to over-read the buffer.

peterbarker · 2025-10-16T11:42:44Z

libraries/AP_GPS/AP_GPS_SBF.cpp

+    {
+        const msg4245 &temp = sbf_msg.data.msg4245u;
+        check_new_itow(temp.TOW, sbf_msg.length);
+#if AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED


Similar to the above - should we know about GALAuthStatus at all if we're not doing integrity stuff?

peterbarker · 2025-10-16T11:44:50Z

libraries/GCS_MAVLink/GCS_config.h

 #endif  // AP_MAVLINK_SET_GPS_GLOBAL_ORIGIN_MESSAGE_ENABLED
+
+#ifndef AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED
+#define AP_MAVLINK_MSG_GNSS_INTEGRITY_ENABLED AP_GPS_SBF_ENABLED && HAL_GCS_ENABLED && (HAL_PROGRAM_SIZE_LIMIT_KB > 1024)


We'll probably change this down-the-line - we can actually use this new information you're supplying in the EKF to change how ArduPilot responds to bad GPS data. But this is fine for now.

peterbarker · 2025-10-24T03:04:29Z

BTW, how does this PR relate to #27891 ?

Tory9 · 2025-10-24T06:36:01Z

@peterbarker This is an old PR opened by a former Septentrio intern. I based this PR on it but had to create a fresh one. You can safely close that one. Sorry, I should’ve mentioned it in the description of PR

peterbarker · 2025-10-26T08:13:24Z

@peterbarker This is an old PR opened by a former Septentrio intern. I based this PR on it but had to create a fresh one. You can safely close that one. Sorry, I should’ve mentioned it in the description of PR

Thanks.

Note that if you based your work on someone else's unmerged work it's often a good idea to add a Co-authored-by: to the commits containing their work.

peterbarker requested changes Sep 5, 2025

View reviewed changes

Tory9 force-pushed the pr-resilience3 branch from b01f2a9 to c89ee9e Compare September 9, 2025 08:48

Tory9 requested a review from peterbarker September 11, 2025 07:39

MattKear reviewed Sep 17, 2025

View reviewed changes

rmackay9 added the DevCallEU label Sep 24, 2025

rmackay9 reviewed Sep 24, 2025

View reviewed changes

rmackay9 added the WikiNeeded needs wiki update label Sep 24, 2025

peterbarker removed the DevCallEU label Sep 24, 2025

Tory9 added 3 commits October 7, 2025 21:13

AP_GPS_SBF: add support for resilience related SBF messages

30d59ae

AP_GPS: Add GNSS integrity parameters and send_mavlink_gnss_integrity…

140ca5c

… function definition

GCS_MAVLink: Add GNSS_INTEGRITY message support

77d63ac

Tory9 force-pushed the pr-resilience3 branch 2 times, most recently from 74536d8 to 2fdd96a Compare October 7, 2025 20:43

Tools/scripts: add support for GNSS_INTEGRITY MAVLink message in buil…

6dd1438

…d options

Tory9 force-pushed the pr-resilience3 branch from 2fdd96a to 6dd1438 Compare October 8, 2025 13:05

peterbarker requested changes Oct 16, 2025

View reviewed changes

peterbarker mentioned this pull request Oct 26, 2025

AP_GPS: support GNSS receiver resilience information over MAVLink #27891

Closed

		enum GPS_Authentication {
		AUTHENTICATION_UNKNOWN = 0, ///< The GPS receiver does not provide GPS signal authentication info

	const AP_GPS_SBF::SBF_Error_Map AP_GPS_SBF::sbf_error_map[] = {
	static const AP_GPS_SBF::SBF_Error_Map AP_GPS_SBF::sbf_error_map[] {

Septentrio: Add GNSS resilience reporting #31040

Are you sure you want to change the base?

Septentrio: Add GNSS resilience reporting #31040

Uh oh!

Conversation

Tory9 commented Sep 4, 2025

What does this PR do?

Why is this change needed?

How is it implemented?

Related Work & Context

How has this been tested?

Uh oh!

peterbarker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Tory9 commented Sep 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattKear commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rmackay9 commented Sep 24, 2025

Uh oh!

peterbarker commented Sep 24, 2025

Uh oh!

peterbarker commented Sep 24, 2025

Uh oh!

Georacer commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Tory9 commented Oct 8, 2025

Uh oh!

peterbarker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

peterbarker commented Oct 24, 2025

Uh oh!

Tory9 commented Oct 24, 2025

Uh oh!

Georacer commented Sep 24, 2025 •

edited

Loading