机器人系统软件与具身智能
让机器人抬起一只手，看起来只是执行了一个动作。但对软件系统来说，它可能经过任务规划、消息传输、回调执行、关节控制、驱动通信和位置反馈。每一段都可能影响动作是否及时、准确，以及出现异常时能否停在预期状态。
这就是本专栏的起点：关注机器人怎样把一个决定变成可执行、可观测、可验证的动作。 从熟悉的 C++、嵌入式实时系统和通信问题出发，逐步走进 Linux、ROS2、控制框架和具身智能系统。文章不把每一种技术当成孤立知识点，而是放回具体的运行路径中讨论。
读者不需要先掌握运动控制或深度学习。如果已经熟悉嵌入式软件，可以从车载系统经验怎样迁移开始；想直接弄清 ROS2 消息的执行过程，可以跳到控制指令的执行链路。
阅读路线
| 阅读入口 | 文章 | 可以带走的理解 |
|---|---|---|
| 01 · 建立全貌 | 人形机器人系统软件的技术能力地图与工程实践路线 | 机器人软件各层各管什么；为何先学通信、运行时和硬件接口 |
| 02 · 理解执行过程 | 一条 ROS2 控制指令的执行路径：从消息到回调，再到控制时效 | Topic、DDS QoS、Executor、Callback Group 怎样影响指令抵达和处理 |
| 03 · 进入实际实验 | 待 ROS2 C++ 节点与数据采集完成后更新 | 把发布周期、接收间隔、序号缺口和调度影响拆开测量 |
| 04 · 连接控制接口 | 待 Mock Hardware 与 ros2_control 仿真验证 | 区分上层命令、控制器更新周期、状态/命令接口 |
| 05 · 接入感知与智能 | 待模型接口和仿真系统验证 | 处理不同频率、过期动作、反馈与异常 |
建议顺序：先读第一篇，看清软件分层；接着读第二篇，沿一条指令分析通信与调度。后续涉及运行时指标和故障模型时，可以穿插阅读本站已有的嵌入式运行时测量专题。
一条控制指令在系统中经历什么
设想一台在仿真环境中的双关节机械臂。任务层要求它把末端移动到某个位置。这里不急着讨论复杂的轨迹算法，先看软件需要共同完成的事情：
任务 / 感知 看见什么？想完成什么？
│
▼
规划 / 动作生成 目标位置、关节目标或轨迹
│
▼
ROS2 通信与执行器 Topic / Action → DDS → Executor 回调
│
▼
运行时与控制接口 数据是否过期？状态是否允许执行？
│
▼
控制器 / 硬件抽象 读取关节状态 → 计算输出 → 写入命令
│
▼
仿真模型或驱动 产生运动及位置 / 速度 / 力矩反馈
│
└─────────────── 状态反馈到控制、规划和任务层这是一张职责图，并不是要求所有机器人都按相同顺序部署进程。某些机器人把高频控制留在独立实时控制器中，ROS2 只承担任务目标、状态或较低频率的控制指令传递。把所有节点都放进一个 ROS2 Executor，也不会自然得到确定的实时性。
真正需要回答的四个问题
| 问题 | 涉及的机制 | 工程上如何验证 |
|---|---|---|
| 消息能否送达？ | Topic、DDS 发现、QoS 相容性、网络/进程边界 | 从发送端和接收端记录序号、配置与拓扑 |
| 消息何时被处理？ | Executor、Callback Group、线程调度、回调负载 | 记录到达事件与回调执行时刻，构造忙碌回调 |
| 旧命令能否继续执行？ | 时间戳、有效期、最新状态、控制授权 | 注入过期或乱序命令，观察拒绝和状态变化 |
| 动作是否符合预期？ | 控制器、关节接口、硬件/仿真模型及反馈 | 对照命令、实际关节状态与误差，不只看可视动画 |
这四个问题对应不同层次。消息“可靠送达”，不代表回调立即执行；回调执行，也不代表输出命令仍然有效；关节动起来，也不能证明控制系统已满足安全与实时要求。
把 ROS2、Linux 和控制框架放在各自的位置
ROS2 / DDS：让组件交换有语义的数据
ROS2 负责节点、消息接口与执行框架；DDS 是常见的底层通信中间件方案。Topic 适合连续数据，Service 适合有界请求与响应，Action 适合持续一段时间、需要反馈和取消的目标任务。究竟使用哪一种接口，要由业务语义决定，不能简单按“实时/非实时”分类。
QoS 决定历史缓存、可靠性、持久性等策略，还要关注发布端与订阅端的相容性。传感器状态可能更看重新鲜度，配置类消息可能强调可靠取得；但Reliable 不是低延时保证，Best Effort 也不等于不值得信任。实际选择取决于采样周期、丢失容忍度和应用的恢复逻辑。
Executor / Linux：消息到了，也得有人运行回调
Executor 的职责是选择已经就绪的回调并执行。回调可能来自订阅、定时器、Service 或 Action。单线程 Executor 中，长回调会推迟后续处理；换成多线程也不意味着所有回调都并发，Callback Group 的互斥约束仍然有效。
Linux 线程调度、CPU 负载、锁竞争、内存分配及系统中断共同影响实际时间。分析性能时，至少要分清发送周期、订阅回调间隔和控制器更新/反馈周期，避免用一个“延时”替代所有环节。
ros2_control：把控制器与硬件接口连接起来
ros2_control 提供控制器管理和硬件抽象机制。以常见 Controller Manager 模型为例，控制循环的关键工作是读取硬件状态、执行控制器更新、写出控制命令。硬件组件的生命周期、状态接口和命令接口需要和驱动或仿真模型对应。
它并不规定感知模型应该如何训练，也不保证任意 ROS2 节点满足硬实时。真正能否达到目标周期，还取决于控制器工作负载、线程策略、驱动和所用平台。
从车载软件到机器人系统哪些经验值得保留
嵌入式开发中的许多问题在机器人身上仍然存在，只是边界换了。与其把既有经验全部丢掉，不如先识别哪些工程方法可以直接帮助定位问题，再补上机器人特有的软件栈。
| 熟悉的工程问题 | 在机器人里会遇到什么 | 新增的知识 |
|---|---|---|
| 周期任务、抢占和多核执行 | 控制线程与 ROS2 回调的调度关系 | Linux 调度、Executor、Callback Group |
| SOME/IP、CAN 和 Ethernet 通信 | 节点发现、Topic 数据传输和控制器链路 | DDS、RMW、QoS 与 ROS2 接口 |
| 共享状态与跨核一致性 | 订阅回调、控制状态和诊断数据的访问竞争 | C++ 并发、生命周期、数据所有权 |
| 运行时 CPU / ISR / Stack 统计 | 控制周期抖动、线程占用与瓶颈追踪 | 主机观测、实验时钟及数据分析 |
| 诊断、超时和恢复机制 | 过期指令、节点失联、控制状态降级 | 机器人状态机、硬件/仿真行为约束 |
| 视觉模型评估 | 感知结果传递到任务与动作接口 | 坐标变换、运动学、执行反馈 |
这里有两篇相关的已发表技术文章，适合与机器人内容交叉阅读：
- 嵌入式 CPU 负载测量：Task、Idle 与 ISR：怎样定义被测时间，为什么不能只凭一个百分比判断系统时序。
- 跨核不是缓存问题：从 AUTOSAR COM Deferred EventCache 看事件与状态一致性：状态、事件、顺序与并发之间是什么关系。注意其中的 AUTOSAR 机制不能直接等同于 ROS2 实现。
这种迁移关注的是分析问题的方法，不是把 AUTOSAR 的接口改个名字后直接移植到 ROS2。
一个小实验，怎样逐步接近真实问题
从 100 Hz ROS2 Publisher → Subscriber 开始是合理的：它足够小，能在普通开发环境里运行，又包含定时、通信、调度和观测四类问题。
目标频率 100 Hz 对应 10 ms 名义周期。但“设定每 10 ms 发布一次”和“每条消息恰好间隔 10 ms 被处理”不是一回事。
| 观察对象 | 实际要记录的事件 | 结果如何解释 |
|---|---|---|
| 发布端 | 相邻两次发送调用时刻 | 用户态发布循环的实际周期及抖动 |
| 接收端 | 相邻两次订阅回调进入时刻 | 消息处理的观测间隔，混合了通信与调度影响 |
| 序号 | 发布序号与接收序号 | 查找缺口，需排除订阅晚启动、队列覆盖等因素 |
| QoS | Reliability、History、Depth、RMW | 在明确条件下比较不同配置的行为 |
| 负载 | 回调工作时间、线程/CPU环境 | 观察忙碌回调和操作系统调度对间隔的影响 |
第一轮先记录基线；第二轮只改变一个条件，例如订阅回调的负载。每轮保留原始记录、系统与 ROS2/RMW 版本、执行器类型、QoS 和统计脚本。用 P50、P95、P99 与最大值描述观测分布，再分析异常点。不能因为多数样本接近 10 ms，就推出控制环路具有 10 ms 的硬实时保证。
在不同机器上记录单向时延时，还需要合适的时钟同步及误差预算；直接相减两台机器的单调时钟没有可比意义。
下一步才是把消息接入 Mock 关节接口，观察命令、状态反馈与故障处理。先让问题可测，再考虑让系统更复杂。
技术范围与验证约定
工程实践将怎样继续
这里不是把一份学习计划改写成发布日历。每个主题都需要能回答的工程问题，以及与之匹配的实现或公开来源。
| 阶段 | 工程切入点 | 文章所要解释的机制 |
|---|---|---|
| 基础通信与运行时 | C++17/20、Linux、ROS2 Pub/Sub、Executor、QoS | 从发布到回调到底经过什么，周期抖动如何测量 |
| 控制与仿真 | ros2_control、Mock Hardware、关节状态、简单运动学 | 控制器怎样连接状态、命令和硬件接口 |
| 平台可靠性 | 状态机、超时、故障注入、追踪和监控 | 何时拒绝过期指令，异常后如何恢复 |
| 智能系统集成 | 感知输出、任务/动作接口、不同周期协调 | 推理结果怎样在有效期内转成受控动作 |
| 整体验证 | 架构、自动化测试、可复现演示 | 用什么证据说明平台确实解决了问题 |
目前已经公开的是架构与机制说明；配套私有实验仓库具备 C++17 构建、测试和用户空间定时基线，ROS2 通信、控制仿真和整机反馈还没有可公开的完成证据。未来只有在实验实际完成后，才会更新这些主题的验证结论。实验代码也必须经过独立脱敏审查，不能把私有仓库地址当作读者可以直接访问的公开源码。
相关公开资料
比起一开始搜集数十份教程，先保留几个能直接解决工程问题的文档更有用：
- ROS2 Jazzy 官方文档——整体API和发行版文档入口。
- ROS2 Jazzy：Executors——回调为什么会等待、如何安排执行上下文。
- ROS2 Jazzy：QoS——History、Depth、Reliability 与端点相容性。
- ROS2：Callback Groups——多线程 Executor 中的互斥与可重入。
- ros2_control 文档——机器人控制框架文档入口。
- ros2_control：Getting Started / Architecture——Controller Manager、控制器和硬件组件的职责。
- MuJoCo 文档——仿真环境的官方入门。
继续阅读： 技术能力地图与路线 → ROS2 控制指令执行路径。也可以返回技术专题或浏览全部文章。