10 comments

[ 3.5 ms ] story [ 29.5 ms ] thread
That's useful, in a way. ROS is a collection of several hundred academic software packages which share an interprocess messaging system. Installing ROS tends to cause package problems on Linux due to excessive version pinning.

So, add another level of indirection with Docker! Now ROS has its own versions of everything.

I just use ROS in a ubuntu VM. Installing/Maintaining ROS on Arch is a hell of a time
Debian/Ubuntu maintainer here; it sucks for us, too.
In my experience, using ROS outside of Docker is a mistake. Avoids all the usual headaches of software packaging, and with nvidia-docker I can use all the GUI tools (rviz, gazebo, etc) without a hitch.
How do you handle opening ports to a ROS publisher inside a Docker container, when you don't know the port numbers in advance?
The same way you handle pci and usb devices: unless you configure a root-owned devfs bind-mount, you don't.
At Elementary we're working on [atom](https://github.com/elementary-robotics/atom) which is a ROS-like OS for your robot in which each element (effectively a "node" from ROS) is docker containerized. Docs [here](https://atomdocs.io/) It also gives you more powerful serialization options on the wire (no serialization, msgpack and arrow currently supported) and has some nice data APIs due to using redis streams as a message brokering backend.

It's still pretty early and doesn't have nearly as many features or open-source packages but it's helped us be nimble and avoid a fair amount of the build/maintenance headaches.

Only at important times, such as tournaments and business talks, I couldn't debug ROS because my PC was out of order or the battery ran out. . . Isn't that so? In such a case, if at least rviz can be started using someone's PC, So, I made a script to create ROS LiveUSB using Docker and chroot.
At one point, ROS documentation touted its ablity to support multiple "ros_distros" on a single host. That developers are reduced to isolation via live USB is some pretty stark irony.
Recently I needed some ROS code for a four wheel steering controller. Someone has this really neat steering controller package that lets you define a wide variety of robots and interface them with ROS, and it does nice things like calculate the odom values for you.

But I ultimately found that setting up and running ROS was sort of more complex than I needed (I’m running on raspberry pi). I pulled the snippet of C++ from the steering controller that I needed and converted it to python. I use python multiprocessing to launch multiple python files as processes that run independently, and use multiprocessing pipes to communicate between the parent process and the sub processes.

I’ve got a whole pure python robot with RTK GPS, four wheel steering, a live server interface, and GPS path-following. It’s all working fine and I haven’t really needed ROS yet.

I feel like I never would have learned how to build this software if I hadn’t learned ROS first though. ROS shows you how all the pieces fit together, and after learning that I started to see how to build it from scratch. For simple applications in resource constrained environments there may be times where building it from scratch is easier. I sure am glad that ROS code and steering controller were there for me to borrow from though!

EDIT: The USB package in TFA looks nice. It’s tricky to run ROS on anything but the exact distro they recommend and this seems to be a useful tool for getting it running quickly without messing with your system.