I have a ZED 2i camera connected to my jetson orin nano 8GB board.
I also have a GNSS receiver on that board, and NTRIP software to get RTK fix.
I have setup a second tty USB port to the receiver where i can enable multiple NMEA messages.
I then subscribe to them with gpsd to get the data into the global navigation example. however, I don’t get any time stamps.
I have enabled GPGSV, GLGSV, GAGSV, GBGSV, GNGLL, GNTXT, GNVTG, GNGGA. All with 20 Hz.
I have also tried to make my own reader, where i get the position data directly. but without a covariances, so i get something from my kalman filter i then have to scale. But no matter how low or high i scale the variance i get very unprecise position. look at attached figure.
The orange data is meter grid from GNSS, and the blue it lat long scaled to match somewhat with the orange. I’m not worried about the scale or translation. But i’m worried about the line quality. cause, as you can see on the orange, the lines is very straight, but the blue are not.
I don’t know if it would help to use the gpsd reader, but doing it manually doesn’t work.
It seems that you have problem in your GNSS that can explain the fusion position orientation problem. Moreover where to you placed the ZED camera compared to the GNSS antenna ? Whitout GNSS signal the fused position rely only on the VIO that is returned relative to ZED left camera sensor.
Hello @tmrpj,
Thanks for you response !
The difference that you saw may comes from the transformation between GNSS antenna and ZED. Have you provided the gnss_antenna_position in the API? This parameter plays a crucial role in the calibration process, as detailed in the API reference for C++. Once GNSS and VIO are calibrated, the fused position should align closely with the quality of your GNSS data.
For an accurate calibration, ensure that you provide precise timestamps for your GNSSData alongside the appropriate covariance values. Throughout the calibration process, you should observe the decrease in yaw_std, which can be obtained using getCurrentGNSSCalibrationSTD.
Okay so i have put in some calibration for the gnss_antenna_position, and is also checking the getCurrentGNSSCalibrationSTD.
But the STD’s are all just -nan.
I’m still using the gpsd, however it cannot get a timestamp so i set a timestamp manually. But can also see with cgps that the Err fields are all n/a except for 2D Err. Is gpsd not working then?
I have made my own code to read the gga data from the reciever and input into zed sdk. the covariance of the gnss data is as low as it can be before the sdk starts to complain about the variance being too small. i then drove a 4x4 square for some time and then drove a longer route while checking the std value of sdk.
Here are the resulting plots. the lat longs has been shifted by a static value.
The std are static at std x,y,z: [0.018258972, 0.00247082, 0.002852182]
Hello @tmrpj,
Indeed your results seem bad. Is it possible to record an SVO2 for testing on our side ? Furthermore is it possible to also have the yaw std given by the sdk ?
It seems to work since i get some data files, but today is very rainy so i keep getting the error: Fix lost: reinit GNSS terminate called without an active exception Aborted
And then the program closes.
Anyway, here are what i managed to create, but since i’m on a jetson orin board, i had to record in SVO_COMPRESSION_MODE::LOSSLESS
Hi @tmrpj,
Sorry for the delayed response; the beginning of the week has been very busy. A few remarks regarding your SVO2. When I look at the saved image, a large portion of the optics is water-saturated. This could largely explain the odometry issues you were facing. Furthermore, no GNSS data is present in the SVO2 you sent. Did you use the recording sample?
Finally, we released today a new version 4.2.4 that contains a lot of fixes that can be useful to you. Do not hesitate to test it
Hello @TanguyHardelin
Also, sorry for my late response
I have been playing around with to better understand what goes on. not much wiser, however i have noticed alot of NO_NEW_DATA_AVAILABLE and GNSS_DATA_COVARIANCE_MUST_VARY.
I’m pretty sure i get data, otherwise i will not be able to plot them, but i might not ingest them correctly, do i need to do more than:
auto ingest_error = fusion.ingestGNSSData(input_gnss);
or might it be because of the sanity checks for covariance, and can that be disabled? i do vary it with our internal kalman filter believe, but it doesn’t vary a lot. I can however guarantee that the positions I send to the node is of good quality.
I have made a new recording with the saveKMLData aswell. I cannot use your sample, since i do not have a screen, or any GUI enabled on that machine, however, my program looks alot like the sample, except for the viewer parts.
The data is bigger this time, so i have to send via google drive instead. you can simply request access through this link: ZedCameraData