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

[rmw] Improve handling of dynamic discovery #338

Merged
merged 31 commits into from
Apr 8, 2023

Conversation

gbiggs
Copy link
Member

@gbiggs gbiggs commented Dec 14, 2022

This PR adds to rmw functionality necessary to support the improved handling of dynamic discovery.

It adds handling of the new discovery-related configuration parameters to rmw so they can be used by rcl to control the behaviour of RMW implementations.

Copy link
Member

@ivanpauno ivanpauno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

I have some minor comments/suggestions.

rmw/include/rmw/discovery_params.h Outdated Show resolved Hide resolved
rmw/include/rmw/discovery_params.h Outdated Show resolved Hide resolved
Comment on lines 29 to 30
/// Uses ROS_LOCALHOST_ONLY environment variable.
RMW_AUTOMATIC_DISCOVERY_RANGE_DEFAULT = 0,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that if ROS_LOCALHOST_ONLY is not set, it is just up to rmw implementation? that means, changing rmw implementation via environmental variable changes application behavior pretty much? i think it would be nice to define the default in ROS 2?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavior in rcl is to use RMW_AUTOMATIC_DISCOVERY_RANGE_LOCALHOST if no value is given for the environment variable.

I think it's worth considering removing the RMW_AUTOMATIC_DISCOVERY_RANGE_DEFAULT value entirely since it currently will never get passed to rmw from rcl, and furthermore we're expecting the RMW implementations to implement ..._DEFAULT the same as ..._LOCALHOST anyway. Having this redundancy is probably just creating confusion and not accomplishing anything.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The QoS enums have a *_SYSTEM_DEFAULT value. I forget what this was for. Was it to allow setting QoS via a middleware specific configuration?

If so, RMW_AUTOMATIC_DISCOVERY_RANGE_SYSTEM_DEFAULT might be useful to say "don't mess with discovery settings, they're already configured with middleware specific APIs".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right @sloretz.

I think @mxgrey is also right, it's weird if we're never sending the value down to rmw, so we should either not have it as an rmw option or we should handle it in the rmw layer. It might make sense to have ROS/RCL version that has system default but not have one in RMW if that one doesn't make sense. I know we only have RMW enums atm, however.

However, it might just be that we shouldn't be automatically be converting the DEFAULT into LOCALHOST as we are now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, it might just be that we shouldn't be automatically be converting the DEFAULT into LOCALHOST as we are now.

If we are just converting DEFAULT to LOCALHOST ( I see that happening in the rmw_cyclonedds_cpp PR) then I agree it doesn't seem like an option at the RMW layer is necessary.

If someone wants to use an XML config, and doesn't want the rmw_* layer to mess with discovery settings, and the default discovery range is localhost, what option should they provide for the range? SUBNET since the default behavior seems to be to do nothing, at least for cyclonedds?

Comment on lines 35 to 36
/// Allows multicast on the reachable network
RMW_AUTOMATIC_DISCOVERY_RANGE_SUBNET = 3,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if system has multiple network interface? that is also rmw implementation dependent as it is now?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. That is out of scope of this PR.

Comment on lines 45 to 48
if (strncmp(
left->static_peers[ii],
right->static_peers[ii],
RMW_DISCOVERY_PARAMS_PEER_MAX_LENGTH) != 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the one is with hostname which can be DNSed to IP, and the other with the same IP address? that is not supported here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main use case for this is testing and configuration. So yes, this means that discovery_params which has a hostname that can be DNSed to some other host name is considered a different configuration.

@ros-discourse
Copy link

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

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-02-16/29927/1

gbiggs and others added 4 commits March 21, 2023 11:46
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
@wjwwood wjwwood force-pushed the gbiggs/discovery-peers-specification branch from ee413aa to a493020 Compare March 21, 2023 18:47
arjo129 and others added 13 commits March 21, 2023 11:52
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
@sloretz

This comment was marked as resolved.

Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API and functions that are implemented here lgtm, but we should have some tests for those new functions that live here. I think @sloretz and I can help with that tomorrow.

rmw/include/rmw/discovery_options.h Outdated Show resolved Hide resolved
rmw/include/rmw/discovery_options.h Outdated Show resolved Hide resolved
rmw/include/rmw/discovery_options.h Outdated Show resolved Hide resolved
rmw/include/rmw/discovery_options.h Outdated Show resolved Hide resolved
@wjwwood
Copy link
Member

wjwwood commented Mar 27, 2023

I also think we need to address @fujitatomoya's comments, as I think they're still relevant even after the changes.

@arjo129
Copy link
Contributor

arjo129 commented Mar 27, 2023

I don't have push access to this repo. Would you like me to open yet another PR?

@clalancette
Copy link
Contributor

I don't have push access to this repo. Would you like me to open yet another PR?

@arjo129 I invited you to have push access. Once you accept, you should be able to continue here.

Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
@sloretz
Copy link
Contributor

sloretz commented Mar 27, 2023

@wjwwood FYI 2cf62e3 is a sizeable change. It:

  • adds rmw_discovery_options_init() to allocation options with a set number of static peers
  • adds an allocator member to the rmw_discovery_options_t object
  • uses a pointer to an allocator as an argument because I saw that used elsewhere
  • errors if copy is called with same object for src and dst
  • adds a whole bunch of tests

Signed-off-by: Shane Loretz <sloretz@google.com>
Copy link
Member

@wjwwood wjwwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one small necessary (imo) change, otherwise lgtm

rmw/include/rmw/discovery_options.h Outdated Show resolved Hide resolved
rmw/src/discovery_options.c Show resolved Hide resolved
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
@sloretz sloretz changed the title Improve handling of dynamic discovery - rmw changes [rmw] Improve handling of dynamic discovery Mar 29, 2023
sloretz and others added 4 commits March 30, 2023 15:55
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: Shane Loretz <sloretz@google.com>
@sloretz sloretz merged commit 418781a into rolling Apr 8, 2023
@delete-merged-branch delete-merged-branch bot deleted the gbiggs/discovery-peers-specification branch April 8, 2023 04:35
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

10 participants