The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
The way I use Clion and Qt Creator for c++ projects in ros2 is by first building my overlay workspace via --symlink-install using colcon, then opening a new shell to source install space for the newly built workspace and then launch Clion or Qt Creator via that shell environment and pointing it to the CMakeLists.txt for the particular package I'd like to work on. I then also change the cmake build directory under the setting menu to point to the same build/<package_name> directory that colcon stores the build artifacts, such that colcon and the IDE share the same build cache, and that the symlinks in the install folder point to the same binaries that my IDE builds. This also helps when using orchestration tools to run your nodes like ros2 launch or ros2 run.
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000164204-How-to-specify-build-directory-?page=1#community_comment_360000120690
https://doc.qt.io/qtcreator/creator-build-settings.html
This allows me the use of code completion and introspection as normal without having to patch any Cmake files. You can also open multiple Cmake projects if the IDE supports this, although Clion only starts one process, so the first shell you launch the Clion from will dictate the environment variables that process will inherit, making it tricky to work on packages from non-overlaping workspaces simultaneously.
This same approach of launching IDEs from a workspace sourced shell works fine for me when using python and Pycharm or JupyterLab as well. Just be sure your IDE build/install artifacts coincide with the workspace, so that changes are appropriately reflected by other ros tools or overlay workspaces that may source the current one as an underlay workspace.
Pro-tip: if you run node your debugging via ros-launch, and it crashes, the traceback includes the command line arguments that roslaunch passed to node's executable, e.g. paths or all the temp yaml files that encode all the parameters and re-mapping logic ros launch does when resolving launch configurations. You could then just copy and paste those arguments to the appropriate setting field for the IDE that could then be passed to your executable when using the debugger under gdb.
This helps if the node is crashing before you get the chance to attach to the node's process, or when you'd rather not kill the rest of the launch file that may have other nodes like camera drivers or static tf publishers that you don't want to start manually. Just note that if you reboot or change the launch file per that node, you'll have to update the debug args in the IDE, given the previously temporarily yaml files may then be cleared or outdated.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
