Using GNSS Data in Your Application
Once your GNSS receiver is set up, your application must read its measurements, convert them to sl::GNSSData, and ingest them into the Fusion module with ingestGNSSData, as shown in the Global Localization overview.
This page shows how to read GNSS data from gpsd on Linux. On Windows, see Setting up GNSS / RTK on Windows.
Reading data from gpsd
Python
To access GNSS data in Python, you can use the gpsdclient library. It provides a Python interface to the gpsd daemon, giving access to latitude, longitude, altitude, speed, estimated errors, satellites in view, and more.
You can install gpsdclient with:
Here is an example of a simple script using gpsdclient:
The position is contained in the TPV (Time Position Velocity) reports. The SKY reports describe the satellites in view.
C++
To access GNSS data in C++, you can use the libgpsmm library.
You can install libgpsmm with:
Here is an example of a simple program using libgpsmm:
The libgps-dev package of your distribution may be older than the gpsd daemon you compiled from source. If you get connection or protocol errors, build your application against the headers and library installed with gpsd in /usr/local.
Converting to sl::GNSSData
The sl::GNSSData structure ingested by the Fusion module contains:
The covariance must reflect the actual uncertainty of each measurement. Set it from the errors estimated by the receiver: a constant value triggers the GNSS_DATA_COVARIANCE_MUST_VARY warning described in Troubleshooting.
When the status field is missing, and for the other gpsd statuses such as dead reckoning, the examples use SINGLE, as recommended for the GNSS_DATA_NEED_FIX warning. The estimated errors may also be unavailable for some reports, for example right after the first fix: gpsd then omits them from the JSON reports, and sets them to NaN in the C++ structure (check them with std::isnan). Skip these reports instead of ingesting a made-up covariance.
Timestamps
The Fusion module matches GNSS data with camera images by timestamp, and camera images are timestamped with the system clock of the host. There are two ways to timestamp the GNSS data:
- GNSS time, as in the examples above. This is the most accurate option, as it gives the instant of the measurement, but it requires the system clock to be synchronized with UTC, for example with NTP, or better, with PPS.
- Reception time, with
sl::getCurrentTimeStamp()when the data is read. It works with any system clock, but includes the latency of the receiver and of the serial link, typically a few tens of milliseconds.
If the system clock is not synchronized and the GNSS time is used, the Fusion module rejects the data with an INVALID_TIMESTAMP error. See Data Synchronization for details.
Complete samples
The Global Localization samples on GitHub read GNSS data from gpsd, convert it to sl::GNSSData and ingest it into the Fusion module. They also show how to record GNSS data with an SVO file and replay it. See the samples page for a description of each sample.
Using GNSS with ROS 2
The ZED ROS 2 Wrapper reads the GNSS data from a sensor_msgs/msg/NavSatFix topic and performs the fusion for you. See Geo Tracking for the compatible drivers and the configuration of the wrapper.

