GNSS Fusion Covariance, Missing gnss_ref_pose TF, and CMake Policy Warnings When Building ROS 2 Humble

[whypushhh]

Hello,

I’m running the ZED ROS2 Wrapper (master branch) inside a Docker environment on a Jetson platform (L4T R35.4.1) with ZED SDK 4.2.2 and ROS 2 Humble, using a ZED X camera. When I enable GNSS by launching the wrapper as follows:

ros2 launch zed_wrapper zed_camera.launch.py camera_model:=zedx enable_gnss:=true gnss_antenna_offset:=[0.0,0.25,-0.6]

I have a GNSS source publishing on the /smc_2000/fix topic,

and the covariance values there are properly populated. However, the pose/origin_fix topic produced by the ZED Wrapper always shows a covariance array filled with -1 when GNSS is enabled.

Additionally, when launching zed_display, the aerial map in RViz2 indicates that the gnss_ref_pose TF is missing

Because the Humble Docker image provided by dustynv is based on Ubuntu 20.04, I couldn’t install ROS Humble packages via apt and had to build from source. If you have any advice on that, please let me know. Also, despite using CMake version 3.22.1, I kept getting CMP0146 and CMP0148 warnings during the build. I ended up completing the build by adding --cmake-args -Wno-dev. I’m wondering if this could cause any issues.

Also, I ran the docker container with the -v /etc/localtime:/etc/localtime:ro and -v /etc/timezone:/etc/timezone:ro options on the host PC. Even though the header timestamps appear to be very similar when compared, I still occasionally encounter timestamp-related errors.

Thank you for your assistance!

[Myzhar]

Hi @whypushhh
Welcome to the StereoLabs community.

Unfortunately, covariance is not yet available for GNSS fixed position.

[whypushhh]

Hi, @Myzhar thank you for your previous response, but unfortunately, I couldn’t fully understand it because I encountered an error related to covariance.

Let me explain my current setup and situation:

1. Environment:

• I am not using Docker.
• Host configuration:
  • ROS 2 Foxy
  • zed-ros2-wrapper -b humble-4.1.4
  • ZED SDK 4.1.4

2. GPS Topic: When I check the /fix topic using ros2 topic echo, the covariance data appears to be normal, as shown below:
   

   

3. GNSS Fusion: I perform GNSS fusion by running the following command:
   ros2 launch zed_wrapper zed_camera.launch.py camera_model:=zedx enable_gnss:=true

• I modified config/common.yaml to set gnss_enable: true, but this did not take effect, so I forcibly set it via the terminal.

4. Results:

• The /zed/zed_node/pose/origin_fix topic shows the following:
  

  

• The /zed/zed_node/pose/fused_fix topic shows the following:
  

  

Although the latitude, longitude, and altitude appear to be correct, the covariance in /origin_fix is filled with -1.
5. Code Review: I reviewed the zed_camera_component.cpp code at line 8170:

• It seems that if the covariance type is COVARIANCE_TYPE_UNKNOWN, it is filled with -1. However, in my case, the type is 2, which is not unknown.

6. Logs and Timestamp Issue: I am also seeing logs indicating “covariance is small, and the timestamp is mismatched.” These logs repeat very quickly:
   
   
   
   
   

---

Questions:

1. Why is the covariance in /origin_fix filled with -1 when the covariance type is 2 (not COVARIANCE_TYPE_UNKNOWN)?
2. Could there be a configuration or process I missed in enabling proper GNSS fusion?
3. Regarding the timestamp issue:

• What might cause the timestamp mismatch?
• Is there a recommended approach to synchronize timestamps for ZED and GNSS fusion?

I would greatly appreciate your advice and suggestions to resolve these issues. Thank you!

[Myzhar]

Hi @whypushhh
are you providing GNSS information with fixed values for the covariance?
What GNSS driver are you using to generate the GPS FIX messages?

[whypushhh]

Hi @Myzhar
I’m using a Ublox GPS module along with a ROS package to publish GPS Fix messages on a custom topic. In my setup, the GPS covariance is not fixed—it updates continuously. However, I noticed that the covariance values shown in the ZED Wrapper’s origin_fix differ from what I’m actually publishing. Because of this discrepancy, it seems that the GPS fusion calibration never completes and keeps restarting.

I’ve attached my Ublox GPS configuration file and launch file below for reference. Could you please advise on why the covariance in the origin_fix might not match the one I’m sending and how to ensure the GPS fusion calibration finishes properly?

Thank you in advance for your help!

[Myzhar]

@whypushhh

Could you please advise on why the covariance in the origin_fix might not match the one I’m sending and how to ensure the GPS fusion calibration finishes properly?

What are the expected values?
What values do you get?

[whypushhh]

@Myzhar
As I mentioned earlier, the GPS fix values I am publishing have a covariance of 12.9, 12.9, and 27.6, with a covariance type of 2.

However, the covariance values of pose/origin_fix are filled with -1, and the covariance type is set to 0.

I believe the covariance values should be similar to or the same as the ones I am publishing.

[radisc]

I’m having the same exact problem, i’m using the nmea_navsat_driver package.