2

I have a ROS node that gets image frames from a camera sensor and publishes image messages to a topic of type sensor_msgs::image. I run a ros2 executable which deploys the node. I notice that the rate at which the camera sensor provides the frames is 30 fps but the frame rate returned by "ros2 topic hz" is comparatively quite low, that is, around 10 Hz. I verified this using the output of "ros2 topic echo" wherein only around 10 messages were published with the same "sec" (second) value.

So, it seems that a large overhead is involved in the topic publishing mechanism. Most likely, entire image frames are being copied which is causing low fps. I would like to confirm whether this is indeed the case, that is, does ros2 copies the entire message while publishing to a topic? And if yes, what are the workarounds to that? It seems that using intra process communication (using components) might be a workaround. But note that I am only deploying one node and publishing messages to a topic from it, that is to say, there is no second node which is consuming those messages yet.

Regards

Shashank Kumar
  • 65
  • 8
  • of course it has to "copy" somehow, the data has to leave the host over the network. if it's all local stuff, the network stack *might* be able to do some zero-copy magic... unless this stuff gets framed. then there's no way around copying. even in *Inter-Process Communication* that doesn't use the network stack, copying might happen, but there's a lot better chance that it's just shared memory and pointers. -- I can't speak for ROS/ROS2. they might do something silly... -- what you **should** be asking is whether there's any color space conversion or other heavy lifting involved. – Christoph Rackwitz Mar 10 '22 at 14:33
  • @ChristophRackwitz It's all on the same host. Nah, the color space conversion and other such heavy duty stuff takes place in the node itself. Since everything is on the same host, I thought there might be a possibility that they may be doing a zero-copy message transfer somehow while publishing the image frames. But it seems that's not the case. – Shashank Kumar Mar 10 '22 at 15:34

2 Answers2

2

I can think of a couple reasons why the reported frequency from ros2 topic hz is reporting a lower frequency than expected.

There are known performance issues with Python publishers and large data (like images). Improvements have been made, but still exist in older version of ROS 2 (Galactic or earlier) (related Github issue). I don't know if these issues affect Python subscriptions, but I imagine there is some overhead in converting from C to Python (which ros2 topic hz is doing). You could try subscribing with a C++ node and see if that makes any difference.

The underlaying robot middleware (RMW) may also be a source of increased latency. There have been various issues documented in trying to send large data. You can check out this documentation on tuning the middleware for your use-case: https://docs.ros.org/en/rolling/How-To-Guides/DDS-tuning.html

To take advantage of intraprocess communication, I recommend writing your publisher and subscriber nodes in C++ as components, which have the flexibility of being run in their own process or loaded into a common process (letting them use pointers to pass around data). You can also configure the RMW to use shared memory (agnostic to how you're using ROS), but I won't get into that here since it depends on what RMW you are using.

Jacob Perron
  • 36
  • 1
2

You can try using usbcam pkg to get the camera feed. This pkg is in cpp and sensor QoS. So you should get the best speed.

installation:

sudo apt get install ros-<ros2-distro>-usb-cam

ros2 run usb_cam usb_cam_node_exe

ros2 run image_transport republish compressed raw --ros-args --remap in/compressed:=image_raw/compressed --remap out:=image_raw/uncompressed

you can echo the topic: image_raw/uncompressed

link attached.

https://index.ros.org/r/usb_cam/

Gautham M Sam
  • 39
  • 5