ROS, Docker, and CLion for flexible local & full-remote Robotics Software Development
How can you make your ROS development environment setup system-independent and ready in no-time? Or even better: How can you do it on a powerful, remote host and retain all excellent features of your local IDE, including code completion, refactoring, and very importantly: debugging? This detailed tutorial will show you how to achieve all of that with Docker, CLion, and a few other tools. By the end of this tutorial, you will be able to use CLion to work with your local ROS workspace natively or in a custom Docker container. You will compile and run ROS nodes on that container, and attach a debugging session to a local or remote GDB server.
Tutorial Outline & Target Audience
This guide is outlined as follows: In the first section “Why a containerized ROS environment matters?” I provide the motivation and three use-cases why would you use a containerized Docker ROS environment. In the second section I specify the scope of today’s tutorial and distinguish it from other development configurations that include remote targets. The third and forth section discusses the meat of this tutorial – a step by step guide how to set up a local or full-remote development with the already described toolbox. Lastly, I discuss general limitations of this particular setup and potential Docker limitations for ROS. The closing remarks include a recommended list of references.
The target audience for this guide are the users who wish to locally or remotely develop ROS applications with CLion and Docker while retaining all the features of this powerful IDE, including local or remote debugging with GDB. There are already many useful tutorials provided for CLion that describe the process of remote C++ development without ROS or local CLion development with ROS, but none of the tutorial I have seen talks about a complete remote setup with ROS which takes into considerations actual debugging. Moreover, the direct Docker integration arrived only at the most recent CLion release, and to the best of my knowledge there are no tutorials supporting
there are no tutorials for using ROS in a direct
I focus here on CLion because it is free for academic and Open Source use, and it offers excellent refactoring and code suggestions capabilities. For these reasons, CLion is a preferable choice to me when compared with VSCode (which is also very powerful!). If you are a VSCode user, you might benefit from a very good talk describing VSCode & Docker setup.
Now you can proceed with reading the introduction, or go straight to the main tutorial. Let’s get started!
(I or we?)The outline
Why a containerized ROS environment matters?
We first need to discuss the general purpose of virtualization before focusing on the remote development environment setup. Containers are packages of software that include all the libraries, dependencies and source code to run an application on its own, and they use virtualization on a system level to achieve that. Building your robotics application in containers enables a way to deploy ROS environment configurations that is scallable, flexible, and avoids a “dependency hell”, is scalable, and highly flexible. (order?). These qualities can be used for both prototyping and production. In this guide we will rely on Docker containers, that are one of many available containerization solutions, yet very popular for robotics. For starters: Docker is an excellent system-level virtualization software platform that achieves a near-zero performance cost for a user. Today it is de-facto a standard component in the modern Continuous Integration pipeline tools that the ROS ecosystem uses [industrial_ci] Docker and its has been promoted in the ROS community as early as 2015 [ROSCon talk] with the goal to automate and mange ROS-based applications better. Docker vast popularity comes also from managing web application infrastructure including microservices orchestration.
Let’s start with a an example of prototyping a robotic system: you have a force sensor that relies on drivers compatible only with the outdated ROS Indigo distribution, while the rest of your system uses ROS Noetic distribution. You could achieve that by using two computers (each with its own ROS setup) connected in a single ROS network. However, this approach quickly becomes difficult to manage. A better way to do it is by building a ROS environment on a single machine with two Docker containers, one for each distribution. The ROS Indigo container with appropriate drivers will communicate with a force sensor. Meanwhile, the second container will run ROS Noetic, where the rest of your system resides. Both containers will be sharing a common ROS network, so that the sensor data streamed from ROS Indigo will be accessible to the rest of your ROS network. Please keep in mind that this approach is suitable for certain prototyping cases and might not be good for production environment, where an updated sensor driver for Noetic would be desired.
A second common use case is to use containerized ROS environment for Continuous Integration/Continous Delivery pipeline. In such scenario, your attempt to commit changes to a repository spawns a fresh Docker container to which your proposed version is copied. Your code is then compiled and several tests are run, and if succeeded, the commit is can be accepted. This is very useful when working with large code bases with multiple contributors. Since this is a huge topic by itself, I will cover it in a separate post. You can check this talk to learn more.
A third use case for Docker I have seen is showing the demos of simulated robotic application in a portable way by packaging them to docker containers and using VNC remote access technology to run them in a browser. One could question the performance of such solution, but it tends to be sufficient for basic demonstration and learning purposes. In fact, you can check out some containers with VNC capabilities that try to reproduce Udacity Robotics Software Engineer Nano degree challenges. Or else, you can preview my demo of a Docker container running a custom Docker image with VNC-capabilities vs. my another container without VNC but by sharing a X desktop session instead. Both containers run Adnan Munavar’s Asynchronous Multi Body Framework, (WPI AMBF) simulator.
A fourth use-case relevant to robotics include deployment of your containers in a High Performance Computing (HPC) cluster. This is advantageous because you can set up your container with all system dependencies locally and then build and run it in a cluster. A common non-ROS application would be to deploy a container for training Deep Learning networks. This container would have the access to GPU resources on the host. In such cases Docker would be replaced with other solutions feasible for HPC, such as Singularity, which offers better sand-boxing of your containers.
Limitations
Limitations
Docker builds sometimes break when packages are updated. Building packages from sources.
The container will be running on your local machine, so that you do not need to have two separate computers to follow the tutorial.
Why a containerized ROS environment matters?
ROS, Docker, and CLion for flexible Full-Remote
CLion is one of the best Integrated Development Environments for C++, and it is free for academia and open-source projects.
Resources
Docker Mastery by Bret Fisher – Excellent online course to learn how to build your own Docker containers