-
Notifications
You must be signed in to change notification settings - Fork 10
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
Configurable QoS for Publishers and Service Clients #3
base: feature/qos
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some comments on parts I was unsure about.
@@ -51,6 +58,8 @@ class Publisher : public QObjectRos2 | |||
|
|||
quint32 queueSize() const; | |||
|
|||
void setQueueSize( quint32 value ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've kept the name QueueSize
here even though I believe it should be HistoryDepth
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've kept the name queueSize
for backwards compatibility. Not sure if it makes sense to have a cut there and use the new terminology.
It's not like these libraries are out for that long so making such a change is still possible.
However, the publisher was not really intended to be modified after creation.
The only reason Subscription
supports modification is because it can be instantiated as a QML item.
The publisher receives all required information in the constructor to ensure that it will be in a consistent state from the start.
Not sure what the use case would be to change such properties dynamically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've kept the name
queueSize
for backwards compatibility. Not sure if it makes sense to have a cut there and use the new terminology.
It's not like these libraries are out for that long so making such a change is still possible.
so change to HistoryDepth
, or keep QueueSize
?
However, the publisher was not really intended to be modified after creation.
The only reasonSubscription
supports modification is because it can be instantiated as a QML item.
The publisher receives all required information in the constructor to ensure that it will be in a consistent state from the start.
Not sure what the use case would be to change such properties dynamically.
things will only get less complex if it can't be changed, so I'd be in favour of removing the setter(s).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so change to HistoryDepth, or keep QueueSize?
or remove it completely and add properties to QoS
to get these values.
However, QoS is currently a Q_GADGET
which means it does not support signals so no changed notify signals.
I don't think they are necessary for the QoS
settings, though, and don't justify dealing with the complications that would arise when changing QoS
to Q_OBJECT
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I'm not a Qt aficionado I'm going to need some guidance in this case.
If you'd rather have properties in QoS
, that would be fine by me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, QoS
is a Q_GADGET
class. The difference to a standard QObject
based class is that we don't have all that QObject
overhead at the cost of not being connected to the signal mechanism.
Hence, we can have properties (I think) but they can't notify of changes since the Q_GADGET
can't have signals.
I don't think we need them though and switching to QObject
would make building the QoS
more complicated since the gadget is passed by value whereas QObject
is always passed by pointer and I'm currently using the value mechanism to enable that you can start configuring QoS use them for one publisher and add some more settings for the second one without these changes being reflected on the first publisher. I think that behavior is closer to the cpp version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, conclusion: keep QoS
a Q_GADGET
class, but add (more) properties to it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think adding properties for the available options would make most sense.
Since humble there are getters for properties such as the history
but they have the same name as the setter.
I don't think that will work with QML. Will have to get around that.
@@ -40,7 +40,7 @@ void ServiceClient::onRos2Initialized() | |||
try { | |||
rclcpp::Node &node = *Ros2Qml::getInstance().node(); | |||
client_ = | |||
babel_fish_.create_service_client( node, name_.toStdString(), service_type_.toStdString() ); | |||
babel_fish_.create_service_client( node, name_.toStdString(), service_type_.toStdString(), qos_.getQoS().get_rmw_qos_profile() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure why create_service_client(..)
needs a rmw_qos_profile_t
, while create_subscription(..)
et al. accept rclcpp::QoS
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that should change in ros2_babel_fish
? Or is it as-intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly because the ROS2 service client required the C struct in its constructor but I guess it makes sense to change that in ros2_babel_fish
to make it more consistent.
I will change it but keep the old function for a while with a deprecation message.
I can extend |
f9ce190
to
10ecaac
Compare
Addressed most of the comments I believe. Force-pushed the update. |
hm. If I understand the code correctly here, we should now also check for compatible QoS to figure out whether a subscription already exists? |
Hm, you're right, it's a bit more complicated for image transport and I think this would create some error potential if you could accidentally create multiple subscribers differing only in their QoS which would increase the bandwidth requirements. |
yeah, that might work. I'm having a bit of difficulty pin-pointing where the QoS is configured right now though in the |
I think I will just do that outside of this PR since it doesn't really have anything to do with configurable QoS. |
This is for #1.
A bit of a WIP, as I haven't tested it (yet) and I've not ran
clang-format
.I've tried to follow the style of bab270d.
I'll add some in-line comments to aspects I'm not sure about.
Please review and let me know whether this would be acceptable.