GNSS Overview

The Global Localization module fuses the visual-inertial odometry of a ZED camera with the position given by an external GNSS receiver. This page explains the GNSS concepts used across the documentation and helps you choose and install a receiver.

What is GNSS?

GNSS (Global Navigation Satellite System) is the generic name for the satellite constellations that broadcast positioning and timing signals worldwide:

Regional systems such as QZSS (Japan) and NavIC (India) complement them. “GPS” is often used as a synonym for GNSS, but it is only one of these constellations. Modern receivers track several constellations at the same time, which increases the number of visible satellites and improves both availability and accuracy.

A GNSS receiver measures the travel time of the signals coming from at least four satellites and computes its latitude, longitude, altitude and the current UTC time. These values are usually expressed in the WGS84 geodetic reference system. See Coordinate Systems for the conversions available in the SDK.

Why fuse GNSS with a ZED camera?

GNSS and visual-inertial odometry (VIO) have complementary strengths:

• GNSS gives an absolute position on Earth with an error that does not grow over time, but it is updated slowly (typically 1 to 10 Hz), it is noisy over short distances, it gives no orientation, and it degrades or disappears under bridges, in tunnels, near tall buildings or under dense trees.
• VIO gives a smooth, high-rate 6-DoF pose (position and orientation), but only relative to its starting point, and its error slowly accumulates with the traveled distance.

By fusing both, the ZED SDK provides a global, drift-free, high-rate pose that keeps working during GNSS outages.

Positioning accuracy

The accuracy of a GNSS position depends on the receiver, the antenna, the sky visibility and, above all, on the correction data used by the receiver. Receivers report the type of solution they computed as a fix type:

These values are indicative and assume an open sky. In urban canyons, the reflection of the signals off buildings (multipath) can add errors of several meters even with corrections.

The ZED SDK exposes these fix types through sl::GNSS_MODE (no fix, 2D, 3D) and sl::GNSS_STATUS (single, DGNSS, RTK float, RTK fixed), which you set in the sl::GNSSData structure ingested by the Fusion module. See Using GNSS Data in Your Application.

RTK

RTK (Real-Time Kinematic) is the technique used to reach centimeter-level accuracy. A base station, installed at a precisely known position, observes the same satellites as your receiver (the rover) and streams correction data to it, usually in the RTCM 3 format. Since most of the errors (satellite orbits and clocks, atmospheric delays) are shared by two receivers that are close to each other, the rover can cancel them and use the phase of the carrier signal to compute a very precise relative position.

RTK requires:

• an RTK-capable receiver and a compatible antenna,
• a source of corrections: your own base station, or a public or commercial correction network,
• a base station close enough to the rover. The accuracy decreases with the distance, and a distance below 25 km is recommended.

NTRIP

NTRIP (Networked Transport of RTCM via Internet Protocol) is the standard protocol used to receive RTK corrections over the internet. An NTRIP caster is a server that distributes the corrections of many base stations; each base station stream is called a mountpoint. To connect, an NTRIP client running on your device needs:

• the URL (or IP address) and port of the caster,
• the name of the mountpoint, usually the base station closest to your working area,
• a username and password, if the caster requires them.

The client sends the corrections to the receiver through its serial or USB link. Some networks also require the client to periodically send the rover position (an NMEA GGA sentence), for example to generate a virtual reference station (VRS) close to it.

Correction services are offered by national geodetic agencies, by regional networks, and by commercial providers. Some of them are free, others require a subscription: check what is available in your country.

GNSS data formats

Most receivers output their measurements as NMEA 0183 sentences: lines of text starting with $ and ending with a checksum. The most useful ones are:

The two letters following the $ identify the constellation: GP for GPS, GL for GLONASS, GA for Galileo, GB (or BD) for BeiDou, and GN for a solution combining several of them.

Many receivers also provide a proprietary binary protocol, with richer information such as the full position covariance. Tools like gpsd decode both NMEA and the most common binary protocols, so that your application does not have to.

Position uncertainty

The Fusion module weights the GNSS measurements according to their uncertainty, provided as a position covariance matrix in meters. It is important to give the values computed by the receiver for each measurement, for example from the GST sentence or from the estimated errors reported by gpsd, rather than a constant. A wrong uncertainty degrades the fusion: a constant value triggers the GNSS_DATA_COVARIANCE_MUST_VARY warning, and a value that is too small triggers the INVALID_COVARIANCE warning, both described in Troubleshooting.

Choosing a receiver and an antenna

Any GNSS receiver can be used with the ZED SDK, as long as your application can read its position, its uncertainty and its timestamp. When choosing one, consider the following criteria:

• Corrections: for centimeter-level accuracy, choose an RTK receiver that accepts RTCM 3 corrections.
• Multi-constellation and multi-band: receivers tracking several constellations on two frequency bands (for example L1/L2 or L1/L5) obtain an RTK fix faster and are more robust to multipath.
• Update rate: most receivers output 1 Hz by default. A higher rate (5 to 10 Hz) provides more frequent corrections on fast-moving platforms.
• Uncertainty output: make sure that the receiver reports its estimated accuracy, for example through the GST sentence.
• Interface: USB receivers are the easiest to set up. UART receivers require a serial port and the correct baud rate.
• PPS output: required only if you want to discipline the system clock with GNSS time. See Time Synchronization with PPS.

The antenna has a large impact on the final accuracy:

• Use an active antenna that covers all the frequency bands of your receiver. Wi-Fi, LTE and other antennas will not work, even if they use the same connector.
• Mount it at the highest point of your platform, with the widest possible view of the sky, and away from electronics and cables that may cause interference.
• Use a ground plane if the antenna manufacturer recommends it.
• Mount it on the same rigid structure as the camera, and measure its position relative to the camera. This offset is set with the gnss_antenna_position parameter. See VIO/GNSS Calibration.

Next steps

1. Set up your receiver and the RTK corrections on Linux or on Windows. If you use a ZED Box Orin with the GNSS option, follow the dedicated ZED Box Orin GNSS guide.
2. Optionally, synchronize the system clock with PPS for accurate timestamps.
3. Read the GNSS data in your application and ingest it into the Fusion module.
4. If you use ROS 2, see Geo Tracking to fuse GNSS data with the ZED ROS 2 Wrapper.