I have been working with ZED through ROS 1 an ROS 2, and ported a project of a autonomous vehicle. In particular, I am working with a node that subscribes to the ZED camera through the left/rect_image_color topic and applies a lane detection strategy. Just recently, I analyzed the time latency in the whole message flow, and I am getting the following results in both ROS 1 and ROS 2:
(node) /zed/zed_node: 15 Hz publishing rate (every 66ms)
(topic) left/rect_image_color: ~ around 100 ms topic delay
(node) /lane_detection: 3.7 Hz publishing rate (every 280 ms)
Reading the following the following reported issue, it stated that the latency was a ROS issue, since ZED was having good strategies for latency, and reporting low latency on Ubuntu.
My question then is what work around are there to be reducing this latency, both in ROS 1 and ROS 2
I confirm thta the publishing drop is due to the code applying a summfilter, reducing the final publishing rate. My question then still arrises about the topic delay.
I am running the software stack on a Nvidia AGX Orion, and versions ROS 1 Noetic and ROS 2 Foxy.
Any suggestions on how could I proceed?
can you please provide more information regarding your configuration and how you are benchmarking the performance?
Are you subscribing to the topics on the same machine or over a network? Is it a cable connection or WiFi?
Can you provide more info? Mostly on this:
is due to the code applying a summfilter
My question then still arrises about the topic delay.
- there is workflow added latency in zed_ros_driver, see
At 15 FPS this (in theory) may improve by up to (1000/15)/2 ~= 33 ms average and (1000)/15 ~= 66 ms.
ROS2 doesn’t have workflow issue of this kind.
If you are not running locally (on single PC) ROS communication for video workflows may take considerable time (depending on resloution/framerate those may be Gbps orders of data for uncompressed video processing)
If you are using image_transport with some compression, compression happens in publisher and depending how it is written it may limit the time driver has for other things to do.
In such cases you may decouple compression from driver with image_transport republish.
Or decouple local publish (same PC - fast) from remote publish (different PCs - slow)
Also if your lane_detection node is slow (non-realtime, like 280 ms) and you setup ROS queues to be anything > 1 then you are adding latency yourself (as ques will fill up with frames waiting for processing)
This “problem” is fixed in the
update_wrapper branch that will be merged soon after internal validation.
The ZED ROS Wrapper is now update with the latest improvements