仿真到实物迁移的关键不是让两端内部实现完全相同，而是让上层规划与任务逻辑面对稳定、可替换的控制和状态接口。
感知与任务逻辑 → 运动规划器 → 轨迹控制器 → ros2_control 硬件抽象
↓
仿真接口 / 真实硬件接口
↓
关节状态反馈
仿真阶段可接虚拟或仿真硬件接口，实物阶段替换为真实驱动接口。只要关节名称、单位、限制、命令接口、状态接口和控制器契约保持一致，上层规划与任务节点就不必整体重写。仿真模型仍需与实物的关节方向、零位、限位和尺寸保持一致，否则“接口相同”也无法保证行为一致。
执行器反馈决定系统上限
普通 PWM 舵机通常只接收目标脉宽，主控难以直接获得真实关节位置。系统可能只能假设关节到位：RViz 已更新，而实物因负载、间隙或卡滞没有到位。这适合低成本演示，但不构成可靠的状态闭环。
支持总线通信与位置反馈的执行器可返回角度、速度、电流、温度或错误状态，更容易把真实状态发布为 /joint_states，使可视化、规划和诊断基于实际运动结果。选型时应确认真实位置反馈、通信协议、刷新率、零位/方向/限位配置，以及断线、过温、过流或卡滞的处理方式。
ROS 2 与单片机的职责
ROS 2 并不替代单片机。视觉、坐标变换、运动规划和任务编排适合运行在上位机；确定性更强的执行器通信、安全限制和底层控制适合由 MCU 或专用控制器负责。若系统只播放几个固定角度动作，引入完整 ROS 2 架构收益有限；当系统需要多传感器融合、规划、状态反馈和模块替换时，统一接口才体现价值。
“上位机”和“下位机”描述的是系统中的相对职责，不是固定设备类型。典型机器人可进一步分为：
PC / 工控机 / Jetson
任务、感知、规划、非实时算法
↓ 目标轨迹或目标状态
实时控制器 / MCU / DSP
周期控制、状态采样、限幅与故障处理
↓ 总线命令
伺服驱动器 → 电机与机构
↑ 编码器、电流、温度与故障状态
实际产品不一定严格采用三台独立设备：高级控制算法可能运行在实时 Linux 工控机上，电流环也常封装在伺服驱动器内部。判断边界时应看控制周期、最坏时延、失效责任和接口契约，而不是只看设备名称。
跨层接口必须明确的契约
上层输出“目标位置”并不足以构成可部署接口。仿真与真机共用控制链时，至少需要明确：
- 命令模式：位置、速度、力矩或轨迹点；是否允许运行中切换。
- 单位与约定：弧度或角度、关节正方向、零位、坐标系和时间戳。
- 更新特性：控制频率、通信延迟、抖动、超时阈值与数据新鲜度。
- 状态反馈：位置、速度、力矩或电流、温度、驱动器错误及有效性标志。
- 约束与安全：软硬限位、速度和力矩限制、看门狗、急停、掉线后的安全状态。
- 启停状态机：上电、使能、校零、运行、降级、故障和复位的合法转换。
CAN、EtherCAT、串口等只是传输机制，不能单独保证闭环质量。高性能多轴系统尤其需要检查同步方式、周期稳定性、丢包或掉站处理，以及命令是否在确定时刻生效。
原型平台、嵌入式与商业机器人的边界
- Arduino 是便于快速验证传感器、舵机和简单动作的开发平台，适合原型，不代表完整的工业实时控制方案。
- STM32、DSP 等 MCU 常用于编码器采集、PWM、CAN、实时循环和安全逻辑；机器人算法开发者不必等同于嵌入式工程师，但应能理解并联调这层接口。
- ABB 等工业机器人是包含本体、控制柜、示教器、编程环境和安全机制的完整商业平台。掌握某厂商的示教与应用接口，和掌握通用运动学、规划及控制算法是不同能力。
- ROS 2、MoveIt 2 和通用控制算法可以参与商业机器人系统集成，但不能假设可绕过厂商控制柜、认证接口或安全边界直接驱动关节。
机电原型或竞赛中的“电控”也可能横跨多层：简单顺序控制主要解决动作状态机；编码器反馈、位置或速度闭环开始进入运动控制；视觉定位、轨迹规划和多轴协调则进入机器人系统集成。团队使用“电控 1/2”等称呼时没有统一行业含义，应以实际负责的接口和交付物判断职责。
验证原则
先验证单个执行器的通信、反馈、限位与故障处理，再扩展到整机；先验证关节空间轨迹，再加入视觉和抓取任务。实物迁移还需要单独验证负载、背隙、结构刚度、重复定位精度与急停，不能把仿真成功当作实物安全证明。
相关知识
- ROS 2 工作空间、仓库与软件包边界
- URDF 机器人模型基础
- 机器人系统中 AI、规划与控制的职责边界
- 机械臂运动规划、轨迹规划与控制