Why Your RTK Fix Drops in the Field: Multipath, Sky View and Baseline Length

TL;DR: Your RTK fix drops in the field for five recurring reasons: obstructed sky view, multipath from nearby surfaces, rover-to-reference distance or correction-network limitations, cellular or radio dropouts on the NTRIP link, and antenna or cabling issues on the rover itself. This guide shows how to diagnose each cause with real GNSS logs, how to configure Nav2 to fall back on wheel and IMU odometry when the RTK fix is lost on a mobile robot, and provides a pre-mission checklist you can run in under ten minutes. Written for engineers running Leo Rover, Raph Rover, or any ROS 2 UGV in outdoor autonomy missions.

Why RTK Fix Is Lost on a Robot in the Field

Real-Time Kinematic (RTK) positioning can deliver centimeter-level accuracy under favorable conditions. The problem starts when you drive a rover into an orchard, along a building facade, or into a forest edge. The receiver can drop from FIX (RTK fixed, typically centimeter-level) to FLOAT (RTK float, accuracy ranging from centimeters to decimeters or worse) or to a plain 3D single-point solution (often meter-level). For an autonomous mission planned around a 10 cm corridor, that can be a stop condition.

Understanding why the RTK fix is lost on a robot is not one problem but a family of five, each with its own signature in the NMEA or UBX log. The rest of this article walks through each cause using the problem -> reason -> test -> fix format, then covers what Nav2 should do when the correction stream dies mid-mission.

How Poor Sky View Kills Your RTK Fix

Problem: The rover works fine in an open parking lot, then loses fix within seconds of driving under a tree canopy or between two buildings.

Cause: RTK ambiguity resolution needs enough simultaneous carrier-phase observations from satellites tracked by both the rover and the reference station. Multi-constellation tracking improves availability, but RTK does not inherently require two constellations. Obstructions block low-elevation satellites and reduce geometric diversity. Dilution of Precision (HDOP, PDOP) rises, and the ambiguity resolver may refuse to commit to an integer solution.

Test: Log the GGA and GSV NMEA sentences and inspect them. A healthy fix can look like this:

$GNGGA,121854.00,5210.12345,N,02059.67890,E,4,14,0.6,112.3,M,42.1,M,1.2,0001*7A

The 4 in field 6 is commonly used for RTK fixed, while 5 is commonly used for RTK float and 1 for an autonomous single-point fix. Exact mappings can vary by receiver and NMEA implementation. 14 is satellites used and 0.6 is HDOP. When your fix drops, satellite count often falls and HDOP may rise before the quality flag changes, but neither value alone proves the cause.

Run this quick sanity check on your ROS 2 GNSS topic:

ros2 topic echo /gps/fix --field status

Watch the status.status field. In sensor_msgs/NavSatFix, values such as 2 (STATUS_GBAS_FIX) are sometimes used by GNSS drivers to represent corrected solutions, but this field does not define RTK FIX or FLOAT universally. Consult the driver documentation and, where available, use its receiver-specific RTK status message.

Fix: Mount the antenna as high as practical on the rover mast, use a survey-grade multi-band antenna with an appropriate ground plane, and, if the mission truly runs under canopy, plan routes that maximize time in clear sky so the receiver can re-establish carrier-phase tracking and resolve ambiguities.

How Multipath Interference Corrupts Carrier Phase

Problem: The sky is open, satellite count is 15+, HDOP is 0.7, but the fix flickers between FIX and FLOAT and the reported position wanders by 30-50 cm even while the rover is stationary.

Cause: Multipath. The antenna receives both the direct signal and reflections from nearby metal, wet asphalt, vehicle bodies, or the robot’s own chassis. The reflected signal arrives with a phase delay that biases the carrier-phase measurement. Unlike weak signal, multipath does not necessarily reduce satellite count; it corrupts the measurements the receiver trusts.

Test: Multipath often has a distinct fingerprint. Place the rover stationary in a location you suspect. Log the position for 60 seconds at 5 Hz. Compare the horizontal scatter and receiver quality indicators against an open-field log collected with the same equipment. Large scatter or frequent FIX/FLOAT transitions at one location, despite apparently good satellite visibility, are consistent with multipath. Signal-strength values reported in GSV sentences can support the diagnosis, but GSV data are receiver-dependent and should not be used as the only test.

Distinguishing multipath from a long baseline: multipath errors are often directional and location-specific. Move the rover several meters and the pattern may change. Atmospheric decorrelation associated with a longer rover-to-reference distance is generally broader across the operating area and varies with conditions over time.

Fix: Raise the antenna above the highest metal surface on the robot. On Leo Rover, the standard mast can place the GNSS antenna above the electronics box and side panels, reducing chassis reflections. Use an antenna and ground plane appropriate for the GNSS bands in use. Avoid stopping the robot next to vertical walls or shipping containers for critical measurements.

When Baseline Length Exceeds the RTK Service Range

Problem: The rover is operating far from its reference station or outside the intended coverage area of the correction service, with no obvious sky-view change, and it increasingly drops to FLOAT or produces less stable fixed solutions.

Cause: The baseline is the straight-line distance between your rover and a physical RTK base station. Ionospheric and tropospheric delays are strongly correlated at short baselines and cancel out in the differential solution. As the baseline grows, those errors decorrelate and integer ambiguity resolution becomes less reliable. The usable distance depends on receiver capability, constellations and frequencies, correction format, ionospheric conditions, and the correction service. A single-base setup is generally most robust over short baselines and should be validated against the provider’s specifications. Network RTK services can support larger areas, but their practical limits are set by the network design and service policy rather than one universal distance.

Test: For a physical single-base mountpoint, query the NTRIP caster source table for the base coordinates and compute the distance to your work area. For a VRS or network-RTK mountpoint, verify the provider’s stated coverage and operating limits instead; the source-table coordinates may not represent the effective virtual reference location. In parallel, log the GST sentence, which gives the receiver’s own error estimate:

$GNGST,121854.00,0.023,0.015,0.011,89.2,0.014,0.012,0.028*6A

Fields 6 and 7 are the standard deviations of latitude and longitude errors in meters. These estimates are useful trend indicators, but they do not by themselves identify baseline length as the cause of a degraded solution.

Fix: Switch to a closer single-base NTRIP mountpoint where available, or set up a local base station within a few kilometers of the work area. For research fleets, a temporary base on a surveyed point plus an NTRIP caster on a laptop is often the fastest path. If the mission spans a large area, validate RTK performance throughout the area rather than relying on a fixed universal baseline limit.

How NTRIP Link Dropouts Break the Correction Stream

Problem: The rover has good sky view, short baseline, and no multipath, but fix drops every few minutes for 10-30 seconds at a time.

Cause: The correction stream from the NTRIP caster to the rover is riding over cellular LTE or a long-range radio. Cellular handovers, packet loss, or radio fades can cause RTCM messages to stop arriving. Receivers may maintain a fixed solution briefly after corrections stop, but the hold time varies by receiver, configuration, motion, and measurement conditions.

Test: Log RTCM arrival times and message types at the rover. On a ntrip_client ROS 2 node, monitor:

ros2 topic hz /rtcm

Interpret this carefully: RTCM streams commonly contain several message types and may be published at rates other than 1 Hz, so topic frequency alone is not a complete health metric. Look for gaps in the arrival of required observation messages and correlate them with receiver correction-age data, RTK status, and cellular signal strength if you can read the modem’s AT interface.

Fix: Improve link reliability rather than retransmitting stale RTCM corrections, which can degrade or invalidate the solution. Use a suitable external or directional antenna for the cellular modem if you are at the edge of coverage. For mission-critical work, consider a dedicated radio link between the base and rover where permitted by local spectrum regulations, and monitor correction age so the autonomy stack can react before position quality becomes unsafe.

Why Antenna Cabling and Grounding Cause Silent Failures

Problem: Fix is intermittent in ways that do not correlate with sky view, baseline, or link quality.

Cause: A damaged coax cable, a loose SMA connector, water ingress at the antenna base, or electrical interference from motor drivers. These are unglamorous but common. Vibration on a UGV can work connectors loose over dozens of missions.

Test: Check C/N0 across tracked satellites, taking elevation and constellation into account. If signal levels are uniformly low compared with a known-good installation in the same open location, the cable or antenna may be attenuating the signal. Carefully inspect and reseat connectors while logging; a repeatable change in signal strength can identify an intermittent connection.

Fix: Tighten SMA connectors to the torque specified by the connector and equipment manufacturer. Weatherproof the antenna base with appropriate outdoor-rated sealing materials. Route the GNSS coax away from motor power cables and other noise sources; maintain physical separation where practical and cross cables at 90 degrees where they must meet.

What Nav2 Does When the RTK Fix Disappears Mid-Mission

A resilient autonomy stack does not assume that RTK will always be available. It degrades gracefully. In ROS 2 Nav2 with robot_localization, a common pattern uses two EKF instances:

• ekf_local fuses wheel odometry and IMU into odom -> base_link. This runs continuously and never depends on GNSS.
• ekf_global fuses odometry with navsat_transform_node output and, when configured with world_frame: map, publishes the global map -> odom correction.

The key configuration is covariance and measurement-quality handling. When your GNSS driver reports FLOAT or a single-point solution, use receiver-provided covariance where it is trustworthy, or republish the NavSatFix message with a conservatively inflated covariance appropriate to the measured performance. For example, a system may use 1.0 m² for FLOAT and 25.0 m² for single-point after validating those values in its environment. The ekf_global can then down-weight the measurement and lean more heavily on odometry.

A minimal covariance-scaling node in Python can read receiver-specific fix status and rewrite position_covariance before navsat_transform_node consumes it. Odometry drift during a 30-60 second fix loss must be measured on the specific rover, terrain, speed, and wheel setup; it should not be assumed to remain within a particular distance. Beyond the validated dead-reckoning interval, the recommended behavior is to pause the mission and hold position rather than accumulate open-loop error.

Configure the Nav2 behavior_tree with a custom condition node that checks receiver-specific fix quality and triggers a Wait behavior when quality remains below the mission threshold for the configured timeout. For tight corridors, that threshold will commonly require RTK FIX rather than FLOAT.

Pre-Mission RTK Checklist

Before you send the rover out, run these checks. They take under ten minutes and prevent many field failures:

1. Power the rover in an open area and confirm that it reaches the RTK quality required for the mission. Investigate unusual acquisition times before driving.
2. Log 60 seconds stationary and compare horizontal scatter with your validated acceptance threshold.
3. Verify that a single-base mountpoint is within the operating distance recommended for that receiver and service; verify network-RTK coverage with the provider.
4. Check that required RTCM messages arrive continuously for 2 minutes and that correction age remains acceptable.
5. Inspect antenna connector torque and cable routing away from motor cables.
6. Check C/N0 and satellite tracking against a known-good open-sky baseline for the same hardware.
7. Verify Nav2 fallback behavior by interrupting the NTRIP source briefly and confirming the robot enters its configured safe behavior after the timeout.

Frequently Asked Questions

How long does it take for RTK to reacquire fix after signal loss?

Reacquisition time varies widely with receiver type, signal interruption length, correction availability, motion, satellite geometry, and sky view. Modern multi-band receivers such as u-blox ZED-F9P and Septentrio mosaic units can often recover a fixed solution within seconds under favorable conditions, but recovery can also take minutes. Power-on GNSS acquisition and RTK ambiguity resolution are separate processes, so there is no universal cold-start-to-FIX time.

Does RTK work at night or in rain?

Yes. Night has no meaningful effect on GNSS. Rain and clouds usually cause little direct attenuation at GNSS frequencies, although heavy wet foliage can worsen canopy-related attenuation and multipath.

Can I use RTK indoors or in tunnels?

Not reliably. RTK requires sufficient direct satellite visibility and correction data. Indoor environments and tunnels generally need alternative positioning such as UWB, visual SLAM, or LiDAR-based localization. Some robotics teams switch localization sources at the door threshold.

What is the difference between RTK FLOAT and RTK FIX?

FIX means the receiver has resolved carrier-phase integer ambiguities and can provide centimeter-level positioning under good conditions. FLOAT means the ambiguities are not fixed, so accuracy is less reliable and may range from centimeters to decimeters or worse. For autonomous navigation with tight corridors, define a validated quality threshold; many missions require FIX.

How do I choose between a local base station and network RTK?

A local base gives you a short baseline and can work without cellular coverage, but requires setup and a known reference position. Network RTK via a national or commercial NTRIP service is faster to deploy and covers wider areas, but depends on cellular connectivity, service availability, and subscription. For repeated work at one site, a local base is often more controllable.

Does the robot’s chassis material affect RTK performance?

Yes. Metal chassis can create multipath reflections and block low-elevation satellites. Raising the antenna above the highest metal surface and using an appropriate ground plane can mitigate these effects. Non-metallic covers may reduce some reflections, but antenna placement remains the more important factor.

Can I fuse RTK with visual odometry for better robustness?

Yes, and this is common in field robots. Visual-inertial odometry (VIO) can provide short-term motion estimates that bridge RTK dropouts. The robot_localization package accepts multiple odometry inputs simultaneously. Cameras add cost and processing load, so the decision depends on mission requirements.

Building Field-Ready Autonomy

RTK is a powerful tool, but treating it as a black box that always works leads to failed missions. The failure modes above are common causes of field dropouts on ROS 2 UGVs, and the diagnostic techniques give you a repeatable path from symptom to root cause. Combined with a Nav2 stack configured for graceful degradation, your robot can handle interruptions that would otherwise abort a mission.

Fictionlab’s team works with research groups and integrators building outdoor autonomy on Leo Rover and Raph Rover platforms. Learn more about research applications or browse the shop for GNSS-ready configurations. If you need a custom sensor stack or a tailored integration for a specific field environment, get in touch through Fictionlab’s custom robotics service.