Low imu frequency (190Hz, unstable) of ZED X1 GS with Jetson NX16Gb on ZED mini carrierboard.

Hardware ZED X
,
1

Good afternoon,

I have 2 (sn300473976 and sn309573082) x1 gs cameras (stereo configuration) both have the same problem on all 3 topics:

  • Accelerometer
  • Gyroscope
  • Orientation

The data comes at a lower frequency than reported in the webshop and is not stable at that lower value. Its important to mention that I have first encountered this issue in my ros2 setup and discovered that it is also present in ZED_Sensor_viewer, so I don’t know how to proceed on my own. Any ideas how to debug this issue?

I have the recorded .csv file at hand, however I cannot upload as new accounts cannot upload documents on this forum :(.

Have a nice day. Kuba

2

Hi @kubaplonka
Welcome to the Stereolabs community.

What is the expected value?

3

Thank you for your reply. 400Hz/200Hz as reported in the datasheet of this product: https://www.stereolabs.com/en-nl/store/products/zed-x-one-gs . For my purposes all I need is a stable value of at least 200Hz, however 400Hz would be much appreciated!

4

The correct ODR value for the Gyroscope and the Accelerometer of the ZED X One cameras is 200 Hz. The product page has been fixed.

What NVIDIA Jetson model are you using with your cameras?

5

Well that is quite unexpected! I am using NVIDIA Jetson orin nx 16gb with your ZED mini carrierboard. Those 190Hz (Instead of promised 200Hz) are too unstable (175-195, most commonly ~191 Hz), happening on both of my cameras. If I could provide you with more useful information about my setup or run any tests on my side, let me know!

6

What ZED SDK version and ZED X Driver version are you using?
I can get stable 195/200 Hz with the latest ZED SDK v5.0.7 and driver v1.3.1

8

Did you figure out the issue? I also use two ZED x one gs and have the same issue on my orin nx 16 GB. I have a unstable IMU frequency all the way between 148 hz to 203 hz. I use the newest SDK version 5.1.0

9

Hi Jacob,
IMU reading will be improved with one of the next releases of the ZED SDK.

10

Okay, sounds good, thank you. Is there a way i can lower the frequency with the current version and then get it more stable maybe? And do you have a approximate planned timeline of the release of the SDK version that will fix it?

11

In a multithreading application you can simply change the frequency of the thread to call the getSensorData API function at your desired rate.

A curiosity, can you share the code that you are using to retrieve the IMU information to check that it’s correct?

12

Yes, here is a minimum example which reproduces my results. This runs in its own thread.

void imuThread(
    sl::Camera* zed,
    std::function<void(okvis::Time, const Eigen::Vector3d&, const Eigen::Vector3d&)> imuCallback) {

  sl::SensorsData sensor_data;
  uint64_t last_ts = 0;  // store nanoseconds of last IMU sample

  while (!shtdown) {
    if (zed->getSensorsData(sensor_data, sl::TIME_REFERENCE::CURRENT) == sl::ERROR_CODE::SUCCESS) {

      uint64_t ts_ns = sensor_data.imu.timestamp.getNanoseconds();

      if (ts_ns > 0 && ts_ns != last_ts) { 

        double dt_s = (ts_ns - last_ts) * 1e-9;  // convert ns to seconds
        double freq = 1.0 / dt_s;
          LOG(INFO) << "IMU frequency: " << freq << " Hz";

        last_ts = ts_ns;  // update last timestamp
      }
    }
  }
}

And here is the result i get
204.123 198.373 198.452 198.452 147.929 147.973 147.929 200.723 200.763 200.763 150.602 150.602 150.648 197.161 197.161 197.161 200.803 200.763 200.844 148.192 148.192 148.214 200.642 200.682

13

I recommend you add a minimal sleep at the end of the loop to give time to the other threads to perform, otherwise one thread can take all the CPU time.

The expected frequency is 200 Hz, so you should wait for 5 milliseconds (or a little less).

In the ZED ROS2 Wrapper we use a “trick” to guarantee a stable data frequency:

14

I tried adding a small sleep, but the issue became worse. The example i sent you i disabled everything else so there wasnt really any other threads running. I also tried doing it with depth mode set to none and without retrieving images to isolate the issue, but the result is the same

15

@Jacob Python is not good for this type of multi-thread processing.
An adaptive sleeping time, like we did in ROS 2, could help, but I’m not sure you can get very precise frequencies in any case.

16

The example i sent you is C++. Do you know if the instability comes from your SDK or from the IMU own sampling rate? My concern with the adaptive sleep timing is that i would get more steady publishing rate, but i guess the actual period between when the measurements is taking will still vary as before

17

You are right. I confused the code with something from another post. My apologies.

It’s a mix of causes. Also, the CPU load because of OS jobs is a factor.

The purpose of the adaptive sleep time is to guarantee a stable rate. The sleep time automatically adapts to the host status.

18

So in your example, where and how do you use _sensRateComp?

19

In this function: