[Feature/Experiment]: Proper VsCode debugging

[Zelberor]

Description

As already discussed in the Discord help channel, there currently seems to be no proper way to debug ros nodes.
It is only possible to watch the ros console output or use rosrun <package> <node> in the build-agent container to watch its python console.

But proper debugging support inside VsCode with breakpoints and data insight would probably speed up development times significantly.

I propose a solution/experiment:

VsCode supports attaching to an external debugging server: debugpy
This debugger can be attached to an already running python executable in two ways:

• attach the debugger to a process via its pid
• (preferred) import it inside the python file to debug. This also allows for waiting until VsCode is attached

The solution might be to create a ros debug wrapper node:

• that has two parameters: the ros python node to run and the network port the debugger should run on
• starts a debugpy debugger on the given port
• imports and runs the actual python node/module with importlib.import_module()
• the debug_wrapper.py replaces the type field for the node the developer wants to debug (inside the *.launch configuration).
• the original type of the node has to be added as parameter inside the launch configuration

VsCode can then connect to this debugger on the specified port. (Dockerfiles have to be adjusted to export a range of ports for debugging)

Definition of Done

• Proper debugging works within VsCode (and is reasonably easy to use)
• The containers have been adjusted to expose debugging ports and the debugging dependencies have been installed
• An easy-to-use default VsCode debug configuration has been added

or

• Issue closed without solution, because no solution was feasible or easy to use

[vinzenzm]

There is currently a way to get the messages sent out by loginfo/logwarn etc.
If you attach a vscode window to built-agent (not dev) and open the folder /home/USERNAME/.ros/log/latest you will find log files which are updating while the system is running.
Of course this is not the most simple and convenient method but could help anyone facing the issue mentioned above.

Also, could you elaborate more on the first part of the following sentence:
"It is only possible to watch the ros console output or use rosrun in the build-agent container to watch its python console."
Are you able to get the ros console without attaching the shell and launching the node separately?

[Zelberor]

Yes, I meant debugging is (as far as I can tell) currently only possible by watching log messages, but not with the "proper" python debugger inside VsCode.

By watching the ros console I meant viewing the log messages from loginfo/logwarn etc.
There seem to be several ways to access them:

• logfile in the build-agent container, as you mentioned
• execute rosconsole echo in a shell attached to the build-agent. This only shows new incoming log messages
• use the console plugin in rqt (rqt opens when the leaderboard is started). This even allows filtering for debug levels and message content.

Relating to rosrun <package> <node>: When the node throws an exception while initializing (before rospy.init_node), these exceptions seem not to be logged into the ros console. The node then just does not show up on the node graph and the developer is left wondering what happened. In this case, running the node directly from the build-agent can be used to view the exception error message.

---

While logging can be used for debugging, I think it is pretty cumbersome / time intensive. Log messages have to be specifically added and the leaderboard restarted (can take a few minutes). If these messages get sent from a hot loop, they "spam" the log and have to be removed after debugging.

This is why I think that proper debugging support would be a significant quality-of-life improvement.

For clarification, the new workflow would be:

• Edit the *.launch config to use the debug_wrapper for the node and add the required parameters
• Launch the leaderboard
• Connect VsCode to the specified port and debug: set breakpoints in the callbacks and view variables

I will bring this topic up in the coming meeting where the team can discuss if it is worthwhile to be added.