RFC: GNSS: Integrate RTK data-correction to GNSS modems

[ubieda]

Introduction

The following is a proposal to integrate RTK correction data to GNSS modems in order to enhance GNSS fix accuracy to centimeter-level.
This is valuable for navigation applications, in which uncorrected GNSS fix accuracy is not good enough.

The goal is to define an approach that is flexible enough to accomodate the extensive number of ways correction data can be provided, as well as the data-format these messages are presented.

Problem description

In RTK-based applications, in addition to the mobile device(s) (Rovers) usually there is a Base-Station (also known as Reference Station), which provides correction data in order to improve the GNSS fix accuracy to centimeter-level. The way this is implemented is very application specific and there can be both different media as well as compatible formats, some examples are listed below:

Transmission media

• LoRa (Sub-GHz transceivers both on the Rover and the BS).
• SBUS (Rover has an UART port connected to an SBUS RC receiver).
• TCP/UDP (both Rover and BS are in the same local network).
• NTRIP (Rover implements an NTRIP client connected to an NTRIP caster to get decentralized correction data over the internet).
• Other (e.g: ROS topic? with the GNSS controller being configured by a ROS node).

Data Format

• RTCM3
• SPARTN
• CMRX
• Proprietary

Proposed change

Define a structure in-tree to enable adding client libraries that subscribe/receive a combination of data-format/media and make these available to GNSS drivers to apply RTK data-corrections in a decoupled and vendor-agnostic fashion.

Detailed RFC

Proposed change (Detailed)

The proposal is to add a new directory for RTK clients (e.g: subsys/rtk/ for instance in which these instances are selected, depending on the application).

Directory Structure

• Clients:
  • LoRa (subsys/rtk/lora)
  • Serial (subsys/rtk/serial)
  • Telnet (subsys/rtk/telnet)
  • NTRIP Client (subsys/rtk/ntrip)
• Protocols:
  • RTCM3 (subsys/rtk/protocol/rtcm3)
  • SPARTN (subsys/rtk/protocol/spartn)

APIs and Mode of Integration

Similar to how currently Navigation and Satellite data is sent to the application (through an iterable section of callbacks for subscribers), we could have macros to similarly have GNSS drivers subscribe to these data-corrections (including preferred data-format):

• GNSS driver side integration

static void on_rtk_corrections_received(const struct dev, const void *data)
{
        const struct gnss_rtk_rtcm3 *rtcm_correction = (const struct gnss_rtk_rtcm3 *)data;
        ...
        /* Data is provided to the modem for proper digestion */
}

...

GNSS_RTK_CORRECTION_DATA_CALLBACK_DEFINE(GNSS_RTK_CORRECTION_DATA_RTCM3, on_rtk_corrections_received);

• RTK Client-side integration:

static void on_packet_received(uint8_t *data, size_t len)
{
        /* e.g: a thread or workqueue context */
        /* packet is validated, with the proper RTK protocol helper APIs */

        for (size_t i = 0 ; i < num_of_compatible_packets ; i++) {
            /* Notifies all the installed subscribers so they process the data accordingly */
            gnss_rtk_correction_data_publish(GNSS_RTK_CORRECTION_DATA_RTCM3, correction_data);
        }
}

Alternatives

Add only vendor-specific RTK integrations on a per-driver basis in a custom way.

Next Steps

If the RFC looks good to the Zephyr community, I'll proceed to file a PR with:

• Basic directory structure.
• Add APIs
• Add basic RTK client (Serial)
• Add Integration to a GNSS driver (U-Blox F9P)
• Add RTCM3 protocol.
• Add GNSS RTK sample with basic code to have a PC as a base-station and a Zephyr-running target as a Rover.

Draft PR

#90890

[ubieda]

@bjarki-andreasen @bperseghetti @PetervdPerk-NXP Feel free to provide your feedback here! I'm up for presenting this at the Arch WG and/or iterate a few times before following up with the PR.

Thanks in advance!

[bjarki-andreasen]

This looks pretty much perfect :)

[bperseghetti]

Looks great! Thanks for all your great work pushing this forward, will be a great addition!

[ubieda]

@carlescufi @henrikbrixandersen I'd like to present this RFC sometime soon at the Arch WG meeting. Please LMK when is it a good time!