GNSS

GNSS – definition

GNSS stands for Global Navigation Satellite System. It is a generic term for satellite-based positioning, navigation, and timing systems such as GPS (United States), Galileo (European Union), GLONASS (Russia), and BeiDou (China). In mobile robotics, GNSS is used to estimate a robot’s global position, velocity, and time reference in an Earth-fixed coordinate frame. For UGV platforms, GNSS is mainly relevant outdoors, where satellite visibility is sufficient and long-range global localization is required.

In practical robotics terms, GNSS provides an absolute position estimate, usually expressed as latitude, longitude, and altitude in the WGS84 geodetic reference frame. This is different from odometry, which estimates motion relative to a previous pose, and different from SLAM, which estimates pose within a local map. A UGV often combines GNSS with wheel odometry, IMU data, and sometimes LiDAR or vision. The goal is to improve robustness and reduce drift. GNSS alone is rarely enough for precise autonomous navigation on rough terrain, because its accuracy depends on receiver class, antenna quality, multipath conditions, correction method, and sky visibility.

For platforms such as Leo Rover and Raph Rover, GNSS is typically part of a fused localization stack rather than a standalone navigation source. Leo Rover can carry compact GNSS receivers suitable for research and education. Raph Rover, with higher payload capacity, is more suitable for dual-antenna GNSS, RTK hardware, or integrated GNSS/INS systems used in field robotics, inspection, agriculture, or construction research.

How GNSS is used in mobile robotics and ROS 2

In ROS 2, GNSS data usually enters the system through a hardware driver node that publishes standard message types. The most common message is sensor_msgs/msg/NavSatFix for geodetic position. Velocity may be published through vendor-specific topics or converted into geometry_msgs/msg/TwistStamped. Time and covariance information are critical, because downstream localization nodes use them to decide how much trust to place in the GNSS measurement.

A common ROS 2 pattern is to convert GNSS coordinates into a local Cartesian frame and fuse them with odometry and IMU data. This is often done with the robot_localization package, which supports GNSS integration through navsat_transform_node. The transform chain must be consistent with ROS frame conventions. REP 103 defines standard units and coordinate conventions, while REP 105 defines common mobile platform frames such as map, odom, and base_link.

ROS 2 element	Typical use	Common message / frame
GNSS driver node	Read receiver data over UART, USB, CAN, or Ethernet	`sensor_msgs/msg/NavSatFix`
IMU driver	Provide orientation and angular velocity	`sensor_msgs/msg/Imu`
Wheel odometry	Short-term local motion estimate	`nav_msgs/msg/Odometry`
navsat_transform_node	Convert geodetic fix to local world frame	`map`, `utm`, `base_link`
EKF / UKF	Fuse GNSS, IMU, odometry	`odometry/filtered`

The distinction between ROS 1 and ROS 2 matters operationally. Leo Rover supports ROS 2, so GNSS integration should target ROS 2 drivers and localization nodes. Legacy ROS 1 GNSS drivers exist for many receivers, but interface details, QoS handling, and launch syntax differ.

Key parameters and metrics

GNSS quality is not described by a single number. UGV integrators should evaluate update rate, horizontal accuracy, vertical accuracy, covariance, fix status, and correction mode. Research-grade field results depend strongly on antenna placement and on whether RTK or PPP corrections are available.

Update rate – commonly 1 Hz to 20 Hz for robotic receivers; some integrated systems support higher rates.
Position type – standalone GNSS, SBAS, DGNSS, RTK float, RTK fixed.
Horizontal accuracy – meter-level for standard GNSS, decimeter- to centimeter-level for RTK under good conditions.
Covariance – should be published or estimated; required for proper fusion in EKF/UKF.
Time to first fix – relevant after power-up or signal loss.
Satellite geometry – often summarized by DOP metrics such as HDOP and VDOP.
Heading support – may require motion-based estimation or a dual-antenna setup.

A simple accuracy model used in filtering is based on measurement covariance. If the GNSS-reported horizontal standard deviation is sigma_x and sigma_y, the planar covariance contribution can be approximated as:

R_gnss =
[ sigma_x^2      0    ]
[    0       sigma_y^2 ]

If the receiver outputs a full covariance matrix in NavSatFix, that source should be preferred over fixed assumptions.

GNSS hardware and correction methods

For UGVs, GNSS hardware selection depends on the required accuracy and environment. Entry-level single-band receivers are suitable for waypoint logging, rough geotagging, or outdoor telemetry. Precise navigation and repeatable path following usually require multi-band GNSS and RTK corrections. In dense urban or partially obstructed environments, even RTK performance may degrade due to multipath and poor satellite visibility.

The main correction modes used in robotics are:

Standalone GNSS – no external correction; simplest integration; lowest accuracy.
SBAS / DGNSS – augmentation from regional services; moderate accuracy improvement.
RTK – uses carrier-phase corrections from a base station or NTRIP caster; can reach centimeter-level accuracy in favorable conditions.
GNSS/INS fusion – tightly or loosely coupled integration with IMU; improves continuity during temporary GNSS degradation.

Raph Rover is better suited to heavier survey-grade antennas, rugged enclosures, and integrated GNSS/INS payloads. Leo Rover can still be used effectively for GNSS experiments, field mapping, and educational localization pipelines, but its compact form factor favors lightweight sensors and careful power budgeting.

Practical integration on Leo Rover and Raph Rover

On Leo Rover, GNSS is usually added as an external sensor over USB or serial. A typical pipeline includes a GNSS receiver, an IMU, wheel odometry from the differential drive base, and robot_localization. The output is a globally referenced estimate in the map frame. This is useful for outdoor waypoint navigation, dataset collection, or georeferencing observations from a camera or LiDAR payload.

On Raph Rover, the same architecture scales to larger outdoor deployments. The higher payload budget supports better antennas, elevated mounts, vibration isolation, and compute hardware capable of running perception, mapping, and state estimation in parallel. This matters in field applications such as agricultural rows, terrain inspection, and large construction sites, where the robot must preserve global consistency over long distances.

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

ros2 topic echo /fix
ros2 topic hz /fix
ros2 run tf2_ros tf2_echo map base_link

The GNSS antenna should be mounted with a clear sky view and with known offset relative to base_link. Poor mounting can introduce systematic localization error even when the receiver itself is performing correctly.

Limitations and trade-offs

GNSS does not solve local obstacle avoidance, terrain understanding, or indoor localization. It is weak under trees, near buildings, under bridges, and next to reflective metal surfaces. Standard GNSS also does not provide reliable heading when the robot is stationary, unless the system uses a dual-antenna configuration or a tightly coupled inertial solution.

For this reason, GNSS on UGVs is usually combined with:

wheel odometry for short-term motion tracking,
IMU for orientation and dynamic stabilization,
LiDAR or vision for local mapping and obstacle detection,
SLAM or localization against a prior map where GNSS is degraded.

Normative references and standards

In ROS-based mobile robotics, GNSS integration should follow ROS coordinate and frame conventions. The key references are REP 103 for standard units and coordinate conventions, and REP 105 for coordinate frames on mobile platforms. Message-level integration relies on standard ROS interfaces such as sensor_msgs/msg/NavSatFix and sensor_msgs/msg/Imu. For practical fusion in ROS 2, the robot_localization package and its navsat_transform_node are widely used reference implementations.

At the geodetic level, WGS84 is the standard global reference frame used by GNSS receivers. Integrators should also check receiver-specific documentation for supported constellations, correction services, output rates, and covariance reporting behavior. These details vary across vendors and firmware versions.