Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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.

ROS 2 doesn't use ROS_MASTER_URI nor ROS_IP.

Could you clarify your question?

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.

ROS 2 doesn't use ROS_MASTER_URI nor ROS_IP.

Could you clarify your question?

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.case (each process has its own environment).

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

Could you clarify your question?


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.

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.

Could you clarify your question?


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.

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).

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.

Could you clarify your question?


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).