-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GZ->ROS communication doesn't work when using the bridge and gz_server in the same composable container #555
Comments
I thought about this and have a few ideas: 1. Solve it a Transport level: Similar to ROS, add a new 2. Solve it at the bridge with extra support from Transport. I need to review the bridge code but another idea could be to modify Then, in the bridge, when receiving a message from a callback we could check the Node UUID of the sender. If that matches the UUID of the bridge's publisher we know we should ignore the message to avoid loops. I'm leaning towards (1) because if doesn't add any extra overhead to the network protocol. |
I would also be in favor of (1), but I think we would only need the
|
I think we need a solution where "real" publishers share the process with the bridge, which should be the case where we use composition. That's the case where the current bridge implementation doesn't work as we're relying only on the That's why I think proposal (1) has a finer control because we'll discriminate the case where the bridge subscriber receives the data publisher from the bridge. I think that's what we want (we should set that Do you agree? |
Yes, I agree. I'm saying we don't need the part where you said
We just need to implement the |
Maybe I'm misunderstanding. I thought in (1) you were stating two solutions. (a) |
Sorry if this was a bit confusing. My proposal in (1) is a single solution and I was describing some implementation details to do it. The |
I see. Well, let's go ahead with (1) then since we're both on the same page. |
See gazebosim/gz-transport#506 and #559 |
Part of #544
When the bridge and gz_server nodes are in the same process, GZ->ROS communication doesn't work because of
ros_gz/ros_gz_bridge/src/factory.hpp
Lines 112 to 115 in cfc94bc
which ignores all
gz-transport
messages published from the same process. This was done to enable bidirectional bridges, so I don't think we can simply remove it.The text was updated successfully, but these errors were encountered: