gps(septentrio): add resilience information reporting

[flyingthingsintothings]

Solved Problem

When errors occur in attached GNSS receivers, there is no way to report them to the user so they know what is going wrong.

Solution

• Add automatic configuration for Septentrio receivers to report resilience information every second
• Add to Septentrio parser so it can parse the new message types
• Change the uORB message for GNSS information to support this new information
• Report the changes through MAVLink (submodule still needs to be updated)

Changelog Entry

For release notes:

Feature: Report resilience information from GNSS receivers
Documentation: Need to clarify page ...

Alternatives

/

Test coverage

/

Context

Another part has been implemented for QGroundControl to display this new information to users. This feature was proposed during the 2022 Developer Summit and received positive feedback. Messages to report jamming and spoofing state were already in the uORB protocol, but weren't used by any modules.

I would love to discuss this during the next Community Q&A call on Wednesday 🙂

• Add support for GNSS receiver resilience information mavlink/qgroundcontrol#11486
• gps: add status and integrity information mavlink/mavlink#2110

[AlexKlimaj]

One note that jamming and spoofing state is used currently by the ublox driver. I did the implementation last year.

https://github.com/PX4/PX4-GPSDrivers/blob/main/src/ubx.cpp#L2361-L2362

https://github.com/PX4/PX4-GPSDrivers/blob/main/src/ubx.cpp#L2120

[flyingthingsintothings]

I did indeed notice that the u-blox driver already provides this information to the rest of the system, but it isn't really used anywhere as far as I can tell. This PR would aim to send this information to ground control stations so they can display it to the user. I used the existing uORB topics from the u-blox implementation you mentioned, but added some things to send extra information like GNSS signal authentication state.

[flyingthingsintothings]

This implementation should be ready, although there is one problem I don't know how to solve. The Septentrio driver uses get_device_id() to get the unique identifier for the GNSS receiver, but that one is the same for both instances of the module. I've looked how this function gets its id, but I don't really understand where in the code it gets generated. I can see that there are some files in NuttX that may generate this value, but I don't know specifically where. If anybody knows how to have two different ids for the two GNSS receivers, that would be a big help. Currently the code functions but QGroundControl can't differentiate between values from the main and secondary receiver because of this bug.

This is also meant as a basic implementation of the new protocol that can be further implemented in the future. For example the RAIM fields in the new MAVLink message aren't used yet. This is also only implemented for the Septentrio driver for now.

[flyingthingsintothings]

I just noticed that most boards use the common.xml dialect from the MAVLink protocol. That one doesn't include the new message yet. Some boards like the 6X I was using for testing are already using the development.xml dialect. What is the best approach to solve this problem? Move the other boards to that dialect as well? Conditional compilation based on the dialect (if such a thing is possible)? Other options to make this PR compile?

[chiara-septentrio]

I've added a conditional include in mavlink_message.cpp as I've seen done with other types of messages using development.xml. I didn't have an issue with building when not using development.xml with this change.

[dagar]

This is minor, but can you make sure that even one line if statements have braces to prevent any accidents?

Suggested change

	if (receiver_status.rx_error_cpu_overload)
	if (receiver_status.rx_error_cpu_overload) {

[chiara-septentrio]

I've added all the missing braces

[DronecodeBot]

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-sync-q-a-aug-14-2024/40168/1

[chiara-septentrio]

@dagar I've also double checked, the resilience values were already at 0 by default. It was probably already done when they were first created for Ublox.

[DronecodeBot]

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-sync-q-a-aug-21-2024/40268/1

[chiara-septentrio]

@dagar I added comments to make more clear which value were the default ones for the new fields but I'm not sure where you would expect them to be initialized to default other than the files where it's already the case in the modules and drivers folder.

[chiara-septentrio]

Would it be possible to have an update quickly on this PR, I'm coming at the end of my internship and any hardware testing won't be possible afterward on my part.