2. 机器人控制系统基础

机器人控制系统是连接感知、决策与执行的枢纽。在排查通信延迟、动作误触发和状态不同步等问题之前，必须先理解控制系统的基本骨架：它由哪些模块组成、模块之间如何对话、系统如何管理自身状态、以及一条指令从下发到执行完毕需要经过哪些环节。本章从工程实践角度拆解这四个核心维度，为后续排错建立共同语言。

上图展示了机器人控制系统的基本分层架构。感知层负责采集环境与本体状态，决策层运行状态机和规划算法，执行层驱动电机与IO设备。三层之间通过实时总线通信，并依赖反馈回路实现状态同步。排错时，首先要判断问题发生在哪一层、哪条链路上，才能避免盲目修改参数。

2.1 典型架构：集中式、分布式与混合式

机器人控制系统的物理架构决定了通信延迟的上限和故障传播的范围。理解架构类型是排错的第一步。

核心原理

集中式架构中，所有传感器和执行器直接连接到单一控制器（如工业PC + 运动控制卡）。优点是同步性好、调试简单；缺点是线缆繁多、单点故障风险高。分布式架构中，每个关节或功能模块配备独立微控制器（MCU），通过总线互联（如EtherCAT、CANopen）。优点是布线简洁、模块可独立更换；缺点是节点间通信延迟累积、时钟同步复杂。混合式架构则结合两者：关键轴采用集中控制，辅助轴或IO模块分布式部署，兼顾性能与灵活性。

判断方法

排查架构相关问题时，按以下步骤操作：

1. 绘制系统拓扑图，标注所有控制器、驱动器、传感器节点及其连接方式。
2. 测量各节点之间的通信周期和抖动（使用总线分析仪或控制器内置诊断功能）。
3. 对比设计指标：EtherCAT 理论抖动 <1μs，CANopen 典型周期 1-10ms。
4. 检查是否有节点在通信中掉线或重连（日志中会出现"Node Lost"或"Sync Error"）。

案例拆解：AGV 分布式架构的延迟波动

某仓储 AGV 采用 CANopen 总线，主控制器通过 CAN 网关连接 4 个驱动轮和 2 个安全传感器。调试中发现，当 AGV 加速时，轮速反馈延迟从 2ms 增加到 8ms，导致速度环振荡。

分析过程：使用 CAN 分析仪抓取总线负载，发现加速时安全传感器以 100Hz 频率发送大量报文，占用总线带宽约 60%。进一步检查发现，传感器节点配置了错误的发送类型（事件触发而非周期触发），导致高优先级报文频繁抢占总线。

解决步骤：将安全传感器改为 20Hz 周期发送，并设置轮速反馈报文为更高优先级。调整后，延迟恢复至 2ms 以内，速度环振荡消失。

复盘经验：分布式架构中，每个节点的报文类型和优先级必须经过总线负载计算，不能仅凭功能需求配置。

2.2 通信协议：实时性与可靠性权衡

通信协议决定了数据如何封装、传输和校验。机器人领域常用协议各有侧重，选型错误或配置不当是通信延迟和误触发的常见根源。

核心原理

EtherCAT 采用主从站通信，主站发送一帧数据，从站在帧经过时插入/提取数据，延迟极低且同步精度高。CANopen 基于 CAN 总线，支持多主和事件触发，但带宽较低（最高 1Mbps）。Modbus 简单易用，但实时性差，适合非实时监控。EtherNet/IP 基于标准以太网，兼容性好，但需要 QoS 保障才能用于实时控制。

// EtherCAT 从站配置示例（部分）
// 从站地址：0x01，周期 1ms
ec_slave_config_t sc = {
    .position = 0,
    .vendor_id = 0x00000001,
    .product_code = 0x00000002,
    .sync_mode = EC_SYNC_SM3,
    .cycle_time_ns = 1000000  // 1ms
};

判断方法

• 检查通信周期是否与配置一致：使用示波器测量 SYNC 信号，或读取主站统计信息。
• 检查报文丢失率：正常应为 0，若大于 0.1% 则需检查线缆、终端电阻或电磁干扰。
• 检查数据校验错误：CRC 错误计数持续增加，说明物理层存在干扰或连接不良。

案例拆解：EtherCAT 通信抖动导致动作误触发

某六轴机器人使用 EtherCAT 控制，运行中偶尔出现关节 3 突然跳动 5°。抓取主站日志发现，该关节的伺服驱动器在某个周期内收到错误位置指令，且 CRC 错误计数在故障瞬间增加。

分析过程：检查从站配置，发现关节 3 的驱动器被设置为"自由运行"模式，未与主站同步。当总线负载波动时，该驱动器使用本地时钟执行指令，导致位置偏差。

解决步骤：将所有驱动器改为 DC（Distributed Clock）同步模式，并重新计算偏移量。修改后，连续运行 72 小时未再出现误触发。

风险提示：修改同步模式后，必须重新验证所有轴的跟随误差，否则可能引入新的振动问题。

2.3 状态机：系统行为的逻辑骨架

状态机管理机器人从启动到停止的各个阶段，包括初始化、待机、运行、暂停、急停、错误恢复等。状态不同步问题往往源于状态机设计缺陷或外部信号干扰。

核心原理

状态机由状态、事件、迁移条件和动作组成。每个状态定义一组允许的行为，事件触发迁移，迁移条件必须全部满足才能切换。例如，从"运行"迁移到"暂停"需要满足：收到暂停指令且当前速度低于安全阈值。状态机设计的关键是确保任何时刻只有一个状态是激活的，且迁移路径明确无歧义。

判断方法

排查状态不同步问题时，重点检查：

1. 状态机当前状态是否与上位机显示一致（通过诊断变量读取）。
2. 迁移条件是否被意外满足（例如，急停信号抖动导致误触发）。
3. 状态机是否卡在某个中间状态（常见于条件判断中使用了非原子变量）。

案例拆解：急停信号抖动导致状态机误切换

某协作机器人在手动示教时，操作者按下急停按钮后立即释放，机器人从"运行"状态跳转到"错误"状态，但上位机显示仍为"运行"。检查发现，急停信号经过继电器触点时产生约 30ms 的抖动，状态机在抖动期间检测到两次边沿，触发了两次迁移。

解决步骤：在急停信号输入处增加软件滤波（连续采样 5 次，间隔 2ms），并修改状态机逻辑：只有急停信号持续 50ms 以上才触发错误迁移。修改后，抖动不再导致误切换。

复盘经验：所有外部输入信号必须经过去抖处理，且状态机迁移条件应包含时间确认，不能仅依赖电平边沿。

2.4 动作执行流程：从指令到运动的完整链路

一条动作指令从下发到执行完毕，需要经过指令解析、轨迹规划、插补、伺服控制、反馈确认等多个环节。任何一个环节的延迟或错误都会导致动作异常。

核心原理

典型流程如下：上位机发送目标位置 → 控制器解析指令并校验 → 运动规划器生成轨迹（包括速度、加速度约束） → 插补器按周期（如 1ms）计算中间点 → 伺服驱动器执行位置环/速度环 → 编码器反馈实际位置 → 控制器确认到达目标。整个链路中，每个环节都有固定的时间预算，任何超时都会导致通信延迟或动作中断。

// 动作执行流程伪代码
void execute_move(float target_pos) {
    if (state != RUNNING) return;  // 状态检查
    plan_trajectory(target_pos);    // 规划
    while (!trajectory_done) {
        setpoint = interpolate();   // 插补
        servo_write(setpoint);      // 下发
        wait_for_cycle();           // 等待下一个周期
    }
    confirm_arrival();              // 确认
}

判断方法

当动作执行异常时，按以下顺序排查：

• 检查指令是否被正确接收（控制器日志中应有指令记录）。
• 检查规划器是否生成了轨迹（输出轨迹点数量和时间戳）。
• 检查插补周期是否稳定（使用示波器测量 DAC 输出或伺服指令更新频率）。
• 检查伺服驱动器是否收到指令（驱动器状态字中的"目标到达"位）。

案例拆解：插补周期抖动导致轨迹轮廓误差

某焊接机器人加工圆弧轨迹时，焊缝出现周期性波纹。测量发现，插补周期在 0.8ms 到 1.2ms 之间波动，导致每个插补点的实际位置与理论位置偏差最大达 0.3mm。

分析过程：检查控制器 CPU 负载，发现后台任务（日志写入、网络通信）占用了约 30% 的 CPU 时间，导致插补任务无法稳定在 1ms 周期执行。

解决步骤：将日志写入改为异步模式，并将网络通信任务优先级降低。优化后，插补周期稳定在 1ms±0.05ms，焊缝波纹消失。

复盘经验：实时控制系统必须进行任务优先级划分和 CPU 负载预算，确保关键任务（插补、伺服控制）不被非实时任务干扰。

2.5 总结与常见误区

本章内容为后续排错打下基础。以下是常见误区总结：