> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.stereolabs.com/docs/development/zed-sdk/modules/global-localization/gnss/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.stereolabs.com/_mcp/server. # GNSS Overview The [Global Localization](/docs/development/zed-sdk/modules/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: | Constellation | Operator | | ------------- | -------------- | | **GPS** | United States | | **Galileo** | European Union | | **GLONASS** | Russia | | **BeiDou** | China | 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](/docs/development/zed-sdk/modules/global-localization/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**: | Fix type | Description | Typical horizontal accuracy | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | **No fix** | Not enough satellites to compute a position | None | | **2D fix** | Latitude and longitude only, with an assumed altitude | Several meters | | **3D fix** (single point) | Standalone position, without corrections | 1 to 5 m | | **DGNSS / SBAS** | Corrected with differential data from a reference network or from satellite-based augmentation (WAAS, EGNOS, MSAS, GAGAN) | 0.5 to 2 m | | **RTK float** | RTK corrections are received, but the carrier phase ambiguities are not resolved yet | 0.2 to 1 m | | **RTK fixed** | RTK corrections are received and the carrier phase ambiguities are resolved | 1 to 3 cm | 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](/docs/development/zed-sdk/modules/global-localization/gnss/using-gnss-data). ### 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: | Sentence | Content | | -------- | -------------------------------------------------------------- | | `GGA` | Time, position, fix quality, number of satellites, altitude | | `RMC` | Time, date, position, speed and course | | `GSA` | Fix mode (2D/3D), satellites used, dilution of precision (DOP) | | `GSV` | Satellites in view and their signal strength | | `GST` | Standard deviation of latitude, longitude and altitude | | `VTG` | Speed and course over ground | 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](/docs/development/zed-sdk/modules/global-localization/gnss/setting-up-gnss-rtk) 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](/docs/development/zed-sdk/modules/global-localization/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](/docs/development/zed-sdk/modules/global-localization/gnss/pps-time-synchronization). 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](/docs/development/zed-sdk/modules/global-localization/vio-gnss-calibration). > **Tip** > > The first fix after power-on (*cold start*) can take from a few seconds to a few minutes. The receiver needs an open sky during this time, so wait outdoors before starting your application. ## Next steps 1. Set up your receiver and the RTK corrections on [Linux](/docs/development/zed-sdk/modules/global-localization/gnss/setting-up-gnss-rtk) or on [Windows](/docs/development/zed-sdk/modules/global-localization/gnss/setting-up-gnss-windows). If you use a **ZED Box Orin** with the GNSS option, follow the dedicated [ZED Box Orin GNSS guide](/docs/products/embedded/zed-box-orin/using-gnss). 2. Optionally, [synchronize the system clock with PPS](/docs/development/zed-sdk/modules/global-localization/gnss/pps-time-synchronization) for accurate timestamps. 3. [Read the GNSS data in your application](/docs/development/zed-sdk/modules/global-localization/gnss/using-gnss-data) and ingest it into the Fusion module. 4. If you use ROS 2, see [Geo Tracking](/docs/integrations/ros-2/geo-tracking) to fuse GNSS data with the ZED ROS 2 Wrapper. > What GNSS is, how RTK improves it, and what you need to use it with the ZED SDK ## Docs - [Setting up GNSS / RTK on Linux](https://docs.stereolabs.com/docs/development/zed-sdk/modules/global-localization/gnss/setting-up-gnss-rtk.md) - [Setting up GNSS / RTK on Windows](https://docs.stereolabs.com/docs/development/zed-sdk/modules/global-localization/gnss/setting-up-gnss-windows.md) - [Time Synchronization with PPS](https://docs.stereolabs.com/docs/development/zed-sdk/modules/global-localization/gnss/pps-time-synchronization.md): Discipline the system clock with GNSS time to get accurate timestamps - [Using GNSS Data in Your Application](https://docs.stereolabs.com/docs/development/zed-sdk/modules/global-localization/gnss/using-gnss-data.md): Read GNSS data from gpsd and ingest it into the ZED SDK Fusion module