Hi there
We are using one zed2i on a Jetson Orin, with the zed SDK 4.1.1. jetson_clocks
is running.
The zed2i is one of several sensors we have in our system, running on ROS. When we profiled the performance of the zed-ros-wrapper, we found it was dropping too many frames for our use case, and so we opted to instead write our own c++ script that calls the SDK directly and writes to svo2 files, which we post-process offboard.
This has some strange behaviour that we were hoping you may be able to help with or explain: when running a standalone c++ script, frames are dropped once per second consistently, seemingly agnostic to framerate.
Here’s my testing setup, let me know if I can provide you with anything else
Note: for all the tests below I overwrote the bag timestamps that rqt_bag uses with the image header timestamps, so that the rqt_bag visualization accurately reflects the capture times of the images.
Basline
I ran the zed-ros-wrapper configured as lightly as possible (no OD, mapping etc), at 15fps.
You can see that frames are dropped at varying intervals. This was the performance we wanted to improve upon.
Direct Comparison
Instead of running the zed-ros-wrapper, I ran our own custom ros node which is as lightweight as possible and only writes to an svo file, following the examples in your codebase. I ran the rest of our ROS system as well, for direct comparison to the zed-ros-wrapper performance in our system.
I post-processed via running the .svo2 files through a modified zed-ros-wrapper that publishes topics using the timestamps of the original svo image, and verified this works as expected. I then ran the same analysis as the baseline on the output rosbags.
You can see that frames are again dropped, but this time consistently around the second mark.
Standalone Tests
I also took the logic from our custom ROS node and put it in a standalone c++ script (included below), and then ran that without any other processes running on the Jetson and observed similar behaviour, with slightly different rates of frame drops.
And I ran the same test at 30fps, and saw something similar again. This seems to indicate we weren’t at the edge of the performance abilities at 15fps, seeing as most of the time it is able to consistently capture 30fps:
Conclusion
The odd pattern of the frame drops, and the fact that running at 30fps doesn’t change the pattern much, seems to me like the issue isn’t one of performance, and that there might be something blocking processing ~once per second. But I don’t know how to debug further.
At a high level, we are trying to ensure that frames don’t drop, and would gladly take any advice you have - we aren’t tied to using our custom ros node solution.
Thank you very much
Kappi