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

spawner does not work with discovery-server #1200

Closed
Timple opened this issue Dec 11, 2023 · 3 comments
Closed

spawner does not work with discovery-server #1200

Timple opened this issue Dec 11, 2023 · 3 comments
Labels

Comments

@Timple
Copy link
Contributor

Timple commented Dec 11, 2023

Describe the bug
The fastdds discovery server is optimized in the sense that one cannot (by default) see all nodes/topics/services.

The spawner therefor observes wrongfully that the controller_manager is not present and waits until a timeout occurs.

To Reproduce
Steps to reproduce the behavior:

  1. Terminal 1: fastdds discovery -i 0
  2. Terminal 2: export ROS_DISCOVERY_SERVER=localhost:11811 && ros2 launch ros2_control_demo_example_2 diffbot.launch.py

Expected behavior
Everything works the same as without discovery server.

Screenshots
Not helpful

Environment (please complete the following information):

  • Version: Iron

Proposed solution
I think crawling nodes and services to find your other half is an anti-pattern.

We could use a pythonic "Ask forgiveness not permission" method. Try to call the service until is succeeds or a timeout is reached.

Can you agree on such an implementation? Than we could implement this.

@Timple Timple added the bug label Dec 11, 2023
@fmauch
Copy link
Contributor

fmauch commented Dec 26, 2023

I was just about to start implementing a fix for #1182 when stumbling upon this. I would be nice to fix both issues with a change.

@Timple crawling for nodes is one thing. From my understanding waiting for services is not an anti-pattern but the usual way to make sure your target service is actually there before calling it.

Removing the wait_for_controller_manager functionality makes use of wait_for_service internally which seems to work fine with the discovery server. If this also solves my use case from #1182 I'll provide a PR implementing this.

@Timple
Copy link
Contributor Author

Timple commented Dec 27, 2023

I didn't mean to suggest waiting for a service is an anti-pattern. I was refering to the crawling.

Although I don't really see the benefit of waiting for the service. Why not do the pythonic optimistic way: try the service and re-try if it failed.
It doesn't introduce more overhead I think. It even reduces overhead in the happy-flow.

But great that you are looking into this 🙂

@destogl
Copy link
Member

destogl commented Aug 15, 2024

resolved in #1562

@destogl destogl closed this as completed Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants