# Local parameters from a remote launch file

I'm working on writing a ROS node that publishes network statistics as each machine sees them; that is, each node maintains its own directed graph of what it thinks the network is like (latency, reliability, etc.) from the local machine's point of view. I've got most of what I need written, but I'm running into one problem: the naming of the nodes. If I make them anonymous, I'm not sure if the machines can discover each other. If I try to use substitution arguments as shown at http://www.ros.org/wiki/roslaunch/XML, then the arguments that get substituted in are the ones discovered on the machine that runs roslaunch. How do I write a roslaunch file that launches remote machines with parameters that are local to that machine?

edit retag close merge delete

I don't clearly understand your use case. Could you say more about what you need?
( 2011-11-01 04:31:28 -0500 )edit
That's because I didn't understand how ROS works well enough; turns out you can only have one Master at a time. Fortunately, Willow Garage is working on it; see http://www.ros.org/wiki/Projects/Building%20Manager/Overview
( 2011-11-02 00:56:54 -0500 )edit

Sort by » oldest newest most voted

Well, after poking around some more, I've learned the following:

• I asked the wrong question.
• ROS can't quite do what I want.

Basically, my assumption was that each robot ran its own Master, with all nodes on that robot answering to that Master. Masters on different robots would peer with one another across a weakly connected interface. That assumption is why so many people are confused by my question. So, here is the complete background on what I'm doing, so everyone can follow along:

I have a group of robots that are communicating over a lossy, multi-hop wireless mesh network. If you want to command a robot to do something, there must be a route to it through the network graph that is good enough (low enough latency, high enough throughput, etc.) for you to communicate. To guarantee this, I want robots that are not currently being teleoperated to autonomously move to locations that will improve network connectivity. This means that each robot needs to gather and maintain information about what the network looks like independent of any other robot (so that if network partition occurs, robots can still try to do something reasonable). As long as there is a network, the robots need to reach consensus on what the network is like, along with a host of other information. To do that, robot A needs to know what robot B's view of the network is like, and vice-versa; using ROS, that would mean I would have my topics/namespaces organized like /A/networkStatus and /B/networkStatus (or some other, similar hierarchy).

But for all of this to work, each robot needs to have its own name. That means that I want the robots to look up their own name in their own parameter server, or their own environment, or whatever. I thought I could do that via a roslaunch file, but now that I know how ROS works a bit better, I now know that the only thing I can really do is setup a bash script to kick-off all the robots remotely. This isn't ideal, but it works, so I'm not going to worry too much about it. Thanks for all the suggestions from everyone!

more

Have you tried defining an <env> tag within a <machine> tag?

more

I looked into that, but unless I'm reading the documentation wrong, won't roslaunch still read the environment of the machine its launched off of, rather than the local machine?
( 2011-11-02 00:57:50 -0500 )edit

If you've having trouble doing it within ROS launch scripts, there's always bash (e.g., in a shell script, ssh in to remote machine and run roslaunch). Less elegant surely, but more flexible (as long as you're on a linux box).

Also, namespaces can help (/machine/somenode).

Finally, the launch-prefix tag in <node> can, in a limited way, bridge between bash and ROS launch (e.g., use xterm or ssh as a launch-prefix).

more

I'm probably just going to write up a bash script to do all this. The trick is coming up with multi-master support until Willow Garage adds multi-master support (see http://www.ros.org/wiki/Projects/Building Manager/Overview)
( 2011-11-02 01:06:48 -0500 )edit

I'm a little surprised about your mentioning needing to "discover" the other machines. Which may be related to this thread.

This is a bit of speculation, from my interpretation of your question I would do the following.

I would launch n nodes (anonymously if desired) on each machine. They would each publish on the same topic, not in their private namespace. And you could set the hostname parameter for each one in the launch file, or use the node to introspect the hostname in the code, and embed the hostname into the data.

more

It turns out that I misunderstood how ROS works; I assumed that each robot ran its own Master, and that the robots discovered each other on the fly. It turns out that what I want is a [multi-master](http://www.ros.org/wiki/Projects/Building Manager/Overview) setup.
( 2011-11-02 01:16:33 -0500 )edit

AFAIK, joq's answer is the main approach if you wanted to separate machine-specific information out w/o having to change the <node> tag.

There are multiple ways of solving this problem that go a bit out of the original problem statement. It seems that you just want the nodes to know what the different machines are. This could easily be done by storing a data structure of all the machines on the Parameter Server, and having the nodes all read that same data structure (presumably they could recognize themselves). If you need to know the node names, the nodes could register their own name on the Parameter Server is a pre-assigned namespace, so that could be used to find each other.

Basically, I don't understand the need to launch with parameter specific to the remote machine. The remote machine knows where it is, so the information that all the nodes need is the same -- data about the full list of machines that they should monitor.

more

It turns out I didn't understand how ROS works well enough; I thought it was possible to have a master on each robot, and have them peer with one another. Right now, I don't think that is possible, but Willow Garage is working on it; see comments above for the link.
( 2011-11-02 01:05:21 -0500 )edit