187、机器人软件架构设计：模块化可扩展与实时性兼顾的系统昨晚在实验室调一台六轴机械臂的抓取程序，又碰到老问题——视觉节点刚把目标位姿发出来，运动控制节点那边已经超时丢包了。控制周期是1ms，视觉推理跑一次要80ms，中间还隔着一层ROS2的DDS通信，消息在队列里排队等着，等控制节点真正拿到数据，机械臂早就不知道跑到哪里去了。这种问题不是第一次遇到，每次都是临时加个缓冲区或者把视觉频率调低糊弄过去，但治标不治本。今天索性把机器人软件架构这件事彻底捋一遍，把我这些年踩过的坑和沉淀下来的设计思路写出来，希望能帮到正在被实时性和模块化折磨的同学。先说说为什么机器人软件架构这么难搞。普通软件架构追求的是高内聚低耦合、可测试性、可扩展性，这些在机器人系统里当然也重要，但机器人多了一个普通软件没有的维度——物理世界的实时约束。你的算法再漂亮，如果控制指令晚到1ms，机械臂可能就撞上桌子了。所以机器人架构本质上是在两个互相拉扯的目标之间找平衡：一边是模块化带来的灵活性和可维护性，另一边是硬实时要求带来的确定性和低延迟。我见过太多团队在这上面栽跟头。有的团队一上来就搞微服务，把感知、规划、控制、状态估计全拆成独立进程，用消息队列通信，结果发现消息在进程间传来传去，延迟累积到几十毫秒，根本没法做力控。有的团队反过来，把所有东西写成一个巨大的单进程，共享内存直接访问，实时性是保证了，但改一行代码要重新编译整个项目，加一个新传感器要动十几个文件，代码review的时候谁都不敢碰。我自己比较推荐的做法是分层加分区，不是一刀切。核心思想是：把系统分成几个层次，每个层次内部用适合该层次的方式组织，层次之间用明确定义的接口通信。具体来说，从上到下大致是：决策层、规划层、控制层、驱动层。