ARTICLE DETAIL

资讯详情

深耕商务建站与企业官网运营的一线实战洞察。

ROS2与VSCode开发环境配置及一键调试实践指南

ROS2与VSCode开发环境配置及一键调试实践指南 ROS2 和 VSCode这两个词凑到一起凡是跟着“ROS2菜鸟教程”走过一遍的人都知道最大的坑往往不是机器人本身而是开发环境这一关。环境没配好后面写节点、跑launch、调参数全都是折磨。尤其是当你习惯了 VSCode 那一套“改完代码按 F5 就能看结果”的节奏再回到“命令行编译、手动 source、四处找日志”的状态落差感非常明显。这篇文章就围绕“ROS2 开发 VSCode 调试”这条完整链路来写从 Ubuntu 下 ROS2 的安装选型到 VSCode 里的 C/Python 环境配置再到 tasks、launch、调试配置的一键化。目标很直接让你在一台干净机器上从零配出一个能写代码、能编译、能一键启动、能打断点看变量的 ROS2 开发环境。适合刚入门 ROS2 的同学也适合已经会用命令行但不是太爽、想优化工作流的开发者。这篇内容不是我拍脑袋总结出来的是几台机器、几个发行版、无数次“command not found”之后沉淀下来的实操记录。下面直接进入正题。1. 环境选型与整体思路1.1 版本搭配不能乱来ROS2 对 Ubuntu 版本的绑定非常严格不同发行版对应不同的 Ubuntu装错了就是无尽的依赖地狱。目前最常见也最稳的搭配是 Ubuntu 22.04 配 ROS2 Humble还有一个老牌组合 Ubuntu 20.04 配 ROS2 Foxy。如果你拿的是新电脑别犹豫直接上 Ubuntu 22.04 Humble。如果你手头已经有 Ubuntu 20.04 的机器那就用 Foxy别强行升级系统去追新版本稳定压倒一切。这里要特别提醒一下ROS2 的安装方式有源码编译和二进制包安装两种。新手千万别碰源码编译除非你要定制底层 DDS 或者改核心代码。二进制包安装省时省力官方仓库里的包足够覆盖绝大多数开发需求。1.2 为什么推荐“VSCode 远程/本地”组合很多 ROS2 开发者习惯在 Ubuntu 里开发但日常办公又离不开 Windows/Mac这就引出了“远程开发”的需求。VSCode 的 Remote-SSH 插件可以让你在本地编辑器里写代码实际编译、运行、调试全在远端 Ubuntu 机器上完成体验非常接近本地开发文件传输、终端操作也都整合在同一个窗口里不用来回切。如果你就是直接在 Ubuntu 的图形环境下操作那更简单VSCode 直接装在 Ubuntu 里面就行和普通桌面软件没区别。后面讲的配置流程本地和远程基本通用差别只在于 VSCode 是否安装到远端。我自己实测下来Remote-SSH 方式对 ROS2 这种常驻 Ubuntu 环境的项目更友好因为你的构建目录、日志、依赖全在同一个系统里不会有 path 不一致的怪问题。1.3 配置工作的三条主线整个环境的搭建可以归纳成三条主线。第一条是系统级环境Ubuntu 系统本身、ROS2 基础包、编译工具链、Python 环境。这条线决定了“ros2 命令能不能用colcon build 能不能跑”。第二条是项目级配置你的 ROS2 工作区 src 目录、包的依赖关系、编译选项。第三条是编辑器与调试器配置VSCode 扩展、tasks.json、launch.json、c_cpp_properties.json 等。这三条线缺一不可很多人只做了第一条线就开始写代码结果 VSCode 里全是红色波浪线也不知道怎么加断点。理解了这个整体思路下面开始实际操作。2. ROS2 系统环境配置2.1 基础准备在装 ROS2 之前先把系统基础环境整干净。用 Ubuntu 22.04 的话先确保软件源更新正常并安装一些基本工具sudo apt update sudo apt install -y curl gnupg2 lsb-release software-properties-common然后设置 locale。ROS2 对 UTF-8 支持有要求尤其运行 Python 节点的时候locale 不对会出现奇怪的中文编码问题。推荐这样配置sudo apt install -y locales sudo locale-gen en_US en_US.UTF-8 sudo update-locale LC_ALLen_US.UTF-8 LANGen_US.UTF-8 export LANGen_US.UTF-8这里的 export 只对当前终端有效需要把它写进~/.bashrc里才会永久生效echo export LANGen_US.UTF-8 ~/.bashrc source ~/.bashrc2.2 添加 ROS2 软件源并安装核心包ROS2 官方软件包不在 Ubuntu 默认源里需要手动添加 ROS2 仓库。这里以 ROS2 Humble 为例sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null sudo apt update然后安装桌面版完整包包含 ROS2 核心、可视化工具 RViz2、演示例程等sudo apt install -y ros-humble-desktop如果你只想跑命令行节点不想要图形化工具可以装ros-humble-ros-base体积小很多。但做机器人开发基本离不开 RViz2所以我建议直接装 desktop 版省得后面缺这个缺那个。接着安装编译和依赖管理工具sudo apt install -y python3-colcon-common-extensions python3-rosdep python3-pip sudo rosdep init rosdep update注意rosdep init 如果提示“command not found”说明 python3-rosdep 没装成功重新执行上面的安装命令。如果提示 ROS 版本无法识别通常是环境变量没 source。2.3 环境变量配置ROS2 安装完成后每次打开终端都要先 source 才能使用命令。手动 source 容易忘建议直接写进~/.bashrcecho source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc然后验证一下ros2 --help如果能看到帮助信息说明系统环境基本搞定。再用官方自带的小乌龟例子做个验证ros2 run turtlesim turtlesim_node另开一个终端运行ros2 run turtlesim turtle_teleop_key能用键盘控制小乌龟移动说明 ROS2 的安装和通信机制都正常了。2.4 为什么很多人卡在“command not found”“ros2 command not found”是出现频率最高的问题。原因一般有三个没有执行 source /opt/ros/humble/setup.bash或者没写进 .bashrc装的是简化版并没有包含 ros2 核心命令当前 shell 是非交互式 shell.bashrc 没有被加载。前两种好理解第三种容易被忽略比如你在 VSCode 里配置 task 或脚本时经常遇到明明终端里能运行脚本里却报 ros2 找不到。解决办法是在需要的地方显式加一行source /opt/ros/humble/setup.bash不要依赖系统自动加载。尤其是在配置 VSCode task 的时候这一步必须写不然一键编译永远会失败。3. VSCode 安装与基础配置3.1 安装 VSCodeUbuntu 下装 VSCode 最简单的方式是去官网下载 .deb 包然后用命令安装sudo apt install -y ./code_*.deb也可以先把微软仓库加进 apt 源以后就能用 apt 升级。两种方式我都用过官网下 .deb 更直观适合一次性安装。如果不想折腾直接在 Ubuntu 软件中心搜“Visual Studio Code”安装也可以只是版本可能更新稍慢。装完之后首次打开界面是英文的。汉化这一步不是必须的但中文用户用起来更顺手。在扩展市场搜“Chinese (Simplified) 中文简体语言包”安装后右下角会提示切换语言重启即可。3.2 必装扩展清单ROS2 开发常用的 VSCode 扩展我分成三类。第一类是必装级C/C 扩展ms-vscode.cpptools负责 C 语法提示和调试Python 扩展ms-python.python负责 Python 提示和调试CMake Tools 辅助管理 CMake 工程ROS2 的 ament_cmake 底层还是 CMake。第二类是增强效率级微软官方 ROS 扩展ms-ros.ros能在 VSCode 里直接看到 topic 列表、节点信息还能生成 launch 模板Remote-SSH 用于远程开发XML 与 YAML 工具在修改 launch 文件和 package.xml 时非常有用。第三类是可选级GitLens 看历史记录Todo Tree 标记 TODO 注释这些和 ROS2 没有直接关系看个人习惯。安装扩展的命令不复杂在扩展商店里搜名字点 Install 就行。不过要注意C/C 扩展第一次打开大项目时会做 IntelliSense 索引CPU 占用会飙升一阵子这不是出 bug 了等索引完成就安静了。3.3 用户级 settings.json 配置VSCode 的配置逻辑是“用户设置”和“工作区设置”两层。ROS2 项目里很多路径和编译参数依赖工作区目录所以建议大家把 ROS2 相关的配置写进项目根目录的.vscode/settings.json这样同一个项目在不同机器上打开时行为统一。下面是我常用的 RO2 工作区 settings.json 基础模板{ editor.formatOnSave: true, files.associations: { *.repl: cpp }, C_Cpp.default.includePath: [ /opt/ros/humble/include/**, ${workspaceFolder}/src/** ], C_Cpp.default.cppStandard: c17, python.defaultInterpreterPath: /usr/bin/python3, python.analysis.extraPaths: [ /opt/ros/humble/lib/python3.10/site-packages ], ros.distribution: humble, cmake.configureOnOpen: false }这里面有几个点值得说清楚。C_Cpp.default.includePath是把 ROS2 头文件和 src 目录下的头文件路径告诉 C/C 插件这样代码里的#include rclcpp/rclcpp.hpp才能被正确解析红色波浪线基本消失。python.analysis.extraPaths是给 Python 插件指定 ROS2 的 Python 库路径不然 import rclpy 也会标红。ros.distribution用来告诉 ROS 扩展当前是哪个发行版Humble 就填 humble。3.4 工作区 c_cpp_properties.json 的坑很多教程会直接让你在 c_cpp_properties.json 里写大量 includePath但我测下来发现新版 C/C 插件如果不指定 compilerPath经常出现“找不到标准库头文件”的问题。比如vector、memory这些标准库都标红那大概率是 compilerPath 没设置对。我推荐的 c_cpp_properties.json 写法{ configurations: [ { name: Linux, includePath: [ ${workspaceFolder}/**, /opt/ros/humble/include/** ], defines: [], compilerPath: /usr/bin/g, cStandard: c17, cppStandard: c17, intelliSenseMode: linux-gcc-x64 } ], version: 4 }compilerPath 显式指定为/usr/bin/g后C 标准库头文件就能正常索引了。如果你的 g 不是这个路径可以用which g查一下。4. 构建一个可调式的 ROS2 项目4.1 创建工作区与功能包在 ROS2 里代码的顶层目录叫工作区工作区下面用src存放功能包。先建工作区mkdir -p ~/ros2_ws/src cd ~/ros2_ws colcon build第一次 build 一个空工作区会生成 build、install、log 三个目录这三个目录是构建产物不要手动改也不要提交到 Git。接下来的工作都在 src 下进行。创建一个 C 功能包cd ~/ros2_ws/src ros2 pkg create demo_cpp --build-type ament_cmake --dependencies rclcpp std_msgs创建一个 Python 功能包cd ~/ros2_ws/src ros2 pkg create demo_py --build-type ament_python --dependencies rclpy std_msgs创建之后别急着写代码建议先用 VSCode 打开整个工作区cd ~/ros2_ws code .这样 VSCode 的工作区根目录就是~/ros2_ws后面配置的相对路径都是以~/ros2_ws为基准的。4.2 配置 tasks.json 实现一键编译在.vscode目录下创建 tasks.json作用是把“编译当前工作区”这个动作固化成一个任务然后绑定快捷键或菜单点击。先给 C 和 Python 包统一定义一个 colcon build 任务{ version: 2.0.0, tasks: [ { label: colcon build, type: shell, command: source /opt/ros/humble/setup.bash colcon build --symlink-install, options: { cwd: ${workspaceFolder} }, group: { kind: build, isDefault: true }, problemMatcher: [] } ] }这里有一个细节--symlink-install对 Python 包尤其重要。不加这个参数时Python 包的安装目录里是拷贝出来的代码副本你改了 src 下的 .py 文件必须重新 build 才能生效。加了 symlink-install 后install 目录里是软链接改完源码马上生效Python 开发体验会好很多。如果只想编译某个具体包可以再加一个任务把包名作为变量传进去{ label: colcon build (current package), type: shell, command: source /opt/ros/humble/setup.bash colcon build --symlink-install --packages-select ${input:packageName}, options: { cwd: ${workspaceFolder} }, problemMatcher: [] }配合 inputs 数组inputs: [ { id: packageName, type: promptString, description: 请输入要编译的功能包名 } ]这样按 CtrlShiftB 后VSCode 会弹出输入框你输入包名就只编译这个包比全量编译快不少。4.3 安装扩展的 ROS 插件辅助 launchROS 扩展装好后你可以在 VSCode 命令面板CtrlShiftP里输入“ROS: Create Catkin Package”之类的命令生成包模板。不过我更常用的功能是“ROS: Start”和“ROS: Stop”它们会在 VSCode 内置终端里启动 ROS2 launch 文件并把启动信息嵌入任务输出窗口。但要注意ROS 扩展的 launch 功能依赖系统环境变量如果你的 VSCode 是从桌面图标打开的可能没加载~/.bashrc。遇到找到不到 launch 文件时可以试着重启 VSCode或者在 launch 之前手动在终端里 source 一次。这个问题我在远程开发时遇到过很多次后面排查章节会细讲。5. 从源码到断点一键调试完整流程5.1 调试 C 节点的 launch.json调试是整个流程里最筛人的部分。先说 C 节点思路是用 gdb 启动一个 ROS2 可执行文件VSCode 作为前端图形化操作断点、变量、调用栈。在.vscode/launch.json里加如下配置{ version: 0.2.0, configurations: [ { name: Debug C Node, type: cppdbg, request: launch, program: ${workspaceFolder}/install/demo_cpp/lib/demo_cpp/talker, args: [], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [ { name: LD_LIBRARY_PATH, value: /opt/ros/humble/lib } ], externalConsole: false, MIMode: gdb, setupCommands: [ { description: Enable pretty-printing for gdb, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: colcon build } ] }有几个关键点。program路径必须指向编译后生成的实际可执行文件。ROS2 用 ament_cmake 构建后可执行文件的路径规律是install/包名/lib/包名/可执行文件名可执行文件名由 CMakeLists.txt 里的add_executable和install(TARGETS ...)决定。如果你不确定路径直接在文件管理器里打开 install 目录找或者用find install -name talker命令查。preLaunchTask填的是 tasks.json 里定义的任务 label这里填colcon build。效果就是按 F5 启动调试前VSCode 会先自动编译一次保证你调试的是最新代码。这是“一键调试”的核心省去了“先切终端编译再回 VSCode 按 F5”的来回折腾。如果你调试的是 Python 节点配置会简单很多。ROS2 的 Python 节点本质就是一个普通 Python 脚本用 VSCode 的 Python 调试器即可。在 launch.json 里加{ name: Debug Python Node, type: debugpy, request: launch, program: ${workspaceFolder}/install/demo_py/lib/demo_py/talker, console: integratedTerminal, cwd: ${workspaceFolder}, env: { PYTHONPATH: /opt/ros/humble/lib/python3.10/site-packages }, preLaunchTask: colcon build }这里的program指向安装后的 Python 入口脚本。因为 build 时用了 symlink-install所以 install 目录里的脚本其实是软链接直接改 src 下的源码也能命中调试断点。5.2 调试带 launch 文件的多节点项目单节点调试适合验证一个节点的逻辑。但真实项目往往一个 launch 文件里拉起好几类节点有话题通信有参数分发这时候再一个个节点调试就很痛苦。一个可行的方案是使用attach模式而不是launch模式。先正常启动 launch 文件再用 gdb 或 debugpy 附加到已经运行的进程上。C 进程用 attach 模式需要管理员权限因为 gdb 附加进程默认受 ptrace 权限限制解决办法是临时允许sudo sysctl kernel.yama.ptrace_scope0这个设置重启后失效想永久生效可以写入/etc/sysctl.d/10-ptrace.conf。但要注意关闭 ptrace 限制有一定安全风险只在开发和调试机器上使用。Python 节点的 attach 略微复杂需要在启动节点前在目标脚本里提前加入debugpy监听。但 ROS2 的 Python 节点入口是自动生成的脚本很多人不愿意改。这里我分享一个更轻量的替代做法给 launch 文件的 node 加prefix参数让 gdb 或 debugpy 前置加载。以 Python 节点为例可以在 launch 文件里这样写from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packagedemo_py, executabletalker, nametalker, prefix[xterm -e gdb -ex run --args], outputscreen ) ])这样启动 launch 时节点会跑在一个独立的 xterm 窗口里面并用 gdb 前置启动。你可以在那个窗口里打断点、查看堆栈。这个方法不需要改任何业务代码适合临时调试。5.3 配置 launch.json 支持“调试整个 launch”还有一种更省事的方案是针对 launch 文件本身的调试。在 launch.json 里新增一个配置直接让 ROS2 launch 文件运行起来同时允许对多个节点分别中断。C 场景下我常用pipeTransport或直接启动整个 launch 进程但这种方式对单个节点打断点的控制度较弱适合看整体启动顺序和日志输出。如果你的项目节点不多我更推荐逐个节点调试问题定位更准。如果节点多、交互复杂我建议先用ros2 run拉起基础节点再用 attach 模式连接关键节点效率最高。6. 常见问题与排查技巧实录6.1 问题速查表下面这个小表我每次配置新机器时都会对照一遍基本覆盖了大多数报错场景。现象可能原因解决方法ros2 命令找不到环境变量未 source检查 .bashrc 是否写入 source /opt/ros/humble/setup.bashcolcon build 失败找不到头文件依赖包没装或 includePath 不对用 rosdep install --from-paths src -y -i 安装依赖VSCode 里 C 头文件标红includePath 缺少 ROS2 路径在 c_cpp_properties.json 增加 /opt/ros/humble/include按 F5 报 program 路径不存在可执行文件名写错用 find install -name 可执行文件名 查路径断点命中不了编译时优化导致行号偏移在 CMakeLists.txt 里设置 CMAKE_BUILD_TYPEDebugPython 代码改动后没反应没使用 symlink-installcolcon build --symlink-installlaunch 文件找不到环境没 source 或包没安装source install/setup.bash 后再试gdb 附加进程权限不足ptrace_scope 限制临时关闭 kernel.yama.ptrace_scope6.2 preLaunchTask 的连锁问题设置了 preLaunchTask 后如果编译失败VSCode 默认不会启动调试器这符合直觉。但有个坑colcon build 不一定会把编译错误输出成 VSCode 能解析的“问题”格式。因为我前面 problemMatcher 写的是空数组所以编译错误不会跳到“问题”面板。如果编译失败你需要自己切到终端输出窗口手动往回翻看错误。想更顺滑一点可以把 problemMatcher 设置为 gcc 自带匹配器problemMatcher: [$gcc]这样编译错误会被 VSCode 解析并在“问题”面板里直接显示。缺点是 gcc 匹配器对 colcon 输出的多行错误提示偶尔对不齐不过大部分情况下够用。嫌烦的话直接在终端窗口看一眼最底下那条错误信息就行。6.3 远程开发时的环境变量不同步用 Remote-SSH 在 VSCode 里连 Ubuntu 服务器时经常遇到一个问题在 VSCode 的集成终端里能 ros2 run但 debug 配置里启动的进程却找不到 ros2。原因在于 VSCode 的调试器进程不像交互式 shell 那样读取 .bashrc它的环境变量是直接从 VSCode 进程继承的。解决办法有三个。第一个是在 launch.json 的 environment 字段里显式写全 PATH、LD_LIBRARY_PATH、AMENT_PREFIX_PATH 等变量。例如environment: [ { name: PATH, value: /opt/ros/humble/bin:/usr/bin:/bin }, { name: LD_LIBRARY_PATH, value: /opt/ros/humble/lib }, { name: AMENT_PREFIX_PATH, value: /opt/ros/humble;/root/ros2_ws/install }, { name: PYTHONPATH, value: /opt/ros/humble/lib/python3.10/site-packages } ]第二种是在 preLaunchTask 里先强制 source 一次因为 task 本来就是 shell 命令只要 command 里写了source /opt/ros/humble/setup.bash编译和后续的调试器启动就都能读到环境。第三种是写一个包装脚本在 launch.json 里把 program 指向脚本脚本内部负责 source 然后 exec 真正的可执行文件。这是最稳的方式适合公司团队统一开发环境时使用缺点是多一层脚本对新手不够透明。6.4 IntelliSense 检索慢与误报ROS2 头文件数量非常多尤其是装完 desktop 版之后/opt/ros/humble/include 下有一堆头文件。C/C 扩展全量索引会很慢打开项目前缀会卡一会儿。我的做法是不要无脑把整个/opt/ros/humble/include加进 includePath而是按需添加。比如只用 rclcpp就只加/opt/ros/humble/include/rclcpp/**。但这种精确写法对新手不友好因为不确定以后会用哪些库。折中方案是保留全量 includePath但关掉自动刷新C_Cpp.intelliSenseCachePath: ${workspaceFolder}/.vscode/.cache, C_Cpp.autocomplete: default另外误报问题也常出现。比如你写了std::make_sharedrclcpp::Node()VSCode 可能提示找不到 rclcpp。但只要编译能过基本就是 IntelliSense 配置问题不是代码问题。可以先跑一次 colcon build确认能编译通过再回头调整 includePath。6.5 调试 Python 节点时断点不生效Python 断点不生效常见原因有两个。第一个是调试器选错了类型。VSCode 新版 Python 插件建议用debugpy如果你还在用老式python类型可能因为调试器版本不匹配导致断点无法命中。launch.json 里写type: debugpy即可。第二个是源码路径和实际执行路径不一致。ROS2 Python 包经常出现这种情况你明明在 src/demo_py/demo_py/talker.py 里打了断点但实际启动的是 install/demo_py/lib/demo_py/talker 这个软链接最终解析到的路径是 install 下的副本位置。如果 symlink-install 没生效这个副本是物理拷贝断点位置和你打开的文件不是同一个文件自然不会命中。解决方案是确保用--symlink-install编译并且在 launch.json 里把justMyCode: false也加上避免调试器跳过非用户目录代码。7. 一键调试的两种典型工作流7.1 单人开发流F5 启动单节点工作区只有一个核心节点时我的流程是这样改代码按 CtrlShiftB 编译确认 0 error 后在节点代码里打上断点按 F5。VSCode 会自动执行 preLaunchTask 里的编译任务然后启动调试器断点命中后左侧面板能看局部变量鼠标悬停能看对象成员右上角能单步、下一步、跳入。这套流程的核心收益是“改代码-编译-调试”不用离开编辑器注意力不会被打断。7.2 多节点联调流launch 启动 attach 附加多节点场景下我建议提前把所有可执行文件都确认能跑通之后开启两个 VSCode 调试会话。一个会话负责运行 launch 文件另一个会话用 attach 模式连接关键节点。具体操作是先ros2 launch 你的launch文件在集成终端里启动再在 launch.json 里选 attach 配置填好进程名按 F5 附加。这个过程第一次配好之后后面几乎不用改。唯一要注意的是 attach 到 C 进程时如果进程崩溃调试器可能会连不上所以最好在节点启动初期就挂上调试器。8. 让环境长期保持可用的几个习惯最后分享几个我长期使用后形成的习惯这些小事看着不起眼但能让你少踩很多坑。第一个习惯是“每次打开新终端前先看 prompt 有没有 ROS2 环境标记”。我习惯在 .bashrc 里加一行if [ -f /opt/ros/humble/setup.bash ]; then source /opt/ros/humble/setup.bash export ROS_DOMAIN_ID0 export ROS_LOCALHOST_ONLY1 fiROS_LOCALHOST_ONLY1对单机开发很有用它让 DDS 只在回环接口通信可以避免多机环境下无关节点互相干扰还能让话题发现更快。如果团队里有多个机器人同一个网络这个参数要慎重设置别把跨机通信堵死。第二个习惯是“养成看 CMakeLists.txt 中 install 段的习惯”。很多断点命不中、可执行文件找不到的问题本质都是 CMakeLists.txt 漏了 install 规则。看到 add_executable 之后马上确认下面有没有对应的 install(TARGETS ... DESTINATION lib/${PROJECT_NAME})。Python 包则检查 setup.py 里的 entry_points 是否正确。第三个习惯是“git 分支隔离构建产物”。build、install、log 目录很大也不该进版本库。在 .gitignore 里固定写build/ install/ log/ .vscode/但 .vscode 里的 settings.json、tasks.json、launch.json 对团队协作是有价值的可以单独用 shared 配置目录管理。方法是在项目根目录放一个.vscode-shared目录把配置文件复制进去新成员克隆后复制为 .vscode 即可。ROS2 和 VSCode 的组合说到底追求的就是一件事把重复劳动自动化把调试效率提上来。环境配置阶段确实麻烦但一开始把底子打好后面写节点、跑实验、定位问题都会顺手很多。上面这些配置是我在多个版本和多个机器上反复验证过的你可以照着抄再根据实际包的路径调整一下基本就能把“改代码-编译-调试”的循环拧顺。
返回列表
PREV
查看更多资讯
NEXT
返回资讯列表