Skip to content
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

Expose sequence number for received messages #201

Open
paulbovbel opened this issue Mar 14, 2020 · 2 comments
Open

Expose sequence number for received messages #201

paulbovbel opened this issue Mar 14, 2020 · 2 comments
Labels
backlog enhancement New feature or request help wanted Extra attention is needed

Comments

@paulbovbel
Copy link

paulbovbel commented Mar 14, 2020

Feature request

Feature description

The auto-populated seq field was dropped from Header in transition from ROS1 to ROS2 (ros2/common_interfaces#2). This data was useful in measuring lost messages, and I imagine will be even more helpful with ROS2's focus on unreliable communication channels.

Implementation considerations

Some implementation hints were provided in https://discourse.ros.org/t/foxy-message-api-review/13105/17

@ros-discourse
Copy link

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/foxy-message-api-review/13105/19

@wjwwood wjwwood added backlog enhancement New feature or request help wanted Extra attention is needed labels Mar 16, 2020
@RMichaelSwan
Copy link

I would like to add to this that the ordering of messages documentation is unclear. There are a couple of threads on this that seem to definitively answer the question:
https://answers.ros.org/question/280144/are-ros2-messages-guaranteed-to-be-received-by-a-subscriber-in-the-same-order-they-were-published/
https://robotics.stackexchange.com/questions/87494/can-we-ensure-subscribing-order-same-as-publishing-order-in-ros-given-multiple-p

However this seems to conflict with the design docs. In https://design.ros2.org/articles/qos.html - it states under the "Integration with non DDS RMW Implementations" section that:

an RMW implementation must implement the same behavior as DDS. Once a subscriber takes a message from the RMW implementation it must not be allowed to take an earlier message from the same publisher."

Finally, it seems like there are QoS options that can solve this (possibly with a performance hit), but these don't seem to be exposed for ROS, even though it seems most DDSes have some option for it, e.g DDS_DESTINATIONORDER.

Some documentation or characterization of what ROS2 does under different DDSes with respect to this topic would be helpful, otherwise it seems that users must manually handle a feature that DDSes can already do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants