Just to state I am new to this device and the software, but not to the geospatial domain. I have a capable GNSS system, Ublox with an IMU for dead reckoning. I can get fixes, but I am perpetually getting “GNSS DATA COVARIANCE MUST VARY” in a static mode. What is the criteria for this message? I am using the latest version of the SDK.
Hi @nwoodhou
normally in a GNSS system, the covariance of the satellite fix varies between consecutive data.
You are instead providing a covariance matrix with fixed values, that’s why you get this warning.
My application, whilst coding, is static and the variation in movement and variance is small. Can’t really code whilst in motion. What I am wondering is what I can do to force the calibration of the fusion model to work to get some positional results even if they are wrong? Initially I thought of adding a random position and variance into the GNSS reader, but how big do these need to be?
Finally, when looking at the GNSS output the covariance is varying which implies this message does not make much sense. In a static mode I think we all know that the position varies. Note I have varied the yaw tolerance to force some convergence of the solution.
Hello @nwoodhou,
Indeed this is a known issue. This is supposed to be a warning message but it is actually handled as an ingestion error that prevent GNSS data to be ingested. This warning is printed when you ingest 15 time the same covariance in GNSSData. This behavior is plan to be changed in the next release.
That being said, the GNSS / VIO algorithm need movements for it initialization. If you don’t, the system won’t be able to initialize and will continue to report un-calibrated state.
Regards,
Tanguy
Is there a shift that I can simulate on my static device that would change the device to think it is calibrated? For now I don’t need motion to develop the code. For example a shift by 10 meters for the first 10 seconds and then move it back to the static location?
Unfortunately no, without movement the calibration process is not able to determine the calibration between GNSS (global referenced) and VIO (locally referenced). This is why we need real movement.
However what you can do is to record your ZED data + GNSS once in SVO2 and then replay it as many times as necessary for your development. We provide sample for recording here and playback here your data.
Regards,
Tanguy
Note I control the GNSS data that is read and is set for fusion. Therefore, I can change the input into the process. How far does the device have to move for fusion to at least accept a solution? The nuance is that I don’t have the hardware to deploy the device in a vehicle and want to make a start.
With the 'fix" to the solution will we at least get a pose from the system even if it calibrating. If not will there be an override?
Hello @nwoodhou,
Typically, the system initializes within a range of 10 to 15 minutes at most. However, if your application remains static consistently, this might not be the optimal solution.
To better assist you, could you please provide more details about your application, such as:
- The nature of your application (e.g., is it a dynamic or static application?)
- The specific requirements your application has
- Any additional information that could help us understand the context of the issue you’re facing.
Regarding your question about the “fix” position. At the very beginning before the first movement the SDK output the raw GNSS position as GeoPose output. However, no fusion or projection from other modules can be performed at this step. You will need to wait for the first calibration estimation to complete before these operations can be carried out.
If your application is supposed to be dynamic, I would strongly encourage you to try the SVO recording with playback solution. This approach is designed to work seamlessly with the SDK and should provide a reliable solution for your needs.
However, if your application is static but requires the use of SDK output projected in the geo-world, I may be able to provide some insight but we will need to implement it by yourself (especially the calibration part) since it is not handled by the SDK.
Regards,
Tanguy
Just to note my application is not static. The part that is static is my coding and my questions are simply a reflection of that I need to get started with this device. As mentioned previously I am not in a position to put the device in the vehicle due to having to resolve some hardware issues, namely powering the system and how to mount the device.
Due to the static nature of the development I don’t really care that the quality is bad and will save this analysis for the in motion tests. In this regard I do have some questions brewing, but will leave those until later.
On a positive note I have been busy and have managed to get some data flowing through my code and I am satisfied with the output. Some refinement is necessary to make it ready for motion. I’m wondering if you have some test SVO files that will calibrate that are on GitHub? This may start to help ground zero developers to get started.
Thanks for your help.
Neil
Hello @nwoodhou,
Regrettably, the SVO is the sole option available for testing at this time. The upside is that the SVO was specifically designed to facilitate camera testing without the need for physical device connections. However, the downside is that we are unable to share the SVO we possess due to privacy concerns.
Unfortunately I think that your only option is to use our recording sample with one GNSS and ZED camera plugged to your computer or your embedded device (if you have one). If you do so be careful to have a rigid transform between your ZED camera and your GNSS.
I hope this still help,
Regards,
Tanguy
Just to note it would be helpful to have some SVOs without privacy issues for people to be able to develop against. For example the global localization example put the SVO files in GitHub so that the data be reprocessed. The notion here is giving the user the opportunity to get started quickly.
As I mentioned I think my problems are over and I am getting ready to deploy the system in a vehicle.
Neil
Absolutely! It is on our roadmap, unfortunately we do not have estimate date for it.
Regards,
Tanguy
Hello, I am wondering if you now have an estimate of when this behavior will be changed to make it a warning instead of an error? We are currently experiencing this error. Although it is mostly due to user error tbh because basically we have a global position estimate from apriltags detected by isaac_ros_apriltag and are trying to feed that into the zed wrapper as a gnss position so that it will fuse it with the VIO for us, however we learned that isaac_ros_apriltag just gives a zero covariance matrix for all apriltag detections for some reason so we are not sure how to work around this issue… Is there a better way to give the ZED wrapper a more generic global position estimate to fuse that is not gnss? Because another thing is that from the apriltags we get an orientation estimate as well, but gnss messages only contain a position so we can’t fuse the orientation estimate too. How can we fuse our global position & orientation estimate from apriltags with the VIO from the zed wrapper? Thank you for your time!
Hi @umnrobotics !
Welcome to the forum 
Indeed it would be beneficial to interpret it as a warning. This behavior will be implemented in next release 
Regarding your specific application you use resetPositionalTracking of ZED SDK instead of trying to convert it in GNSS and try to fuse it. I think you will obtains better results with it.
Regards,
Tanguy
1 Like
Thanks for the reply!
Sounds good, we look forward to the next release then!
And thank you for the advice, we will look into using the /reset_pos_tracking service of the zed ros2 wrapper to do this. Although, we are already using Apriltags to computer our map->odom TF, and we have a ros2 action we can call the recompute the map->odom TF which theoretically should correct for drift if any occurred since the last time we computed the TF using Apriltags. I wonder if we are already doing this then maybe there isn’t a need for us to also call the /reset_pos_tracking service if it’s essentially doing the same thing, or maybe it is still useful for us to call it?
Thank you again!
Hi,
It was released yesterday. It is supposed to be presents in 4.2.4 !
Indeed if you are already correct the drift in your ROS application you do not need to call the /reset_pos_tracking. The result is expected to be the same 
Regards,
Tanguy
1 Like
Awesome, we will try out ZED SDK 4.2.4, thanks for your help!