Subscriber node do not seems to register publisher on remote machine

asked 2020-05-05 04:34:24 -0500

TK
1 ●1 ●2 ●2

The setup: Similar to the ROS tutorial on writing publisher and subscriber, I have a listener node, which listens to the topic "/chatter" and talker node which publishes to "/chatter".

The problem: Things works fine when both nodes are launched on same machine, which is just WSL. Things however get peculiar when I try to launch the talker node on RPi, a remote machine. The listener and the master are both still on WSL. The listener node will not subscribe to the topic the talker node is publishing on. rqt_graph confirmed no connection between two nodes.

I had tried using "rostopic echo chatter" command on WSL and it will subscribe to the topic and echo back what is published by the remote talker node. So I am pretty sure I had the network configuration done correctly. The problem seems to be due to issue with publisher update callback by rosmaster....

Is there anything I possibly overlooked? Any guidance is utmost appreciated.

Thanks.

edit retag flag offensive close merge delete

Comments

BTW this is the output for when "rosnode info talker" command is used

Node [/talker]
Publications:
 * /chatter [std_msgs/Float64]
 * /rosout [rosgraph_msgs/Log]

Subscriptions: None

Services:
 * /talker/set_logger_level
 * /talker/get_loggers


contacting node http://192.168.137.170:39201/ ...
Pid: 1070

There is no connections shown, I am not sure why is that the case.

TK ( 2020-05-05 05:03:23 -0500 )edit

Some new information: This problem seems to only affect subscriber initiated with roscpp, not rospy.

TK ( 2020-05-05 20:39:17 -0500 )edit

is the remote machine has been configured to connect the master ip ?

Nitesh_j ( 2020-05-06 12:37:57 -0500 )edit

Yes. In fact, when I do "rostopic echo chatter" on WSL it will subscribe and echo whatever that is published by the remote publisher. The subscriber only fail to do so when the subscriber is invoked from roscpp version of the subscriber. It does kinda seems like a bug within source code of ros_comm package.

TK ( 2020-05-06 19:08:37 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-05-12 10:18:12 -0500

TK
1 ●1 ●2 ●2

As I have stated previously, the problem seems to be a bug within ros_comm package. The following merge request from ros_comm github confirmed my suspicion. Reason being that during multiple machine setup, ros_comm c++ client API failed to check whether the socket is connected when asynchronous, which causes the problem manifesting itself in the first place in WSL

https://github.com/ros/ros_comm/pull/...

In fact the fix had already been developed by bxwllzz in the said merge request. However the merge had never been done to the kinetic branch of the ros_comm package, which resulted in the bug being observed during my setup. Merging the source manually and build it on-site solved the problem.

edit flag offensive delete link

Comments

(One of) the reason(s) why the linked PR was not merged was that the author did not respond any more and the PR was targetting a ROS release which did not accept PRs which would break ABI.

Actually: without someone submitting this for Noetic, the patch will not get into Noetic either.

gvdhoorn ( 2020-05-12 10:49:07 -0500 )edit

I see... will there be any way to get this fix into future version of ROS? This fix is crucial if multiple machine setup is to be used with WSL.

BTW, despite it breaks ABI, it would seems to be more of an issue for developers that deal with the TransportTCP class, since I presume with my little experience with ROS that typical user would not have instantiated such class directly by themselves. Hence the calling class will stays within the packages which get built together and hence not much of a problem since the class within the packages will always be linked to the correct object file. Personally as I described in this answer my package is built and linked with the original ros_comm package in mind, then run with the modified ros_comm package dwelling in my catkin workspace and no problem had been seen thus far....(or at ...(more)

TK ( 2020-05-12 19:27:59 -0500 )edit

it would seems to be more of an issue for developers that deal with the TransportTCP class

This issue affects everyone who is using roscpp in WSL.

Personally as I described in this answer my package is built and linked with the original ros_comm package in mind, then run with the modified ros_comm package dwelling in my catkin workspace and no problem had been seen thus far.

roscpp is a very low-level package in a ROS environment. Building it from source is possible, but to be absolutely sure no ABI incompatibilities have been introduced, you should really build everything else in your ROS installation which depends on roscpp from source as well. This essentially includes almost all other packages (which contain C++ nodes).

The fact that it seems to work is of course not really a guarantee it will work for everyone, which is one of the reasons the linked ...(more)

gvdhoorn ( 2020-05-13 02:14:05 -0500 )edit

add a comment

-2

answered 2020-05-06 22:15:58 -0500

Nitesh_j
65 ●17 ●4

Try this website https://www.theconstructsim.com/subsc...

edit flag offensive delete link

Comments

Could you please update your answer with the relevant information instead of just linking to a site? We try to keep answers self-contained and if that site/page were to go down then this answer won't be self-contained.

jayess ( 2020-05-06 22:40:37 -0500 )edit

it's from The Construct, I don't think the website will be down anytime soon

Nitesh_j ( 2020-05-06 22:57:50 -0500 )edit

Any site can change at anytime, even companies big and small. Remember Google Code, Google+, etc?

jayess ( 2020-05-06 23:00:52 -0500 )edit

Perhaps my language is a bit confusing. But essentially this doesn't solve my problem. I have no problem with either C++ subscriber subscribing to Python publisher or whatsoever. The problem only arose when the publisher, irrespective of being Python or C++, resides on a remote machine, while the C++ subscriber is instantiated in WSL. Meanwhile, if the C++ subscriber is in the remote node, irrespective of whether it is Python publisher or C++ publisher on WSL, the subscriber can subscribe to it normally. There is a version difference between the ros_comm package on my RPi and WSL which leads me to believe that it might actually be caused by some unintended side effect of bug fix on recent version.

TK ( 2020-05-06 23:37:34 -0500 )edit

While I would +100 for the effort to answer, I've downvoted this as link-only answers should be discouraged.

@Nitesh_j: @jayess' comment is completely justified: if/when The Construct disappears or changes their website, your answer will potentially not be useful any more. That would be very unfortunate, but there is a simple way to avoid that: by including the relevant parts of the website you link to in your answer. If you clearly mark those as quotes, it would be perfectly acceptable to do that (as the origin of those sections is clear).

gvdhoorn ( 2020-05-07 07:11:14 -0500 )edit

add a comment

Subscriber node do not seems to register publisher on remote machine

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Subscriber node do not seems to register publisher on remote machine edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Subscriber node do not seems to register publisher on remote machine