I’m bringing up a new system on which I’d like to use Ubuntu 16.04. I’m noticing that some of the ROS packages I’d like to use are stuck on Indigo.
How are people dealing with this mismatch? Docker? Source builds?
1 Like
I’ve had a lot of success running things in Docker. There’s very little overhead, and if I remember correctly, that’s how OSRF tests all of their packages. I’ve also used it to cobble systems together in the past. For example, I had two packages with different ubuntu requirements, so I ran one in Docker, and one natively. I was able to establish communication as well as perform the high framerate calculations needed in Docker.
As a maintainer of several device driver packages that have not yet been released to Kinetic, I suggest the following:
- Open a github issue requesting a Kinetic release (unless there already is one).
- Try checking out the source and building it yourself. Whether that works or not, report your results in the relevant github issue.
I find it helpful to know when people actually need a new release (most people are not yet using Kinetic). Having someone test it for me, saves me time, making it quicker and easier to get a new release out.
4 Likes
With docker I’m reading about a philosophy of one process per container. Not everyone agrees. Does anyone know the real reason for this and whether that reason applies to a ROS node network?
It’s certainly in the main best practices guide
Run only one process per container
In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. If that service depends on another service, make use of container linking.
However as you start reading a little bit deeper it gets nuanced about making it more like one entry point with recommendations to use supervisord
Traditionally a Docker container runs a single process when it is launched, for example an Apache daemon or a SSH server daemon. Often though you want to run more than one process in a container. There are a number of ways you can achieve this ranging from using a simple Bash script as the value of your container’s CMD instruction to installing a process management tool.
This evolves into a discussion of role-based virtual machiens But as the article that links to, decoupling some services comes at a cost
There are other competing container based systems that have less of a axiomatic approach to what you run in the container such as LXD
The ephemeral microservice approach can map relatively well to ROS nodes since they’re mostly stateless. It would be interesting to explore making a roslaunch like functionality that could launch nodes from one of the standard containers published on dockerhub.
2 Likes
When you start a container with Docker, you normally specify a process to live the life cycle of that container, this is pid 1. There are dangers if you go and decide to run more than one process per container, such as children processes being terminated uncleanly by the kernel. But there are ways around this, and perhaps this will improver nativly in Docker (or perhaps it has, and I haven’t caught up yet); see some friendly reading material from a little more than a year ago: Docker and the PID 1 zombie reaping problem
As long as you take precautions, I don’t think there is anything technically limiting running more that one node per container, just more or less philosophical, like would you prefer your system architecture to center around “micro services” or more like a mainframe.
For ROS and for now, I think it’s mostly up to the user, e.g. should I stick to one container so I can simply stick to one roslaunch file/process, or am I have an issue with a flaky camera driver and so I’d prefer to keep it to its own container so that I may tinker with the underlying image and not have to restart the whole robot. Although, like @tfoote mentioned, it would certainly be nice to better integrate roslaunche’s functionality with Docker.
2 Likes
The zombie reaping article is really interesting. Seems like the fix is easy and given number of mixed experience users ros has it seems like a good idea to include that in the ros images.
That helps me understand. Thanks.
Heh, exactly what I tell people about ROS, YARP, etc…
There are numerous such projects that come and go:
I’m hesitant to commit to any one implementation, although it may be useful to at least create a new sub tag under OSRF’s unofficial ros repo that extends such features an example for users to follow. Perhaps we could spin off a new thread and ask about other ROS users experience and success with such tools.
1 Like
Thanks for pointing this out. It lead me to dig and learn about the underlying kernel technology and take a look at who is using it and how. I have some more testing to do but I think I’m going to prefer systemd-nspawn to docker.