ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

ROS2 foxy not seeing topics published in sudo shell

asked 2021-04-12 05:05:07 -0500

Sebastian Delling gravatar image

updated 2021-04-14 04:52:36 -0500

We often have problems with seeing topics from nodes started as super user. Sometimes we had this issue without sudo but I cannot reproduce it so I will focus on that point.

The easiest way for me to reproduce is starting the demo talker as super user:

open terminal -> sudo -s -> source /opt/ros/foxy/local_setup.sh -> ros2 run demo_nodes_cpp talker

Then open another terminal and source /opt/ros/foxy/local_setup.sh -> ros2 topic list

If I open the second terminal as super user I am able to see the chatter topic.

Is there anything I can do to make sure all nodes find each others topics on the same machine?

Edit: The reason my node has to run as root is we are capturing raw packages with pcap. That is also possible via specific capture capabilities but then you have issues with the path set by the setup scripts.

I tried to figure out what happens and after trying to show the ros2 topics as normal user the ros_daemon goes to 100% cpu load.

Edit2: The same issue arises when using different users where none is root but without the cpu load going up.

edit retag flag offensive close merge delete

Comments

Perhaps an environment issue?

Did you set any env vars in the .bashrc of the non-root account? Perhaps a ROS domain ID?


Edit: and you probably already know this, but running ROS nodes (whether ROS 1 or ROS 2) as root is not a good idea. It's also not often really needed (device access fi under Linux can often be solved using appropriate user accounts and/or capabilities).

If you don't really need to run as root, it may save time trying to figure out what's going wrong by using a different approach.

gvdhoorn gravatar image gvdhoorn  ( 2021-04-14 04:07:42 -0500 )edit

Hi, we tried setting specific domain ids but that did not help. I will add some more information to my question.

Sebastian Delling gravatar image Sebastian Delling  ( 2021-04-14 04:20:31 -0500 )edit

I'm inclined to suspect environmental factors, as running ROS 2 nodes in Docker containers works for many users. Without configuring it differently, everything in a Docker container runs as root.

gvdhoorn gravatar image gvdhoorn  ( 2021-04-14 04:22:07 -0500 )edit

Edit: The reason my node has to run as root is we are capturing raw packages with pcap. That is also possible via specific capture capabilities but then you have issues with the path set by the setup scripts.

what does "but then you have issues with the path set by the setup scripts" mean?

you mean that the environment is sanatised by loading the binary?

I've seen setups with a secondary process being given the required capabilities and then the ROS node communicating with that process using IPC or some other mechanism.

Separates concerns nicely, but I can understand why that would perhaps be involved.

gvdhoorn gravatar image gvdhoorn  ( 2021-04-14 04:30:16 -0500 )edit

Basically you cannot find the shared libraries of ROS because the path is reset. Here is a description of the issue: https://stackoverflow.com/questions/9...

Sebastian Delling gravatar image Sebastian Delling  ( 2021-04-14 04:32:28 -0500 )edit

Yes, that's what I was referring to.

I tried to figure out what happens and after trying to show the ros2 topics as normal user the ros_daemon goes to 100% cpu load.

this seems like it could provide a clue.

Seeing as it's Python-based, you could see whether pdb can help finding out what's going on.

You could also try running it not as a background process, but in a separate terminal.

gvdhoorn gravatar image gvdhoorn  ( 2021-04-14 04:42:51 -0500 )edit

@Sebastian could you elaborate on how you changed the DDS settings? I'm facing the same issue but can't figure out how to force UDP like you mention below.

mcevoyandy gravatar image mcevoyandy  ( 2022-11-30 13:40:19 -0500 )edit
1

We ended up using cyclone DDS which uses UDP. See here. Also in this discussion there is the description how to use fastRTPS with UDP via a config file and the environment variable FASTRTPS_DEFAULT_PROFILES_FILE.

Sebastian Delling gravatar image Sebastian Delling  ( 2022-12-01 01:13:00 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2021-04-14 04:57:49 -0500

gvdhoorn gravatar image

updated 2021-04-14 05:16:39 -0500

Edit2: The same issue arises when using different users where none is root but without the cpu load going up.

Which RMW are you using?

I remember a similar Q&A where it turned out that FastRTPS was trying to use shared memory between different users (as the processes were all running on the same machine) which didn't work, as those shared memory segments are not accessible by different users due to standard Linux security.

Note: using shared memory is obviously advantageous for performance, but in your setup it might not work due to external factors.


Edit: found it: #q371315. See the answer by @Iker (ie: the non-accepted answer).

Issue on the FastRTPS tracker: eProsima/Fast-DDS#1750.


Edit 2: and another related Q&A: #q370595.

edit flag offensive delete link more

Comments

Yes, thank you those links explained the issue and I was able to fix it via enforcing UDP with a fastRTPS config.

Sebastian Delling gravatar image Sebastian Delling  ( 2021-04-15 02:21:58 -0500 )edit

Question Tools

Stats

Asked: 2021-04-12 05:05:07 -0500

Seen: 2,125 times

Last updated: Apr 14 '21