-
Notifications
You must be signed in to change notification settings - Fork 43
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
Unable to obtain publisher GID and sequence number errors #130
Comments
Thanks for trying it out! I think this is a bug (or at least, a part I missed) in #123 . In particular, I think that rmw_publish_serialized_message needs to "attach" the publisher GID and sequence number, similar to what rmw_publish does. Would you be interested in trying that out, and then submitting a pull request to add it? I'm more than happy to review. |
@clalancette sure! I just made a PR (#131). |
This is from a subscriber using the latest rolling branch of rmw_zenoh on a Jazzy distro subscribing live to a camera topic. It works, but deluges the stdout with these messages. Using the shared-memory transport.
|
This looks like it is using an older version of |
Both built from source on commit e73df29 |
The publisher also spits out the same messages, maybe 50 of them, but not continuously like the subscriber |
Also should mention they're running in separate rootless Podman containers, with /tmp and /dev/shm bind-mounted into each and both using the host's network namespace so the shared-memory transport can work |
It might be the case that shared-memory transport doesn't support attachments. If that is the case, then this can't possibly work; we rely on the attachments to send metadata along with the messages. That said, I really don't know what's happening; I don't see any of this locally. |
Functionally it does work though, I'm seeing the camera stream in the application, and there's no significant loopback traffic, so it must be using the shared-memory transport. The RUST_LOG=trace also indicates this with mentions of |
Yeah, it will deliver data, but none of the metadata will be there. So things like timestamps and the such will all be missing and empty. Many applications in ROS don't actually depend on any of that, but some do (like rosbag). |
Is this on the roadmap to be addressed? You mentioned it might not be possible, why is that? Would it require reworking how shared-memory is done in Zenoh itself upstream or is it more fundamental? |
No, not on the roadmap at the moment; this is the first I've heard about it. We'll have to do some deeper digging to figure out what is happening. I'm going to suggest you open a new issue, with a reproducer that we can use to do that digging. |
On further investigation it's not an issue exclusive to the shared-memory transport, as the issue also occurs with it disabled and nodes communicating on the loopback interface. Reproduced with image pub/sub, not sure if it's an issue with that implementation or the fact it's higher-bandwidth. |
Hi,
Thanks for all your work on the Zenoh RMW! We are very excited to try it out.
I'm getting the following errors when using data from a rosbag through
ros2 bag play
. These errors show up in any node that subscribes to topics published over Zenoh. It seems like these errors go away when subscribing to "live" topics rather than those played back throughros2 bag
. Do you have any idea what the root cause could be?The text was updated successfully, but these errors were encountered: