RTK GPS

RTK GPS – definition

RTK GPS stands for Real-Time Kinematic Global Positioning System. In current technical usage, the term usually refers more broadly to RTK GNSS, because many receivers use multiple satellite constellations such as GPS, Galileo, GLONASS, and BeiDou. RTK is a high-precision satellite positioning method that uses carrier-phase measurements and correction data from a reference station or correction service to improve position accuracy from meter-level to centimeter-level under suitable conditions.

In mobile robotics and UGV platforms, RTK GPS is used when global outdoor localization must be more accurate than standard GNSS. Typical use cases include waypoint navigation, geo-referenced mapping, repeatable path following, agricultural row navigation, and inspection in large open areas. For platforms such as Leo Rover and Raph Rover, RTK is not a replacement for odometry, IMU, or local perception. It is one localization source within a sensor fusion stack.

From a robotics perspective, RTK matters because local navigation and global positioning solve different problems. Wheel odometry and IMU estimate short-term motion but drift over time. LiDAR or visual SLAM can provide local consistency but may fail in low-feature terrain or may not be globally referenced. RTK provides an absolute position in a world-fixed frame, typically converted to a map frame through a localization pipeline in ROS 2.

How RTK positioning works

RTK uses a base-rover architecture. The base station is placed at a surveyed or otherwise known position. It computes correction data from observed satellite errors and sends these corrections to the rover receiver over a communication link. The rover then resolves integer carrier-phase ambiguities and estimates its position with much higher precision than code-based GNSS alone.

In practice, an RTK system has the following elements:

a GNSS antenna and receiver on the robot
a correction source – local base station or NTRIP service
a communication channel – radio, Wi-Fi, LTE, or Ethernet via onboard computer
time-consistent integration with the robot state estimator

Most professional receivers report several solution states. The exact names depend on vendor firmware, but the common interpretation is:

single – standalone GNSS, usually meter-level
float – carrier-phase used, but ambiguities not fully fixed
fix or fixed – integer ambiguities resolved, typically centimeter-level horizontal accuracy

Under open-sky conditions, many receivers specify RTK fixed horizontal accuracy around 1 cm + 1 ppm to 10 mm + 1 ppm, with vertical accuracy around 15 mm + 1 ppm to 20 mm + 1 ppm. These values come from manufacturer specifications and depend on baseline length, antenna quality, multipath, and constellation visibility.

RTK GPS in ROS 2

In ROS 2, RTK data is typically integrated through GNSS drivers and fused with other sensors using robot_localization. The key ROS message types come from sensor_msgs, nav_msgs, and geometry-related packages. The GNSS receiver often publishes latitude, longitude, altitude, covariance, and fix status. A separate node can convert geographic coordinates to a local Cartesian frame for navigation.

The most common ROS interfaces are:

sensor_msgs/msg/NavSatFix – geodetic position and covariance
sensor_msgs/msg/Imu – orientation, angular velocity, linear acceleration
nav_msgs/msg/Odometry – fused state estimate in robot frames
geometry_msgs/msg/Twist – velocity commands or estimated body motion

For frame semantics, ROS follows REP 103 for units and conventions and REP 105 for coordinate frames such as base_link, odom, and map. GNSS localization usually requires a transform chain that connects the antenna frame to base_link using a static transform. If the antenna offset is ignored, the robot pose can be biased during turning or when comparing GNSS to wheel odometry.

A typical ROS 2 workflow includes these steps:

receive GNSS data from the receiver driver
receive correction stream via RTCM from NTRIP or radio
convert geodetic coordinates to a local frame
fuse GNSS, IMU, and wheel odometry in an EKF or UKF
publish a globally consistent pose for navigation

ekf_filter_node:
  ros__parameters:
    frequency: 30.0
    two_d_mode: true
    map_frame: map
    odom_frame: odom
    base_link_frame: base_link
    world_frame: map

    odom0: /wheel/odometry
    odom0_config: [false, false, false,
                   false, false, false,
                   true,  true,  false,
                   false, false, true,
                   false, false, false]

    imu0: /imu/data
    imu0_config: [false, false, false,
                  false, false, true,
                  false, false, false,
                  false, false, true,
                  true,  false, false]

    odom1: /odometry/gps
    odom1_config: [true,  true,  false,
                   false, false, false,
                   false, false, false,
                   false, false, false,
                   false, false, false]

Key parameters and metrics

RTK performance should be evaluated using measurable parameters rather than generic claims. For UGV integration, the following metrics are usually the most relevant:

solution status – single, float, fixed
horizontal and vertical accuracy – often specified in cm + ppm
update rate – commonly 1 Hz, 5 Hz, 10 Hz, or 20 Hz depending on receiver
time to first fix and re-convergence time after signal loss
baseline length to base station or correction network
heading availability – from dual antenna setup or GNSS plus motion
covariance quality in ROS messages

For navigation on a small UGV, 5 Hz to 10 Hz is common for GNSS output, while IMU and wheel odometry run much faster. The state estimator must handle these asynchronous rates correctly. RTK alone does not provide stable heading at standstill in a single-antenna setup. For low-speed robots, heading usually comes from IMU fusion, wheel motion, or a dual-antenna GNSS receiver.

Supported hardware and integration on Leo Rover and Raph Rover

On Leo Rover, RTK integration must respect the onboard compute and power budget. Leo Rover uses Raspberry Pi as the default compute unit and supports ROS 2. This is sufficient for GNSS drivers, NTRIP client software, and state estimation, but heavy perception workloads may require careful resource planning.

For Leo Rover, a practical RTK setup usually includes a compact multi-band GNSS receiver, an external active antenna mounted above the chassis, and IMU plus wheel odometry fusion. Because Leo Rover is a differential-drive platform with four wheels, wheel slip on loose terrain can degrade dead reckoning. RTK helps bound long-term drift during outdoor operation.

On Raph Rover, the larger payload capacity makes it easier to add higher-grade GNSS receivers, dual-antenna heading systems, rugged antennas, LTE routers, and dedicated compute for sensor fusion. This is useful in field inspection, construction environments, or research payloads that need better global repeatability over larger areas.

For both platforms, antenna placement is important. The antenna should have an unobstructed sky view and should be separated from EMI sources and tall payload structures. The static transform between antenna and robot body must be measured and published.

ros2 run tf2_ros static_transform_publisher \
  0.12 0.0 0.18 0 0 0 base_link gps_antenna

Limitations and trade-offs

RTK is highly effective outdoors, but it has operational limits. Dense tree canopy, urban canyon effects, tunnels, roofs, and reflective metal structures can reduce fix quality or prevent integer ambiguity resolution. Multipath is often a larger practical problem than nominal receiver accuracy specifications suggest.

In UGV deployments, RTK should therefore be treated as one layer in a redundant localization architecture. A robust stack often combines:

RTK GNSS for absolute outdoor position
IMU for short-term attitude and motion dynamics
wheel odometry for local motion estimation
LiDAR or visual odometry for drift reduction when GNSS degrades

Another trade-off is infrastructure. A local base station gives high control over corrections, but requires setup and a surveyed reference position. An NTRIP service is easier to deploy, but depends on network coverage and subscription terms.

Normative references and standards

The ROS coordinate and unit conventions relevant to RTK integration are defined in REP 103 – Standard Units of Measure and Coordinate Conventions, and REP 105 – Coordinate Frames for Mobile Platforms. These documents are important when transforming GNSS outputs into map, odom, and base_link frames in ROS and ROS 2.

For data transport, correction streams are commonly provided as RTCM messages. NTRIP is a standard network transport method used by many GNSS receivers and correction services. Exact supported RTCM versions and message sets depend on receiver vendor and firmware. Accuracy claims must therefore be checked against the specific hardware specification rather than assumed from the term RTK alone.