Ask Your Question
0

Is there a reason rosout might be started more than once?

asked 2012-12-12 07:47:56 -0500

updated 2012-12-12 08:03:22 -0500

I have a setup where I start a bunch of ROS related stuf on startup. I've been careful to put sleeps between roslaunch calls, but for some reason rosout keeps getting started more than once and its wreaking havoc on message connections at certain high traffic moments.

Context:

  • ROS electric by necessity
  • I start a bunch of nodes via separate roslaunch calls in separate gnuscreen sessions from an sysvinit script
    • All processes started as root
  • sleep 1 is used between roslaunch calls
  • I do not start roscore separately but rather rely on roslaunch to start it (though I have tried that in hopes that it would prevent the situation)

The symptoms are:

  • Ps reports two copies of rosout
    • One is started by roscore itself at the top level (no parent process)
    • The other is started by roslaunch which intern is a top level process.
  • Nodes have many many connections to rosout (sometimes hundreds!)
  • continual ps grepping for rosout shows that the processes are both being created and destroyed constantly.
  • At high traffic moments, certain messages just fail to arrive (reproducable, reason inferred)

TL;DR:

  • Is there any known way to accidentally startup up to roscores and have them fight for dominance?
  • Is there any known way to avoid this?
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2012-12-12 09:16:08 -0500

It turns out I had another script hiding in gnome config that my predecessor setup up. It was running another roscore.

Still not sure why they fought with each other, seems like one should just die, and the other should stay up.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2012-12-12 07:47:56 -0500

Seen: 115 times

Last updated: Dec 12 '12