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

Configurable QoS for Publishers and Service Clients #3

Draft
wants to merge 2 commits into
base: feature/qos
Choose a base branch
from

Conversation

gavanderhoorn
Copy link

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.

@gavanderhoorn gavanderhoorn changed the title Configurable QoS for Publisher Configurable QoS for Publishers and Service Clients Sep 13, 2022
Copy link
Author

@gavanderhoorn gavanderhoorn left a 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 );
Copy link
Author

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?

Copy link
Owner

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.

Copy link
Author

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 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.

things will only get less complex if it can't be changed, so I'd be in favour of removing the setter(s).

Copy link
Owner

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.

Copy link
Author

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.

Copy link
Owner

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.

Copy link
Author

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?

Copy link
Owner

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.

include/qml_ros2_plugin/ros2.hpp Show resolved Hide resolved
include/qml_ros2_plugin/service_client.hpp Show resolved Hide resolved
src/publisher.cpp Outdated Show resolved Hide resolved
src/publisher.cpp Show resolved Hide resolved
src/ros2.cpp Outdated Show resolved Hide resolved
@@ -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() );
Copy link
Author

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?

Copy link
Author

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?

Copy link
Owner

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.

@gavanderhoorn
Copy link
Author

I can extend ImageTransportSubscription in a similar way once we get the style-issues sorted out.

include/qml_ros2_plugin/ros2.hpp Outdated Show resolved Hide resolved
src/publisher.cpp Outdated Show resolved Hide resolved
@gavanderhoorn
Copy link
Author

Addressed most of the comments I believe. Force-pushed the update.

@gavanderhoorn
Copy link
Author

I can extend ImageTransportSubscription in a similar way once we get the style-issues sorted out.

hm. If I understand the code correctly here, we should now also check for compatible QoS to figure out whether a subscription already exists?

@StefanFabian
Copy link
Owner

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.
Maybe it makes more sense to have a fixed QoS there, e.g., a best effort, volatile subscription which would be compatible with every publishing mode.

@gavanderhoorn
Copy link
Author

Maybe it makes more sense to have a fixed QoS there, e.g., a best effort, volatile subscription which would be compatible with every publishing mode.

yeah, that might work.

I'm having a bit of difficulty pin-pointing where the QoS is configured right now though in the ImageTransportSubscription. Could you point it out?

@StefanFabian
Copy link
Owner

I'm having a bit of difficulty pin-pointing where the QoS is configured right now though in the ImageTransportSubscription. Could you point it out?

I think I will just do that outside of this PR since it doesn't really have anything to do with configurable QoS.

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

Successfully merging this pull request may close these issues.

None yet

2 participants