尧图网站建设 
人形机器人赛道的讨论里优必选和宇树经常被放在一起对比。行业大会的演示视频、社交平台的产品截图、甚至一段工厂测试的长镜头都能触发新一轮“谁更强”的争论。可如果从机器人研发角度来看“追上了”并不是一个适合用视频和截图回答的问题。它至少涉及整机运动控制、关节模组一致性、算法工具链、量产交付、现场运维和成本控制等多个层面而且每个层面都要用不同方式验证。这里不打算下“谁赢了”的结论而是想提供一个更扎实的讨论方式先把人形机器人运动控制的核心链路讲清楚再用仿真环境跑通一个最小平衡控制示例最后给出一套可以用于评估机器人公司技术能力的框架。读完后再看类似对比你会知道该看哪些指标、该问哪些问题、该避开哪些坑。1. 为什么“追上了”必须先拆成技术维度1.1 “追上”是工程问题不是视频问题很多对比讨论停留在产品发布会或短视频层面。一个后空翻视频可能意味着运动控制算法很强也可能只是特定动作在特定场地做了大量调试。一个工厂分拣演示可能代表整机稳定性不错也可能只是演示流程被严格固定机器人并没有面对真实随机工况。演示视频本质上是单次成功的证据而不是长期可靠性的证据。把“追上了”当工程技术问题处理首先要承认它不是一个单一指标。它是一组多维指标的综合结果。只比较某个参数比如关节峰值扭矩、行走速度、自由度数量都会得到偏颇的结论。更合理的做法是先把比较拆成不同技术层然后逐层寻找证据。1.2 两家公司的公开产品路线差异先看公开产品线呈现的差异。优必选在公众视野中更早、更集中地打出人形整机这张牌旗下产品线围绕仿人形机器人展开长期在整机结构、机电一体化、行业解决方案方向积累。宇树则从四足机器人产品起步以较高辨识度的运动能力走入开发者视野随后把在小型运动平台上积累的电机驱动、硬件设计、运动控制经验迁移到人形机器人产品线上。两者起点和目标不完全相同。优必选更早面对“把人形整机做成可对外交付的系统”这个问题宇树则更早面对“把运动平台做轻、做快、做到成本可控”这个问题。进入同一赛道后它们要补的短板不同前者可能要补消费级成本控制和小型化后者可能要补大型整机系统集成和行业场景交付。1.3 四层技术评估结构综合来看一个相对完整的评估体系至少要覆盖四层整机运动能力能不能在不同地面、不同任务下保持稳定动态扰动后能否恢复平衡连续运行多久不失效。关节模组与硬件能力电机、减速器、驱动器、编码器组成的关节模组是否达到足够扭矩密度峰值性能和持续性能是否匹配散热、寿命、一致性如何。感知与决策视觉、力觉、语音、导航、操作技能是否打通能否完成真实任务闭环。工程化能力量产一致性、出厂标定、软件调试工具、日志与监控、OTA 升级、售后响应和成本控制。技术层需要回答的问题常见验证方式整机运动能力能否在未知地形稳定行走、跌倒后恢复真机连续行走测试、抗扰动测试、仿真回归关节模组与硬件关节扭矩、寿命、散热是否满足长期运行台架测试、多批次抽检、寿命试验感知与决策能否识别目标、完成抓取和导航实际场景回测、离线数据测试工程化能力能否稳定量产并支持交付维护批次记录、售后数据、工具链体验这四层不是并列加分项而是层层依赖。硬件不够强上层算法再好也会在真实电机上失败状态估计不稳规划轨迹再完美也无法落地没有工程化体系几台样机可以演示几十台上量的机器会暴露大量一致性问题。因此判断优必选是否追上了宇树需要细化成在运动能力上是否追上、在关节模组一致性上是否追上、在量产落地和成本控制上是否追上。这四个判断对应完全不同的证据。2. 先理解人形机器人运动控制的核心链路2.1 从上层规划到关节力矩人形机器人可以理解为一个空间分布的大规模机器人控制系统。上层视觉和导航模块决定目标位置步态规划模块生成脚掌轨迹和躯干姿态状态估计模块通过 IMU、关节编码器、足底力传感器估计当前姿态和接触状态最后把期望位置或速度发送给每个关节的伺服控制器。伺服控制器内部通常分位置环、速度环和电流环三层。最内侧电流环的频率决定了力矩响应速度。一个常见范围是电流环 20 kHz 以上关节位置环 1 kHz 左右上层状态估计和规划在 200 Hz 到 1 kHz 之间。这些频率只是经验区间不同硬件实现不同但它们决定了系统的刚性和延迟。频率不足机器人在大扰动下就很难保持稳定。2.2 关键硬件模块和参数关节模组是整机性能的基础。这里列出最关键的硬件模块以及每一个模块在工程中最常见的限制。硬件模块核心作用工程中常见问题无框力矩电机嵌入关节提升扭矩密度峰值扭矩与实际持续扭矩差距大易过热谐波减速器大减速比、高精度抗冲击能力弱装配不当会加速磨损行星减速器扭矩密度高、抗冲击好背隙控制复杂减速比选择要权衡伺服驱动器电流环控制和通信电流环带宽不足会导致关节抖动编码器提供位置反馈分辨率不足或零位漂移会造成定位偏差IMU提供姿态参考长时间运行存在漂移需要滤波和融合足底力/力矩传感器感知地面反力标定复杂过载易损坏只看峰值扭矩很容易被误导。峰值扭矩决定机器人能不能做出爆发动作持续扭矩决定它能不能稳定工作两小时而不过热。对比两家公司时不能只看发布会上的爆发瞬间还要关注关节温度、控制带宽、通信总线和批量一致性。这些参数很难在一段视频里体现却在每一次真实运行中起作用。2.3 平衡控制的经典判据ZMP双足平衡最经典的判据之一是零力矩点Zero Moment Point, ZMP。通俗地说机器人脚底与地面接触的支撑区域内存在一个点地面反作用力在该点形成的合力矩为零。只要这个点始终落在支撑多边形内部机器人就在静力学意义上稳定。一旦 ZMP 接近支撑多边形边缘机器人就在倾倒边缘。实际系统中不会直接测得 ZMP而是通过关节扭矩、脚底压力传感器和动力学模型估算。很多步态规划算法也以 ZMP 轨迹为目标生成脚掌和躯干运动。当前主流的强化学习方案不一定显式维护 ZMP 模型但最终学习到的策略仍然必须满足“质心投影保持在支撑域内”这一物理约束。2.4 最小控制单元PD 控制器关节控制中最基础、也最能说明平衡问题的控制器是 PD比例-微分控制。PD 控制的任务很简单测量当前关节角度和当前角速度给定期望角度和期望角速度输出一个与误差成正比、与误差变化率成正比的力矩。比例项负责把关节拉向目标微分项负责抑制速度振荡。double joint_torque(double q_des, double q_cur, double qd_des, double qd_cur, double kp, double kd) { double error q_des - q_cur; double error_dot qd_des - qd_cur; return kp * error kd * error_dot; }这里的关键是 kp 和 kd 的配合。kp 过大系统会产生高频抖动kd 过大响应变慢表现为“僵”两者搭配不当机器人站都站不稳。真实机器人关节控制中还会加入重力补偿、摩擦补偿、前馈力矩。PD 只是最底层的一个闭环它前面还有运动规划、状态估计、步态模式生成等模块。理解这个层级再看机器人演示视频时就能区分一条动作是“动作库预设”还是“实时反馈控制”驱动的。3. 用最小仿真环境把平衡控制跑通3.1 为什么先搭仿真机器人研发不能每次都在真机上试错。真机测试成本高、周期长而且摔一次就可能损坏关节。仿真可以在几分钟内重复多次实验适合参数调优、算法对比和危险场景验证。MuJoCo、dm_control、Isaac Gym/Sim、PyBullet 是常见选择。仿真不能完全替代真机但它能快速完成算法闭环并暴露大量逻辑问题。3.2 环境准备与最简模型定义准备 Python 环境安装以下依赖pip install numpy dm_control mujoco pip install gymnasium stable-baselines3MuJoCo 负责物理仿真dm_control 提供高层 API 和预置任务。如果直接用 mujoco则需要自己写 MJCF 模型。MJCF 是 MuJoCo 的模型描述格式机器人结构、关节、几何体、驱动器和传感器都可以在 XML 里定义。下面是一个单摆模型只有一个绕 Y 轴旋转的关节mujoco modelsingle_pendulum option gravity0 0 -9.81/ worldbody body namelink pos0 0 1.0 joint namejoint1 typehinge axis0 1 0 pos0 0 0/ geom namelink_geom typecapsule fromto0 0 0 0 0 -0.5 size0.04/ /body /worldbody actuator motor jointjoint1 namemotor1/ /actuator /mujoco这个模型只能用来展示“模型文件到仿真执行”的最小流程。人形机器人模型复杂得多但基本单位都是这类关节、连杆、驱动器和传感器的组合。用 mujoco 库直接加载并步进import mujoco model mujoco.MjModel.from_xml_path(single_pendulum.xml) data mujoco.MjData(model) for step in range(1000): data.ctrl[0] 0.0 mujoco.mj_step(model, data) if step % 100 0: print(step, data.qpos[0], data.qvel[0])运行后可以看到单摆逐步摆动停下。这个示例建立了“模型文件、仿真环境、控制指令、物理结果”的最小闭环。接下来的 cartpole 任务把问题升级为“不稳定系统如何控制”。3.3 用 DM Control 跑通 PD 平衡cartpole 是经典控制任务小车推动倒立摆保持直立。虽然简单但它和人形机器人平衡有相同的核心问题对象本身不稳定必须用连续反馈控制维持平衡。import numpy as np from dm_control import suite env suite.load(cartpole, swingup) time_step env.reset() def pd_controller(obs, kp30.0, kd8.0): # 不同版本中 obs 排列可能不同运行前先打印 obs 确认 angle obs[0] angle_velocity obs[1] return np.array([kp * angle kd * angle_velocity]) for step in range(500): obs time_step.observation[observations] action pd_controller(obs) time_step env.step(action) if time_step.last(): print(episode ended at step, step) break print(PD control ran, step 1, steps)这里要特别注意不同版本或任务中观测数组的排列可能不同。运行前先打印obs确认哪个维度是角度、哪个维度是角速度否则控制器会失效。PD 控制对参数很敏感kp、kd 需要一点一点调调参过程本身就是机器人控制的日常。3.4 用强化学习替代手工调参当系统复杂到一定程度手工设计 PD 参数就变得困难。这时候可以转向强化学习。用 stable-baselines3 训练时直接使用 gymnasium 的 CartPole-v1 环境更简单import gymnasium as gym from stable_baselines3 import PPO env gym.make(CartPole-v1) model PPO(MlpPolicy, env, verbose1, n_steps2048, batch_size256, gamma0.99) model.learn(total_timesteps100_000) model.save(cartpole_ppo)PPO 通过大量采样、计算优势函数、小批量梯度更新来提升策略。它不需要显式给出动力学方程但需要精心设计状态表示、奖励函数和训练分布。对机器人团队来说强化学习真正的问题不是训练能否收敛而是训练得到的策略搬到真机后是否仍然有效这就是 Sim2Real 迁移。3.5 Sim2Real仿真到真机的距离真机与仿真在摩擦系数、关节延迟、机械弹性、电机死区、通信抖动上都不一样。最简单的迁移手段是域随机化在训练时随机扰动物理参数让策略在多种环境下都尽量稳健。另一个手段是系统辨识先标定真机参数再尽量还原到仿真里。实际项目中两者会结合使用。注意仿真里跑通的 PD 参数和强化学习策略不能直接搬到真机。至少要先做系统辨识再留出安全保护逻辑不能把控制开关直接搭在未经验证的参数上。这个环节是判断一个团队算法工程能力的试金石能跑通演示的团队很多能在真机上稳定迁移的团队很少。4. 从“跑通”到“量产”还隔着哪些工程问题4.1 三阶段验证的差异很多人把“实验室跑通”和“具备量产能力”混为一谈。实际上这两者之间还隔着完整的小批量验证。三者的关注点完全不同。阶段关注点典型问题需要的数据实验室演示单台样机、受控场景成功一次即可人工干预频繁演示视频、开发日志小批量验证5 到 10 台样机、相似场地、长时间反复运行一致性、故障率、维修难度日志、故障记录、修复记录量产交付数十上百台、多客户场地、现场运行供应链、成本、标定、OTA、售后批次质量数据、远程监控、返修率一台机器人能走一次和一百台机器人能连续走几天是两个完全不同的问题。后者的难点在于一致性同型号每一台机器人的表现要接近否则售后工程师会疲于奔命。4.2 关节一致性由标定决定同一型号的电机、减速器、驱动器都有制造公差。出厂时每个关节的零位、摩擦、力矩系数都不同。如果没有标定一台机器人就可能出现细微的左右不对称一百台机器人 人形机器人运动控制核心链路与工程化评估框架解析
人形机器人赛道的讨论里优必选和宇树经常被放在一起对比。行业大会的演示视频、社交平台的产品截图、甚至一段工厂测试的长镜头都能触发新一轮“谁更强”的争论。可如果从机器人研发角度来看“追上了”并不是一个适合用视频和截图回答的问题。它至少涉及整机运动控制、关节模组一致性、算法工具链、量产交付、现场运维和成本控制等多个层面而且每个层面都要用不同方式验证。这里不打算下“谁赢了”的结论而是想提供一个更扎实的讨论方式先把人形机器人运动控制的核心链路讲清楚再用仿真环境跑通一个最小平衡控制示例最后给出一套可以用于评估机器人公司技术能力的框架。读完后再看类似对比你会知道该看哪些指标、该问哪些问题、该避开哪些坑。1. 为什么“追上了”必须先拆成技术维度1.1 “追上”是工程问题不是视频问题很多对比讨论停留在产品发布会或短视频层面。一个后空翻视频可能意味着运动控制算法很强也可能只是特定动作在特定场地做了大量调试。一个工厂分拣演示可能代表整机稳定性不错也可能只是演示流程被严格固定机器人并没有面对真实随机工况。演示视频本质上是单次成功的证据而不是长期可靠性的证据。把“追上了”当工程技术问题处理首先要承认它不是一个单一指标。它是一组多维指标的综合结果。只比较某个参数比如关节峰值扭矩、行走速度、自由度数量都会得到偏颇的结论。更合理的做法是先把比较拆成不同技术层然后逐层寻找证据。1.2 两家公司的公开产品路线差异先看公开产品线呈现的差异。优必选在公众视野中更早、更集中地打出人形整机这张牌旗下产品线围绕仿人形机器人展开长期在整机结构、机电一体化、行业解决方案方向积累。宇树则从四足机器人产品起步以较高辨识度的运动能力走入开发者视野随后把在小型运动平台上积累的电机驱动、硬件设计、运动控制经验迁移到人形机器人产品线上。两者起点和目标不完全相同。优必选更早面对“把人形整机做成可对外交付的系统”这个问题宇树则更早面对“把运动平台做轻、做快、做到成本可控”这个问题。进入同一赛道后它们要补的短板不同前者可能要补消费级成本控制和小型化后者可能要补大型整机系统集成和行业场景交付。1.3 四层技术评估结构综合来看一个相对完整的评估体系至少要覆盖四层整机运动能力能不能在不同地面、不同任务下保持稳定动态扰动后能否恢复平衡连续运行多久不失效。关节模组与硬件能力电机、减速器、驱动器、编码器组成的关节模组是否达到足够扭矩密度峰值性能和持续性能是否匹配散热、寿命、一致性如何。感知与决策视觉、力觉、语音、导航、操作技能是否打通能否完成真实任务闭环。工程化能力量产一致性、出厂标定、软件调试工具、日志与监控、OTA 升级、售后响应和成本控制。技术层需要回答的问题常见验证方式整机运动能力能否在未知地形稳定行走、跌倒后恢复真机连续行走测试、抗扰动测试、仿真回归关节模组与硬件关节扭矩、寿命、散热是否满足长期运行台架测试、多批次抽检、寿命试验感知与决策能否识别目标、完成抓取和导航实际场景回测、离线数据测试工程化能力能否稳定量产并支持交付维护批次记录、售后数据、工具链体验这四层不是并列加分项而是层层依赖。硬件不够强上层算法再好也会在真实电机上失败状态估计不稳规划轨迹再完美也无法落地没有工程化体系几台样机可以演示几十台上量的机器会暴露大量一致性问题。因此判断优必选是否追上了宇树需要细化成在运动能力上是否追上、在关节模组一致性上是否追上、在量产落地和成本控制上是否追上。这四个判断对应完全不同的证据。2. 先理解人形机器人运动控制的核心链路2.1 从上层规划到关节力矩人形机器人可以理解为一个空间分布的大规模机器人控制系统。上层视觉和导航模块决定目标位置步态规划模块生成脚掌轨迹和躯干姿态状态估计模块通过 IMU、关节编码器、足底力传感器估计当前姿态和接触状态最后把期望位置或速度发送给每个关节的伺服控制器。伺服控制器内部通常分位置环、速度环和电流环三层。最内侧电流环的频率决定了力矩响应速度。一个常见范围是电流环 20 kHz 以上关节位置环 1 kHz 左右上层状态估计和规划在 200 Hz 到 1 kHz 之间。这些频率只是经验区间不同硬件实现不同但它们决定了系统的刚性和延迟。频率不足机器人在大扰动下就很难保持稳定。2.2 关键硬件模块和参数关节模组是整机性能的基础。这里列出最关键的硬件模块以及每一个模块在工程中最常见的限制。硬件模块核心作用工程中常见问题无框力矩电机嵌入关节提升扭矩密度峰值扭矩与实际持续扭矩差距大易过热谐波减速器大减速比、高精度抗冲击能力弱装配不当会加速磨损行星减速器扭矩密度高、抗冲击好背隙控制复杂减速比选择要权衡伺服驱动器电流环控制和通信电流环带宽不足会导致关节抖动编码器提供位置反馈分辨率不足或零位漂移会造成定位偏差IMU提供姿态参考长时间运行存在漂移需要滤波和融合足底力/力矩传感器感知地面反力标定复杂过载易损坏只看峰值扭矩很容易被误导。峰值扭矩决定机器人能不能做出爆发动作持续扭矩决定它能不能稳定工作两小时而不过热。对比两家公司时不能只看发布会上的爆发瞬间还要关注关节温度、控制带宽、通信总线和批量一致性。这些参数很难在一段视频里体现却在每一次真实运行中起作用。2.3 平衡控制的经典判据ZMP双足平衡最经典的判据之一是零力矩点Zero Moment Point, ZMP。通俗地说机器人脚底与地面接触的支撑区域内存在一个点地面反作用力在该点形成的合力矩为零。只要这个点始终落在支撑多边形内部机器人就在静力学意义上稳定。一旦 ZMP 接近支撑多边形边缘机器人就在倾倒边缘。实际系统中不会直接测得 ZMP而是通过关节扭矩、脚底压力传感器和动力学模型估算。很多步态规划算法也以 ZMP 轨迹为目标生成脚掌和躯干运动。当前主流的强化学习方案不一定显式维护 ZMP 模型但最终学习到的策略仍然必须满足“质心投影保持在支撑域内”这一物理约束。2.4 最小控制单元PD 控制器关节控制中最基础、也最能说明平衡问题的控制器是 PD比例-微分控制。PD 控制的任务很简单测量当前关节角度和当前角速度给定期望角度和期望角速度输出一个与误差成正比、与误差变化率成正比的力矩。比例项负责把关节拉向目标微分项负责抑制速度振荡。double joint_torque(double q_des, double q_cur, double qd_des, double qd_cur, double kp, double kd) { double error q_des - q_cur; double error_dot qd_des - qd_cur; return kp * error kd * error_dot; }这里的关键是 kp 和 kd 的配合。kp 过大系统会产生高频抖动kd 过大响应变慢表现为“僵”两者搭配不当机器人站都站不稳。真实机器人关节控制中还会加入重力补偿、摩擦补偿、前馈力矩。PD 只是最底层的一个闭环它前面还有运动规划、状态估计、步态模式生成等模块。理解这个层级再看机器人演示视频时就能区分一条动作是“动作库预设”还是“实时反馈控制”驱动的。3. 用最小仿真环境把平衡控制跑通3.1 为什么先搭仿真机器人研发不能每次都在真机上试错。真机测试成本高、周期长而且摔一次就可能损坏关节。仿真可以在几分钟内重复多次实验适合参数调优、算法对比和危险场景验证。MuJoCo、dm_control、Isaac Gym/Sim、PyBullet 是常见选择。仿真不能完全替代真机但它能快速完成算法闭环并暴露大量逻辑问题。3.2 环境准备与最简模型定义准备 Python 环境安装以下依赖pip install numpy dm_control mujoco pip install gymnasium stable-baselines3MuJoCo 负责物理仿真dm_control 提供高层 API 和预置任务。如果直接用 mujoco则需要自己写 MJCF 模型。MJCF 是 MuJoCo 的模型描述格式机器人结构、关节、几何体、驱动器和传感器都可以在 XML 里定义。下面是一个单摆模型只有一个绕 Y 轴旋转的关节mujoco modelsingle_pendulum option gravity0 0 -9.81/ worldbody body namelink pos0 0 1.0 joint namejoint1 typehinge axis0 1 0 pos0 0 0/ geom namelink_geom typecapsule fromto0 0 0 0 0 -0.5 size0.04/ /body /worldbody actuator motor jointjoint1 namemotor1/ /actuator /mujoco这个模型只能用来展示“模型文件到仿真执行”的最小流程。人形机器人模型复杂得多但基本单位都是这类关节、连杆、驱动器和传感器的组合。用 mujoco 库直接加载并步进import mujoco model mujoco.MjModel.from_xml_path(single_pendulum.xml) data mujoco.MjData(model) for step in range(1000): data.ctrl[0] 0.0 mujoco.mj_step(model, data) if step % 100 0: print(step, data.qpos[0], data.qvel[0])运行后可以看到单摆逐步摆动停下。这个示例建立了“模型文件、仿真环境、控制指令、物理结果”的最小闭环。接下来的 cartpole 任务把问题升级为“不稳定系统如何控制”。3.3 用 DM Control 跑通 PD 平衡cartpole 是经典控制任务小车推动倒立摆保持直立。虽然简单但它和人形机器人平衡有相同的核心问题对象本身不稳定必须用连续反馈控制维持平衡。import numpy as np from dm_control import suite env suite.load(cartpole, swingup) time_step env.reset() def pd_controller(obs, kp30.0, kd8.0): # 不同版本中 obs 排列可能不同运行前先打印 obs 确认 angle obs[0] angle_velocity obs[1] return np.array([kp * angle kd * angle_velocity]) for step in range(500): obs time_step.observation[observations] action pd_controller(obs) time_step env.step(action) if time_step.last(): print(episode ended at step, step) break print(PD control ran, step 1, steps)这里要特别注意不同版本或任务中观测数组的排列可能不同。运行前先打印obs确认哪个维度是角度、哪个维度是角速度否则控制器会失效。PD 控制对参数很敏感kp、kd 需要一点一点调调参过程本身就是机器人控制的日常。3.4 用强化学习替代手工调参当系统复杂到一定程度手工设计 PD 参数就变得困难。这时候可以转向强化学习。用 stable-baselines3 训练时直接使用 gymnasium 的 CartPole-v1 环境更简单import gymnasium as gym from stable_baselines3 import PPO env gym.make(CartPole-v1) model PPO(MlpPolicy, env, verbose1, n_steps2048, batch_size256, gamma0.99) model.learn(total_timesteps100_000) model.save(cartpole_ppo)PPO 通过大量采样、计算优势函数、小批量梯度更新来提升策略。它不需要显式给出动力学方程但需要精心设计状态表示、奖励函数和训练分布。对机器人团队来说强化学习真正的问题不是训练能否收敛而是训练得到的策略搬到真机后是否仍然有效这就是 Sim2Real 迁移。3.5 Sim2Real仿真到真机的距离真机与仿真在摩擦系数、关节延迟、机械弹性、电机死区、通信抖动上都不一样。最简单的迁移手段是域随机化在训练时随机扰动物理参数让策略在多种环境下都尽量稳健。另一个手段是系统辨识先标定真机参数再尽量还原到仿真里。实际项目中两者会结合使用。注意仿真里跑通的 PD 参数和强化学习策略不能直接搬到真机。至少要先做系统辨识再留出安全保护逻辑不能把控制开关直接搭在未经验证的参数上。这个环节是判断一个团队算法工程能力的试金石能跑通演示的团队很多能在真机上稳定迁移的团队很少。4. 从“跑通”到“量产”还隔着哪些工程问题4.1 三阶段验证的差异很多人把“实验室跑通”和“具备量产能力”混为一谈。实际上这两者之间还隔着完整的小批量验证。三者的关注点完全不同。阶段关注点典型问题需要的数据实验室演示单台样机、受控场景成功一次即可人工干预频繁演示视频、开发日志小批量验证5 到 10 台样机、相似场地、长时间反复运行一致性、故障率、维修难度日志、故障记录、修复记录量产交付数十上百台、多客户场地、现场运行供应链、成本、标定、OTA、售后批次质量数据、远程监控、返修率一台机器人能走一次和一百台机器人能连续走几天是两个完全不同的问题。后者的难点在于一致性同型号每一台机器人的表现要接近否则售后工程师会疲于奔命。4.2 关节一致性由标定决定同一型号的电机、减速器、驱动器都有制造公差。出厂时每个关节的零位、摩擦、力矩系数都不同。如果没有标定一台机器人就可能出现细微的左右不对称一百台机器人