2. 机器人系统架构概览：感知-规划-控制分层与ROS2通信
做机器人系统调优，第一件事不是看代码，而是看架构。我见过太多团队一上来就盯着某个算法模块死磕，结果发现瓶颈根本不在那里——数据流堵在中间件层，或者感知和规划之间的通信延迟把整个系统拖垮了。
这一章，我们就把机器人系统的骨架拆开来看。说白了，就是搞清楚数据从哪里来、经过谁、到哪里去，以及为什么慢。
2.1 典型机器人系统分层：感知-规划-控制
几乎所有移动机器人，不管是用激光雷达还是视觉，都逃不出这三层结构。我习惯把它们叫做「三驾马车」：
- 感知层：负责把传感器原始数据变成有意义的信息。比如激光雷达的点云 → 障碍物检测 → 定位。
- 规划层：根据感知结果，决定下一步怎么走。全局路径规划 + 局部运动规划。
- 控制层：把规划出的轨迹变成电机指令。PID、MPC 都在这一层。
你想想看，这三层之间是典型的「上游产粮、下游吃饭」的关系。感知慢了，规划就饿着；规划慢了，控制就抖。
核心观点： 调优的本质，就是让这三层之间的数据流「跑得稳、跑得快、不堵车」。
下面这张图是我在项目中常用的分层结构，你可以把它当作本章的「地图」：
2.2 ROS2节点通信机制：数据流的「血管」
分层架构搭好了，节点之间怎么说话？ROS2 给了我们几种方式。我建议你记住一个原则：选对通信方式，比优化算法更管用。
| 通信方式 | 适用场景 | 典型延迟 | 我踩过的坑 |
|---|---|---|---|
| Topic（发布-订阅） | 周期性数据流（点云、速度指令） | 1-10 ms | QoS 设置不当导致丢包 |
| Service（请求-响应） | 偶发调用（地图保存、参数查询） | 5-50 ms | 同步调用阻塞主循环 |
| Action（带反馈的异步任务） | 长时间任务（导航、机械臂运动） | 10-100 ms | 反馈频率太高反而增加开销 |
我的习惯： 激光雷达点云这种大带宽数据，一定要用 Topic + 合适的 QoS（比如 KeepLast + Depth=1）。别用 Service 去传点云，那等于让快递员每次扛一吨货走楼梯。
为什么会这样？因为 ROS2 底层用的是 DDS（数据分发服务）。DDS 的好处是去中心化、自动发现节点，坏处是——如果你不调 QoS 参数，默认配置可能让你的系统「看起来通，实际上堵」。
2.3 数据流与延迟瓶颈分析：找到「堵点」
好，架构有了，通信方式也选了。接下来是最关键的一步：找出数据流中到底哪里慢。
我在项目中遇到过这样一个案例：一台搭载 16 线激光雷达的 AGV，导航时总是走走停停。一开始以为是规划算法太慢，结果一测——感知层处理一帧点云要 80ms，而规划层每 50ms 就要一次数据。感知跟不上，规划只能等，控制自然就抖了。
这就是典型的「感知瓶颈」。怎么定位？我一般用三步：
- 打时间戳：每个关键节点（传感器回调、算法输出、发布）都打上系统时间戳。
- 画流水线图：把每个模块的处理时间画出来，看谁最慢。
- 测端到端延迟：从传感器数据产生到控制指令发出，总耗时多少。
注意： 不要只看平均延迟。我曾经被平均延迟骗过——平均 30ms，但偶尔跳到 200ms。这种抖动对控制层是致命的。一定要看 P99 延迟。
下面这张图展示了一个典型的激光雷达机器人数据流，以及常见的瓶颈位置：
2.4 延迟瓶颈的常见「元凶」
根据我这些年调过的机器人系统，延迟问题通常出在以下几个地方。你可以对照自己的项目检查：
- 感知层：点云降采样太暴力。我曾经为了省算力，把 64 线点云直接降采样到 1/10，结果障碍物检测漏检率飙升。后来改用体素滤波 + 自适应参数，延迟从 35ms 降到 12ms，精度还没掉。
- 规划层：全局路径规划频率过高。A* 算法在复杂地图上跑一次可能要 100ms，但实际场景中地图变化没那么快。我建议全局规划跑 1Hz 就够了，局部规划跑 10-20Hz。
- 通信层：Topic 带宽打满。ROS2 的 DDS 默认配置可能让点云数据重复传输。用
rmw_fastrtps的BEST_EFFORT+KEEP_LAST(1)能显著降低带宽占用。
一句话总结： 调优不是让每个模块都快，而是让整个数据流「匹配」。感知 20ms、规划 30ms、控制 10ms，加起来 60ms，比感知 10ms、规划 100ms、控制 10ms 的 120ms 要好得多。
2.5 本章小结
嗯，这一章我们把机器人系统的骨架搭起来了。你记住三件事：
- 分层架构是基础，数据流是命脉。
- ROS2 通信方式选不对，后面全白费。
- 延迟瓶颈要「测」出来，不是「猜」出来的。