1. 装之前先想清楚ROS2的版本、Ubuntu版本和你的板子得先对上号ROS2基础入门教程这类内容网上一抓一大把但真正让人卡住的往往不是概念听不懂而是第一步装环境就翻车命令敲下去提示ros2: command not found或者装完了跑小乌龟报一堆找不到库的错。我带过几届学生也帮同事配过工控机和开发板发现九成的入门挫败感都发生在环境这两个字上。这篇就把ROS2从装到跑通、从看懂小乌龟到能自己写节点发消息的完整路径捋一遍顺带把那些文档里不写、但实际一定会遇到的坑点讲透。它适合完全没碰过机器人中间件的同学也适合从ROS1转过来、发现老经验不灵了的老手。ROS2和ROS1最大的区别是它把通信这件事从自研的一套东西换成了工业级的DDS中间件节点之间可以真真正正地跨机器、跨网络、动态发现不需要一个中心节点管理器。这个改动听着美好代价是概念变多了QoS、DDS域、发现机制全都是ROS1里没有的新面孔。所以入门顺序特别重要别一上来就啃导航和机械臂先把一个节点怎么说话、另一个节点怎么听见搞明白后面全是这套逻辑的重复。提示如果你只是想在电脑上看看效果装完系统级ROS2就够了如果你要接开发板、要用串口和传感器务必先确认板子的SDK和系统版本这一步偷懒后面会还债。1.1 三个版本号必须对齐ROS2的版本和Ubuntu版本是绑死的这个对应关系记不住就等着踩坑。目前主流的是这么几组ROS2版本对应Ubuntu状态Foxy20.04已停止维护别再用它开新项目Humble22.04长期支持版资料最多新手首选Jazzy24.04较新生态在追赶选版本的原则很简单你要用的那个第三方包它支持到哪你就装哪。比如很多雷达、相机、机械臂的官方驱动包更新慢可能只维护到Humble。你贪新装了Jazzy结果发现驱动编不过那只能重装。所以新手我建议直接用Humble配22.04网上能搜到的教程、论坛回答、视频绝大多数都是基于这一套遇到问题一搜就有答案这个有人踩过同样的坑的价值比版本新不新重要得多。至于Ubuntu 24.04装Jazzy这类组合不是不行但你得接受一个现实出问题时能搜到的中文资料会少一大截很多时候得去翻英文的issue。这不是技术难度问题是时间成本问题。1.2 source 与工作空间覆盖环境变量是怎么生效的ROS2安装完之后最让人困惑的就是为什么每次开新终端都要source一下。这不是多此一举而是ROS2整个环境是靠一堆环境变量撑起来的。安装系统级ROS2后/opt/ros/humble/setup.bash这个文件里做的事情就是把ROS2的命令路径、库路径、Python包路径追加进当前shell的环境变量里。你不sourceshell就不知道ros2这个命令在哪自然报command not found。让它在每个新终端自动生效的办法是在~/.bashrc末尾加一行source /opt/ros/humble/setup.bash但这里有个很多人没搞懂的点工作空间的setup.bash和系统级的不是替代关系是叠加关系。你自己编译的工作空间装完之后要source的是install/setup.bash而且顺序上要放在系统级的后面这样你自己的包才能覆盖掉系统里同名的东西。source /opt/ros/humble/setup.bash source ~/ros2_ws/install/setup.bash注意工作空间一层层嵌套的时候建议用--extend或者干脆按上面顺序手动source。出现过明明改了代码却还是跑旧行为的情况八成是因为source的是旧的install目录或者忘了重新编译。还有个容易忽略的检查手段echo $AMENT_PREFIX_PATH能看出当前环境到底挂了哪些路径which ros2能看出命令走的哪个。排查环境问题这两条命令比瞎猜快得多。1.3 一键安装脚本省事但你要知道它替你做了什么社区里有不少一键安装脚本跑一条命令就把ROS2、常用工具、甚至换源配置全搞定对新手确实友好能省掉手动配置软件源、处理依赖的繁琐。但我不建议你把它当黑盒用至少要知道它干了这几件事替换或添加了系统的软件源让你能下载到ROS2的包安装了ros-humble-desktop或对应的包集合这里面包含了RViz2、demo节点、示例功能包往.bashrc里追加了source语句有的还会顺手装一些常用工具比如通过串口和板子通信的库、构建工具。知道这些之后当脚本跑完但命令还是找不到时你就知道该去检查软件源有没有配错、.bashrc有没有生效.bashrc的改动要重开终端或source ~/.bashrc才生效。另外脚本装的是某一时刻的状态如果你后面自己手动装包时软件源被别的操作覆盖了依然会出问题。所以把源配置文件的位置记住比记脚本本身更有用。2. 小乌龟跑起来后真正该看的是节点、话题、服务之间的关系大多数人跑ROS2第一条命令都是那个经典的小乌龟ros2 run turtlesim turtlesim_node ros2 run turtlesim turtle_teleop_key窗口弹出来键盘一按乌龟就动很有成就感。但如果你止步于此等于白跑。小乌龟之所以经典是因为它把ROS2最核心的三种通信模式都放在一个极简例子里了你得会拆它。2.1 节点一个进程一个名字节点是ROS2里的最小执行单位说白了就是一个跑起来的进程但它给自己起了个名字方便别人找到它。小乌龟跑起来之后开个新终端敲ros2 node list你能看到/turtlesim和/teleop_turtle两个节点。再敲ros2 node info /turtlesim它会把这个节点所有的发布、订阅、服务都列出来。这一步特别重要——学会用node info读一个陌生节点比背任何概念都有用。你以后拿到任何一个别人写的包不知道它怎么工作第一步就是把它跑起来然后node info看它对外暴露了什么。这里有个命名规范值得养成习惯节点名、话题名用全小写加下划线比如/laser_scan_filter别用大写。ROS2的命名空间机制对大小写敏感混用迟早出乱子。另外同一个节点名在同一时刻只能有一个重复启动第二个会被系统提示重命名这个行为跟ROS1不一样ROS1是直接覆盖ROS2会保护你避免两个节点互相抢名字。2.2 话题发布订阅与谁在等谁话题是ROS2里用得最多的通信方式模型是发布-订阅。发布者往一个话题名上丢消息订阅者从同一个话题名上收消息双方互相不认识也不需要知道对方存在。小乌龟的键盘控制节点发布/turtle1/cmd_vel仿真节点订阅这个话题所以按键一动速度指令就传过去了。用这几条命令把整条链路看清楚ros2 topic list # 列出所有话题 ros2 topic info /turtle1/cmd_vel # 看话题的类型和发布订阅数量 ros2 topic echo /turtle1/cmd_vel # 实时打印话题内容 ros2 topic hz /turtle1/cmd_vel # 看发布频率ros2 topic echo是我调试时用得最多的命令没有之一。你的控制节点发了消息但机器人不动第一反应就应该是echo一下话题看看到底有没有数据发出来、发的数值对不对。很多机器人不动的问题定位到最后就是话题压根没发数据或者发的是全零。topic hz则能帮你判断数据流是否正常。一个本该跑10Hz的传感器话题如果hz显示只有1Hz或者时有时无那多半是发布频率设置不对、或者计算耗时太长卡住了。提示ros2 topic echo会真的占用一个订阅者资源在带宽紧张的场景下调试完记得关掉别让它一直挂着影响实时性。2.3 服务、Action同步请求与长任务的分工话题是一直播但有些操作你要的是问一句答一句比如让仿真器重置画布。这时候用的是服务ros2 service list ros2 service call /reset std_srvs/srv/Empty {}服务的模型是请求-响应客户端发一个请求服务端算完返回结果。它适合那种我发个指令你告诉我成功与否的短操作。但服务有个硬伤它不能反馈进度。如果是个要跑几十秒的任务比如让机械臂走一条轨迹你用服务发出去中间完全不知道走到哪了超时了也不好处理。这就是Action存在的意义。Action本质上是话题服务的组合拳它有一个目标话题、一个反馈话题、一个结果话题客户端发目标服务端周期性汇报进度最后给结果还支持中途取消。导航里的去某个坐标点、机械臂的走一段轨迹用的都是Action。ros2 action list ros2 action send_goal /turtle1/rotate_absolute turtlesim/action/RotateAbsolute {theta: 1.57}判断该用哪种通信我总结了个简单标准场景推荐方式持续数据流传感器、控制指令话题一问一答的短操作重置、查询服务有进度、可取消的长任务导航、轨迹Action刚入门不用把Action的底层实现啃透知道什么时候该用它就够了。3. QoS那类能ping通却收不到数据的问题多半出在这如果你是从ROS1转过来的这一节可能是最容易让你翻车的地方。ROS1里话题连上就是连上了能收到数据ROS2里话题名字对、类型对、两边都在跑但就是一个收不到——这个问题我第一次遇到时排查了整整一个下午最后发现是QoS不匹配。3.1 为什么ROS1的老经验在ROS2会翻车QoS服务质量是DDS带来的概念它描述的是这个通信在可靠性、实时性、缓存上愿意付出多少代价。发布者和订阅者各自声明自己的QoS策略两边要能谈得拢才能建立连接。谈不拢怎么办没人报错就是静默地收不到数据。最常见的组合是发布者用可靠传输订阅者用尽力而为或者反过来。比如你用一个默认配置的命令行工具去echo一个配置了BEST_EFFORT的传感器话题可能就没数据。这不是bug是设计如此。ros2 topic info /some_topic --verbose这条命令会把话题两端的QoS策略都列出来--verbose是关键不带这个参数你只能看到类型和数量看不到QoS等于白看。3.2 几组常用QoS组合与选型依据理解QoS不需要背全部策略抓住三个维度就够了可靠性、持久性、历史深度。维度取值含义与适用场景可靠性RELIABLE保证送达重要指令用会重传可靠性BEST_EFFORT尽力而为丢了就丢了高频传感器用持久性TRANSIENT_LOCAL后来者能拿到最后几条地图、静态配置用持久性VOLATILE只发当前普通数据流用历史KEEP_LAST(N)只缓存最近N条最常见选型逻辑其实对应物理含义相机、雷达这种每秒几十上百帧的数据丢一两帧完全不影响用BEST_EFFORT反而更省资源、延迟更低而开始运行急停这种指令丢一条就出事故必须RELIABLE。地图这种发一次就一直有效的东西用TRANSIENT_LOCAL这样订阅者晚启动也能拿到。注意混合使用命令行工具调试时ros2 topic echo默认是可靠订阅遇到尽力而为的发布者可以加参数调整。别一看到没数据就怀疑自己的代码先看看QoS对不对得上。4. 从开三个终端到一条launch参数与启动的组织方式新手阶段我们习惯一个终端跑一个节点但真实项目动辄十几个节点每个节点还有一堆参数靠手敲不现实也极其容易出错。launch文件就是用来解决一键启动一整套系统的。4.1 launch.py 的最小骨架ROS2的launch用Python写也有XML和YAML格式但Python最灵活一个能跑的最小例子长这样from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packageturtlesim, executableturtlesim_node, namesim ), Node( packageturtlesim, executableturtle_teleop_key, nameteleop, prefixxterm -e ), ])这个文件放在功能包的launch/目录下安装配置里要让launch目录被识别到否则运行时找不到。用一个功能包同时装节点和launch文件时package和executable分别指包名和可执行文件名不是文件名本身这点新手经常搞混。prefixxterm -e是个实用技巧键盘控制节点需要一个终端窗口接收按键不加这句它启动后没有输入的地方表现就是节点启动了但按键没反应。4.2 参数外置与yaml真实项目里参数不该硬编码在代码里应该外置到yamllaunch时读进来。这样换一台设备、换一个场景只改配置不改代码。turtlesim_node: ros__parameters: background_r: 100 background_g: 150 background_b: 200在launch里用parameters[yaml文件路径]加载。这里有个特别容易踩的坑yaml里的顶层键名要和节点名对得上。节点名在launch里改了yaml里的名字没跟着改参数就会加载不上而且不报错参数就是保持默认值——又是一个静默失败。排查方式是启动后ros2 param list和ros2 param get确认参数到底有没有生效。5. 从跑别人的包到自己写包工作空间、colcon与自定义消息会跑别人写的东西和能自己写出来中间隔着一道坎。这道坎的实质是你得搞清楚一个ROS2功能包长什么样以及它是怎么被编译出来的。5.1 工作空间的目录约定标准的工作空间结构是这样ros2_ws/ ├── src/ # 源码你的每个功能包放这里 │ └── my_pkg/ │ ├── package.xml │ ├── CMakeLists.txt (或 setup.py) │ ├── src/ │ ├── launch/ │ └── msg/ ├── build/ # 编译中间产物别手动改 ├── install/ # 编译产物source的是这里 └── log/ # 编译日志build和install是工具自动生成的不要往里面塞东西也基本不用手动改。真正干活的只有src。养成习惯永远在src下改代码编译后sourceinstall/setup.bash。创建包用ros2 pkg createC的包和Python的包生成的东西不一样。C包依赖package.xml和CMakeLists.txtPython包用setup.py和setup.cfg。选C还是Python别纠结看场景对性能敏感的、要对接硬件驱动的用C写上层逻辑、快速验证、做数据处理的用Python。很多实际项目是混着来的底层C驱动上层Python规划。5.2 colcon 构建与常见报错编译命令是colcon build colcon build --packages-select my_pkg # 只编一个包省时间 colcon build --symlink-install # Python包改动不用重编--symlink-install这个参数值得单独说。Python包用它之后改了.py文件不用重新build直接source一下就行开发效率提升明显。C代码改了还是得重编的。常见报错大概这么几类报错关键词大概率原因处理方向package not found没source系统环境或包名拼错检查source、检查包名找不到头文件package.xml里少了depend依赖补依赖再重编Python模块导入失败忘了--symlink-install或路径没source重编并source编译过了但运行时找不到source的是build不是installsource install/setup.bash提示编译报错时别急着搜整个报错先看第一行和最后一行。第一行通常告诉你哪个包开始出问题最后一行是根本原因中间那一大堆往往是连锁反应看了反而干扰判断。5.3 自定义 msg/srv 的完整链路当现成的消息类型不够用时就要自己定义。定义一个消息要做四件事建msg/目录、写.msg文件、在CMakeLists.txt和package.xml里声明消息生成、编译后source。# msg/MyData.msg float64 x float64 y string label编译成功后用ros2 interface show 包名/msg/MyData就能看到定义生效了。这里最容易出问题的不是写msg文件而是依赖声明如果msg里用到了别的包的消息类型必须在package.xml里加depend在CMakeLists.txt里加对应依赖少一个就编译失败。而且改完消息定义一定要重新编译整个工作空间因为依赖它的包也要重新生成代码。6. 仿真与可视化Gazebo和RViz2各自负责什么跑通小乌龟之后下一步通常是上仿真。这里有个特别常见的误解得先纠正RViz2不是仿真器Gazebo才是。6.1 RViz2 只是显示不产生数据RViz2是个可视化工具它的作用是把话题里的数据画出来给你看。激光雷达的点云、机器人的位姿、地图、路径规划结果都是别的东西算出来发到话题上RViz2订阅了之后渲染。所以如果RViz2里一片空白问题几乎肯定不在RViz2本身而是话题里根本没数据或者RViz2订阅的话题名、坐标系frame对不上。排查RViz2空白问题的顺序ros2 topic list确认话题有没有数据在RViz2里检查你添加的显示项订阅的话题名和实际话题名对不对检查Fixed Frame设置这是新手最容易忽略的。如果frame设成了map但你的数据都在odom或base_link下东西就会显示不出来或者位置乱飞。6.2 Gazebo 提供物理与传感器Gazebo才是真正干仿真的活重力、碰撞、摩擦、传感器噪声全在这里算。它会加载机器人的URDF或SDF模型把你描述的关节、连杆、传感器变成仿真世界里真实存在的东西然后按照物理规律算出传感器应该读到什么再发布到话题上。从URDF到Gazebo能加载的模型中间往往要补很多信息惯性参数质量、转动惯量、碰撞体、关节类型、传感器插件。新手做机械臂或移动机器人仿真时卡最久的一般就是URDF这一段。有个经验是先用简单的几何体方块、圆柱把结构搭对把Gazebo里的物理行为调正常再去替换成精细的模型。一上来就用复杂模型出问题你根本分不清是模型文件语法错了还是物理参数不合理。仿真和真机的链路其实是一样的都是话题、服务、Action。这也是为什么仿真值得花时间学你在仿真里调通的代码换个话题名和参数大概率能直接上真机。7. 卡住的时候按这个顺序排查讲了这么多最后落回到实际操作上。入门阶段的问题看起来千奇百怪其实高度集中在几类。下面这个排查顺序是我自己用下来最省时间的。7.1 command not found 的三种成因敲ros2提示找不到命令就三个原因没source。.bashrc里没加或者当前终端是旧终端改动没生效装了但路径不对。which ros2看有没有输出没有就说明环境变量没加进去装了两个版本。系统里有ROS1也有ROS2时两者的环境变量可能互相干扰。最简单粗暴但有效的办法是同一时间只source一个需要切换时新开终端。先查第二种再用第一种验证最后才考虑第三种。按这个顺序能避免无谓地重装。7.2 编译与运行期报错分流编译报错和运行报错要分开处理思路完全不同。编译期的问题基本是依赖、语法、版本不匹配运行期的报错则要看具体现象。运行时节点起不来先看报错是找不到包还是找不到库前者是环境问题后者可能是动态库路径没配好。节点起来了但行为不对回到第2节的思路node list看节点在不在topic list看话题有没有topic echo看数据有没有。永远从数据流这个角度去查而不是盯着代码猜。7.3 硬件与串口类问题一旦接上真实硬件问题会多一层串口权限、波特率、设备名漂移。这类问题的典型现象是昨天还好好的今天设备找不到了。原因多半是USB设备插的顺序变了/dev/ttyUSB0变成了/dev/ttyUSB1。处理这类问题的通用做法是给设备起个别名用设备的固定属性比如序列号绑定一个稳定的名字让程序去读这个名字而不是直接写死设备号。这个习惯能省掉未来无数次重新插一下就好了的无效排查。另外串口权限问题表现为打不开设备把当前用户加进串口对应的用户组就能解决加完要重新登录才生效。这类问题不难但不知道的话能卡很久。我个人在实际操作中的体会是ROS2入门的难点从来不在概念本身而在环境配置和静默失败上。概念看两遍就懂了但一个QoS不匹配、一个yaml键名写错、一个source顺序不对能让你怀疑自己是不是根本不适合这行。等你把这些坑都踩过一遍回头看会发现ROS2的设计其实相当一致所有东西都围绕节点通过话题/服务/Action通信展开QoS是通信的细则launch是启动的组织方式工作空间是代码的存放规则。把这条主线抓住了剩下的就是查文档和积累经验的事。最后分享个小习惯每配好一个环境、跑通一个例子就把当时敲的命令和踩到的坑记一笔哪怕就几句话等下次换机器或者帮别人的时候这些笔记的价值比任何教程都高。
1. 装之前先想清楚ROS2的版本、Ubuntu版本和你的板子得先对上号ROS2基础入门教程这类内容网上一抓一大把但真正让人卡住的往往不是概念听不懂而是第一步装环境就翻车命令敲下去提示ros2: command not found或者装完了跑小乌龟报一堆找不到库的错。我带过几届学生也帮同事配过工控机和开发板发现九成的入门挫败感都发生在环境这两个字上。这篇就把ROS2从装到跑通、从看懂小乌龟到能自己写节点发消息的完整路径捋一遍顺带把那些文档里不写、但实际一定会遇到的坑点讲透。它适合完全没碰过机器人中间件的同学也适合从ROS1转过来、发现老经验不灵了的老手。ROS2和ROS1最大的区别是它把通信这件事从自研的一套东西换成了工业级的DDS中间件节点之间可以真真正正地跨机器、跨网络、动态发现不需要一个中心节点管理器。这个改动听着美好代价是概念变多了QoS、DDS域、发现机制全都是ROS1里没有的新面孔。所以入门顺序特别重要别一上来就啃导航和机械臂先把一个节点怎么说话、另一个节点怎么听见搞明白后面全是这套逻辑的重复。提示如果你只是想在电脑上看看效果装完系统级ROS2就够了如果你要接开发板、要用串口和传感器务必先确认板子的SDK和系统版本这一步偷懒后面会还债。1.1 三个版本号必须对齐ROS2的版本和Ubuntu版本是绑死的这个对应关系记不住就等着踩坑。目前主流的是这么几组ROS2版本对应Ubuntu状态Foxy20.04已停止维护别再用它开新项目Humble22.04长期支持版资料最多新手首选Jazzy24.04较新生态在追赶选版本的原则很简单你要用的那个第三方包它支持到哪你就装哪。比如很多雷达、相机、机械臂的官方驱动包更新慢可能只维护到Humble。你贪新装了Jazzy结果发现驱动编不过那只能重装。所以新手我建议直接用Humble配22.04网上能搜到的教程、论坛回答、视频绝大多数都是基于这一套遇到问题一搜就有答案这个有人踩过同样的坑的价值比版本新不新重要得多。至于Ubuntu 24.04装Jazzy这类组合不是不行但你得接受一个现实出问题时能搜到的中文资料会少一大截很多时候得去翻英文的issue。这不是技术难度问题是时间成本问题。1.2 source 与工作空间覆盖环境变量是怎么生效的ROS2安装完之后最让人困惑的就是为什么每次开新终端都要source一下。这不是多此一举而是ROS2整个环境是靠一堆环境变量撑起来的。安装系统级ROS2后/opt/ros/humble/setup.bash这个文件里做的事情就是把ROS2的命令路径、库路径、Python包路径追加进当前shell的环境变量里。你不sourceshell就不知道ros2这个命令在哪自然报command not found。让它在每个新终端自动生效的办法是在~/.bashrc末尾加一行source /opt/ros/humble/setup.bash但这里有个很多人没搞懂的点工作空间的setup.bash和系统级的不是替代关系是叠加关系。你自己编译的工作空间装完之后要source的是install/setup.bash而且顺序上要放在系统级的后面这样你自己的包才能覆盖掉系统里同名的东西。source /opt/ros/humble/setup.bash source ~/ros2_ws/install/setup.bash注意工作空间一层层嵌套的时候建议用--extend或者干脆按上面顺序手动source。出现过明明改了代码却还是跑旧行为的情况八成是因为source的是旧的install目录或者忘了重新编译。还有个容易忽略的检查手段echo $AMENT_PREFIX_PATH能看出当前环境到底挂了哪些路径which ros2能看出命令走的哪个。排查环境问题这两条命令比瞎猜快得多。1.3 一键安装脚本省事但你要知道它替你做了什么社区里有不少一键安装脚本跑一条命令就把ROS2、常用工具、甚至换源配置全搞定对新手确实友好能省掉手动配置软件源、处理依赖的繁琐。但我不建议你把它当黑盒用至少要知道它干了这几件事替换或添加了系统的软件源让你能下载到ROS2的包安装了ros-humble-desktop或对应的包集合这里面包含了RViz2、demo节点、示例功能包往.bashrc里追加了source语句有的还会顺手装一些常用工具比如通过串口和板子通信的库、构建工具。知道这些之后当脚本跑完但命令还是找不到时你就知道该去检查软件源有没有配错、.bashrc有没有生效.bashrc的改动要重开终端或source ~/.bashrc才生效。另外脚本装的是某一时刻的状态如果你后面自己手动装包时软件源被别的操作覆盖了依然会出问题。所以把源配置文件的位置记住比记脚本本身更有用。2. 小乌龟跑起来后真正该看的是节点、话题、服务之间的关系大多数人跑ROS2第一条命令都是那个经典的小乌龟ros2 run turtlesim turtlesim_node ros2 run turtlesim turtle_teleop_key窗口弹出来键盘一按乌龟就动很有成就感。但如果你止步于此等于白跑。小乌龟之所以经典是因为它把ROS2最核心的三种通信模式都放在一个极简例子里了你得会拆它。2.1 节点一个进程一个名字节点是ROS2里的最小执行单位说白了就是一个跑起来的进程但它给自己起了个名字方便别人找到它。小乌龟跑起来之后开个新终端敲ros2 node list你能看到/turtlesim和/teleop_turtle两个节点。再敲ros2 node info /turtlesim它会把这个节点所有的发布、订阅、服务都列出来。这一步特别重要——学会用node info读一个陌生节点比背任何概念都有用。你以后拿到任何一个别人写的包不知道它怎么工作第一步就是把它跑起来然后node info看它对外暴露了什么。这里有个命名规范值得养成习惯节点名、话题名用全小写加下划线比如/laser_scan_filter别用大写。ROS2的命名空间机制对大小写敏感混用迟早出乱子。另外同一个节点名在同一时刻只能有一个重复启动第二个会被系统提示重命名这个行为跟ROS1不一样ROS1是直接覆盖ROS2会保护你避免两个节点互相抢名字。2.2 话题发布订阅与谁在等谁话题是ROS2里用得最多的通信方式模型是发布-订阅。发布者往一个话题名上丢消息订阅者从同一个话题名上收消息双方互相不认识也不需要知道对方存在。小乌龟的键盘控制节点发布/turtle1/cmd_vel仿真节点订阅这个话题所以按键一动速度指令就传过去了。用这几条命令把整条链路看清楚ros2 topic list # 列出所有话题 ros2 topic info /turtle1/cmd_vel # 看话题的类型和发布订阅数量 ros2 topic echo /turtle1/cmd_vel # 实时打印话题内容 ros2 topic hz /turtle1/cmd_vel # 看发布频率ros2 topic echo是我调试时用得最多的命令没有之一。你的控制节点发了消息但机器人不动第一反应就应该是echo一下话题看看到底有没有数据发出来、发的数值对不对。很多机器人不动的问题定位到最后就是话题压根没发数据或者发的是全零。topic hz则能帮你判断数据流是否正常。一个本该跑10Hz的传感器话题如果hz显示只有1Hz或者时有时无那多半是发布频率设置不对、或者计算耗时太长卡住了。提示ros2 topic echo会真的占用一个订阅者资源在带宽紧张的场景下调试完记得关掉别让它一直挂着影响实时性。2.3 服务、Action同步请求与长任务的分工话题是一直播但有些操作你要的是问一句答一句比如让仿真器重置画布。这时候用的是服务ros2 service list ros2 service call /reset std_srvs/srv/Empty {}服务的模型是请求-响应客户端发一个请求服务端算完返回结果。它适合那种我发个指令你告诉我成功与否的短操作。但服务有个硬伤它不能反馈进度。如果是个要跑几十秒的任务比如让机械臂走一条轨迹你用服务发出去中间完全不知道走到哪了超时了也不好处理。这就是Action存在的意义。Action本质上是话题服务的组合拳它有一个目标话题、一个反馈话题、一个结果话题客户端发目标服务端周期性汇报进度最后给结果还支持中途取消。导航里的去某个坐标点、机械臂的走一段轨迹用的都是Action。ros2 action list ros2 action send_goal /turtle1/rotate_absolute turtlesim/action/RotateAbsolute {theta: 1.57}判断该用哪种通信我总结了个简单标准场景推荐方式持续数据流传感器、控制指令话题一问一答的短操作重置、查询服务有进度、可取消的长任务导航、轨迹Action刚入门不用把Action的底层实现啃透知道什么时候该用它就够了。3. QoS那类能ping通却收不到数据的问题多半出在这如果你是从ROS1转过来的这一节可能是最容易让你翻车的地方。ROS1里话题连上就是连上了能收到数据ROS2里话题名字对、类型对、两边都在跑但就是一个收不到——这个问题我第一次遇到时排查了整整一个下午最后发现是QoS不匹配。3.1 为什么ROS1的老经验在ROS2会翻车QoS服务质量是DDS带来的概念它描述的是这个通信在可靠性、实时性、缓存上愿意付出多少代价。发布者和订阅者各自声明自己的QoS策略两边要能谈得拢才能建立连接。谈不拢怎么办没人报错就是静默地收不到数据。最常见的组合是发布者用可靠传输订阅者用尽力而为或者反过来。比如你用一个默认配置的命令行工具去echo一个配置了BEST_EFFORT的传感器话题可能就没数据。这不是bug是设计如此。ros2 topic info /some_topic --verbose这条命令会把话题两端的QoS策略都列出来--verbose是关键不带这个参数你只能看到类型和数量看不到QoS等于白看。3.2 几组常用QoS组合与选型依据理解QoS不需要背全部策略抓住三个维度就够了可靠性、持久性、历史深度。维度取值含义与适用场景可靠性RELIABLE保证送达重要指令用会重传可靠性BEST_EFFORT尽力而为丢了就丢了高频传感器用持久性TRANSIENT_LOCAL后来者能拿到最后几条地图、静态配置用持久性VOLATILE只发当前普通数据流用历史KEEP_LAST(N)只缓存最近N条最常见选型逻辑其实对应物理含义相机、雷达这种每秒几十上百帧的数据丢一两帧完全不影响用BEST_EFFORT反而更省资源、延迟更低而开始运行急停这种指令丢一条就出事故必须RELIABLE。地图这种发一次就一直有效的东西用TRANSIENT_LOCAL这样订阅者晚启动也能拿到。注意混合使用命令行工具调试时ros2 topic echo默认是可靠订阅遇到尽力而为的发布者可以加参数调整。别一看到没数据就怀疑自己的代码先看看QoS对不对得上。4. 从开三个终端到一条launch参数与启动的组织方式新手阶段我们习惯一个终端跑一个节点但真实项目动辄十几个节点每个节点还有一堆参数靠手敲不现实也极其容易出错。launch文件就是用来解决一键启动一整套系统的。4.1 launch.py 的最小骨架ROS2的launch用Python写也有XML和YAML格式但Python最灵活一个能跑的最小例子长这样from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packageturtlesim, executableturtlesim_node, namesim ), Node( packageturtlesim, executableturtle_teleop_key, nameteleop, prefixxterm -e ), ])这个文件放在功能包的launch/目录下安装配置里要让launch目录被识别到否则运行时找不到。用一个功能包同时装节点和launch文件时package和executable分别指包名和可执行文件名不是文件名本身这点新手经常搞混。prefixxterm -e是个实用技巧键盘控制节点需要一个终端窗口接收按键不加这句它启动后没有输入的地方表现就是节点启动了但按键没反应。4.2 参数外置与yaml真实项目里参数不该硬编码在代码里应该外置到yamllaunch时读进来。这样换一台设备、换一个场景只改配置不改代码。turtlesim_node: ros__parameters: background_r: 100 background_g: 150 background_b: 200在launch里用parameters[yaml文件路径]加载。这里有个特别容易踩的坑yaml里的顶层键名要和节点名对得上。节点名在launch里改了yaml里的名字没跟着改参数就会加载不上而且不报错参数就是保持默认值——又是一个静默失败。排查方式是启动后ros2 param list和ros2 param get确认参数到底有没有生效。5. 从跑别人的包到自己写包工作空间、colcon与自定义消息会跑别人写的东西和能自己写出来中间隔着一道坎。这道坎的实质是你得搞清楚一个ROS2功能包长什么样以及它是怎么被编译出来的。5.1 工作空间的目录约定标准的工作空间结构是这样ros2_ws/ ├── src/ # 源码你的每个功能包放这里 │ └── my_pkg/ │ ├── package.xml │ ├── CMakeLists.txt (或 setup.py) │ ├── src/ │ ├── launch/ │ └── msg/ ├── build/ # 编译中间产物别手动改 ├── install/ # 编译产物source的是这里 └── log/ # 编译日志build和install是工具自动生成的不要往里面塞东西也基本不用手动改。真正干活的只有src。养成习惯永远在src下改代码编译后sourceinstall/setup.bash。创建包用ros2 pkg createC的包和Python的包生成的东西不一样。C包依赖package.xml和CMakeLists.txtPython包用setup.py和setup.cfg。选C还是Python别纠结看场景对性能敏感的、要对接硬件驱动的用C写上层逻辑、快速验证、做数据处理的用Python。很多实际项目是混着来的底层C驱动上层Python规划。5.2 colcon 构建与常见报错编译命令是colcon build colcon build --packages-select my_pkg # 只编一个包省时间 colcon build --symlink-install # Python包改动不用重编--symlink-install这个参数值得单独说。Python包用它之后改了.py文件不用重新build直接source一下就行开发效率提升明显。C代码改了还是得重编的。常见报错大概这么几类报错关键词大概率原因处理方向package not found没source系统环境或包名拼错检查source、检查包名找不到头文件package.xml里少了depend依赖补依赖再重编Python模块导入失败忘了--symlink-install或路径没source重编并source编译过了但运行时找不到source的是build不是installsource install/setup.bash提示编译报错时别急着搜整个报错先看第一行和最后一行。第一行通常告诉你哪个包开始出问题最后一行是根本原因中间那一大堆往往是连锁反应看了反而干扰判断。5.3 自定义 msg/srv 的完整链路当现成的消息类型不够用时就要自己定义。定义一个消息要做四件事建msg/目录、写.msg文件、在CMakeLists.txt和package.xml里声明消息生成、编译后source。# msg/MyData.msg float64 x float64 y string label编译成功后用ros2 interface show 包名/msg/MyData就能看到定义生效了。这里最容易出问题的不是写msg文件而是依赖声明如果msg里用到了别的包的消息类型必须在package.xml里加depend在CMakeLists.txt里加对应依赖少一个就编译失败。而且改完消息定义一定要重新编译整个工作空间因为依赖它的包也要重新生成代码。6. 仿真与可视化Gazebo和RViz2各自负责什么跑通小乌龟之后下一步通常是上仿真。这里有个特别常见的误解得先纠正RViz2不是仿真器Gazebo才是。6.1 RViz2 只是显示不产生数据RViz2是个可视化工具它的作用是把话题里的数据画出来给你看。激光雷达的点云、机器人的位姿、地图、路径规划结果都是别的东西算出来发到话题上RViz2订阅了之后渲染。所以如果RViz2里一片空白问题几乎肯定不在RViz2本身而是话题里根本没数据或者RViz2订阅的话题名、坐标系frame对不上。排查RViz2空白问题的顺序ros2 topic list确认话题有没有数据在RViz2里检查你添加的显示项订阅的话题名和实际话题名对不对检查Fixed Frame设置这是新手最容易忽略的。如果frame设成了map但你的数据都在odom或base_link下东西就会显示不出来或者位置乱飞。6.2 Gazebo 提供物理与传感器Gazebo才是真正干仿真的活重力、碰撞、摩擦、传感器噪声全在这里算。它会加载机器人的URDF或SDF模型把你描述的关节、连杆、传感器变成仿真世界里真实存在的东西然后按照物理规律算出传感器应该读到什么再发布到话题上。从URDF到Gazebo能加载的模型中间往往要补很多信息惯性参数质量、转动惯量、碰撞体、关节类型、传感器插件。新手做机械臂或移动机器人仿真时卡最久的一般就是URDF这一段。有个经验是先用简单的几何体方块、圆柱把结构搭对把Gazebo里的物理行为调正常再去替换成精细的模型。一上来就用复杂模型出问题你根本分不清是模型文件语法错了还是物理参数不合理。仿真和真机的链路其实是一样的都是话题、服务、Action。这也是为什么仿真值得花时间学你在仿真里调通的代码换个话题名和参数大概率能直接上真机。7. 卡住的时候按这个顺序排查讲了这么多最后落回到实际操作上。入门阶段的问题看起来千奇百怪其实高度集中在几类。下面这个排查顺序是我自己用下来最省时间的。7.1 command not found 的三种成因敲ros2提示找不到命令就三个原因没source。.bashrc里没加或者当前终端是旧终端改动没生效装了但路径不对。which ros2看有没有输出没有就说明环境变量没加进去装了两个版本。系统里有ROS1也有ROS2时两者的环境变量可能互相干扰。最简单粗暴但有效的办法是同一时间只source一个需要切换时新开终端。先查第二种再用第一种验证最后才考虑第三种。按这个顺序能避免无谓地重装。7.2 编译与运行期报错分流编译报错和运行报错要分开处理思路完全不同。编译期的问题基本是依赖、语法、版本不匹配运行期的报错则要看具体现象。运行时节点起不来先看报错是找不到包还是找不到库前者是环境问题后者可能是动态库路径没配好。节点起来了但行为不对回到第2节的思路node list看节点在不在topic list看话题有没有topic echo看数据有没有。永远从数据流这个角度去查而不是盯着代码猜。7.3 硬件与串口类问题一旦接上真实硬件问题会多一层串口权限、波特率、设备名漂移。这类问题的典型现象是昨天还好好的今天设备找不到了。原因多半是USB设备插的顺序变了/dev/ttyUSB0变成了/dev/ttyUSB1。处理这类问题的通用做法是给设备起个别名用设备的固定属性比如序列号绑定一个稳定的名字让程序去读这个名字而不是直接写死设备号。这个习惯能省掉未来无数次重新插一下就好了的无效排查。另外串口权限问题表现为打不开设备把当前用户加进串口对应的用户组就能解决加完要重新登录才生效。这类问题不难但不知道的话能卡很久。我个人在实际操作中的体会是ROS2入门的难点从来不在概念本身而在环境配置和静默失败上。概念看两遍就懂了但一个QoS不匹配、一个yaml键名写错、一个source顺序不对能让你怀疑自己是不是根本不适合这行。等你把这些坑都踩过一遍回头看会发现ROS2的设计其实相当一致所有东西都围绕节点通过话题/服务/Action通信展开QoS是通信的细则launch是启动的组织方式工作空间是代码的存放规则。把这条主线抓住了剩下的就是查文档和积累经验的事。最后分享个小习惯每配好一个环境、跑通一个例子就把当时敲的命令和踩到的坑记一笔哪怕就几句话等下次换机器或者帮别人的时候这些笔记的价值比任何教程都高。
