这两年，不少制造企业面临一个现实问题：产线上已经有一套成熟的自动化设备——PLC控制的流水线、固定程序的工业机械臂、AGV搬运车——运行得还算稳定。现在想引入具身智能机器人，但发现这两拨“工人”根本说不到一块去。具身智能机器人看到传送带不知道该等多久，机械臂抓着工件走过来它也不知道避让，PLC发出的信号它听不懂。

于是出现一个尴尬的局面：新买的机器人只能单独放在一个工位上干活，和旁边的老设备老死不相往来。原本设想的“人机共融、柔性生产”变成了两套系统并行，效率不升反降。

这个问题本质上不是机器人不行，而是协同机制没打通。这篇文章聊的就是：具身智能机器人和传统自动化设备到底该怎么配合，以及企业需要做哪些准备。

一、先搞清楚两类设备的“性格”差异

传统自动化设备的特点是确定性。PLC按预设逻辑执行，工业机械臂按示教轨迹重复运动，它们的输入输出是明确的0和1。优点是稳定、速度快、可预测；缺点是僵硬，换一个产品规格就要重新编程甚至更换硬件。

具身智能机器人的特点是不确定性。它靠视觉和力觉感知环境，用大模型做决策，能应对一定范围内的变化。优点是柔性，工件歪了它能自己找正，产线换型不用重新示教；缺点是行为不那么“确定”——有时候它会停下来思考两秒，有时候它走的路径和上一次不一样。

这两种东西放在一起，天然有矛盾。确定性设备希望周围的环境也是确定的，而具身智能机器人恰恰会引入不确定性。所以协同的第一步不是技术，而是重新划分工位职责。

一个经过验证的分工方式是：传统自动化负责“快、准、重”的工序，具身智能机器人负责“活、变、细”的工序。

• 传送带高速输送、重物搬运、重复性焊接——交给传统设备。

• 混线生产中的换型调整、精密装配、异常处理、物料分拣——交给具身智能机器人。

二者不是替代关系，而是上下游或并行的协作关系。

二、打通协同的四个技术关卡

如果确定要在一个工站里让两类设备一起干活，下面这几个坎必须迈过去。

1. 通信协议的统一

传统自动化设备的“母语”是Profinet、EtherCAT、Modbus TCP这些工业总线协议。而具身智能机器人通常跑的是ROS 2，上层用HTTP或WebSocket对外通信。两边直接对话就像一个人说中文一个人说俄语。

解决方式有两种。一种是在中间加一个协议转换网关，把ROS的消息转成PLC能读的字节流，反之亦然。另一种更彻底一些：在具身智能机器人的控制器里直接集成工业协议栈，让它能作为Profinet从站接入产线网络。

由你创在做定制开发时，通常会选择第二种方案——因为少一个中间节点就少一个故障点。我们在控制器底层就把EtherCAT主站跑起来，具身智能机器人可以像一台高级伺服驱动器一样被PLC直接调用。

2. 安全信号的硬线互锁

通信可以走网络，但安全信号不行。当一个机器人伸手进入传统机械臂的工作区域时，必须用硬线信号来保证互锁，不能依赖网络通信的可靠性。

标准做法是：在两类设备的急停回路里串入对方的安全输出。如果具身智能机器人的安全PLC检测到风险，直接切断传统机械臂的动力电源；反之亦然。这套硬线逻辑和网络状态无关，任何时候都有效。

3. 空间占用的动态协调

传统自动化设备通常有固定的安全围栏，划定一个区域不允许人或其他设备进入。但具身智能机器人需要频繁进出这些区域去取料或放料。如果每次都让机械臂停下来等，效率就没了。

更聪明的办法是引入动态安全区域。当具身智能机器人要进入某个工位时，它先通过无线信标或视觉定位向区域控制器发送请求，区域控制器判断当前机械臂的状态——如果机械臂正在高速运动就拒绝，如果处于低速或暂停状态就批准，并临时缩小机械臂的安全边界。机器人完成任务退出后，安全边界恢复。

这套机制在传统的PLC逻辑里写起来非常繁琐，但用具身智能机器人的感知和决策能力来做反而自然——它能“看见”机械臂当前在干什么，而不是死等一个信号。

4. 任务粒度的重新拆解

最容易被忽视的是软件层面的协同。传统自动化产线的任务通常被拆解成固定的步骤序列——Step 1、Step 2、Step 3……每个步骤的触发条件是前一步完成。但具身智能机器人执行任务的时间是不固定的，有时候快有时候慢，取决于工件的状态和环境。

如果还是用固定序列去驱动，整个产线会被最慢的那个机器人拖累。正确的做法是把任务拆成更细的事件驱动模型：不是“机器人A完成后触发机器人B”，而是“当工件到达工位X且当前设备空闲时，有能力处理该工件的任意设备去执行”。

这种柔性编排，传统PLC也能做，但逻辑会非常复杂。更好的方式是用一个上层调度系统（MES或者专门的协同控制器），具身智能机器人和传统设备都作为执行单元接入，由调度系统根据实时状态动态派单。

三、从实际案例看协同的价值

去年一个做家电总装的客户遇到了典型的“协同问题”。他们的产线上有六台传统SCARA机器人负责锁螺丝，锁完螺丝后需要有人把半成品搬到下一工位进行功能测试。搬运工作简单但频繁，工人一天要走两万步，离职率很高。

他们想过用AGV，但工位之间的通道太窄，AGV转不过弯。后来引入了一台双轮足式具身智能机器人，上半身是一个轻型机械臂，下半身是能原地旋转的轮式底盘。这台机器人和SCARA之间的协同是这样设计的：

• SCARA锁完螺丝后，通过PLC发一个“完成”信号到调度网关。

• 具身智能机器人收到信号后，导航到该工位，用视觉确认工件位置，抓取。

• 抓取的同时，它通过无线信号通知SCARA“我正在取件，请不要启动下一次锁付”。

• 运送到测试工位后，再通知测试设备开始检测。

整个过程没有改造SCARA的程序，只是在PLC里加了几行信号转发。但原来需要一个人全职搬运的工位，现在一台机器人全部搞定。客户的产线规划负责人后来说了一句很实在的话：“以前觉得新设备和老设备肯定打架，没想到只要把接口想清楚，它们配合得比人还默契。”

四、如果你想做协同，从哪里开始

如果你的企业也面临类似的情况——老产线上有传统自动化设备，想引入具身智能机器人但又怕两套系统打架——建议从下面几个步骤开始：

1. 画出当前产线的物料流和信息流，标出哪些环节是瓶颈、哪些环节适合引入柔性操作。

2. 明确新旧设备之间的交接点：物料在哪里传递？信号从哪里触发？安全边界在哪里？

3. 评估通信接口：现有的PLC和机器人支持哪些协议？是否需要网关或控制器升级？

4. 做一个小范围试点：先在一个工站上实现“具身智能机器人取料—传统设备加工—具身智能机器人放料”的小闭环，验证可行性后再推广。

在这些步骤中，最容易被卡住的是通信接口和任务调度的设计。不同品牌的PLC、不同年代的设备，协议千差万别，没有通用的“即插即用”方案。

由你创机器人在做定制开发时，很大一部分工作就是解决这类“新老对话”的问题。我们不只提供具身智能机器人本体，还会根据你现有产线的设备清单、通信协议和控制架构，设计一套最小改动的协同方案。目标不是让你推倒重来，而是在现有投资的基础上，把具身智能机器人的灵活性真正用起来。

如果你对具体的协同方案感兴趣，可以拿一条产线的图纸和需求过来，由你创的技术团队会帮你做一个免费的协同可行性评估——不收费、不推销，只是告诉你这件事能不能做、大概需要改哪些地方。