AP_GPS: added GPS_DRV_OPTIONS for fully parsing RTCMv3 injection

[tridge]

This adds full RTCM parsing of incoming RTCM injection if it sees RTCM coming in on more than one MAVLink channel.
This allows for setups where you have redundency in comms links, such as is common for light show drones which may inject RTCM data via both WiFi and a SiK radio setup as receive only
This also gets RTCM logging at the message ID level, allowing you to debug RTCM injection issues with a lot more detail
Two new GPS_DRV_OPTIONS are added:

• one to enable this RTCM full parse even for a single channel (useful for extra logging for debugging)
• one to disable the automatic full RTCM decode for multi-channel (in case users want to inject non-RTCM data or data that our RTCM parser can't handle)

[andyp1per]

LGTM, just one comment

[IamPete1]

Any reason we should not do this by default?

[tridge]

maybe we should automatically enable this if we see GPS RTCM packets on more than 1 MAVLink channel?

[tridge]

pending testing from @ntamas and @andyp1per

[tridge]

Any reason we should not do this by default?

I've now made it automatic when it sees RTCM on multiple channels. It can be disabled with the option (for the case where users are injecting non-RTCM data)

[ntamas]

Tested the latest version today (only in the lab yet, with a pre-recorded RTCM stream) and it seemed to work well! It was slightly confusing that injection on one channel only does not trigger the writing of the RTCM log entries - I understand why that happens (I needed to set GPS_DRV_OPTIONS to 64), but it should be documented somewhere for the RTCM log entries so people won't start looking for the log entries if they have a single channel only.

I also had to #include "AP_GPS_config.h" in AP_GPS.h in our fork (based on ArduCopter 4.4.x) because AP_GPS.h refers to AP_GPS_RTCM_DECODE_ENABLED and its default value comes from AP_GPS_config.h.

[ntamas]

One more comment: GPA.RTCMFU and GPA.RTCMFD seem to be redundant / misleading now. When the fragment goes through the RTCMv3 parser, it never reaches handle_gps_rtcm_fragment() so the rtcm_stats.fragments_used counter never gets incremented.

[tridge]

One more comment: GPA.RTCMFU and GPA.RTCMFD seem to be redundant / misleading now

we could have a separate RTCM message broken out of GPA for that use case, but I don't think it is worth it

[ntamas]

@tridge We tested the injection with 20 drones and two simultaneous channels last Thursday and everything worked fine, thank you!

I'm leaning towards patching the Skybrush branch to always have bit 6 set in GPS_DRV_OPTIONS for sake of consistency of behaviour irrespectively of the number of channels used by the operator, though. It makes automated log analysis and support easier for us if we don't have to consider the legacy RTCM injection mechanism.

[rmackay9]

The two new driver options are pretty esoteric but most users won't need to understand or change them and from testing it seems they're required so fine with me.

[andyp1per]

Very nice work @tridge! Also amazed at how quickly you knocked this together