1.3. Development Environment

This section will describe everything around the development environment, among other things:

• How to set it up

• How to use it

• How to debug with and without ROS

• Why you should always use the docker container

• How to use the CI pipeline

Let’s start with the most important question:

Contents:

• 1.3.1. Our Docker Environment Explained
  • 1.3.1.1. Docker tools and files in AS ROS
  • 1.3.1.2. Setting up environment to run a docker container
  • 1.3.1.3. Build a AS ROS docker image
  • 1.3.1.4. Run a AS ROS docker image
  • 1.3.1.5. Work with docker containers
  • 1.3.1.6. Work with an AS ROS container
• 1.3.2. Visual Studio Code as standardized IDE
  • 1.3.2.1. Installation
  • 1.3.2.2. Configuration
  • 1.3.2.3. Connect to an AS ROS container with VSCode
• 1.3.3. How to write Docs
  • 1.3.3.1. How to add a new ros package to the docs?
  • 1.3.3.2. How to write Docs generelly (e.g. this page)?
  • 1.3.3.3. How to add a custom page to a automatically documented python package
  • 1.3.3.4. How to update the Docs?
• 1.3.4. How to debug AS ROS
  • 1.3.4.1. How to debug within the docker container
  • 1.3.4.2. How to debug ROS Nodes
  • 1.3.4.3. How to add debug options to the debug dropdown menu
• 1.3.5. How to profile your Code
  • 1.3.5.1. How to profile Python scripts
  • 1.3.5.2. How to profile C/C++ programs
  • 1.3.5.3. How to profile ROS Nodes
  • 1.3.5.4. How to analyze profiling
• 1.3.6. How to use the CI Pipeline
  • 1.3.6.1. How to setup a project gitlab runner

1.3.7. Why you should always use a docker container!

First, why do we even use a docker container?

That’s rather simple. We developed on a lot of different systems and still want that the code runs on all machines and especially on the ACU without the need to always install all dependencies on the host system and the need to wonder why it works on his PC but not in mine. One suitable solution is to use docker containers. Another advantage is, that one can simple rebuild or rerun the docker container when something stops working instead of needing to reinstall every dependency.

Yeah okay, then let’s use a docker container on the ACU and run everything on my own host system.

That’s a “neat” idea, but how do you then know, whether the docker image still works?

Yeah okay, then I will develop everything on my own host system, subsequently test it inside the docker container.

That could in fact work, but it is still not recommended and most importantly not supported.

The repository and the development environment is aimed on using Visual Studio Code as IDE and the docker container as development environment. This setup is tested and described, everything else you might do, but there is no support and especially no guarantee that it will work.

This decision hasn’t been decided lightly. Most of the things just works way easier if you develop and run it inside the docker container. Atleast if you do it correctly. To ensure this, this documentation exists.