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

Support keyed instances for liveliness and deadline QoS #252

Open
nburek opened this issue Aug 26, 2019 · 1 comment
Open

Support keyed instances for liveliness and deadline QoS #252

nburek opened this issue Aug 26, 2019 · 1 comment
Labels
enhancement New feature or request

Comments

@nburek
Copy link
Contributor

nburek commented Aug 26, 2019

The current design for deadline and liveliness QoS settings do not support differentiating keyed instances of Topics. As a result, you are not able to determine which instance has violated the QoS policy if your subscription encompasses multiple instances. Supporting this would be useful for cases like when you have multiple robots publishing to a single topic but using a different instance identifier, such as a serial number for the robot. If one of your robots starts failing to publish data to the topic then you could get notified of the liveliness or deadline violation, but you wouldn't be able to tell which of them had caused it.

In order to support this use case, changes would be needed to the callback structure in order to include information about the key identifier for the instance that has violated the policy. This value would need to be optional based on if the message type used for the topic specifies a key or not. How this key is represented may also depend on how ROS 2 decides to represent instanced subscription for topics. It will probably require some code generated for a message in order to cast the key data to the proper type. The C++ api may be able to leverage templates to do this automatically for the user, but rclpy will need a way to do this for the C message types as well.

@nburek
Copy link
Contributor Author

nburek commented Aug 26, 2019

Please label this issue as an enhancement.

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

No branches or pull requests

2 participants