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

feat: Converting between Ros Nodelist and Process Ids #1564

Closed
wkaisertexas opened this issue May 15, 2024 · 6 comments
Closed

feat: Converting between Ros Nodelist and Process Ids #1564

wkaisertexas opened this issue May 15, 2024 · 6 comments

Comments

@wkaisertexas
Copy link

Feature request

Feature description

Going from node name to process id(s).

I am building a profiling tool for ROS nodes and I can find out the nodes which are currently running and their topics. However, I am unable to find out which PID those node names correspond.

Some nodes have the same executable and node name allowing pgrep to effectively filter out nodes by name. However, there does not seem to be an easy way to go from a ros node and namespace to a process ID.

There was a way to do this in Ros 1 as there is a package which was able to monitor CPU usage. However, there seems to be no equivalent in Ros2.

Does anyone have any ideas on this?

@clalancette
Copy link
Contributor

Some nodes have the same executable and node name allowing pgrep to effectively filter out nodes by name. However, there does not seem to be an easy way to go from a ros node and namespace to a process ID.

There are 2 main reasons we don't have this in ROS 2:

  1. There isn't a one-to-one correspondence between nodes and processes. It is entirely possible (and very common) for multiple nodes to be in the same process.
  2. It isn't totally clear how to find out the process name in a cross-platform way, since we have to support Windows as well as Linux here.

@wkaisertexas
Copy link
Author

Process ids do not have to be unique, but it would be nice to know that mapping.

Additionally, a good middle ground would be giving users easy access between the instance of a node and the executable which runs that node.

Currently, if two nodes with the same name exist, distinguishing between how they were launched is kind of pain.

Ros's commitment to cross platform support is admirable, but reducing to the lowest common feature set seems reductive.

@fujitatomoya
Copy link

a couple of comments here,

  • (besides @clalancette 's comment above) ROS 2 supports distributed application, that means there can be multiple systems running ROS 2 application. In this case, process id can be the same with different node name or namespace. having IP address with process ID is not good enough to tell the application either, when we use containers within the different pid namespace assigned. currently i am not sure how we want to (or should) support this...

@wkaisertexas

  • i guess that what you want to do at this moment is like a top command dedicated to ROS 2 in localhost system? in that case, how about https://github.com/iwatake2222/rotop? i have never tried that, but it seems that it works on the localhost system.

@christophebedard
Copy link
Member

You could try to use ros2_tracing and process the rcl_node_init trace events (which can include PID) live.

@wkaisertexas
Copy link
Author

That sounds like a great solution. Thank you so much!

@audrow
Copy link
Member

audrow commented May 23, 2024

I'm glad it seems like there's a good solution. Using a container orchestration software might also be another solution.

It does seem like this would be useful, but it's not clear what this means when nodes are running on different machines. Some middlewares have host information, but I don't think all of them do, so there probably isn't a clean way to do this for different middlewares.

I'm going to close this issue. Feel free to continue the discussion or open it back up, if it makes sense to do so.

@audrow audrow closed this as completed May 23, 2024
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

No branches or pull requests

5 participants