ArduPilot
Septentrio: Add GNSS resilience reporting
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_INTEGRITYmessage. - Add the
GNSS_INTEGRITYmessage to theSTREAM_EXTENDED_STATUSto 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_INTEGRITYmessage 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 , 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?
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.
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?
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.
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
BTW, how does this PR relate to https://github.com/ArduPilot/ardupilot/pull/27891 ?
@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 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.
Hey! The GPS_SYSTEM_ERROR_SOFTWARE error is coming from the ReceiverStatus message's RxError field - specifically the SOFTWARE bit, which is set upon detection of a software warning or error. To reset this bit and see the exact issue, the "lif, error" command should be given to the receiver. This bit can trigger for big issues affecting the operation but also for less critical things like logging-related stuff. The receiver doesn't usually give detailed error info unless you ask it with "lif, error". If you've got logged SBF data from when this happened, I can still replay it and try to figure out what the issue was. The ExtError field is showing SISERROR (Signal-In-Space Error) - which means at least one satellite is broadcasting sketchy position data. Quite possibly, the SISERROR is what's triggering the SOFTWARE error bit internally. I will test it with a few different receivers to see if I get the same issue and if that would be useful, prepare some testing reports.
I agree that the GCS reporting is spammy based on what you sent. But honestly, I think there's something wrong with the receiver config/operation in that image, so I wouldn't expect it to toggle between no error and SISERROR all the time. Under normal operation, it shouldn't trigger often. That said, it's also not super important to send this to GCS, and I agree the numbers don't really tell users much. I can either rework it to send more informative messages or just remove it entirely. Let me know what you prefer.
Regarding renaming GPS_JAMMING_STATE_OK to GPS_JAMMING_STATE_NOT_JAMMED, I agree this would probably make more sense. I'm not sure how exactly the naming was chosen because the MAVLink message was developed a while back by another student. Since the message is still in development.xml, I can open a PR to change the naming. However, I'll also need to coordinate changes with the PX4 implementation, which was already merged into master. If you think the current naming is not representative enough, I can change it across MAVLink/ ArduPilot/ PX4/ QGC.
Regarding renaming GPS_JAMMING_STATE_OK to GPS_JAMMING_STATE_NOT_JAMMED, I agree this would probably make more sense. I'm not sure how exactly the naming was chosen because the MAVLink message was developed a while back by another student. Since the message is still in development.xml, I can open a PR to change the naming. However, I'll also need to coordinate changes with the PX4 implementation, which was already merged into master. If you think the current naming is not representative enough, I can change it across MAVLink/ ArduPilot/ PX4/ QGC.
I'll ping in @hamishwillee on this.
While yes, it is in development.xml, I don't think I can really justify pushing for it if it's already in PX4 master.... I just probably should have picked it up on the original PR :-)
Hey! The GPS_SYSTEM_ERROR_SOFTWARE error is coming from the ReceiverStatus message's RxError field - specifically the SOFTWARE bit, which is set upon detection of a software warning or error. To reset this bit and see the exact issue, the "lif, error" command should be given to the receiver. This bit can trigger for big issues affecting the operation but also for less critical things like logging-related stuff. The receiver doesn't usually give detailed error info unless you ask it with "lif, error". If you've got logged SBF data from when this happened, I can still replay it and try to figure out what the issue was. The ExtError field is showing SISERROR (Signal-In-Space Error) - which means at least one satellite is broadcasting sketchy position data. Quite possibly, the SISERROR is what's triggering the SOFTWARE error bit internally. I will test it with a few different receivers to see if I get the same issue and if that would be useful, prepare some testing reports.
I agree that the GCS reporting is spammy based on what you sent. But honestly, I think there's something wrong with the receiver config/operation in that image, so I wouldn't expect it to toggle between no error and SISERROR all the time. Under normal operation, it shouldn't trigger often. That said, it's also not super important to send this to GCS, and I agree the numbers don't really tell users much. I can either rework it to send more informative messages or just remove it entirely. Let me know what you prefer.
We should at least work out how to log this stuff if we aren't going to send it to the user. That's just a Log_Write call to something like a GSDB message.
Hi, thank you for the review. I have applied the suggestions. I want to address two things:
- Logging of internal errors: I tested the feature with Mosaic X5 and Mosaic H receivers and also experienced the GCS messages about internal errors. However, in my case it was never a software issue but rather CPU overload on the receiver. The errors weren't persistent and only occurred when I heavily loaded the receiver—for example, opening the web interface while simultaneously logging messages and streaming on two ports with two streams each. Under these conditions, the error triggering is completely normal. I would even say it's useful to have these messages as an indication of misuse or failure.
I didn't experience the message flooding issue you reported, so I examined your log. I translated the bin to asc using bin2asc.exe, and the tool detected multiple corruptions reported as: CRC Error: SBF_ERR_CRC Decoder Error: SBF_ERR_DROPPED_106_BYTES This could be related to the software error/warning bit being set. Otherwise, the data I could retrieve looked normal. The exact error can be viewed in the web GUI or RxControl by typing lif, error in the expert console.
I believe this is related to receiver operation rather than our code. If you think this message shouldn't be sent to the GCS, I can log it internally instead. However, normally if this message floods the GCS, it would indicate something is wrong with the receiver, as this is not expected behavior. Please let me know what you think.
- Instance handling: I initially thought implementing this for a single receiver would be sufficient, but your intuition about this line: AP::gps().send_mavlink_gnss_integrity(chan, 0) being off was spot on 😅. I broke the GPS1 port cable on my CubeOrange+ and could only find a replacement for GPS2. When I started testing with GPS2, it didn't work. It took me some time to realize there was an instance mismatch—I was passing instance 0 to send_mavlink_gnss_integrity() but the GPS was connected to instance 1 (GPS2 port).
I've now changed it to use the primary instance instead of hardcoding instance 0, and it works. However, I'm now thinking it might make more sense to send data from all GPS instances (or merge them) to the GCS. Please let me know what you think would be the best approach.
Regarding renaming GPS_JAMMING_STATE_OK to GPS_JAMMING_STATE_NOT_JAMMED, I agree this would probably make more sense.... While yes, it is in development.xml, I don't think I can really justify pushing for it if it's already in PX4 master.... I just probably should have picked it up on the original PR :-)
@peterbarker @Tory9 , I'll take a PR with this change and see if I can get it agreement to change it. We should then move this into common.xml.
The change is only to an enum value name, which is run-time safe. This particular value is not directly referenced in PX4. However it might require a compile-time change to QGC.
@Tory9 Are you happy to create such a PR?
@hamishwillee Sounds good. Do you think it would make sense for me to first join one of the MAVLink Coordination Calls to discuss a clearer naming (and check if any other fields should be aligned), and then open the PR?
@hamishwillee Sounds good. Do you think it would make sense for me to first join one of the MAVLink Coordination Calls to discuss a clearer naming (and check if any other fields should be aligned), and then open the PR?
No, I think you should PR just this change with your suggestion for the enum value name and a reason.
If you think other changes are warranted then please suggest them in the discussion, but don't make them. This is deployed, so we can't change field names or units. We can add new fields and "in theory" modify enum value names, but not their order.
[Actually, we "can" break any users in any way because this is in development, but we would prefer not to]
Note that of course you are more than welcome to join the mav call now or any time, but it isn't necessary for this case.
@peterbarker @hamishwillee Hi, I’ve opened a PR with the suggested naming changes. I’m wondering whether that MAVLink PR will block this one from moving forward, or we still can finalize it?
@peterbarker Hi! In the latest commits I updated the data transmission to send from all GPS instances that support this message. I also attempted to align the naming with the new MAVLink definitions, but since the pipeline hasn’t been updated yet, it caused a large number of test failures, so I reverted that change. Please let me know if anything else needs improvement