Why does the Zed2 camera not include IMU data in SVO files?

I would like to record the IMU data, but the SVO file doesn’t, so I must record a ROSbag simultaneously. I’m wondering why the SVO file doesn’t include IMU data.

Hi @kkoe2
the image data has a maximum framerate of 100Hz, while the IMU data run at 400Hz for the ZED2 and the ZED2i, and 800Hz for the ZED Mini.
It is not possible to store the IMU data at those frequencies in the SVO. Instead storing them at the same frequency of the image frames could generate a phenomenon knows as aliasing.
For these reasons the SVO only contains the orientation that is calculated from the IMU data fusing the Visual Odometry information, so it’s generated at the same frequency as the frame data.

1 Like

Hi @Myzhar ,
Thanks for the response. For the project I am doing, I still need the IMU data, so I try and record the IMU data simultaneously in a rosbag while recording the SVO file. However, I lose some imu data when recording a rosbag file and svo file simultaneously. Do you have any idea why?

It all depends on the write speed of the storage memory. What is your system configuration?
Furthermore the rosbag introduces the ROS communication variable, it may happen that not all the data are received if not using reliable communication.
I suggest you modify the source code of the wrapper to save the IMU data in a CSV file indeed.
You could also write a node that subscribes to the IMU data with a big value for the size of the message queue (e.g. 4000 means a buffer of 10" of data), in this way you are sure that all the data are received and put in the queue of the subscriber that can save them without real-time requirements.

We’ve tested on a Jetson NX and a Jetson AGX Orin. We think we’ve isolated the issue. When we record images and imu data in a rosbag, while simultaneously recording an svo file, then there are gaps in the data. However, when the record a rosbag without the images, but record imu data, while simultaneously recording an svo file, then there isn’t an issue. So I guess the real problem isn’t about the IMU, but something with the images. Do you have any ideas about the origin of this issue?

The rosbag recording is not optimized.
If you save image data without compression you need a very fast write speed, if you add compression then you need a very powerful CPU for the image processing.
The SVO saving is instead optimized because it takes advantage of the GPU encoders to save image data.

1 Like

That makes sense. We originally thought that was the issue too! That’s why we upgraded from the NX to the Orin, but I’m wondering why the Jetson AGX Orin wouldn’t solve this problem. It’s a very powerful computer (Jetson AGX Orin for Next-Gen Robotics | NVIDIA). We’re wondering if there is some conflict when generating the SVO file and recording Rosbag images that causes a loss of data. However, we’re unsure because we don’t know the inner workings of SVO recording.

Like I told you the rosbag saving is not well optimized. In my experience I felt data losing and system slowing down also with powerful i7 when enabling data compression.
AGX Orin is very powerful, but it’s still an embedded device and the overall computational power is still lower than a standard PC.

@Myzhar, what you’re explaining makes sense. However, when I only record rosbags without the SVO file, then there isn’t an issue with lost data. We’ve even recorded with 3 cameras simultaneously and had no issues with data loss. The issue I’m describing only arises when the SVO file and rosbag (recording images) is done simultaneously. This leads me to the conclusion that it isn’t just a computation issue because there is no computation issue when the SVO file and rosbag are recorded independently.

Ah OK, I understood the contrary.
In that case I guess it can be a problem of resource sharing between different processes.
But this is only an hypothesis.
What I understood is that you have problems while using rosbag to record both images and IMU data.

If the problem is resource sharing, do you know of any solution to the issue?

Good question, here we enter the “OS scheduling” field… maybe you can try to increase the priorities of the two concurrent processes. This helped a lot in similar situations