Access to reliable GNSS data can no longer be taken for granted. In regions with active conflicts, jamming, spoofing and loss of reliable position data are now everyday occurrences. Mission-critical systems therefore have to keep operating in GNSS-available, GNSS-denied and GNSS-untrusted environments, and simulation is where that behaviour can be tested safely and repeatably.

GNSS in robotics

Under open sky, GNSS is a reliable source of absolute position in a global frame, something no onboard sensor can provide on its own. Besides position, a receiver also delivers velocity (from Doppler measurements) and very accurate time. The pulse-per-second (PPS) signal and NMEA time messages are commonly used to synchronize LiDARs, IMUs, cameras and other sensors in robotic and mobile mapping systems, so that all measurements share one time base.

GNSS outages and interference

Environment – GNSS needs a line of sight to at least four satellites. Tunnels, underground car parks, dense forest canopy and urban canyons block or attenuate the signals, causing complete outages or a sharp drop in the number of visible satellites and a degraded geometry (high DOP). During such periods the robot must rely on dead reckoning from wheel odometry, IMU or LiDAR/visual odometry.

Jamming – GNSS signals reach the ground extremely weak, so even a low-power transmitter on the same frequency can drown them out. Jamming, intentional or accidental (e.g. cheap in-car jammers), leads to loss of fix over an area that can range from a few metres to many kilometres. A robust localization stack should detect it, for example from a sudden drop in carrier-to-noise ratio, and fall back to other sensors.

Spoofing – Unlike jamming, spoofing does not remove the solution but replaces it: an attacker broadcasts counterfeit signals so the receiver computes a plausible but false position or time. It is harder to detect, because the fix still looks valid; consistency checks against IMU and odometry, multi-constellation and multi-frequency receivers, and signal authentication (e.g. Galileo OSNMA) help mitigate it.

GNSS error sources

Multipath – Signals reflected from buildings, vehicles, water or the ground reach the antenna along a longer path than the direct signal, biasing the measured pseudorange. In urban canyons the direct signal may be blocked entirely (NLOS reception), producing errors of tens of metres. Multipath is local and time-varying, so differential corrections do not remove it; antenna design, placement and signal-quality-based weighting are the main countermeasures.

Atmospheric propagation – On the way through the ionosphere and troposphere signals are delayed, which appears as extra range. The ionospheric delay depends on solar activity and time of day and can reach several meters; dual-frequency receivers can largely cancel it. The tropospheric delay depends on pressure, temperature and humidity and is usually handled with models. Both errors are strongly spatially correlated, which is what makes differential corrections effective.

D-GNSS and RTK

Differential GNSS (D-GNSS) uses a reference station at a precisely known location. The station compares measured pseudoranges with the ones expected from its known position and broadcasts the differences as corrections. A nearby rover applying them removes most of the satellite clock, orbit and atmospheric errors, improving accuracy from a few meters to below one meter. Corrections can come from a local base station, a network over NTRIP, or satellite-based augmentation systems such as EGNOS.

Real-Time Kinematic (RTK) goes further by using carrier-phase measurements instead of code pseudoranges. Once the integer ambiguities are resolved (a "fixed" solution), the rover reaches centimetre-level accuracy relative to the base, typically within tens of kilometres of it. RTK is the standard for precision agriculture, surveying and mobile mapping, but the fix is fragile: obstructions and multipath can drop it to a "float" solution with decimetre-level error, which the localization stack has to handle.

In practice, a robot with an RTK receiver obtains corrections over a wireless connection. There are subscription services that give you access to RTK stations near you, whose corrections you feed into your system. Alternatively, you can set up your own base station, survey it in, and send corrections over LoRa or a similar long-range communication link.

Multi-receiver systems

Some advanced applications use multiple receivers.

Dual-antenna setups are used on robots and machinery that need not only their track (course over ground, which a single receiver derives from velocity and only while moving) but also absolute heading, even when stationary. Two receivers, or one dual-antenna receiver, with antennas mounted at a known baseline compute heading from the relative carrier-phase position between them (moving-baseline RTK); longer baselines give more accurate heading.

Another application is multi-drone systems, such as drone light shows, where each drone carries its own RTK receiver and a shared base station provides corrections, so hundreds of drones can hold centimeter-level formations relative to each other.

GNSS raw data and solution offline

In robotics we usually need a position solution as fast as possible, computed in real time on the receiver. However, many receivers can also log their raw observations (pseudoranges, carrier phase, Doppler and signal strength for each tracked satellite) to a binary file, for example u-blox UBX-RXM-RAWX for later post-processing. These logs are typically converted to the receiver-independent RINEX format. Recording raw data costs little and keeps the option of computing a much better trajectory afterwards, which is valuable for mobile mapping, dataset collection and generating ground truth for evaluating localization.

With archived correction data you can compute an RTK-grade solution after the fact, known as post-processed kinematic (PPK). Post-processing has advantages over real-time RTK: it can run forward and backward in time and combine both passes, which fills gaps after signal outages and resolves ambiguities more reliably, and it is not affected by dropped correction links.

Saving raw data can be also useful for getting post-incident data. It can be used to find if GNSS outage was deliberate act, or what method was used.

Dead reckoning and tight integration

Dead reckoning estimates the current pose by integrating motion from a known starting point: angular rates and accelerations from an IMU, and traveled distance from wheel odometer. It works anywhere and at high rate, but its errors grow without bound over time. GNSS is the opposite: it gives absolute position with bounded error, but at a low rate and only when enough satellites are visible. Combining the two gives a continuous, smooth trajectory that GNSS keeps anchored to the globe, while dead reckoning bridges outages in tunnels, car parks or urban canyons.

There are two main ways to fuse them. In loose integration the GNSS receiver first computes its own position and velocity, and a filter (typically an EKF, e.g. robot_localization with navsat_transform in ROS 2) treats that output as one more measurement. It is simple and works with any receiver, but when fewer than four satellites are visible the receiver produces no fix, so GNSS contributes nothing. In tight integration the filter uses the raw measurements (pseudoranges, Doppler, carrier phase) directly, together with the IMU. Each satellite then counts on its own, so even one or two satellites still correct the drift, and individual faulty measurements, such as multipath-affected ones, can be detected and rejected.

The u-blox ZED-F9R is a good example of this approach packed into a single module. It combines a multi-band, RTK-capable GNSS receiver with a built-in 3D IMU and runs the fusion on the chip itself. In the automotive configuration it also takes wheel ticks or speed from the vehicle; for platforms without odometry it can run on GNSS and IMU alone. The module outputs a fused position, velocity and attitude at a higher rate than the raw GNSS fix and keeps navigating through short outages using the IMU and odometry. For a robot this moves most of the integration work from the robot's software to the receiver, at the cost of less control over the filter and its tuning: the IMU must be rigidly mounted, its orientation relative to the vehicle calibrated, and the module needs a short calibration drive before the dead-reckoning solution is trusted.

GNSS Simulation and its noise model

A GNSS sensor in simulation converts the ground-truth pose of a simulated body into geodetic coordinates (latitude, longitude, altitude), using a georeference that ties the simulation's local frame to a point on the WGS-84 ellipsoid. Ground truth alone is too optimistic: to test localization and sensor fusion realistically, the simulated output needs a noise model and, ideally, a way to reproduce the outages and effects described above.

O3DE

In O3DE, a GNSS sensor is provided by the ROS 2 Gem. It is a component attached to an entity that reads the entity's position, converts it to WGS-84 using the level's georeference, and publishes sensor_msgs/NavSatFix at a configurable rate. The output is essentially ground truth; adding a configurable noise model (position bias and random walk, fix-status changes, outage zones) is the natural next step for realistic testing.

Gazebo

Gazebo (gz-sim) provides a navsat sensor that publishes latitude, longitude, altitude and velocity, using the <spherical_coordinates> defined in the world as the georeference; ros_gz_bridge maps it to sensor_msgs/NavSatFix. Noise can be configured separately for horizontal and vertical position and velocity as Gaussian noise with mean, standard deviation and bias. Effects such as multipath, outages or RTK fix-status changes are not modelled and need custom plugins.

Isaac Sim

NVIDIA Isaac Sim focuses on cameras, LiDAR, IMU and contact sensors, and to our knowledge does not ship a dedicated GNSS sensor. GNSS is usually emulated with a Python script or OmniGraph node that reads a prim's world pose, converts it to WGS-84 from a chosen origin, adds noise and publishes sensor_msgs/NavSatFix through the ROS 2 bridge. The noise model, outages and fix-status behavior are therefore entirely up to the user's implementation.

Conclusion

For past years advanced features like RTK, raw data recording, moving-baseline solutions were not practical for mobile robotics. Receivers where bulky, required a large high-gain antennas. Those were used in surveying, heavy machinery and aviation. That was changed over last where cheap integrated Ublox receiver can both provide raw readout, accept RTK corrections and dead reckoning, with small antenna.

Those receivers are available for every robotic and mapping system. However, building digital twin of such system, requires expert knowledge and custom solutions. Solutions that are in Open Source are fine for initial testing or learning, but there are not enough for testing advanced autonomous system that have to be reliable and robust against challenges. Expertise for simulating GNSS outages, fault injection and noise modelling is essential for building usable digital twin that allows you to test system behavior on GNSS outage or degradation.

Interested in our latest projects? Follow us on LinkedIn to always stay updated!
You can also visit our GitHub page to learn more about our open-source projects.

Authors: