Ingest error occurred when ingesting GNSSdata: NO NEW DATA AVAILABLE

Moh96 · October 13, 2023, 10:51am

Hi,
I have fetched the Getracking API sample from GitHub and have followed the mentioned steps to fuse my external GNSS sensor with the ZED camera, but I received this error “Ingest error … : no new data available”.

Here is the full information about the system that I am using:
1.) ZED-2i Camera
2.) Jetson TX2, Jetpack 4.6.4 (L4T 32.7.4), Ubuntu 18.04, tegra 4.9.337
3.) ZED-SDK v4.0.7
4.) Ublox F9
5.) GPSD v3.25

The live Getracking C++ sample has been compiled properly without any issues. Additionally, I have run the GPSD with the native command without using systemd as was suggested in the documentation, i.e., “sudo gpsd -nG -P /run/gpsd.pid /dev/ttyACM0”, and it runs appropriately with my Ublox F9 (I tested it with xgps).

So, what could be the issue? what am I missing?

Also, is it possible to get any recorded samples?, i.e., SVO file + GNSS JSON file to test the playback sample?

I would appreciate your comments and guidance.

Myzhar · October 13, 2023, 1:20pm

Hi @Moh96
Welcome to the Stereolabs community.

It seems that you are trying to ingest the same GNSS data multiple times, meaning that the sl::GNSSData being ingested has the same timestamp as the previous one.

Regarding the playback sample, you can find it on Github.

Moh96 · October 13, 2023, 4:35pm

Thanks for your reply @Myzhar

I have checked the timestamps coming from the GPSD by using xgps and gpsdclient and it seems to be fine. I am receiving the GNSS data at 1 Hz, so the position is being updated every second.

Actually, I have tested two scenarios:

1.) I ran the live ZED Geotracking API with the GNSS sensor without moving the system (static position). So, I was receiving the same GNSS data (Lat, Lon, Alt) but with different timestamps (updates every second). This scenario still resulted in the same error “Ingest error occurred when ingesting GNSSData: no new data available”.

2.) I ran the live ZED Geotracking API with the GNSS sensor and I moved around (for ca. 1 minute) to make sure that different GNSSdata (positions) were ingested at different timestamps. Again, I encountered the same error.

It’s worth mentioning that I have made no modification to the Geotracking code, I just simply downloaded it from Github and then compiled it.

Regarding the Geotracking API; Should I expect an instantaneous result of fusion right after the ingestion of GNSSdata or does it take time until the output comes? (should I wait more than a minute to see something?)

Also, concerning the playback sample, in my question I meant that, are there perhaps any recorded samples (SVO + GNSS files) that I can download from somewhere? so that I can use them for postprocessing to have a feeling about what kind of result I should expect because for the moment I am not successful in getting the Geotracking API sample to work.

I appreciate your further comments.

TanguyHardelin · October 16, 2023, 9:15am

Hello @Moh96

Actually, the error message ‘Ingest error occurred when ingesting GNSSData: no new data available’ indicates that the timestamp in the current sl::GNSSData is the same as the previous sl::GNSSData. It’s important to determine if this error occurs with every call to fusion.ingestGNSSData(input_gnss) or if it only happens occasionally.

To verify this, you can print the timestamp present in the sl::GNSSData. Each call to fusion.ingestGNSSData(input_gnss) should have a different timestamp.

Regarding your question about the delay of the response, it should be relatively quick. The speed depends on the synchronization module between VIO (Visual-Inertial Odometry) and GNSS, but typically, it takes about 1 to 2 frames, depending on your camera’s frame rate.

As for your question about SVO and GNSS files, we do have some internally. However, I’m not certain if I can share them. I will check and I get back to you.

TanguyHardelin · October 17, 2023, 8:14am

Hello,

Please find the SVO/GNSS file for testing playback sample on this link. To visualize the output, you can use the generated KML file and google map. It should produce a representation similar to the following image:

To ensure clarity, I have highlighted the different parts of the VIO/GNSS fusion algorithm, specifically the Calibration and Fusion sections. If you require a quick estimation of the fusion results, you can utilize the provided parameter.

Best regards,
Tanguy

Moh96 · October 17, 2023, 2:22pm

Hello @TanguyHardelin

Regarding the timestamps of the sl::GNSSData, I have printed the timestamp of each call to fusion.ingestGNSSData(input_gnss), could you please comment on the attached image?

Also thank you very much for providing the SVO/GNSS files for testing the playback sample, it was very helpful and useful to see how the fusion is done and what kind of result should be expected.

TanguyHardelin · October 18, 2023, 8:34am

Hello @Moh96 ,

Indeed your output is strange. Here is my output with GPS set to 10Hz:

The print is done with the following code:

sl::GNSSData input_gnss;
if (gnss_reader.grab(input_gnss) == sl::ERROR_CODE::SUCCESS)
{
    // Publish GNSS data to Fusion
    std::cout << "Ingest with ts = " << input_gnss.ts.getNanoseconds() << std::endl;
    auto ingest_error = fusion.ingestGNSSData(input_gnss);
    if(ingest_error != sl::FUSION_ERROR_CODE::SUCCESS){
        std::cout << "Ingest error occurred when ingesting GNSSData: " << ingest_error << std::endl;
    }
}

For me the NO NEW DATA AVAILABLE only occur when the ingested data was previously ingested.

In order to diagnose the issue further, could you record your data using the recording sample and share the output ?

Moh96 · October 20, 2023, 3:38pm

Hello @TanguyHardelin ,

I have used input_gnss.ts to print the timestamps as I shared in the previous image. Also, I have again used the .getNanoseconds() as you shared and it output the same result for me.

I tried to record data as you suggested and this is the output of the recording sample, it threw out the same error no new data available

Interestingly, I used the Python version of the recording sample and it did not output an error, but the provided JSON file only contained one line of GNSS data although I was moving around with the setup
GNSS_test.json (285 Bytes)

Here is a screenshot of the output of the Python version of the recording sample

What do you think? how should I proceed?

system · October 20, 2023, 3:38pm

Hello @TanguyHardelin ,

I have used input_gnss.ts to print the timestamps as I shared in the previous image. Also, I have again used the .getNanoseconds() as you shared and it output the same result for me.

I tried to record data as you suggested and this is the output of the recording sample, it threw out the same error no new data available

recording_sample_output

Interestingly, I used the Python version of the recording sample and it did not output an error, but the provided JSON file only contained one line of GNSS data although I was moving around with the setup
GNSS_test.json (285 Bytes)

Here is a screenshot of the output of the Python version of the recording sample
python_recording_sample

What do you think? how can I proceed?

[Discourse post]

TanguyHardelin · October 23, 2023, 8:56am

Hello @Moh96,
It appears that everything is running smoothly with your sample. Let me explain the warning message you encountered: “NO NEW DATA AVAILABLE.” This warning occurs when you attempt to ingest data that has already been ingested, meaning that the timestamp of the data you’re ingesting is the same as the previously ingested data. From the warning message you provided, it seems that you are ingesting the same GNSS data multiple times.

For example:
Timestamp of the ingested GNSSData: 169781406000000000 → NO WARNING

There will be no warning because the data is successfully ingested in Fusion, and a “SUCCESS” status is returned.

Timestamp of the ingested GNSSData: 169781406000000000 -->WARNING: Ingest error occured when ingesting GNSSData: NO NEW DATA AVAILABLE

You will receive a warning: Ingest error occurred when ingesting GNSSData: NO NEW DATA AVAILABLE. This indicates that the data with the timestamp 169781406000000000 was previously ingested in Fusion, and it does not provide any new information. Fusion will ignore this ingest, but it will continue to use the previously ingested data with the same timestamp.

Based on the information provided, everything seems to be running well. If you move your robot with camera and GNSS you should be able to get GeoPose once the initializing between VIO and GNSS will be completed. You can obtain the current uncertainty regarding the initialization using the following code snippet:

// GNSS coordinate system to ZED coordinate system is not initialize yet
// The initialisation between the coordinates system is basicaly an optimization problem that
// Try to fit the ZED computed path with the GNSS computed path. In order to do it just move
// your system by the distance you specified in positional_tracking_fusion_parameters.gnss_initialisation_distance
float yaw_std;
sl::float3 position_std;
fusion.getCurrentGNSSCalibrationSTD(yaw_std, position_std);
if(yaw_std != -1.f)
    std::cout << "Calibration uncertainty yaw_std " << yaw_std << " position_std " << position_std[0] << ", " << position_std[1] << ", " << position_std[2] << "\r";

Typically you should see the yaw_std decrease until you reach the target_yaw_uncertainty defined in GNSSCalibrationParameters (present in PositionalTrackingFusionParameters).

Regarding the recording sample, its purpose is to allow you to record SVO and GNSS data together for replaying it later with the playback sample. This provides a convenient way to debug and test your application without having to run a live session every time.

I hope I have addressed all of your questions! If you have any further inquiries, feel free to ask.

Best regards,
Tanguy

Moh96 · October 30, 2023, 12:56pm

Hello @TanguyHardelin ,

Thank you very much for your elaboration on this issue. I have solved this error by forcing the ingested GNSS data to have the same current timestamp of the camera data using this command input_gnss.ts = zed.getTimestamp(sl::TIME_REFERENCE::IMAGE);

Now everything works properly.

Thank you very much and best regards.