Multiple publishers in single node
Hi ,
I have a multiple publishers (~20) running on a single thread and each has their own topic to publish, in other words no two publishers publish to a same topic. My node/thread has only publishers (zero subscribers) and my thread has a requirement of loop rate 500 Hz (2 ms).
The loop rates is achieved when only few topic were subscribed but when i run ros2 bag record -a the loop rate is not achieved. After lttng user space tracing we figured once in a while publisher->publish(msg) is consuming more time than expected.
I am wondering if publisher->publish(msg) hold a mutex in a very low level ? Does it hold mutex on io / network card etc . Any suggestion to speed up the loop rate ?
Asked by BhanuKiran.Chaluvadi on 2021-11-03 05:08:28 UTC
Comments
You tagged this question as
multi-thread, but your description is of a single thread implementation.How big are your output queues? How big are these messages that are being published? Expecting to sustain 0.1 milliseconds per message seems very optimistic to me, even on server-class hardware.
If this were a
ros1question, I'd wonder if you were passing a::Ptrto publish(), and how many spinners you had allocated for roscpp.Asked by Mike Scheutzow on 2021-11-03 08:46:51 UTC
@ Mike Scheutzow Does publishes also have queues like subscribers ? I have seen this articles explaining problems with subscription and how multithreaded_executor/thread helps in that regard. But none when it comes to publishers.
Asked by BhanuKiran.Chaluvadi on 2021-11-03 09:04:58 UTC
@Mike Scheutzow We have only single spinner. I know that it will effect subscriber call backs but not sure about the publishers. Also when ever i define a publisher the queue size is always 1 as if now.
Asked by BhanuKiran.Chaluvadi on 2021-11-03 09:09:21 UTC
Which version of ros2 are you using? If you are using foxy, are you using the improved implementation of rosbag2?
You could also look at this post for suggestions on improving publisher speed
Asked by shonigmann on 2021-11-03 11:43:53 UTC