1.3.4. How to debug AS ROS

An important step during development is obviously debugging the written Code. This section will show you, how you can debug inside the docker container and especially how to debug ROS Nodes, so you do not have to use print statements to make your debugging more efficient.

1.3.4.1. How to debug within the docker container

First off, it is assumed that you installed the docker container as described in Our Docker Environment Explained and VSCode as described in Connect to an AS ROS container with VSCode.

Now all you have to do, to debug any standalone python script, is the following:

  1. Click on the debugging icon in the left sidebar (play button with a bug).

  2. Choose the debug option from the dropdown menu on the top you want to use.

    There are different options, e.g. just debugging the current python file, a specific python file or a ROS Node. We will come to the latter later on.

    If you choose debugging the current python file, you will have to open the according python file to debug it. If you choose a specific python file from the dropdown, you can start the debugging from anywhere. Thus it might be worth it, to add the specific python file to the options. We will come to that in the next subsection.

  3. Start the debugging via the play button next to the dropdown or by pressing F5.

  4. You can add breakpoints by clicking left to the line number in any source file. This will be visualized as red circle left to the line number.

  5. You can pause, resume, step over, step out and stop the debugging session with the small control bar which will stick any where below the file tabs.

1.3.4.2. How to debug ROS Nodes

First off, it is assumed that you installed the docker container as described in Our Docker Environment Explained and VSCode as described in Connect to an AS ROS container with VSCode.

There are two different scenarios that will be explained:

  1. You want to debug a module of the pipeline while the pipeline runs (in a simulation)

  2. You want to debug a module (probably the can_interface, mission_machine or inspection mission)

1.3.4.2.1. Debug a ROS node in a simulation

Essentially, the procedure is very similar to How to debug within the docker container, but you will need to (or at least should) start other necessary ros nodes separately.

Todo

Add good documentation how to simulate the pipeline

Thus before following the instructions from How to debug within the docker container start a simulation as described in …, but exclude the modules you want to debug and start the debugging separately.

  1. Start the simulation and exclude the modules to be debugged (…).

  2. Start the debugging session for the ROS Nodes. (How to debug within the docker container)

  3. After the simulation finished or you want to stop or restart the debugging session:

    1. Cancel the simulation (Ctrl + C)

    2. Cancel the debugging session (red square in the small control bar)

Note

It is not possible/feasible to simultaneously debug and profile a ROS node.

1.3.4.2.2. Debug a ROS Node in a live environment

The idea here is to rather attach to a running node instead of starting it.

  1. Therefore choose the entry ROS: Attach to Python Node or C/C++: Attach to Python Node from the debug option dropdown.

  2. Start the debugging session

  3. Unattach from the process by clicking on the red button in the small control bar.

Todo

C/C++ remains untested. Please test and correct documentation.

Note

To debug a C++ executable, please make sure the binary is built with debug symbols (e.g. -DCMAKE_BUILD_TYPE=RelWithDebInfo, read more about CMAKE_BUILD_TYPE here).

Note

To use VS Code’s C++ extension with MSVC on Windows, please make sure the VS Code instance is launched from a Visual Studio command prompt.

1.3.4.3. How to add debug options to the debug dropdown menu

  1. Open the debugging menu in the sidebar.

  2. Clock on the Settings icon on the top next to the debugging dropdown menu.

  3. Use the Add Configuration button on the lower right to add another debugging configuration to the launch.json.

    Please orientate at the existing configurations for name and other configurations.