'Invisible' nodes (invisible to rosnode, but seemingly working)
Hi, I'm new in the forum. I'm writing to explain to you about my problem. In my application (an atonomous indoor vehicle) we have ROS with a set of nodes for mapping and a set of nodes for navigation. I tested these nodes many times and all of the nodes work good.
Now I bought a new computer (intel NUC) and I installed all the tested repository on it and when I launch the Mapping nodes they crash (?). In this particular case, I run the gmapping node and it appears to run correctly (I can see the terminal where it is running and updates frames), but if I want to see the NODELIST (rosnode list) it is not in the list (also the other nodes ar not in the list, only /rosout).
So, I check in the running process list (command top in the linux terminal) and the "crashed" nodes are in the top process list, but I cannot comunicate with them.
ROSDISTRO: Melodic LINUXDISTRO: Ubuntu 18.04 LTS
PS I'd want to load some screenshot, but I'm a forum newbie :(
Edit: thank you for the answer.
have you copied any configuration files from your old PC?
No, I get the entire repository from my git with the standard procedure (git clone URL)
Do none of your nodes respond?
I'm sure that all the nodes launched for mapping are not present in the rosnode list (Slam_gmapping, Odometry_node, TCPserver_node, Static_tf_publisher ecc.), but only /rosout is present in the list.
are you running rosnode on the NUC, or from a remote one?
I use NUC trought teamviewer but all the ROS environment is running on the NUC
Do the nodes respond to rosservice call .. invocations?
I don't know, because I don't have the NUC until Monday
Is dynamic_reconfigure still working?
I don't know. I don't check for dynamic_reconfigure node comunication.
Did you rebuild everything in a fresh workspace, or did you copy your old workspace to the NUC?
I recreated a new catkin_ws from zero and I rebuilt all
so they are not crashed then? The processes are still there?
what specifically would you want to show in a screenshot? If it's terminal text, please just copy-paste it into your question.
I don't know the specify definition of "crashed node" but the mean is the following: if I run "rosnode list" the node list is empty, contrariwise if I run top I can see the running process in the process list but I cannot comunicate with these nodes (no topic are available).
No problem for the screenshot, they are terminal where you can see the empty rosnode list and the top command result
since a node is just a regular program using the ROS middleware to communicate, the definition of a 'crashed node' would be similar (if not identical) to that of a crashed program: process terminated in an unexpected way. If the processes are still there, they have not crashed.
As to your problem: have you copied any configuration files from your old PC? Do none of your nodes respond? Or only specific ones? are you running
rosnodeon the NUC, or from a remote one? Do the nodes respond torosservice call ..invocations? Isdynamic_reconfigurestill working?And how did you "install[ed] all the tested repository" specifically? Did you rebuild everything in a fresh workspace, or did you copy your old workspace to the NUC?
this question was not about ROS packages, but about files in your
$HOMEdirectory. For instance: did you copy your.bashrcor copy lines from it to your old PC to your NUC?No, I didn' copied any config file from my old PC. I re-installed Ubuntu, I created a new catkin_ws, I clone my git repository, I rebuilt all the repository (and installed necessary dependeces). I wrote a line in the .bashrc (source ~/catkin_ws/devel/setup.bash). If you want, I can give you the entire procedure that I followed for NUC installation (from ubuntu to ROS compiling).
It sounds like your nodes are using a different roscore than your command line tools. Do you have a custom setting for the ROS_MASTER_URI when you start your mapping nodes?
@ahendrix: your question is where I was indeed also going to go after making sure nothing was copied from the original machine (was trying to rule out incorrect settings for either
ROS_IP,ROS_HOSTNAMEand/orROS_MASTER_URI).