人形机器人半马备赛指南：从运动控制到系统可靠性

人形机器人半程马拉松并不是一个简单的概念炒作。它要求机器人具备在真实户外环境中连续奔跑 21.0975 公里的能力同时还要应对转弯、斜坡、地面摩擦变化、风力干扰和电池热衰减等一系列现实问题。2027 年北京亦庄人形机器人半程马拉松宣布全球邀请赛事规格再次升级这意味着参赛队伍不再只是验证实验室里的单点技术而是要把可靠性、续航、运动控制和环境感知整合到一个可长期稳定运行的系统里。这篇文章会围绕“为一场人形机器人半程马拉松做准备”这条主线展开。你会看到赛事规格升级后技术挑战从哪些维度变难机器人参赛需要准备哪些硬件和软件如何设计最小可跑通的运动控制流程在赛前测试和正式比赛时应该重点验证哪些指标以及当机器人突然摔到、掉线或过热时日志和排查链路应该怎么建立。这里不会给出某个参赛队伍的完整技术方案因为每家机器人本体和算法栈差异很大但会给出可用于自己项目对照的工程目录、参数表、检查清单和故障排查顺序。先解释为什么人形机器人跑半马这件事本身就是一个很高难度的系统工程。普通双足机器人能走几步已经不容易连续奔跑几十分钟要同时解决三个矛盾执行器输出功率和关节散热的矛盾、算法计算实时性和本体功耗的矛盾、路径规划精度和室外环境不确定性的矛盾。赛事规格再升级通常意味着赛道更长、地形更复杂、对机器人与人之间的互动规则要求更高还可能加入实时通信、远程监控和数据上报等附加条件。因此备赛不只是调算法而是要像准备一台无人驾驶车辆一样把感知、决策、控制和执行全部拉到极限。1. 先理解人形机器人半马赛事的核心挑战1.1 长距离奔跑对运动控制提出什么新要求实验室里的双足运动控制通常以步数或秒数为单位常用的测试是走 100 米或连续跑 5 分钟。半程马拉松的距离约 21.1 公里以平均速度 2 米/秒估算机器人需要连续运动约 3 小时。这个时间跨度让机械结构疲劳、电机温升、电池电压跌落、减速器润滑油状态和控制系统漂移都会成为显性问题。短时间测试中不容易暴露的控制问题在长距离中会被放大。例如零力矩点ZMP轨迹在平稳地面可以维持稳定但路面有细微坡度变化时如果脚底压力传感器的零点漂移未被校准就会持续输出偏差导致机器人逐渐偏向一侧。另一个常见问题是步态周期参数在电池电压下降后不再匹配。电机在满电压时的响应速度与低电压时完全不同控制系统如果使用固定增益后程会因为执行器带宽下降而出现震荡。1.2 赛事规格升级通常改变哪些变量赛事规格升级不是只增加公里数而是提高整套体系的复杂度。可以从三个维度来理解赛道环境可能从单一塑胶跑道变为柏油路、石板路、缓坡和急弯混合路线。不同材质的路面对摩擦力和冲击吸收不同需要机器人实时调整步频和触地角度。竞赛规则可能加入机器人必须保持在人行道右侧、不得故意碰撞其他机器人、进入补给区需要减速等待等规则。这意味着定位和动态避障不是可选功能而是完赛必要条件。数据要求主办方可能要求每台机器人上报实时定位、电池 SOC、身体倾角和故障状态。这会让通信系统和数据链路成为完赛的第四个轮子。规格升级的本质是把机器人竞赛从“单机表演”推向“系统可靠性竞赛”。参赛队伍需要像运维服务器集群一样管理机器人而不仅仅是写一套步态算法。1.3 为什么需要建立“完赛思维”而不是“跑分思维”很多人形机器人团队在开发时追求最大步速、最快转向或最高跳跃高度。但在 21.1 公里半马场景中峰值性能不重要持续性能才重要。跑分思维追求的是在 10 米测试中跑出最大速度完赛思维追求的是在 3 小时内保持平均速度、能量效率和系统稳定。这直接改变算法设计的目标函数。例如在跑分思维下步态轨迹可能刻意制造较大的重心起伏来增加步幅在完赛思维下则要尽量减少重心垂直波动以降低每步的机械能损耗。另一个例子是控制频率。高算力处理器可以跑到 2000 Hz 的 MPC 控制频率但功耗过高会让续航时间缩短 30% 以上。完赛思维要求采用自适应控制频率在直道降低计算频率在弯道和复杂地形临时提升。2. 备赛环境准备硬件、软件和场地不能只靠自己2.1 机器人本体的关键参数需要先量化准备一场半马之前至少要把机器人本体的以下参数整理成表格作为所有算法优化的基准参数影响建议记录方式整机重量影响步态能量、冲击载荷和续航分状态测量例如满电空载、带电池、带负载关节数量与类型决定控制自由度与运动能力列出每个关节的电机型号和减速比峰值关节扭矩决定最大爬坡和加速能力查阅电机和减速器文档不要只看理论值持续扭矩决定长距离奔跑是否过热并降速用固定负载台架测试 30 分钟记录温升曲线最大步行速度决定能否达到预定配速在平坦地面测 10 米平均速度排除加速段续航能力决定是否需要在赛道中途换电池或充电以匀速方式连续奔跑测试记录电压和剩余电量传感器列表决定感知和状态估计能力包括 IMU、关节编码器、压力传感器、相机、激光雷达这些参数中最容易被低估的是“持续扭矩”。很多机器人使用高功率密度电机但持续输出时热量积累严重。半马工况下关节需要长期稳定输出额定扭矩如果电机和减速器的持续工作区间不匹配跑不到 20 分钟就会因为过温保护而强制停机。2.2 软件框架选择要面向长时运行调试机器人运动控制领域常用 ROS、ROS 2 或自研实时控制框架。备赛半马时软件框架不能只看功能丰富程度还要看三点长时间运行的内存稳定性、日志系统的可回溯性、以及故障恢复能力。ROS 2 在多机通信和生命周期管理上有优势但节点间的 QoS 配置复杂。如果某个主题的发布频率过高长时间运行后可能出现队列积压。自研框架的优势是可控性强但需要自己处理时间同步、线程安全和日志轮转。推荐备赛团队采用“分层架构”上层用 Python 或 C 做任务调度和状态机中层使用实时控制循环底层直接操作关节电机。这样上层逻辑可以频繁调整底层控制不会因为脚本层卡顿而中断。2.3 训练场地和仿真环境要分开准备半马赛前测试不能只在仿真环境里做。仿真无法完全模拟真实路面的摩擦系数变化、风力和电池热特性。但仿真可以帮助验证算法逻辑和探索极端参数。建议按三个层次准备环境纯仿真环境用于批量跑参数、测试边缘案例例如突然失去某个传感器信号、遇到 5 厘米高的路缘、电池电量低于 10% 等。封闭室外场地选择 200 米以上的环形道路模拟柏油路、石板路和缓坡用于验证长距离稳定性。缩小比赛模拟在赛前至少进行两次 5 公里连续测试记录速度、能耗、关节温度和异常事件用于估计完赛余量。仿真环境推荐使用 Gazebo 或 MuJoCo同时加入地形高度图和窄道障碍物。注意不要让仿真中的电机模型过于理想化否则真机测试时会出现巨大的步态落差。3. 最小可跑通的运动控制框架设计3.1 从状态估计到步态生成的整体链路一个最小可跑通的人形机器人半马控制框架至少包含五个模块它们按顺序连接状态估计模块融合 IMU、关节编码器和脚底压力传感器计算机器人的身体姿态、位置和速度。感知模块读取相机或激光雷达数据检测前方障碍物和路径边界。决策规划模块根据赛道地图和实时感知结果生成目标速度、转向角和期望落脚点。步态生成模块把目标速度转化为双腿的摆动轨迹和支撑期望。执行控制模块对每个关节电机下发力矩或位置指令并做力矩保护。这个链路中最容易出问题的不是某个单独模块而是模块间的通信时延。例如感知模块发现前方 2 米有障碍物规划模块计算出转向指令但控制频率是 500 Hz感知频率只有 20 Hz如果处理不当转向指令会有 50 毫秒以上的延迟。对奔跑中的机器人来说这个延迟足够让重心偏离支持多边形。3.2 一个简单的“速度指令到步态生成”示例为了说明最小闭环下面用 Python 代码示意步态生成模块如何根据目标速度计算腿部摆动轨迹。这里使用简化的倒立摆模型真实项目需要替换为全身动力学控制。import numpy as np class BipedalGaitGenerator: def __init__(self, hip_height0.85, step_frequency2.0, step_length0.5): self.hip_height hip_height # 髋关节高度单位米 self.step_frequency step_frequency # 步频单位 Hz self.step_length step_length # 步长单位米 self.cycle_time 1.0 / step_frequency def generate_foot_position(self, time_in_cycle, lateral_offset0.15): # 简化版本根据周期时间计算摆动脚位置 t time_in_cycle % self.cycle_time if t self.cycle_time / 2: # 支撑相脚保持不动 local_x 0.0 local_z 0.0 else: # 摆动相脚从后方移动到前方 phase (t - self.cycle_time / 2) / (self.cycle_time / 2) local_x -self.step_length / 2 phase * self.step_length # 抬脚高度 local_z 0.08 * np.sin(np.pi * phase) return np.array([local_x, lateral_offset, local_z]) def compute_velocity_from_commands(self, linear_velocity_x, angular_velocity_z): # 根据底盘速度指令调整步长和步频 desired_step_length linear_velocity_x / self.step_frequency desired_step_length np.clip(desired_step_length, 0.3, self.step_length) # 转向时增加内外侧步长差这里仅示意 step_adjustment angular_velocity_z * 0.05 return desired_step_length step_adjustment这个示例重点在于展示“速度指令如何转化为落脚点”的基本思路。实际项目中步态生成模块还要考虑脚落地后踝关节的柔顺控制、身体俯仰角补偿和摆动腿避障轨迹。如果直接把这样的代码放到线速度 2 m/s 的奔跑场景里会因为缺少动力学约束而失稳。3.3 实时控制循环需要单独一个高优先级线程不建议把步态生成和电机通信放在 Python 主线程中。半马奔跑时控制循环必须确定性执行否则任何 GC 暂停或日志写入都会导致控制周期抖动。推荐使用 C 或 Rust 编写底层实时控制循环或者使用 RT-Preempt 内核。控制循环应满足以下约束循环周期固定例如 1 到 4 毫秒。电机指令通过实时总线发送例如 EtherCAT、CAN 或者厂商专用总线。传感器数据在循环开始时统一采集保证时间戳对齐。任何异常都记录到循环内的时间戳不影响后续控制。一个简单的实时控制循环结构如下// 伪代码示意实时控制循环 while (running) { // 采集传感器 auto sensors readAllSensors(); // 状态估计 auto state estimator.update(sensors); // 计算期望步态 auto gait gait_generator.compute(target_velocity, state); // 计算关节力矩 auto torques controller.compute(state, gait); // 下发电机指令 motor_bus.send(torques); // 记录日志但不阻塞控制 logger.async_log(state, gait, torques); timer.sleep_until_next_cycle(); }这里的关键是日志不能放在控制循环的同步路径上否则当 SD 卡写入速度波动时控制周期会被拉长。3.4 感知、定位和路径规划如何与运动控制配合半马赛道与实验室走廊最大的区别是环境动态变化。机器人不仅要沿着路径走还要绕过障碍物、保持赛道内位置。感知模块通常以 10 到 30 Hz 的频率运行定位模块以 10 到 50 Hz 运行运动控制模块以 250 到 1000 Hz 运行。三者之间需要建立“慢变”和“快变”分离的思想路径规划生成的是慢变参考例如每 500 毫秒更新一次目标点和局部路径运动控制则基于当前状态执行快变计算避免因为一条稍旧的路径指令而急停。如果机器人在奔跑中检测到前方障碍物规划层应该生成一条平滑的局部绕行路径而不是直接改变目标速度。否则机器人会频繁加速和减速增加能耗和失控风险。4. 赛前测试、验证指标和结果分析4.1 用“分阶段测试”代替一次性跑完半马备赛不能只在比赛当天尝试一次跑完全程。建议把测试分为四个阶段单圈测试在 200 米封闭场地跑 3 圈重点验证基本运动控制和感知。5 公里测试跑 25 圈验证电池管理、电机温升和日志系统。10 公里测试跑 50 圈验证长时间运行后的稳定性尤其是关节漂移和轨迹偏移。半马模拟在赛前 1 周完成一次全距离模拟尽量复现比赛时间和光照条件。每个阶段结束后都需要拉取完整日志并生成报告。日志至少包括速度曲线、关节温度曲线、电池电压曲线、状态估计误差和控制指令变化。4.2 需要重点观察五组指标备赛过程中不能只盯着“有没有摔到”还要看以下指标指标正常范围参考异常表现关注原因平均速度1.5 到 2.5 m/s后程速度下降明显体能或电池热衰减关节温升不超过厂家持续运行上限电机过热报警长时间奔跑的主要故障源电池电压跌落全程电压不低于截止电压后程电压骤降电池内阻增加或容量不足平均功耗与本体质量相关突然升高步态效率下降或感知负载过大状态估计漂移每公里偏航小于 1 米偏航逐渐增大传感器融合稳定性差这些指标之间会互相影响。例如关节温度升高后电机输出扭矩下降机器人为了维持速度会增加步频步频增加又导致更高功耗最终使电池电压更快跌落。备赛时必须用测试数据找出自己机器人的“短板环节”。4.3 如何复现并分析一次摔倒摔倒不是结果而是过程。摔倒是控制失败累积到一定程度后的表现通常可以通过日志倒推。复现流程如下从日志中找到摔倒前的最后 5 秒数据。画出身体倾角、关节角和力矩指令随时间的变化。标记传感器异常值例如压力传感器丢失、IMU 饱和或编码器跳变。对比摔倒前几秒的控制指令是否出现剧烈波动。常见原因是状态估计突然跳变。当脚底压力传感器信号错误时状态估计会误判支撑脚处于摆动相导致重心预测错误进而产生错误的关节力矩。要解决这个问题需要在状态估计模块加入传感器融合的置信度判断而不是直接信任每个传感器数据。4.4 赛前夜间验证和环境干扰测试半马比赛可能从清晨开始地面可能有露水光照角度低。赛前需要在类似光照条件下测试。夜间的低光环境会明显影响视觉感知模块的识别距离如果使用激光雷达则要测试不同反光表面的检测效果。如果比赛道路旁边有大量金属护栏或广告牌需要验证机器人是否会被强反光表面干扰。建议在赛道预热时录制一段点云和图像数据离线测试感知算法避免比赛当天因为光线问题导致机器人错判路沿。5. 常见故障现象、排查顺序和处理方案5.1 机器人跑偏不是直线前进现象机器人出发阶段路线正常几百米后逐渐偏向赛道一侧。可能原因脚底压力传感器零点漂移导致左右脚受力判断不对称。左右关节电机扭矩标定不一致。地图或 GPS 信号偏差导致定位收敛方向偏转。路面存在侧倾角度但状态估计没有正确补偿。检查方式停车后检查左右脚压力传感器的初始读数是否一致。在平坦地面执行原地踏步 1 分钟观察偏航角速率。对比左右关节电流曲线看是否长时间存在固定偏差。查看定位模块输出的航向角和 IMU 航向角的差值。处理建议先校准传感器零点再检查电机力矩环增益。如果左右差异来自机械安装需要在控制补偿矩阵中加入固定补偿常数。5.2 后程速度变慢但关节温度正常现象前 5 公里速度正常第 8 公里开始平均速度下降没有过温报警。可能原因电池电压下降后电机进入弱磁区峰值扭矩输出受限。控制算法被设置为固定参数没有根据电压调整输出。感知模块因为环境变化增加计算量导致控制频率下降。检查方式查看电压-时间曲线看是否低于控制器电压阈值。查看控制循环周期是否在后程出现周期抖动。观察感知模块每秒处理帧数是否下降。处理建议在控制循环中加入“电压自适应”逻辑当电压下降时适当降低最大步幅优先保证稳定性而不是速度。感知模块可以设置优先级在识别到高置信障碍物时才降低控制频率。5.3 通信中断导致机器人紧急停车现象远程监控界面显示机器人离线机器人随后启动急停程序。可能原因无线通信网络覆盖不良尤其在赛道转弯或地道区域。机器人内部通信总线故障例如 CAN 总线受到电磁干扰。上位机 watchdog 判断远程心跳超时误触发急停。检查方式在赛道关键点测试信号强度标记盲区。查看机器人内部日志判断是网络断线还是控制器主动急停。检查 CAN 总线错误计数和重传次数。处理建议不要把安全急停依赖在远程通信上。机器人本体必须有一个独立于通信链路的急停机制只有当本地传感器检测到危险时才触发。远程通信主要用于监控和指令下发不能作为唯一安全屏障。5.4 摔到后无法自动恢复现象机器人摔倒后试图自主站立但反复失败。可能原因站立动作生成没有考虑当前环境的摩擦力。伺服电机因为摔倒撞击减速器或编码器错位。状态估计器在倒地瞬间失去有效参考。检查方式查看摔倒瞬间关节编码器和实际电角度的差值。检测电机驱动器是否报位置偏差错误。检查脚底压力传感器在倒地瞬间的数据是否异常。处理建议摔倒恢复动作应该分两步先判断当前姿态和接触面再决定使用哪个手臂支点。不要在摔倒后立即强制站立否则容易造成二次损伤。6. 生产级备赛清单和工程实践6.1 赛前 24 小时检查清单备赛最后一天需要重点关注的是系统状态检查而不是临时调算法。以下是可复用的赛前检查清单电池电量充满并记录常温下静置 1 小时后的电压。机器人本体所有螺丝按扭矩扳手检查尤其注意脚踝和髋关节。脚底压力传感器执行零点校准并保存校准文件到机器人本地。IMU 温度稳定后执行上电校准确认零偏值。检查所有通信链路遥控急停、无线局域网、内部总线。准备至少两套备用电池并标记好每个电池的内阻历史数据。将控制算法参数和日志模块配置文件备份到外部存储。在赛道现场进行一次 5 分钟低功率行走测试确认环境光线和 GPS 信号。确认所有远程监控页面能正常刷新日志能实时上传。制定紧急处理流程包括机器人摔倒、行人闯入和电池冒烟三种情况。6.2 赛事过程中日志记录要求日志系统不能只记录代码里的 debug 信息。对于半马赛事建议至少记录时间戳统一使用 UTC 或本地时区标出时区。状态估计输出位置、姿态、速度和置信度。感知输出障碍物列表、路径边界、识别置信度。控制输出目标速度、实际速度、关节力矩命令。电量信息电压、电流、SOC、温度。系统事件跌倒、急停、通信断开、过温报警、更新文件等。日志轮转策略要提前设置好。半马约 3 小时如果每周期记录 100 字节总数据量并不大但控制频率高时会达到数百 MB。建议使用环形缓冲区和异步写盘避免日志写入阻塞控制循环。6.3 如何将一次比赛经验沉淀为团队能力赛后复盘最重要的事情不是看成绩而是把全过程数据化。建议赛后 48 小时内完成三件事拉取完整日志按距离分段统计速度和功耗。标注所有异常事件发生的时间点并检查前后各 10 秒的数据。更新参数基线库判断哪些参数需要根据赛道路面特性进行调整。如果比赛中出现未知异常不要直接修改代码后再次测试而是先复现并定位根因。盲改代码只会让系统变得不稳定而且会影响团队对系统行为的判断。6.4 从半马赛事到更复杂场景的扩展完成半马之后下一步可以朝三个方向扩展更高速度下的动态步态、更复杂地形的全身运动规划、以及与人行道上真实行人混行的决策系统。半马积累的长时运行数据是这些方向最宝贵的训练集。其中最值得优先建设的是“长时运行回归测试平台”。每次修改步态算法或更换电机后强制跑一段 5 公里测试用历史数据对比速度、温度和功耗变化。没有这个回归测试团队很难判断一次改动是变好还是变坏。另一个值得投入的方向是电量与热管理预测模型。通过半马积累的电池温升、电压跌落与电机负载数据可以训练一个简单的预测模型用于在比赛前 10 分钟判断是否能够完赛以及应该调整配速还是减少感知计算负载。7. 常见技术选型对比与决策建议7.1 传感器的融合主次关系半马场景中不同传感器的可靠性差异很大。IMU 在高频运动和震动下容易饱和GPS 在道路两侧高楼之间容易漂移视觉在光照变化下不稳定激光雷达在雨天和雾天会受干扰。因此传感器融合不是简单加权平均而是要根据环境动态调整可信度。传感器优点缺点最佳使用场景IMU高频、不受光照影响积分漂移、震动易饱和短时姿态估计辅助控制关节编码器精度较高、直接测量不能感知全身姿态关节角控制和反馈脚底压力直接测量接触状态易磨损、零点漂移步态相位的判断相机信息丰富、成本低光照变化敏感障碍物检测和路径边界激光雷达距离准确、不受光照影响雨雾衰减、点云量大建立局部地图和避障GNSS绝对定位城市峡谷漂移赛道级定位辅助校正7.2 控制算法选型MPC 还是传统 PIDMPC 在理论上有很强的约束处理能力但计算开销大传统 PID 简单稳定但无法自然处理全身重心约束。对于半马场景推荐在基础步态控制中使用 PID 加状态机在高层规划中使用优化方法。前者保证实时性后者保证全局合理性。如果团队有硬件加速器或充足计算资源可以在直道上启用简化 MPC而在弯道和复杂地形切回 PID。关键是要保证两种控制模式切换时关节力矩指令连续不能有突变。7.3 通信协议选择机器人本体的通信协议可以有两种取向可靠但实时性较低的 TCP实时性高但可能丢包的 UDP。控制指令安全不建议使用 TCP 的自动重传机制因为重传会造成延迟抖动。推荐在控制链路使用 UDP 并带上序号和校验在状态上报链路使用 TCP 或 MQTT。比赛现场无线网络存在大量 2.4G 信号干扰建议 5.8G 链路和有线备份同时部署。所有通信链路都要有一个“降级模式”一旦远程链路断开机器人继续按本地传感器数据运行而不是直接停车。8. 赛事现场运营和技术保障8.1 比赛日的技术保障团队分工一支半马参赛机器人团队至少需要四类角色机器人控制工程师负责监控机器人状态、调整赛前参数、处理运行中异常。机械工程师负责现场维护、螺丝紧固、关节润滑和备用电池更换。软件工程师负责日志系统、通信链路和远程监控界面的稳定运行。赛事协调人员负责与主办方沟通规则、赛道情况、补给点和突发变更。分工越明确故障处理越高效。不要出现所有人同时挤在屏幕前看机器人的情况。8.2 临时参数调整要有审批流程比赛过程中可能会出现需要临时调整参数的情况例如发现地面湿滑、风力增大或机器人偏航。临时参数调整需要严格记录不能只改一个数字就继续跑。建议使用参数版本管理工具每次调整后把参数文件保存到本地和云端并记录调整原因。比赛结束后再统一评估决定哪些临时参数可以固化到基准参数库。8.3 突发情况应对预案赛事中最常见的突发情况包括机器人摔到后阻塞赛道、通信频繁中断、电池电量不足以完成下一圈和突发天气变化。针对每种情况都要提前制定响应动作。例如机器人摔到后现场机械工程师应该在 10 秒内抵达机器人身边先用硬开关断电再检查是否需要机械维修。不要远程尝试反复重启现场操作员应该负责评估是否继续参赛。如果天气突变导致降雨而机器人没有防水设计必须立即停车。比赛成绩可以再来但电机和电路板烧毁的损失无法挽回。8.4 赛后数据归集与经验分享比赛结束后主办方通常会提供计时结果、分段时间和裁判记录。这些赛事数据应与机器人内部日志合并分析形成一份完整的赛后报告。报告至少包含比赛时间线、每个时间节点的速度、能耗、温度、故障事件和人工干预行为。这份报告既用于下一次比赛改进也能作为团队长期技术积累的一部分。不要只保留比赛视频视频无法替代日志中的精确数值。9. 从“能跑起来”到“能完赛”的长期路径半马赛事真正考验的是团队能否把机器人从“实验室演示样机”变成“可重复执行任务的工程系统”。这个过程没有捷径。建议按照以下路径推进先跑断一个 5 公里积累第一个完整数据集。找到最薄弱的环节优先解决机械和电池问题再调算法。建立一套自动化的回归测试脚本每次改动后用相同路线跑一次。逐步提高比赛模拟的距离和复杂度直到能在与赛道环境接近的场地上完成半马模拟。最后两周不要引入新功能只做参数细化和故障演练。这条路径的价值在于它把不能量化的“感觉不稳定”变成了可跟踪的“哪一公里速度下降了”“哪个关节温度最高”“哪次通信断了多久”。对刚接触人形机器人竞赛的团队最值得练习的不是写出更先进的强化学习策略而是先建立完整的日志、回放和数据对比流程。只有当你清楚地知道机器人每一步踩在哪里、每个关节输出了多少力矩、每块电池消耗了多少能量你才可能面对半马 21.1 公里时保持冷静并在第 15 公里出现异常时快速判断是继续跑还是停车检修。这就是工程能力与实验室能力之间最本质的区别。下一步可以把比赛积累的长距离数据集用来训练更鲁棒的步态控制器也可以围绕功耗和热管理建立预测模型让人形机器人真正进入半结构化室外环境的应用场景。