前面十几篇聊了感知（点云、视觉）和学习（RL、模仿学习、VLA）的各种技术。但一个真正的机器人系统不是把各种算法堆在一起就能工作的。你需要一个合理的软件架构来组织这些模块，让它们协同工作。

软件架构设计是面试中经常被问到的话题，特别是对于有工作经验的候选人。面试官想知道的不只是你会写算法，还有你能不能设计一个可维护、可扩展、可测试的系统。

机器人软件的挑战

机器人软件跟普通的应用软件有几个关键区别。

实时性要求。机器人的控制循环通常要求100Hz到1000Hz的执行频率。感知模块处理一帧点云可能需要50ms，但控制指令必须每毫秒更新一次。怎么在有限的计算资源下满足这些时间约束，是架构设计要考虑的核心问题。

异构硬件。一个机器人上可能有多个CPU、GPU、FPGA、MCU，还有各种传感器和执行器通过不同的总线连接（CAN、EtherCAT、SPI、I2C）。软件架构要能管理这些异构的硬件资源。

并发和同步。多个模块同时运行，共享数据。激光雷达在采集数据，IMU在更新姿态估计，路径规划器在计算轨迹，控制器在执行动作——这些模块之间有复杂的数据依赖和时序关系。

故障处理。机器人运行中可能出现传感器故障、通信中断、计算超时等问题。架构要有容错机制，不能让一个模块的故障导致整个系统崩溃。比如激光雷达突然断连了，导航系统不能直接崩溃——它应该切换到备用传感器（比如深度相机），同时通知操作员。这种优雅降级的能力是生产级系统的基本要求。

安全性。机器人跟人类共享工作环境时，软件的安全性至关重要。架构中要有独立的安全监控模块，不依赖于任何功能模块。即使所有功能模块都出了问题，安全监控模块也要能紧急停机。这个模块通常运行在独立的硬件上（比如安全PLC），有自己的传感器输入和继电器输出。

分层架构

最经典的机器人软件架构是分层设计。从上到下通常分为：决策层、规划层、执行层、硬件抽象层。

决策层处理高层任务——理解用户指令、选择任务策略、管理任务优先级。这一层的更新频率低（1Hz到10Hz），可以用复杂的算法。

规划层负责路径规划、运动规划、任务分解。这一层的更新频率中等（10Hz到100Hz），需要在有限时间内给出可行方案。

执行层包含控制器、状态估计器、传感器融合。这一层的更新频率高（100Hz到1000Hz），对实时性要求最严格。

硬件抽象层封装了底层硬件的驱动和通信协议，为上层提供统一的接口。

分层架构的好处是职责清晰、模块解耦。每一层只关心自己的任务，通过定义好的接口跟其他层交互。坏处是层间通信的开销——数据从底层传到顶层要经过多次拷贝和转换，延迟可能很大。

实际项目中，分层架构的变体很多。比如很多自动驾驶公司用的"感知-预测-规划-控制"四层架构。感知层融合传感器数据，输出周围环境的模型（物体位置、速度、车道线等）。预测层估计周围物体的未来行为（行人往哪走、车辆会不会变道）。规划层根据预测结果规划本车的轨迹。控制层执行轨迹跟踪。每一层的输入输出都有明确的定义，团队之间可以并行开发。

分层架构的一个常见陷阱是层间耦合太紧。比如规划层直接调用了感知层的内部函数，而不是通过定义好的接口。这种隐式依赖在代码review时不容易发现，但一旦感知层要修改（比如换一个检测算法），规划层可能也跟着出问题。解决办法是严格遵守接口契约，层间只通过数据结构（而不是函数调用）通信。

组件化架构

ROS（Robot Operating System）采用的组件化架构是另一种主流方案。每个功能模块是一个独立的节点（node），节点之间通过话题（topic）或服务（service）通信。

组件化架构的优势是灵活——你可以随时添加、删除或替换节点，不影响其他节点。不同团队可以独立开发不同的节点。调试也很方便——你可以单独测试一个节点，或者用rviz可视化任意话题的数据。

但组件化架构也有明显的问题。通信开销大——每个话题的数据都要经过消息序列化和反序列化。时序控制弱——节点之间的执行顺序和同步关系不容易保证。调试复杂系统时，节点之间的交互可能很混乱，出了问题不容易定位。

ROS2在ROS1的基础上做了很多改进：用DDS替代了自定义的通信中间件，支持实时通信；引入了生命周期节点（Lifecycle Node），可以管理节点的状态转换；支持更好的QoS策略。但核心的组件化思路没变。

组件化架构的一个挑战是数据一致性。多个节点同时读写同一个数据（比如机器人的位姿估计），怎么保证数据的一致性？ROS2的DDS支持多种QoS策略：可靠传输（保证消息不丢失）、最佳效果传输（允许丢消息但延迟低）、瞬态本地（只发给后启动的节点）。选择合适的QoS策略对系统性能影响很大。

数据驱动架构是近年来兴起的一种新范式。不同于传统的命令式控制流，数据驱动架构以数据为中心——所有模块围绕共享的数据存储（data space）工作。模块从数据存储中读取需要的数据，处理后把结果写回去。这种架构在自动驾驶中越来越流行，Waymo和Zoox都采用了类似的设计。好处是数据流清晰、容易回溯问题；坏处是对存储系统的性能要求很高。

面试中常被问到的架构问题

面试官问软件架构设计，通常从你的项目经验出发，然后追问几个方向。

为什么选择这个架构？你用了分层架构还是组件化架构？为什么这样选？如果面试官追问"如果任务需求变了，你的架构能扩展吗"，你要能回答清楚。

模块之间的接口怎么设计？接口设计是架构中最关键的部分。接口要足够抽象（适应未来的变化），又要足够具体（避免歧义）。常见的接口设计模式包括：发布-订阅（异步数据流）、请求-响应（同步调用）、共享内存（高性能数据交换）。

怎么处理实时性？哪些模块需要实时保证？怎么保证控制循环的周期稳定？如果感知模块超时了怎么办？这些问题体现了你对实时系统的理解。实际项目中，通常把控制循环放在实时线程中，感知和规划放在非实时线程中。两者之间用线程安全的缓冲区或者消息队列来传递数据。如果感知超时，控制器用上一次的有效数据继续执行，同时发出告警。

怎么测试？单元测试、集成测试、系统测试分别怎么做？有没有自动化测试框架？怎么处理硬件依赖的测试（比如没有真实传感器时怎么测试感知模块）？实践中常用的方法包括：用录制的数据回放来测试感知模块（不需要真实传感器）、用仿真环境来测试规划模块、用mock对象来替代硬件依赖。自动化测试框架可以在每次代码提交时自动运行，防止回归问题。

版本管理和部署。多个模块由不同团队开发，怎么管理版本兼容性？接口变更怎么通知下游？部署时怎么保证所有模块的版本是匹配的？这些看似"管理"的问题，实际上直接影响架构的可维护性。好的架构会在接口设计时就考虑向后兼容性——新增字段而不是修改字段，废弃旧接口而不是直接删除。

日志和监控。机器人运行时的状态监控和日志记录对调试至关重要。架构中要有统一的日志框架，支持不同级别的日志输出。关键状态（电池电量、CPU温度、通信延迟）要有实时监控和告警。出了问题能回溯日志找到原因，这是生产级系统的基本要求。

给你的建议

学习软件架构设计，最好的方式是从实际项目出发。找一个开源的机器人项目（比如Autoware、NAV2、MoveIt2），读它的代码，理解它的架构设计。然后思考：如果让你重新设计，你会怎么做？哪些地方设计得好，哪些地方可以改进？

面试前准备好你的项目架构的讲解。能用一张架构图清楚地展示模块划分、数据流、通信方式。能解释每个设计决策背后的原因——为什么用这个中间件、为什么这样划分模块、为什么选这个通信方式。

架构文档很重要但经常被忽略。好的架构文档应该包括：系统上下文图（系统和外部实体的关系）、容器图（主要的软件模块和它们之间的通信）、组件图（每个模块内部的子模块划分）。C4模型是一个很好的文档框架，从Context到Component逐层展开，不同层次的受众看不同层次的图。

常用的设计模式也值得了解。观察者模式（发布-订阅的基础）、策略模式（运行时切换算法）、工厂模式（统一创建接口）、适配器模式（接口转换）。这些模式在机器人软件中都有广泛应用。面试时能结合项目经验说出你用了哪些设计模式、解决了什么问题，会很有说服力。

还有一个容易被忽视的点：架构的演进。没有哪个架构是一开始就设计完美的，都是在实践中不断迭代的。关键是每次迭代都要有清晰的目标和评估标准——为什么改？改了之后哪个指标提升了？有没有引入新的问题？能讲清楚架构的演进过程，比单纯描述当前架构更能展示你的工程能力。

---

上一篇：第310篇 Sim2Real——从仿真到真实

下一篇预告：第312篇 模块化设计——高内聚低耦合的实践