Rosanswers logo


Last June 6 I performed the available upgrade of ros packages, and now I'm experiencing an strange problem: using the same roslaunch files I had now the nodes in remote machines (for me those responsible for robot I/O) doesn't start up. They bring up when using a local launch file, so maybe this is an issue with roslaunch?

Now I've checked that they actually start up, but then die inmediately after.

I changed nothing in my launch files, so I was wondering wether this was an issue of the upgrade in the ros_comm stack

Thank you in advance for your comments


I'm using diamondback in Ubuntu 10.04, and here I list the ros packages I updated through Synaptic:

Commit Log for Mon Jun  6 10:11:25 2011
Upgraded the following packages:
ros-diamondback-camera-drivers (1.4.1-s1299038009~lucid) to 1.4.1-s1306620563~lucid
ros-diamondback-common (1.4.3-s1299027615~lucid) to 1.4.3-s1306609639~lucid
ros-diamondback-common-msgs (1.4.0-s1299027519~lucid) to 1.4.0-s1306609559~lucid
ros-diamondback-common-tutorials (0.1.2-s1299053657~lucid) to 0.1.2-s1306638686~lucid
ros-diamondback-control (0.1.1-s1299033115~lucid) to 0.1.1-s1306616386~lucid
ros-diamondback-desktop-full (1.0.0-s1304391878~lucid) to 1.0.0-s1306677492~lucid
ros-diamondback-diagnostics (1.4.0-s1299028141~lucid) to 1.4.0-s1306609964~lucid
ros-diamondback-diagnostics-monitors (1.4.0-s1299038404~lucid) to 1.4.0-s1306621047~lucid
ros-diamondback-documentation (1.4.1-s1299054311~lucid) to 1.4.1-s1306639612~lucid
ros-diamondback-driver-common (1.2.3-s1299028246~lucid) to 1.2.3-s1306610051~lucid
ros-diamondback-erratic-robot (0.2.0-s1304359692~lucid) to 0.2.0-s1306635164~lucid
ros-diamondback-executive-smach (1.0.1-s1299034118~lucid) to 1.0.1-s1306617318~lucid
ros-diamondback-executive-smach-visualization (1.0.1-s1299051085~lucid) to 1.0.1-s1306636595~lucid
ros-diamondback-geometry (1.4.1-s1299027775~lucid) to 1.4.2-s1306609794~lucid
ros-diamondback-geometry-experimental (0.1.4-s1299035647~lucid) to 0.1.5-s1306618067~lucid
ros-diamondback-geometry-tutorials (0.1.3-s1299042659~lucid) to 0.1.3-s1306625345~lucid
ros-diamondback-image-common (1.4.1-s1299029638~lucid) to 1.4.1-s1306610124~lucid
ros-diamondback-image-pipeline (1.4.1-s1302036824~lucid) to 1.4.2-s1306619150~lucid
ros-diamondback-image-transport-plugins (1.4.1-s1302032693~lucid) to 1.4.1-s1306610938~lucid
ros-diamondback-joystick-drivers (1.4.1-s1301689512~lucid) to 1.4.1-s1306611037~lucid
ros-diamondback-kinect (0.1.6-s1302037168~lucid) to 0.1.6-s1306620703~lucid
ros-diamondback-kinematics (0.3.3-s1304034970~lucid) to 0.3.3-s1306615328~lucid
ros-diamondback-laser-drivers (1.2.2-s1299041777~lucid) to 1.2.2-s1306624585~lucid
ros-diamondback-laser-pipeline (1.2.0-s1299027967~lucid) to 1.2.0-s1306612505~lucid
ros-diamondback-motion-planners (0.3.9-s1304352571~lucid) to 0.3.9-s1306615697~lucid
ros-diamondback-motion-planning-common (0.3.6-s1304034571~lucid) to 0.3.6-s1306615012~lucid
ros-diamondback-motion-planning-environment (0.3.1-s1298601768~lucid) to 0.3.1-s1306619083~lucid
ros-diamondback-motion-planning-visualization (0.3.1-s1298607902~lucid) to 0.3.1-s1306625171~lucid
ros-diamondback-navigation (1.4.1-s1301523272~lucid) to 1.4.1-s1306612684~lucid
ros-diamondback-openni-kinect (0.1.3-s1302657579~lucid) to 0.2.1-s1306611764~lucid
ros-diamondback-orocos-toolchain-ros (0.3.2-s1304497659~lucid) to 0.3.2-s1306628274~lucid
ros-diamondback-perception-pcl (0.10.0-s1299028346~lucid) to 0.10.0-s1306611175~lucid
ros-diamondback-physics-ode (1.4.0-s1298593424~lucid) to 1.4.1-s1306612903~lucid
ros-diamondback-point-cloud-perception (0.5.2-s1299038145~lucid) to 0.5.2-s1306619711~lucid
ros-diamondback-pr2-cockpit (0.3.1-s1302040132~lucid) to 0.3.1-s1306634810~lucid
ros-diamondback-pr2-common (1.4.4-s1299032909~lucid) to 1.4.5-s1306616195~lucid
ros-diamondback-pr2-controllers (1.4.0-s1299033347~lucid) to 1.4.0-s1306616592~lucid
ros-diamondback-pr2-ethercat-drivers (1.4.1-s1299037723~lucid) to 1.4.1-s1306622130~lucid
ros-diamondback-pr2-mechanism (1.4.4-s1299033195~lucid) to 1.4.4-s1306616451~lucid
ros-diamondback-pr2-simulator (1.4.3-s1302038183~lucid) to 1.4.3-s1306623403~lucid
ros-diamondback-robot-model (1.4.0-s1299029173~lucid) to 1.4.0-s1306611922~lucid
ros-diamondback-ros (1.4.6-s1298587598~lucid) to 1.4.8-s1306608830~lucid
ros-diamondback-ros-comm (1.4.5-s1299027150~lucid) to 1.4.6-s1306609281~lucid
ros-diamondback-ros-realtime (0.5.1-s1299044295~lucid) to 0.5.1-s1306633260~lucid
ros-diamondback-ros-tutorials (0.2.4-s1299042529~lucid) to 0.2.4-s1306625227~lucid
ros-diamondback-rx (1.4.1-s1299029758~lucid) to 1.4.1-s1306613200~lucid
ros-diamondback-simulator-gazebo (1.2.8-s1299040501~lucid) to 1.2.8-s1306622600~lucid
ros-diamondback-simulator-stage (1.2.4-s1299041907~lucid) to 1.2.5-s1306640478~lucid
ros-diamondback-slam-gmapping (1.2.2-s1301690889~lucid) to 1.2.2-s1306617388~lucid
ros-diamondback-trajectory-filters (0.3.3-s1304352350~lucid) to 0.3.3-s1306615498~lucid
ros-diamondback-vision-opencv (1.4.2-s1302031196~lucid) to 1.4.3-s1306610230~lucid
ros-diamondback-visualization (1.4.1-s1303841303~lucid) to 1.4.1-s1306614471~lucid
ros-diamondback-visualization-common (1.4.0-s1299029955~lucid) to 1.4.1-s1306613399~lucid
ros-diamondback-visualization-tutorials (0.2.2-s1299054203~lucid) to 0.2.2-s1306639510~lucid

Originally posted by chcorbato on ROS Answers with karma: 202 on 2011-06-07

Post score: 0

Original comments

Comment by chcorbato on 2011-06-09:
But I did not change any of that configuration. All that changed was upgrade the ros packages. And downgrading them back solved the issue. I agree it is probably not roslaunch as you argue, but maybe some issue with the master?

Comment by kwc on 2011-06-09:
All implications are that this is a networking issue of some sort, unrelated to roslaunch as the roslaunch processes come up and down correctly. It seems more likely it's a change in a ROS_MASTER_URI, ROS_IP, or some other network configuration as the nodes are having issues contacting the master.

Comment by chcorbato on 2011-06-09:
Thank you anyway, I checked what you said :-)

Comment by chcorbato on 2011-06-09:
I don't think it is a network problem, I can ssh from one machine to the other and roslaunch does it: as I said, even killing the roslaunch process in my desktop computer terminates the remote nodes processes in the remote robot computer. The issue is that they do not appear as ROS nodes

Comment by dornhege on 2011-06-09:
Maybe its a networking problem? Can you check if each machine can ping the master and vice-versa using the hostname of the machine (not its IP). You can try to set ROS_IP on each machine (to its ip).

Comment by chcorbato on 2011-06-08:
I do not get any errors from roslaunch. Apparently the nodes get disconnected from master, since #rosnode list does not list, but the their processes are still there. Surprisingly killing the roslaunch process in the base machine kills them in the remote ones!

Comment by chcorbato on 2011-06-08:
I do not get any errors from roslaunch. Apparently the nodes start up, but then die immediately afterwards. When I do # rosnode list, they are not there. I know they start because one communicates with my robot, and I get the initialization beeps.

Comment by Martin Günther on 2011-06-08:
Can you post the error messages you get from roslaunch?


1 Answer 1


Rosanswers logo

Looks like it is an issue with the upgrades in the lucid packages last June 6. I managed to reinstall my ROS installation from the packages in my /var/cache/apt directory and now roslaunch is back working as expected

Originally posted by chcorbato with karma: 202 on 2011-06-09

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.