Using Docker containers would be one way (as it is able to isolate processes and network traffic).
If you don't want to / can't use that, you could use roslaunch's -p
argument to tell it to start a separate roscore
on a specific port. It will then use that specific roscore
for all the nodes it starts. You'd assign each user a different port which would result in the node graphs tied to that roscore
to be isolated from each other.
The -p
argument also automatically updates the port in the ROS_MASTER_URI
for that roslaunch
session. I'd probably still recommend setting ROS_MASTER_URI
manually though, as the ROS_MASTER_URI
in the environment of the current shell is not changed, only the value passed to processes started by roslaunch
, so rosrun
, rostopic
et al. and directly run node binaries/scripts would still use the default value if you don't change it.
Note: regardless of how you approach this (docker, separate roscore
) there is no protection or authentication, nor access control. All it takes for one user to be able to access (and interfere with) the node graph of another is for them to set their ROS_MASTER_URI
to point to another roscore
instance and "they're in".
If that's a concern (or the UX of Docker, or the UX of having to maintain separate roscore
s), perhaps virtual machines could offer a solution. Give each user their own VM. That would isolate them completely.
Edit:
For docker solution (very new in this): If I have 5 users, it means to pull 5 docker stations, and run them by users right?
I'm not sure I understand what you mean by this. You'd create (at least) 5 containers, which might also be started from 5 different images, but that would depend on what your users want/need to run.
Note that Docker will require some training, and is probably not suited for users with little experience with terminals or Linux process management.
I've looked at docker stuff regarding ROS, and I've had a little trouble connecting two terminals (one for starting ROSCORE, the other one for ROSRUN).
I would probably suggest to start a container and then run ROS-related commands inside that session. You could either use screen
or tmux
to multiplex a single bash
session, or use docker exec
to start additional bash
sessions. That would keep all network traffic inside the container.
B This solution will allow building packages without making a mess is a user makes a mistake?
Again, not sure what you mean by this.
I assumed all users would be actual Linux users with their own $HOME
and thus also their own Catkin workspace. I'm not sure how they would interfere with each other in that case.
Which solution will use less resources from the server?
There might be a slight overhead caused by Docker's networking infrastructure, but I'd be surprised if that influences performance very much. Unless ... (more)