企业官网建设流程全解析

面试翻车现场

面试时面试官问："你在ROS2项目中遇到过最难排查的bug是什么？怎么解决的？"

我讲了个话题通信不通的问题，最后发现是QoS不匹配。面试官追问："除了QoS，你还用过哪些调试工具？怎么定位性能瓶颈？"

这个问题让我意识到，调试能力是面试官非常看重的。写代码谁都会，但出了问题能快速定位，才是真正体现水平的地方。有经验的工程师和新手最大的区别，往往不在编码速度上，而在排查问题的效率上。

通信类问题排查

ROS2最常见的问题就是通信不通。排查思路要系统化。

第一步，ros2 topic list看话题是否存在。如果不存在，说明发布者或订阅者没有正确启动，或者节点名称/命名空间搞错了。

第二步，ros2 topic info /your_topic看话题的类型和发布者/订阅者数量。如果发布者数量为0，说明发布节点没跑起来或者话题名拼错了。

第三步，ros2 topic echo /your_topic看数据是否正常发布。如果没有数据输出，可能是发布者逻辑有问题（比如回调没触发）。

第四步，如果发布正常但订阅者收不到，检查QoS兼容性。ros2 topic info /your_topic -v可以看到详细的QoS配置。Reliability和Durability不匹配会导致通信失败。

第五步，检查DDS域ID。ROS_DOMAIN_ID环境变量不同的机器上的节点互相看不到。

性能问题排查

性能问题比通信问题更难排查，因为你不知道瓶颈在哪里。

ros2 topic hz /your_topic——检查话题的发布频率。如果频率比预期低，说明发布端的处理逻辑有问题。

ros2 topic bw /your_topic——检查话题的带宽占用。大数据量话题（点云、图像）的带宽可能很高，导致DDS传输延迟。

rqt_graph——可视化节点和话题的连接关系。如果连接关系和预期不符，说明某些节点没有正确启动或者话题名配置错误。

rqt_console——查看日志输出。可以按级别过滤（DEBUG/INFO/WARN/ERROR），按节点过滤。调试时多用RCLCPP_DEBUG输出关键变量。

rqt_plot——实时绘制数据曲线。调试PID参数、传感器数据、控制输出时特别好用。选一个话题的一个字段，实时看波形。

更底层的性能分析可以用perf工具（Linux性能分析神器）或者valgrind（内存泄漏检测）。但这些工具的使用门槛比较高，建议先熟悉ROS2层面的调试工具。另外rqt系列工具是个宝库——rqt启动后可以看到所有可用的插件，包括话题监控、服务调用、参数编辑、日志查看等。很多调试需求在rqt里都有对应的插件。

TF问题排查

TF问题在机器人开发中非常常见，排查起来有固定的套路。

ros2 run tf2_ros tf2_monitor——监控所有TF变换的发布频率和延迟。如果某个变换的发布频率很低或者延迟很大，问题就出在那里。

ros2 run tf2_ros tf2_echo source target——查看两个坐标系之间的变换值。看数值是否符合预期。

view_frames——生成TF树的PDF图。看树结构是否完整，有没有断开的分支。如果某个坐标系没出现在图中，说明对应的变换没有发布或者frame_id写错了。

TF问题的常见原因：发布频率太低（传感器驱动问题）、时间戳不对（时钟同步问题）、frame_id拼写错误（低级但常见）、TF树断裂（中间缺少某个变换的发布）。

内存和崩溃排查

ROS2节点崩溃时，如果有core dump，可以用GDB分析。gdb ./your_node core加载core文件，用bt命令看调用栈，定位崩溃位置。

内存泄漏可以用valgrind --leak-check=full ./your_node检测。但valgrind会让程序慢10-50倍，只适合短时间调试。

ROS2本身的日志系统也可以帮助排查。设置日志级别：ros2 service call /your_node/set_logger_level rcl_interfaces/srv/SetLoggerLevel "{logger_name: 'your_node', level: 10}"（10是DEBUG级别）。

Launch文件调试

Launch文件出错时，排查思路和代码调试不太一样。

"节点启动后立刻退出"——通常是节点代码有异常，或者参数配置错误。在Launch文件里给节点加上output: 'screen'参数，这样节点的输出会直接打印到终端，方便看错误信息。

"多个节点之间有依赖但启动顺序不对"——用RegisterEventHandler和OnProcessExit来编排启动顺序。比如让节点B在节点A启动完成后再启动。

"参数传递不生效"——检查Launch文件中的参数文件路径是否正确。ROS2 Launch中参数文件的路径是相对于Launch文件所在包的，用PathJoinSubstitution可以拼接路径。另外检查参数名是否和节点中声明的参数名一致。

"条件启动不工作"——IfCondition和UnlessCondition接收的是字符串'true'或'false'，不是Python的布尔值。如果传了LaunchConfiguration变量，确保它的值是字符串格式。

常见错误模式总结

做了一段时间ROS2开发，你会发现很多错误是反复出现的。总结几个最常见的：

"话题名拼写错误"——/scan写成/Scan，/cmd_vel写成/cmdvel。ROS2话题名区分大小写，这种错误编译器不会报错，但通信就是不通。建议统一用下划线命名法，建立话题名规范。

"消息类型不匹配"——发布者和订阅者的消息类型不一致。比如一个发geometry_msgs/Twist，另一个订阅geometry_msgs/TwistStamped。编译器能检查到，但如果你用的是动态类型的桥接节点，运行时才会发现。

"时间戳为0"——很多算法依赖消息的时间戳来关联TF。如果时间戳是0，TF查询会用最新数据，可能导致对齐不准。发布传感器数据时一定要填正确的时间戳。

"frame_id不匹配"——消息中的frame_id和TF树中的坐标系名不一致。比如消息里写的是laser，TF树里叫laser_link。这种错误会导致TF查询失败。

建立系统化的调试流程

高效的调试不是靠灵感，而是靠流程。

遇到系统问题时，先确定问题的边界。是从数据输入端开始的（传感器数据异常），还是中间处理环节（算法逻辑错误），还是输出端（执行器不响应）？用二分法缩小范围：在数据流的中间位置插入检查点，看数据是否正常。如果中间正常，问题在后半段；如果不正常，问题在前半段。

日志分级很重要。开发阶段多用DEBUG级别输出详细信息，上线后切到INFO或WARN减少日志量。ROS2的日志系统支持运行时动态调整日志级别，不需要重启节点。用rqt_console可以实时过滤和查看各节点的日志输出，比在终端里翻日志高效得多。

分享一个我排查过的比较复杂的bug。当时一个导航系统偶尔会出现"机器人原地转圈"的问题，复现概率大概10%。排查过程是这样的：首先用ros2 topic echo检查cmd_vel输出，发现转圈时角速度异常大。然后往前追溯，发现是规划器发出的全局路径有一个急转弯。再往前查，发现是代价地图里有一块区域的膨胀代价异常高。最后定位到是激光雷达偶尔会返回一个距离很远的噪点（大概是传感器内部的反射），这个噪点打到代价地图上形成了一个大的障碍物。解决办法是在激光雷达驱动端加了一个距离滤波，把超出合理范围的点直接丢掉。这个bug从发现到定位花了两天，但如果一开始就有系统化的排查流程（从输出端往前逐级追溯），可能半天就能搞定。

面试中怎么聊

面试官问调试技巧，你可以说："通信问题用topic list/info/echo三步排查，重点检查QoS兼容性。性能问题用topic hz/bw看频率和带宽，rqt_graph看连接关系，rqt_plot看数据波形。TF问题用tf2_monitor看发布频率，tf2_echo看变换值，view_frames看树结构。崩溃问题用GDB分析core dump，内存泄漏用valgrind。调试能力是做项目最重要的能力之一。"

上一篇：第138篇 MoveIt2进阶——场景配置、约束规划和拾取放置

下一篇预告：第140篇 ROS2性能优化——通信延迟、内存占用和CPU优化