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

Revision history [back]

click to hide/show revision 1
initial version

When I launch the node using rosrun, it works perfectly. What could be causing this issue?

Have you read the note about permissions in the installation documentation? From the robot_upstart 0.2.0 documentation » The install script - permissions:

It’s important to understand how permissions work robot_upstart:

  1. The upstart job invokes its jobname-start bash script as root.

  2. The script sets up environment variables, and then uses setuidgid to execute roslaunch as an unprivileged user. This is by default the user who ran the install script, but it can also be specified explicitly via a flag.

  3. The roslaunch which executes does not have its user’s group memberships. This means that it will not have access to serial ports with the dialout group, or locations in /var/log owned by root, etc. Any filesystem resources needed by your ROS nodes should be chowned to the same unprivileged user which will run ROS, or should set to world readable/writeable, for example using udev.

So jobname-start starts out as user root, but then quickly drops all privileges and continues as a regular user (that is not a member of the dialout group). That is why some more configuration is required.

When I launch the node using rosrun, it works perfectly. What could be causing this issue?

Have you read the note about permissions in the installation documentation? From the robot_upstart 0.2.0 documentation » The install script - permissions:

It’s important to understand how permissions work robot_upstart:

  1. The upstart job invokes its jobname-start bash script as root.

  2. The script sets up environment variables, and then uses setuidgid to execute roslaunch as an unprivileged user. This is by default the user who ran the install script, but it can also be specified explicitly via a flag.

  3. The roslaunch which executes does not have its user’s group memberships. This means that it will not have access to serial ports with the dialout group, or locations in /var/log owned by root, etc. Any filesystem resources needed by your ROS nodes should be chowned to the same unprivileged user which will run ROS, or should set to world readable/writeable, for example using udev.

So jobname-start starts out as user root, but then quickly drops all privileges and continues as a regular user (that is not a member of the dialout or any other group). That is why There may be some more configuration is required.