# Why does ROS use environment variables instead of function parameters to set ROS_MASTER_URI and ROS_ IP？

The use of environment variable limits that all nodes in a process can only specify one ROS master and one IP to publish topics. Why not use function parameters ? Something like,

ros::nodehandle n; n.setMasterUri("10.1.1.10"); n.setIP("10.1.1.11");

In this way, we can use multiple nodes with different maser-uris or IPs in a single app.

edit retag close merge delete

There is no convenient way to use ROS to communicate across network segments for devices with dual network cards

could you perhaps tell us whether this is the real problem you're trying to solve?

( 2020-11-12 01:59:03 -0500 )edit

Yes. I know that there are many ways of inter-process communication to solve this problem, but I am still curious why ros is designed in this way to restrict users.

( 2020-11-12 02:39:47 -0500 )edit

I don't understand your last comment.

( 2020-11-12 02:41:48 -0500 )edit

^^Sorry for my pool english. Maybe ros1 was designed without considering the situation of cross network segments. Thank you for your patient reply.

( 2020-11-12 03:03:54 -0500 )edit

Sort by » oldest newest most voted

The use of environment variable limits that all nodes in a process can only specify one ROS master and one IP to publish topics

ROS 1 doesn't support multiple nodes in a single process by design. Using environment variables doesn't seem like a big limitation in that case (each process has its own environment).

ROS 2 doesn't use ROS_MASTER_URI, ROS_IP nor ROS_HOSTNAME.

Edit: if this is solely about ROS 1, my best answer would be: environment variables are used, as the assumption was/is that a) there is only a single master per ROS application and b) networking hw is sufficiently performant for the type of application.

But I wasn't there when these design decisions were made, so this is extrapolation based ony my understanding of how ROS 1 works.

Having written that: environment variables make two things possible:

1. they act as global variables,which means the same values can be used by multiple/all processes, which makes it easy to configure the same settings for multiple/all nodes
2. they still allow per-process overrides by updating the environment of individual processes before starting them

If you look at how environment variables are used in ROS 1, it could also be that the original developers wanted to avoid having to configure ROS itself (ie: the plumbing) using configuration files. There is almost no use of files to configure ROS itself, only environment variables (an exception is rosconsole, which takes a URL to a configuration file, but that is essentially a wrapper around log4cxx).

Parameters on the ROS parameter server are typically only for use by nodes, not the main infrastructure.

This would make sense, as before being able to use the parameter server, ROS would already need to be (at least partially) initialised. For consistency it would make sense then to avoid using the parameter server completely (otherwise you'd end up in a situation where some configuration comes from environment variables, or files, and other parts of the configuration come from the parameter server).

more

There is no convenient way to use ROS to communicate across network segments for devices with dual network cards. It would be much easier If we can specify different ROS_MASTER_URI and ROS_IP when initializing ros::NodeHandle.

( 2020-11-12 01:48:11 -0500 )edit

This seems like a different question/observation almost.

Seeing as you mention ROS_MASTER_URI and ROS_IP again, I assume you're talking about ROS 1?

Each process gets its own environment variables. Afaik there is no requirement to configure a single, global value for these.

Note also:

It would be much easier If we can specify different ROS_MASTER_URI and ROS_IP when initializing ros::NodeHandle.

NodeHandle != node in ROS 1. ros::start(..) creates a node. You can 'only' call ros::start(..) once in a process (in quotes, as theoretically you may be able to call it more than once). So there would be no way to use a different master nor set a different ROS_IP per NodeHandle, even if those were arguments of the NodeHandle constructor.

( 2020-11-12 01:53:28 -0500 )edit