RTK Base Station vs Rover: Two Meanings of One Word in GNSS

TL;DR: In RTK GNSS, a base station is a stationary receiver on a known coordinate that streams correction data, while a rover is the moving receiver that applies those corrections to reach centimeter-level relative accuracy. The confusion starts when your mobile robot is also called a “rover” (as with Leo Rover). Both meanings can coexist: your Leo Rover (the vehicle) carries an RTK rover (the receiver) that listens to a base station over radio, cellular NTRIP, or Wi-Fi. This article explains the rtk base station vs rover split, what each side must provide, and when to run your own base versus subscribing to a network correction service.

Why “rtk base station vs rover” causes confusion in mobile robotics

The word “rover” carries two entirely different meanings inside the same sentence when you work with Leo Rover or Raph Rover platforms. On one hand, “rover” is the mobile robot chassis rolling across a field. On the other, GNSS engineers have been calling the moving RTK receiver a “rover” since long before UGVs entered mainstream research. When someone writes “the rover received corrections from the base,” they may mean the robot, the GNSS antenna module, or both.

The rtk base station vs rover distinction is not about hardware brand or price. It is about role in the correction pipeline. A base station observes GNSS satellites from a fixed, surveyed location. Because its coordinates are known, its observations can be used to model or remove errors shared with a nearby rover, including atmospheric effects and satellite clock and orbit errors. The base packages observations and station information as RTCM messages and forwards them to any RTK rover in range. The rover combines these data with its own observations, resolves carrier-phase ambiguities, and outputs a fixed solution that can provide centimeter-level relative positioning under good sky conditions.

What the base station does versus what the RTK rover does

To keep the two roles clear, the table below separates responsibilities and prerequisites. This is the practical checklist Fictionlab’s team uses when helping researchers set up field trials with the Leo Rover.

Correction flow, step by step

A working RTK system moves data through a predictable path. Understanding this flow helps you diagnose why a fix drops from FIXED to FLOAT in the middle of a run.

1. Base station tracks satellites from its known position.
2. Base encodes GNSS observations, station coordinates, and related data into RTCM3 messages.
3. Corrections travel via UHF radio, LTE modem to an NTRIP caster, or a local wireless link.
4. The RTK receiver on the robot decodes RTCM and combines it with its own raw satellite observations.
5. The receiver runs carrier-phase ambiguity resolution and outputs a FIXED solution over UART, USB, or Ethernet.
6. ROS 2 nodes (for example, nmea_navsat_driver or a vendor driver publishing sensor_msgs/NavSatFix) forward the position into the navigation stack.

When to run your own base and when to use a network caster

Not every project needs a physical base tripod in the field. Public and commercial GNSS correction services, including national CORS and VRS networks, already provide RTCM streams covering large regions, often through NTRIP casters. The choice comes down to baseline length, latency tolerance, and site logistics.

Running your own base station makes sense in the following situations:

• The nearest network reference station is far away or the available network service does not provide reliable corrections for your area.
• You operate in areas with no cellular coverage, such as forestry sites, mining pits, or agricultural fields far from towers.
• You need repeatable local accuracy without depending on absolute datum alignment, for example when mapping the same test plot over months.
• Regulatory or security constraints prevent uploading position data to a third-party caster.

A network NTRIP correction service is usually the better choice when:

• Your mission area sits within a well-covered CORS or VRS network and you have reliable LTE.
• You want coordinates in a known reference frame without operating and surveying your own base station.
• The mission is short and setting up a base tripod adds more overhead than value.
• You need multiple robots to access the same correction service without deploying local repeaters.

How baseline length and sky visibility limit accuracy

Two physical constraints dominate RTK performance in field robotics. Both apply to the base and the RTK rover receiver equally.

Baseline length is the straight-line distance between the base station and the rover receiver. Ionospheric and tropospheric delays are correlated over short distances but decorrelate as the baseline grows. Single-band L1 receivers are generally best suited to short baselines, often in the order of several kilometres in favourable conditions. Multi-band receivers can support longer baselines and are more robust, but reliable fixing range depends strongly on atmospheric conditions, satellite geometry, receiver capabilities, and the type of corrections used. The u-blox ZED-F9P, for example, is an L1/L2 receiver; its published accuracy specifications are commonly stated for a 10 km baseline. At longer baselines, FLOAT solutions and degraded accuracy become more likely, especially with a single local base.

Sky visibility matters at both ends. The base needs clear horizons to track the same satellites the rover sees. If the base sits under a tree canopy while the rover drives in an open field, common-view satellites drop and the correction stream loses value. On the robot, mount the antenna as high and as clear of metal structures as practical. Multipath from nearby buildings or the robot’s own chassis is a leading cause of degraded fixes in urban and industrial environments.

Connectivity choices for the correction link

The correction stream needs to reach the robot with low and consistent latency; the acceptable correction age depends on the receiver and its configuration, but delays of several seconds can degrade RTK performance. Common transport options include:

• UHF radio (433/868/915 MHz): Line-of-sight range of 1-5 km depending on power and antennas. No infrastructure required but subject to regional licensing.
• NTRIP over cellular: Uses a standard TCP client on the robot. Requires LTE coverage and can transport corrections over long distances, although RTK performance still depends on the effective distance to the reference station or network solution.
• Local Wi-Fi or LoRa: Wi-Fi can be useful for short-range links. LoRa may work for low-rate RTCM streams where its configured data rate, latency, duty-cycle limits, and local regulations are suitable.

How this maps onto Leo Rover and ROS 2 workflows

On a Leo Rover configured for outdoor autonomy, the RTK receiver can sit inside the payload bay with its antenna mounted on the top plate. The receiver publishes NMEA or UBX messages over serial, which a ROS 2 driver converts to sensor_msgs/NavSatFix. That message can be supplied to robot_localization‘s navsat_transform_node, which converts GNSS data into the local navigation frame for fusion with IMU and wheel odometry in an EKF or UKF.

The base station lives entirely outside the robot. It can be a second u-blox module on a tripod configured to output RTCM and used with str2str from RTKLIB to push data to an NTRIP caster, or a receiver board such as the ArduSimple simpleRTK2B configured in base mode. From the robot’s perspective, the source of corrections is transparent: it simply receives RTCM3 and applies it. This modularity is one reason Fictionlab keeps the RTK payload as an optional module rather than a fixed component, and why research teams can swap between their own base and a national correction service depending on the deployment site.

Frequently asked questions

Is the RTK rover the same as the mobile robot?

No. In GNSS terminology, the “rover” is the moving receiver that consumes corrections. When that receiver is mounted on a Leo Rover, both objects share the name but refer to different things. The robot is the vehicle; the RTK rover is a GNSS receiver installed on it.

Can one base station serve multiple robots?

Yes. A base can provide the same RTCM stream to multiple RTK rovers within the effective baseline. Over radio, this can be a broadcast transmission; over NTRIP, each rover normally connects as a separate client. The number of supported NTRIP clients depends on the caster and network capacity, while the required data rate depends on the selected RTCM message set and update rate.

What is the difference between FIXED and FLOAT solutions?

FIXED means the receiver has resolved carrier-phase integer ambiguities and can provide centimeter-level relative accuracy under good conditions. FLOAT means ambiguities are not resolved; accuracy is typically worse and may range from decimeter-level to metres depending on conditions. For autonomous navigation, you generally want FIXED throughout the mission.

Do I need a multi-band receiver?

Multi-band (L1/L2 or L1/L5) receivers acquire fix faster, hold it under partial sky obstruction, and tolerate longer baselines than single-band L1 units. For serious field robotics, multi-band is the practical default. Single-band is acceptable for short-baseline, open-sky demonstrations.

How long does it take to get a FIXED solution?

RTK convergence time can range from a few seconds to several minutes, depending on receiver state, satellite visibility, multipath, baseline length, correction quality, and whether the receiver has recently been operating. A good multi-band receiver with a reliable correction stream often reaches FIXED within a minute, but this is not guaranteed.

Can I use RTK without internet?

Yes. Deploy your own base station and link it to the robot with UHF radio or a local wireless bridge. No cellular or internet connectivity is required for the corrections themselves, though you may need internet elsewhere for mission planning or telemetry.

What happens if the correction stream drops mid-mission?

The receiver may fall back to standalone GNSS, typically with metre-level accuracy, or retain an RTK-derived solution only briefly depending on its configuration and available observations. Some RTK-INS systems can coast using inertial data, but the duration and accuracy depend on the IMU quality and motion conditions; centimeter-level accuracy should not be assumed. Design your navigation stack to detect the transition via the fix status field and adjust behavior accordingly.

If you are planning a field deployment and want to configure an RTK-capable payload on Leo Rover, browse available modules and accessories in the Fictionlab shop.