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

Feature Request: Provide CLI to retrieve IP address a node runs on #781

Open
moooeeeep opened this issue Dec 5, 2022 · 4 comments
Open
Labels

Comments

@moooeeeep
Copy link

I recently was in the situation, that two nodes were publishing on the same topic (classroom environment with several turtlebots, two of which with colliding ROS_DOMAIN_ID), and it would have been helpful if there was a command to find the IP address of each node in the system (some kind of a network inventory). We ended up to go after the tcpdump approach explained here to identify the offending host.

I thought having a ROS 2 native CLI tool would be nice to have, i.e., a tool that would incorporate the relevant abstractions / query info from the daemon.
I’d like to feature request a tool to provide this info, e.g., via ros2 node info --verbose command.
Maybe a similar query for info belonging to a GID for a topic would be useful too, in case node names collide).

I already skimmed through this repo but I didn’t find any obvious angle of approach to add this myself.
Any suggestions welcome.

Previous discussion:

In the linked discussion, the ROS 2 Monitor GUI tool was mentioned that seems to provide a graphical interface for inspection of the running nodes (not sure how vendor-specific this is though):

@ros-discourse
Copy link

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

https://discourse.ros.org/t/feature-request-provide-cli-to-retrieve-ip-address-a-node-runs-on/28569/10

@fujitatomoya
Copy link
Collaborator

@moooeeeep thanks for creating issue.

I recently was in the situation, that two nodes were publishing on the same topic (classroom environment with several turtlebots, two of which with colliding ROS_DOMAIN_ID), and it would have been helpful if there was a command to find the IP address of each node in the system (some kind of a network inventory)

i would like to know how this is gonna solve your situation. you want to identify the node based on IP address? probably i am not really sure about the use case and what you really want to use this IP address information in your application.

@moooeeeep
Copy link
Author

i would like to know how this is gonna solve your situation. you want to identify the node based on IP address? probably i am not really sure about the use case and what you really want to use this IP address information in your application.

Knowing the IP address, I could directly identify and log-in to the offending host and adjust the ROS_DOMAIN_ID settings there. Without it, I would need to try all the hosts, to find out which one has it wrong (or am I missing something here?).

Not sure if it has to be the node info verb to query this, or if it would be easier to add a new verb for listing and inspecting DDS participants directly (e.g., ros2 pub list, ros2 pub info ...).

@fujitatomoya
Copy link
Collaborator

Knowing the IP address, I could directly identify and log-in to the offending host and adjust the ROS_DOMAIN_ID settings there. Without it, I would need to try all the hosts, to find out which one has it wrong (or am I missing something here?).

Ah, I see. so it is physical identification. that makes sense.
I think it is likely to happen that, when one of the nodes printing error via rosout in distributed system, and then where I should log in and fix?
And I believe you are not missing anything, we do not have anything like that at this moment.

Not sure if it has to be the node info verb to query this

this sounds reasonable.

to add this feature, i think we need to add new RMW interface to ask IP address of the node, node information like rmw_get_node_info.

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

4 participants