2. EGM通信架构与数据流

EGM（Externally Guided Motion）不是一条“把位置发给机器人”的单向通道，而是一套由控制器内部选项、网络传输层和外部客户端共同构成的闭环运动控制链路。理解这条链路的关键，是分清三个角色：EGM控制器负责在RobotWare中生成并维护实时运动流；RobotWare选项决定控制器是否具备该能力以及以何种模式运行；外部客户端则是上位机、视觉系统或力控算法所在的程序，它周期性地产生目标位姿并接收机器人反馈。三者通过UDP在同一网段内交换固定格式的数据包，形成“客户端下发目标—控制器插补执行—控制器回传状态—客户端修正目标”的循环。

一、通信链路中的三个角色

EGM控制器位于IRC5或OmniCore控制器的运动控制层，它并不直接暴露给普通RAPID程序，而是通过RobotWare选项EGM（Externally Guided Motion）启用。该选项提供两类典型接口：一类是位置引导（Position Guidance），客户端发送目标位姿，控制器在允许的范围内进行轨迹修正；另一类是速度引导（Velocity Guidance），客户端发送速度指令，控制器按速度积分生成运动。选项还决定了可用的坐标系、最大修正量、超时阈值等约束参数。

外部客户端通常运行在PC或工控机上，使用C++、C#或Python等语言实现UDP套接字。客户端必须知道控制器的IP地址和EGM端口号（默认6510用于UDP通信，具体以控制器配置为准），并按EGM协议规定的数据包结构进行收发。客户端不是“发一次就结束”，而是以固定周期持续发送，周期通常为4ms、8ms或16ms，对应250Hz、125Hz或62.5Hz的控制频率。

二、UDP数据流方向与包结构

EGM使用UDP而非TCP，原因是UDP没有重传和拥塞控制带来的不确定延迟，更适合硬实时周期通信。代价是丢包不会自动恢复，因此EGM协议在应用层设计了序号、时间戳和超时判断。数据流方向可以概括为：

• 客户端→控制器：发送EgExternalData包，包含目标位姿（位置x、y、z，姿态四元数q1~q4）、速度前馈、加速度前馈、以及客户端期望的传感器数据等。
• 控制器→客户端：回传EgRobotData包，包含机器人当前关节角、TCP位姿、速度、加速度、以及EGM状态字（如是否激活、是否超时、是否达到修正限幅）。

两个方向的数据包都带有sequenceNumber和timestamp。控制器用序号判断是否收到新指令，用时间戳计算通信延迟。如果客户端在Timeout时间内没有发送新包，控制器会触发超时保护，停止EGM运动并可能报错。这个超时值通常设置为控制周期的3~5倍，例如周期4ms时超时设为20ms，既容忍偶发丢包，又不会让机器人长时间失控。

三、实时性约束与工程判断

EGM的实时性不是“越快越好”，而是“稳定周期优先”。控制器内部有一个EGM插补周期，通常与客户端发送周期一致或为其整数倍。如果客户端发送周期抖动过大，控制器会认为指令不连续，可能触发EGM_OVERRUN或EGM_TIMEOUT。因此工程上要求客户端使用高精度定时器，避免在发送线程中做文件读写、界面刷新等阻塞操作。

另一个关键约束是修正限幅。EGM位置引导模式下，控制器不会无条件跟随客户端目标，而是限制每个周期内允许的位置修正量。例如设置MaxPositionDeviation为50mm，意味着机器人TCP与原始路径的偏差超过50mm时，控制器会拒绝继续跟随并报错。这个参数既保护机器人不因客户端错误指令而剧烈运动，也要求客户端的目标位姿必须连续、平滑，不能跳变。

网络层面，EGM要求客户端与控制器在同一子网，建议使用千兆交换机直连或专用VLAN，避免与视觉图像流、文件传输共用带宽。UDP包本身很小（通常几百字节），但周期极短，因此抖动比平均延迟更致命。可以用ping观察往返时间，但更准确的方法是读取EGM回传包中的时间戳，计算客户端发送时刻与控制器接收时刻的差值，连续记录并观察其分布。

四、典型配置参数与检查要点

最后需要强调：EGM通信链路中，控制器始终是“安全责任方”。即使客户端发送了错误目标，控制器也会依据选项配置和限幅参数进行拦截。因此，掌握EGM通信架构不仅是理解UDP收发，更是理解客户端意图与控制器约束之间的边界。只有把周期、超时、限幅、坐标系这四个约束同时纳入设计，EGM才能稳定地用于实时运动控制。