Unfortunately, these are our custom nodes and not open-source. But there is no magic there. Of course, we don’t run over a bandwidth-constrained link like you do so we are not seeing the problems you are.
1 Like
Yes, the latter should be the case. That is, the packets should be dropped but shouldn’t affect the publisher, at least I don’t think.
Just for clarification for other readers not following the ticket closely, I want to point out here that this
is not exactly the case, although I understand the perception. In this particular case, the issue arises from the call to write to the UDP socket when sending data to remote subscriptions. In this scenario, that call is blocking, thus blocking the sending thread. In Fast DDS, the socket could be configured as non-blocking instead, and then you won’t experience this issue (although you’d probably start to receive less messages over the WiFi link). For anyone interested in finding out more, take a look at the corresponding Github issue, where more options are being discussed.
My point here is that although it may seem that way, it is not completely accurate to state ROS2 publisher will only publish at the rate at which its lowest common denominator subscriber can receive, as it is not the reception capabilities on the remote what are causing the behaviour.
3 Likes