Hello,
I am doing positional tracking GEN_3 on a svo2 file (ZED-X mini @30hz, Orin Nano) from a desktop using pyzed, and noticed that the poses often take several frames to update (see attached screenshots). This obviously leads to unpredictably long windows with unreliable tracking data. This doesn’t occur with enable_imu_fusion = False.
Is this expected behavior or could there be something wrong with the IMU or SVO recording?
Hi @ZoharO
What version of the ZED SDK are you using?
Hi @ZoharO,
Thanks for the report. Is it possible to get the SVO in order to diagnose the issue on our side ?
Regards,
Tanguy
Hi, I’m using version 5.0.5.
Hi @TanguyHardelin, I sent a snippet of the SVO to support@stereolabs.com.
Hello @ZoharO,
I checked your SVO. It seems to contains a lot of IMU drops. How did you record it ? Is your ZED X driver is up to date ? For recording SVO2 I suggest to use the sample we provide (available at this link).
Your issue is related to this IMU drop. Disabling the IMU fusion give better result. You can disable IMU fusion by setting enable_imu_fusion to false.
Regards,
Tanguy
Hello @TanguyHardelin,
Thank you for looking into this.
It was recorded using the ZED Explorer tool with Lossy (jpeg) compression (Orin nano…). I remember having to manually repair the file and believe it was recorded with SDK 5.0.0EA and zed link mono v1.3.0.
Although I stopped getting corrupt files I am still able to replicate the stagnation behavior with the latest SDK 5.0.5 and driver v.1.3.1 when using the ZED_Explorer (JPEG & PNG based compression).
Using the recording sample code (LOSSLESS) instead of the ZED_Explorer (JPEG LOSSY) seems to have an interesting effect - the pose continuously updates between consecutive frames but the frame rate of the drops to from 16 Hz (frame-rate comparable to ZED_Explorer+LOSSLESS png).
Results summary (SDK 5.0.5, driver 1.3.1, HD1200@30):
- Lossy (ZED_Explorer) → 30 Hz, stagnant poses (~20% of all frames).
- LOSSLESS (ZED_Explorer) → 16 Hz, stagnant poses (~70% of all frames!!)
- LOSSLESS (python example) → 16 Hz, no stagnation.
Much appreciated,
Hello @ZoharO ,
Thanks for your report. This issue is linked to how ZED_Explorer is writing SVOs, I reported the issue. It will be addressed and fixed in a future release.
In the meantime, we recommend using our recording sample with LOSSY compression as a workaround.
Best regards,
Tanguy
Hi, thanks again. How should one implement this? Couldn’t find any mention of LOSSY in the API reference and simply sl.SVO_COMPRESSION_MODE.LOSSY fails.
Hi @ZoharO,
sl.SVO_COMPRESSION_MODE.H265 is the enum that is recommended for best performance, it uses H265 video compression which is lossy.
Edit: I apologize I didn’t catch that you were on Orin Nano. The only compression mode in the API is indeed LOSSLESS
Thank you all for your prompt responses.
Could you lastly clarify what is required for stable SVO2 recordings at 30Hz with the Orin Nano (stereo+imu)? Is this resolvable through a software patch (as the aforementioned) or do I have to upgrade to a Orin NX?
In the meantime, it seems that utilizing the JPEG LOSSY compressions on the ZED_Explorer is my best option. Any tips on how to improve caption stability and identify frame drops in real-time/post will begreatly appreciated.
Kind regards,
Zohar
Hi @ZoharO,
JPEG lossy recording on Orin Nano can be added in a minor version of the ZED SDK, I am logging this internally to add to the next minor release.
In the meantime, you can run recording in lossy JPEG with ZED_Explorer on the command line with
ZED_Explorer -o output.svo2 --cpm 2
You can retrieve the number of dropped frames with this method zed.getFrameDroppedCount()