ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Is there a best practice for setting up ROS development env?

Hi, community,

I’m recently trying to contribute to the ROS2 core packages and yesterday I just broke my own development environment(a virtualbox with ubuntu&eloquent installed), it pushes me to think about how to build a flexible and solid environment for my ROS development.

For now, I use a ros:eloquent-ros-core Docker image to setup a basic ROS env with some essential development tools installed, then run the image with a -v option to mount my local ROS project into the container, then develop & validate everything inside the container, so all my changes are saved to the host machine even the docker container dies.

It works fine for now, but I’m just wondering if there is a best practice for daily ROS development, or how would you develop ROS project in daily work? Would like to hear from you guys :grinning:

2 Likes

@crystaldust

I do the same. bind the develop environment into container (container is build and runtime env). That works for me not only for ROS development but also other development usually. I also would like to know if there would be a better way to proceed.

Yes, it’s a pretty general way!

It just occurs to me that, I can also edit the ROS project with a powerful IDE like PyCharm and then run the changes inside container, so it is possible to develop an IDE plugin to send some commands to the container if we click the IDE’s “Run” button, making the whole development looks like local.

I personally use emacs only, but sometimes vscode. Just FYI, there is a vscode extension for ROS, https://marketplace.visualstudio.com/items?itemName=ms-iot.vscode-ros. I am not sure if they are going to support ROS2.

According to their announcement here they do.

2 Likes

If what you’re looking for is a base docker image with the ROS 2 development tools in it but no ROS 2 packages installed, you may be interested in the osrf/ros2:devel docker image (dockerhub and dockerfile).
It is rebuilt on a daily basis and is built for that purpose.

If is used as a base to build ROS 2 workspace from source, an example is available at: https://github.com/osrf/docker_images/blob/master/ros2/source/source/Dockerfile
Or a more advanced example: https://github.com/ros-planning/navigation2/blob/dafcffa75ba7a1a5e1b1bdd86c80454ba11d2447/tools/source.Dockerfile#L17

A time-saving alternative if you build on top of the ROS 2 core packages is to use the osrf/ros2:nightly image.
This provides a nightly build of all ros2.repos and allows you to build overlays

1 Like

@marguedas

osrf/ros2:devel is useful for me, i actually set up the environment by myself. thanks.

Thanks @marguedas that’s helpful! I’ll take a look at the images and see which suit me best

You should look into ADE. It should make this even easier! The first part of the Autoware course that is currently running touches on ADE a bit I think: Course: Self-Driving Cars with ROS 2 and Autoware.Auto

For completeness, we have a blog post about ROS development with LXC.
The workflow is pretty similar, create a container from an Ubuntu image, install ROS, mount a local workspace and (optionally) enable SSH to the container and running graphical applications (e.g. Rviz, Gazebo).

1 Like

For running docker images, rocker can make it easier to mount through your home directory, set user ids to match your host system, support gpus like nvidia and intel’s integrated, as well as pulse audio if you want.

1 Like

Just to make sure it gets mentioned: Singularity could be interesting here as well.

The things @tfoote describes as being enabled by rocker (nice tool btw) are out-of-the-box supported by Singularity.

No special tricks needed to access $HOME, devices, GPUs, network, etc, etc.

I’ve been using Singularity lately, and it’s great. I create a Singularity sandbox in the root of each ROS workspace (kinetic_ws, melodic_ws, …) and use a --fakeroot shell to update or install packages in the sandbox, or use a normal singularity shell to build and test the workspace.