RTK GPS on a Field Robot: What It Is, Why You Need It, and How to Set It Up

TL;DR: RTK GNSS (often called RTK GPS, Real-Time Kinematic GPS) is a satellite positioning technique that uses carrier-phase measurements and corrections from a fixed base station or reference network to give a mobile robot centimeter-level accuracy (typically 1-2 cm horizontal) instead of the 2-5 m you get from a standard GNSS receiver. On a field robot like the Leo Rover, an RTK GPS robot setup involves a rover-mounted GNSS receiver, a correction source (your own base station or an NTRIP service over the internet), and a ROS 2 driver that publishes sensor_msgs/NavSatFix plus RTK quality information in driver-specific topics or fields. This article explains how RTK works, when you need it, and how to wire it up step by step.

Why standard GPS is not enough for a field robot

A consumer GNSS module on a UGV usually reports a horizontal accuracy of 2-5 meters under open sky, degrading further under tree canopy or near buildings. That is fine for logging a hiking trail. It is not fine when you want a robot to follow crop rows 30 cm apart, return to the exact same soil sampling point next week, or hand off waypoints between a drone and a ground vehicle.

The error budget of a standalone GNSS receiver is dominated by ionospheric and tropospheric delays, satellite clock and orbit errors, and multipath. Many of these errors are spatially correlated: two receivers within roughly 10-20 km of each other see almost the same atmospheric delay. RTK GPS exploits exactly that fact.

What RTK GPS is, in plain language

RTK stands for Real-Time Kinematic. Instead of only measuring the pseudorange (the coarse code-based distance) to each satellite, an RTK receiver also measures the carrier phase of the GNSS signal. The carrier wavelength on GPS L1 is about 19 cm, and a receiver can track phase to a small fraction of that wavelength. The hard part is resolving the integer number of full wavelengths between satellite and antenna – the so-called integer ambiguity.

RTK solves that ambiguity by comparing observations from two receivers:

• Base station: a GNSS receiver at a precisely known, fixed location. It streams its raw observations or corrections (usually in RTCM3 format) over a link.
• Rover: the GNSS receiver on the moving robot. It combines its own observations with the base corrections to cancel out the shared error sources.
• NTRIP: Networked Transport of RTCM via Internet Protocol. A standard way to push corrections from a base (or a national network of bases) to the rover over TCP/IP, typically via a mobile data link.

The data flow looks like this: Satellites → Base (streams observations/corrections) → NTRIP caster (internet relay) → Rover (applies corrections, resolves ambiguities) → centimeter-accurate fix. When the rover successfully resolves the integer ambiguities, the fix status changes from “float” (decimeter-level) to “fixed” (centimeter-level). In ROS 2, sensor_msgs/NavSatFix carries the position and covariance, while the exact RTK fixed/float state is usually exposed by RTK-aware drivers in vendor-specific messages or diagnostics.

RTK accuracy you can expect

Manufacturer specifications for modern multi-band receivers (for example u-blox ZED-F9P, Septentrio mosaic-X5, Fixposition Vision-RTK 2) quote roughly:

• Horizontal accuracy in RTK fixed mode: approximately 1 cm + 1 ppm of baseline length.
• Vertical accuracy: approximately 1.5-2x the horizontal figure.
• Convergence time to fix: typically a few seconds under open sky with a short baseline.

Performance degrades with longer baselines (base-to-rover distance), poor sky visibility, and environments with strong multipath. Always validate these numbers in your own deployment site.

When you actually need RTK on a UGV

Adding RTK GPS to a robot increases cost, integration effort, and dependence on connectivity. Use it when your task genuinely requires it. Typical scenarios include:

• Precision agriculture: row-following, targeted spraying, phenotyping plots where each plant has known coordinates. Explore use cases on the agriculture applications page.
• Geo-referenced mapping: building orthomosaics or point clouds where the dataset needs to align with a cadastral map.
• Repeatable autonomy: coming back to the exact same waypoint across sessions, days, or seasons.
• Sensor fusion ground truth: validating SLAM, visual odometry, or LiDAR odometry against a centimeter-accurate reference. This is common in the kind of work shown on the research applications page.
• Multi-robot coordination: drones and ground robots sharing a common frame.

If your robot operates indoors, in dense forest, or in urban canyons, RTK alone will not save you. There you fuse RTK with wheel odometry, IMU, and visual or LiDAR SLAM.

How to set up RTK GPS on a Leo Rover

The Leo Rover runs ROS 2 on a Raspberry Pi and exposes USB and serial interfaces, which makes it straightforward to add an RTK receiver. The example below uses a generic u-blox F9P-class module, but the same pattern applies to a Fixposition Vision-RTK 2 or any receiver with a ROS 2 driver.

1. Mount the antenna

Place the GNSS antenna as high as possible on the rover, with a clear view of the sky and away from Wi-Fi, USB 3.0 cables, and switching regulators (all sources of RF interference). Use a ground plane if the antenna requires one.

2. Connect the receiver

Plug the receiver into the Leo Rover’s USB port. Verify it enumerates:

ls /dev/serial/by-id/

You should see something like usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00. Use that stable path in your launch file rather than /dev/ttyACM0.

3. Install a ROS 2 driver

For u-blox receivers, a widely used ROS 2 package is ublox_dgnss. Install it into your workspace:

cd ~/ros2_ws/src
git clone https://github.com/aussierobots/ublox_dgnss.git
cd ~/ros2_ws && colcon build --packages-select ublox_dgnss ublox_dgnss_node ublox_nav_sat_fix_hp_node ublox_ubx_interfaces ublox_ubx_msgs
source install/setup.bash

4. Stream NTRIP corrections

You need a source of RTCM3 corrections. Options:

1. Subscribe to a national or commercial NTRIP service; some countries have free public networks, while others require registration or a paid subscription.
2. Run your own base station with a second RTK receiver at a surveyed point.

A common ROS 2 NTRIP client is ntrip_client. Launch it with your caster credentials:

ros2 run ntrip_client ntrip_ros --ros-args \
  -p host:=caster.example.org -p port:=2101 \
  -p mountpoint:=NEAR_RTCM3 \
  -p username:=YOUR_USER -p password:=YOUR_PASS \
  -p ntrip_version:=None

The client publishes RTCM messages on /rtcm, which the GNSS driver subscribes to and forwards to the receiver over the serial link.

5. Verify the fix

Echo the navigation topic and watch the fix quality:

ros2 topic echo /fix

Look at the status.status field and any driver-specific RTK status topics. In standard sensor_msgs/NavSatFix, STATUS_GBAS_FIX often indicates that a differential correction source is being used, but it does not by itself distinguish RTK float from RTK fixed. The position_covariance diagonal should drop to roughly 1e-4 m² (i.e. ~1 cm standard deviation) when fixed.

6. Fuse with the rest of the stack

Feed /fix into robot_localization‘s navsat_transform_node together with the Leo Rover’s wheel odometry and IMU. That gives you a continuous odom → base_link and map → odom transform chain, with RTK pulling absolute position and the IMU/odometry filling gaps during brief outages.

How RTK differs from PPP, SBAS, and dead reckoning

RTK is one of several precise positioning techniques. Knowing the differences helps you pick the right tool:

• SBAS (WAAS, EGNOS): broadcast corrections via geostationary satellites. Accuracy approximately 1-2 m. No base station needed. Useful as a fallback.
• PPP (Precise Point Positioning): uses precise satellite orbit and clock products, no local base. Accuracy reaches a few centimeters but convergence can take tens of minutes.
• PPP-RTK: hybrid approach combining a network of reference stations with PPP-style corrections. Faster convergence than pure PPP.
• Dead reckoning: wheel encoders plus IMU. No absolute reference, drifts over time, but works anywhere.

For most field robotics work with short missions in known areas, RTK over NTRIP is the practical sweet spot.

FAQ

What is the difference between RTK GPS and regular GPS?

Regular GPS uses code-based pseudorange measurements and gives 2-5 m accuracy. RTK GPS adds carrier-phase measurements plus corrections from a base station, reaching approximately 1-2 cm horizontal accuracy when the integer ambiguities are resolved (RTK fixed).

Do you need an internet connection for RTK?

You need a path for RTCM3 corrections from base to rover. The most common path is NTRIP over the internet (mobile data), but you can also use a radio link between your own base and rover, which works in areas with no cellular coverage.

How far can the rover be from the base station?

Accuracy degrades roughly 1 ppm per kilometer of baseline. Under 10 km, expect centimeter-level fixed solutions. Beyond 20-30 km, convergence becomes less reliable. Network RTK (VRS) reduces this distance-dependent error by synthesizing a virtual base near the rover.

What happens when the rover loses RTK fix?

The solution drops to “float” (decimeter accuracy) or to standard GNSS (meter accuracy). A well-designed stack fuses RTK with IMU and wheel odometry, so brief outages produce only small drift before the fix recovers.

Does RTK work under tree canopy or indoors?

Poorly. RTK needs line of sight to multiple satellites, and multi-frequency tracking improves robustness. Under dense canopy, expect frequent drops to float. Indoors, RTK does not work at all – use visual or LiDAR SLAM instead.

Can you use RTK with a single-frequency receiver?

Yes, but convergence is slower and the solution is more sensitive to ionospheric activity. Multi-band, multi-constellation receivers (GPS + Galileo + GLONASS + BeiDou on bands such as L1/L2 and, in newer receivers, L5/E5) are the current standard for serious field work.

Which RTK receiver fits the Leo Rover?

Any receiver with a USB or UART interface and a ROS 2 driver. Fictionlab integrates options such as the Fixposition Vision-RTK 2, which combines RTK with visual-inertial odometry for robust operation in GNSS-degraded environments. Available configurations are listed in the Fictionlab shop.

Get the right RTK hardware for your robot

If you are planning a field deployment that needs centimeter-level positioning, browse the RTK-ready configurations and sensor add-ons in the Fictionlab shop and match a receiver to your accuracy, environment, and budget requirements.