Ros deployment: docker + resin.io ?
I am looking for a way to deploy and maintain my ROS application on remote robots. Frameworks like resin.io seems designed for just that, relying on dockerized applications.
My ROS application would need to access hardware through serial ports and USB.
- Is it a in general a reasonable approach to run ROS in docker for ROS applications in production mode?
- Are the networking complaints mentioned here valid and unresolved?
- Will I be able to interact with the ros master (in docker) from ROS nodes on other machines?
Any advice is appreciated.
I think the terminology used in the OpenCog readme is a bit ambiguous: there are no "port numbers" in "ROS messages". Or at least, not at the user ROS API level. I believe they mean that nodes can open arbitrary TCP/UDP ports, and that those are registered with the master. Other nodes will ..
.. try to connect to those ports when subscribing to msgs. The random aspect obviously complicates things when working with Docker (but mostly in a distributed setting I would think), as it's impossible to configure which ports will be used by which nodes. But that is not a ROS limitation, ..
.. it's just how the TCP/IP stack works (unless you specifically request specific ports to be assigned, but that becomes a logistics problem soon with many nodes and potentially unlimited connections).
To work around that, you could configure the linux kernel to restrict the set of ..
.. ephemeral ports it will use. See #q9725, #q245273, #q12206 and #q268213 for previous questions about that.
After limiting that set, you should be able to use regular Docker configuration options to expose the required port ranges again. But if those get mapped to ports on the host ..
.. I expect you'll run into clashes there soon.
Another option is to give each container its own IP. This is fully supported by Docker. Masquerading will then not be used, and this simplifies things significantly. I do that here in the lab. I don't have experience with doing that with any ..
.. management frameworks though, or with distributed 'cloud' approaches for managing Docker containers.
In summary: I'm not aware of anyone working on the things described in the OpenCog readme, but I also don't believe things are as dire as they are made out to be by that readme. Especially ..
.. when running all containers on the same host (or even distributed), and giving each container its own IP essentially reduces the problem to a standard ROS multi-machine setup. Provided you have a working DNS, or set
ROS_IPproperly in all containers, things "should just work".Re-reading the OpenCogs readme - especially the last bits: I can sympathise with the frustration that the author might've felt, but I feel it's overly alarmist. The readme doesn't mention whether they've tried the non-masquerading option, but I don't believe they did. Unless I'm completely ..