That distinction matters as developers add companion-computer routes for GNSS corrections. A new PX4 pull request #29368 proposes a ROS 2-facing path for RTCM data. Its design questions are broader than PX4: where should a fragmented correction message be reconstructed, how should competing sources be isolated, and what evidence proves the GNSS receiver actually used the bytes? The pull request is open, and its author's reported simulator result is not a hardware qualification.
A byte stream is not an RTK solution
A conventional RTK arrangement involves a base station of known position, a correction distribution link and a rover receiver. In drone operations, the corrections might come from a local base connected to a ground-control station, an NTRIP service reached through a companion computer, or a direct radio link. PX4's RTK documentation describes forwarding correction traffic from a ground station to the vehicle. ArduPilot's documentation also distinguishes ground-station forwarding from direct receiver-side connections.
These routes have different failure boundaries. A network connection can be up while its correction mountpoint is wrong. A flight controller can accept transport packets while the GNSS driver rejects an incomplete RTCM frame. A rover may receive valid corrections but lack matching satellite observations or an adequate base position for the result the operator expects.
The first diagnostic question, therefore, is not simply whether packets arrived. It is which correction source supplied them, when they were generated, whether the rover accepted them, and what positioning mode and uncertainty the rover subsequently reported.
MAVLink fragmentation adds a reconstruction boundary
In the common MAVLink dialect, GPS_RTCM_DATA carries a correction payload of up to 180 bytes. The message includes flags for a fragmentation indicator, fragment identification and sequence identification. Large correction material may require multiple transport packets; the recipient needs to reconstruct the original byte sequence before passing it downstream.
This creates two distinct forms of integrity. The transport must preserve the order and grouping of fragments, and the reconstructed RTCM message must make sense to the GNSS receiver. A packet counter or heartbeat alone establishes neither. Losing a fragment can turn a plausible-looking sequence of MAVLink messages into unusable RTCM data.
The same issue appears without MAVLink. A serial feed, middleware topic or network socket may deliver arbitrary chunks of a continuous RTCM stream. Chunk boundaries are transport conveniences, not necessarily RTCM message boundaries. An interface that assumes each received chunk contains one whole correction message can fail intermittently when payload sizes or buffering change.
ROS 2 moves the boundary, it does not remove it
The PX4 proposal introduces an RTK correction entry point through the existing uXRCE-DDS bridge, using a ROS 2 /fmu/in/rtcm_corrections topic and a px4_msgs/msg/RtcmData representation. The author describes accepting chunks of up to 300 bytes, preserving individual publisher identity through device_id, and using separate internal rtcm_corrections instances. Those are proposed implementation details, not an interface available in every current PX4 release.
PX4's ROS 2 bridge does not automatically expose every internal topic. Its exposed topics are selected in the firmware configuration, and the ROS 2 message definitions need to match the particular PX4 build. Serial or UDP transport to the DDS agent introduces another link with its own buffering and recovery behavior. The PX4 middleware guide is a better source for checking this compatibility than assuming two machines running ROS 2 can exchange a newly proposed message by name alone.
A clean ROS 2 publish call proves that middleware accepted the outgoing sample. It does not prove that the autopilot was subscribed to the matching type, that all correction chunks survived, that the GNSS driver processed the resulting stream, or that the rover reached an RTK fix. Each boundary needs its own observation.
Multiple correction publishers are a provenance problem
Consider a ground station forwarding corrections from a local survey base while a companion computer also connects to an NTRIP caster. Both might produce valid RTCM streams. If the autopilot simply concatenates bytes from the two producers into one parser, the resulting stream can contain partial messages from different origins. The problem is not solved by increasing queue capacity.
The PX4 proposal explicitly aims to keep publishers separate using device_id and multiple internal topic instances. Whether this is sufficient depends on the consumer's selection policy. Identity on ingestion is useful only if the downstream path can avoid interleaving and either select one source or handle source changes safely.
The upstream sources can also disagree about station location, correction types and availability. If a rover is allowed to switch feeds, record the reason for the switch and check the resulting GNSS status. Do not interpret a renewed correction-byte counter as continuity of the same RTK reference solution.
Queue capacity and latency should be tested together
A correction system has two competing requirements. Bursts from a base or network gateway should not overflow small queues, but old corrections should not accumulate into a misleading backlog. More buffering can reduce immediate drops and still increase correction age after a network pause.
The open PX4 change describes a queue of 64 samples, with the author expecting about 10 to 20 incoming chunks per one-second correction epoch in a simulated workload. The author reports a simulator reaching RTK fixed with two ROS 2 publishers, each sending 12 chunks at 1 Hz. These numbers describe that test, not a verified field capacity or a guarantee of receiver behavior. The author explicitly notes the absence of physical GNSS hardware testing in the pull-request discussion.
A useful stress test includes both ordinary bursts and failure recovery. Pause the correction source, reconnect it, vary chunk sizes, and watch for stale data after service resumes. Track queue overruns, correction age and receiver fix status on the same timeline. Keep raw RTCM framing diagnostics where the receiver or gateway exposes them. A rapidly increasing byte count during recovery can indicate backlog rather than improved positioning.
What an end-to-end acceptance test needs to observe
A controlled validation can be organized around a few failure conditions rather than a single successful flight:
- Known baseline. Use a documented base position and a receiver configuration capable of consuming the particular correction messages. Record which source, mountpoint and transport path are active.
- Framing pressure. Send correction traffic in uneven chunk sizes, including chunks that split RTCM frames. Verify byte ordering and receiver acceptance, not only message counts.
- Interrupted delivery. Drop, delay and duplicate selected transport packets. Measure correction age, queue behavior and recovery time without implying a universally safe latency threshold.
- Competing sources. Bring up two correction publishers with distinct source identities. Confirm that their byte streams are not interleaved and document any source-selection or failover policy.
- Independent outcome. Compare autopilot and GNSS receiver reports of correction reception, fix type and position uncertainty against observations from the transport layer. Where survey accuracy matters, use independent checkpoints instead of treating an RTK-fixed status as the entire accuracy result.
Most of this work belongs on a bench, in software-in-the-loop, or in a controlled ground test before any flight. Results must state which firmware commit, ROS 2 message set, receiver firmware and correction source were used.
The architecture decision
MAVLink forwarding, a companion-computer ROS 2 route and direct correction delivery to the receiver can all be legitimate choices. Their relative merits depend on where the NTRIP client lives, how many links must be maintained, whether logs expose each boundary, and who is responsible for arbitration when two sources appear.
The new PX4 proposal is useful because it makes source identity and middleware buffering explicit. It does not establish that a ROS 2 route is more accurate than an existing ground-station path, nor that additional publishers should run simultaneously in an operational aircraft.
For an RTK mapping or inspection platform, the defensible design is the one that can answer four questions after a poor positioning result: Which base produced the corrections? Which bytes reached the receiver? How old were they? What did the receiver actually solve? Without those answers, a green connection indicator can conceal the part of the positioning chain that failed.