我最近把代号“青龙”的人形机器人硬件平台从一张构型草图推到整机控制系统闭环整个过程比预想中费时间但也把不少关键坑位摸清楚了。人形机器人硬件平台从来不是把电机、减速器、传感器堆在一起就行构型决定运动能力上限控制系统决定这些能力能不能稳定释放出来。这篇文章就是围绕“青龙”这个项目完整拆解我从自由度分配、执行器选型、传感器布置到关节伺服、全身控制、 EtherCAT 总线联调的整个实战过程。如果你正准备入门人形机器人本体设计或者已经在做机器人底盘、机械臂、四足之类的硬件集成想了解整机平台怎么做这篇文章都可以当一份可参考的工程笔记来用。我不会讲太多虚的理论推导重点是每个环节我为什么这么选以及实际操作里有什么约束和教训。1. 整体设计思路硬件平台为什么从构型开始1.1 从需求倒推构型青龙项目到底要做什么很多人一开始做机器人习惯先找便宜的电机再拼一个看起来像人的躯干最后发现走起来像“僵尸跳”。这类平台普遍问题不是硬件不够强而是构型没想清楚就开始堆料。做青龙之前我们先把项目定位和工作场景列得足够具体再反过来定自由度、尺寸和功率。青龙的定位是实验室通用人形机器人平台主要用来做双足稳定步态、全身动态运动、双臂协同操作这三类研究。这意味着它不像工业机械臂那样固定安装也不像四足机器人那样天然就是静稳定的。双足机器人在行走过程中重心会周期性脱离支撑多边形对关节峰值扭矩、响应带宽、结构刚度都有非常苛刻的要求。基于这样的使用场景我把需求拆成了五条硬指标整机身高1.65m左右重量控制在65kg以内方便实验室搬运和吊装连续双足行走时间不低于30分钟室内平地为主允许上下缓坡单臂末端负载3kg满足轻量抓取、插拔、推拉类操作关节模块化设计单关节故障能在半小时内更换控制系统开放接口支持外部算法团队二次开发。这些指标不是拍脑袋定的。比如续航30分钟就是因为我们很多实验需要持续采集数据来回跑不到10分钟就换电池会让实验节奏被打断。单臂负载3kg也是对比了几款夹爪和常用实验道具后取的保守值。先有这些边界条件自由度怎么分、电机选多大才有计算依据。确定需求之后我做的第一件事不是建模而是拿一个二维的人体比例图把躯干、大腿、小腿、上臂、前臂的长度和质量分布根据人体测量学数据先估算出来。很多新团队容易忽略这一步直接拿三维软件拉模型结果电机装好后发现膝关节扭矩完全不够只能推翻重来。人体比例数据虽然不能直接等于机器人构型但至少给你一个合理的初始质量分布后续迭代才有参照。1.2 构型方案对比旋转关节、线性执行器还是混合构型人形机器人构型最核心的分歧是腿部执行器形式。早期波士顿动力的Atlas用液压线性执行器体积小力密度高但液压系统对密封和油源要求极高实验室基本玩不转。后来Optimus这类电机驱动方案改用行星滚柱丝杠加线性执行器把电机旋转运动转换成直线推拉力量传递路径更直接膝关节承受的弯矩也更小但结构复杂度和成本都高不少。青龙最终选择了以旋转关节为主、关键大扭矩关节加强支撑的混合构型方案。也就是髋关节、肩关节这些位置用传统旋转电机加减速器膝关节和肘关节也使用旋转方案但在机械结构上增加锥轴承和交叉滚子轴承来抵抗侧向弯矩而不是引入完整线性执行器系统。这个选择主要基于三个考量第一旋转关节供应链最成熟。无框力矩电机、谐波减速器、交叉滚子轴承这些核心部件都有大量成熟供应商采购周期短品控也相对稳定。线性执行器尤其是行星滚柱丝杠国内能做好且价格合理的供应商数量很少定制周期动不动就要几个月。第二调试难度可控。线性执行器对安装精度、丝杠预紧、直线导轨平行度都极其敏感稍有偏差就卡滞或者抖动。旋转关节哪怕中心轴有些偏差至少电机还能转调试阶段容错空间大得多。第三控制系统和仿真工具兼容性好。旋转关节的动力学模型无论是URDF描述还是标准DH模型都有成熟的工具链支持。线性执行器虽然也能建模但刚度和摩擦参数更难标定对团队控制算法经验要求更高。用表格对比三种方案会更直观构型方案力传递效率抗弯矩能力成本调试难度适用场景液压/气动线性执行器高强极高极高高动态跑跳、大负载电机行星滚柱丝杠线性执行器较高强高高高力密度行走、类人比例旋转电机减速器中等较弱但可通过轴承加强中中通用科研、算法验证、教学演示对大多数实验室和创业团队来说旋转关节方案是“少走弯路”的稳妥起点。如果你能做到线性执行器的精密加工和标定性能上限确实更高但前提是团队里有机械精度控制方面经验足够的人否则项目很容易卡在机加工返工和摩擦标定上。1.3 这套方案能复用到哪里青龙这套硬件平台设计本质上是一个“中等规格、高开放度”的科研平台。它不太适合直接去做重工业场景的搬运因为关节负载余量有限连续作业散热也不够。但它非常适合这几类复用场景高校实验室做双足步态算法验证实机摔打磨损后维修成本可控机器人比赛和演示项目需要稳定站立、行走、挥手这类基础动作双臂协同操作研究验证全身运动规划与人机协作算法作为硬件教学平台让学生接触完整的关节伺服与整机通信调试流程。如果你只是想做桌面级玩具或小型人形这套设计方案里的很多思路可以沿用但尺寸和功率都要等比缩小没必要照搬全尺寸参数。反过来如果你想做物流搬运或工业作业机器人那构型要重新考虑腿部需要更强的结构刚度和底盘式支撑不能直接套用人比例方案。2. 硬件构型设计关节怎么排、材料怎么选2.1 自由度分配与关节布局人形机器人的自由度决定了运动灵活性的上限。自由度太少很多动作做不出来自由度太多控制维度爆炸动力学计算和调试成本成倍增加。青龙的自由度配置是这样的部位自由度具体分配腿部单侧6髋关节3横滚、俯仰、偏航 膝关节1 踝关节2俯仰、横滚腰部2俯仰 横滚手臂单侧7肩关节3 肘关节2 腕关节2颈部2俯仰 偏航整机一共29个自由度。腿部做成6自由度而不是5自由度主要是为了给踝关节增加横滚方向的自由度让脚底能根据地形更好地贴合地面这在行走稳定性上非常关键。手臂做成7自由度是为了冗余操作机械臂在保持末端位置姿态不变的情况下肘关节可以有自运动空间能更好地绕开障碍物。关节布局方面我提一条很实用的经验髋关节的三轴交汇点尽量落在同一空间点上。这样腿部可以简化成球关节模型正逆运动学推导和动力学简化都会方便很多。实际机械结构很难做到绝对同轴但至少要让三轴延长线在允许公差内靠近。如果三个轴分散得很开腿部逆解会出现比较明显的畸变控制调试的时候特别难受。腰部的2个自由度一开始被很多人质疑觉得增加重量和复杂度。但实际测试下来腰部俯仰和横滚对行走姿态调整的贡献很大。尤其是转向和上下坡的时候躯干主动倾斜可以显著降低髋关节的扭矩需求。如果你的项目预算有限先把腿部和手臂做扎实腰部可以留作后续升级。但必须在设计之初预留空间和供电接口否则后面加装非常麻烦。2.2 执行器选型与扭矩估算执行器是硬件平台的“心脏”几乎占据了整机成本的一半以上。青龙的每个关节都是一个完整的伺服模组由无框力矩电机、谐波减速器、增量式编码器、绝对值编码器和低压伺服驱动器组成。选型逻辑很简单先算出每个关节的峰值扭矩和额定扭矩再根据转速范围确定减速比最后挑电机。以最容易出问题的膝关节为例做个简化估算。假设青龙大腿长0.42m小腿长0.40m单腿支撑时上半身和另一条腿的质量折算到膝关节的重力分量约为55kg左右。人在正常行走时支撑腿膝关节角度会有一个小幅弯曲缓冲的过程前脚着地瞬间膝关节承受的动态载荷可以达到体重的2到3倍。这里取2倍体重作为峰值参考单腿峰值载荷 F ≈ 55kg × 9.8 × 2 ≈ 1078N力臂按质心到膝关节的水平投影距离估算大概0.15m到0.2m峰值扭矩 T ≈ 1078N × 0.18m ≈ 194Nm实际行走中膝关节峰值扭矩通常在100Nm到200Nm区间因此我直接把膝关节额定输出扭矩定在120Nm峰值做到220Nm以上留出一定余量。髋关节因为支撑整个下肢和躯干峰值扭矩要求比膝关节还高按150Nm额定、260Nm峰值来选。踝关节相对小一些由于力臂短和脚底支撑面大额定60Nm左右就够用。减速比怎么定人形机器人关节输出转速一般不需要太高行走时膝关节最大角速度大约是6rad/s到8rad/s换成每分钟转速大约60到80rpm。无框力矩电机的额定转速通常在2000rpm以上所以减速比大约选50到80。谐波减速器的单级减速比刚好落在40到160这个区间一台50比或80比的谐波减速器就能满足需求结构紧凑回差小。驱动器选型有一个容易忽略的点母线电压。青龙采用48V直流母线供电低压伺服驱动器工作在50A到80A连续电流区间峰值电流要能做到120A以上。很多人只看电机额定电流去配驱动器忽略了电机堵转和急加速时的峰值电流裕量结果走路过程中驱动器过流保护频繁触发整个平台就瘫了。我的经验是驱动器峰值电流至少按电机峰值电流的1.2倍选并且要有完善的过流、过温、欠压保护逻辑。2.3 结构材料与装配工艺构件材料的选择直接影响整机重量和刚度。青龙的主要受力骨架用7075-T6铝合金这种材料强度高、加工成熟度好适合做关节壳体和连接件。大腿、小腿、上臂、前臂这类细长杆件用碳纤维管或碳纤维板加铝合金接头同等重量下刚度比纯铝好很多但碳纤维加工需要更长的周期返修也麻烦所以只在小批量验证阶段使用。3D打印在这套平台里也起了很大作用。关节内部的过渡支架、传感器安装座、线束固定卡扣这类非主要承力件基本都用尼龙加玻纤材料打印价格便宜迭代快。设计时要注意3D打印件的公差比较大凡是需要定位的地方必须留出机械加工面不能直接依靠打印精度。装配工艺上最容易翻车的点是螺栓松动和同轴度。人形机器人长时间行走关节振动比普通工业设备大得多所有高负载螺栓必须用厌氧胶或防松垫圈。电机和减速器连接时如果轴孔配合间隙过大运转起来就有“咯噔”声这种机械间隙靠控制算法很难完全补偿。装配后每一个关节都要做轴向窜动和径向跳动检查偏差超过0.05mm就要重新装配。2.4 传感器系统布置硬件平台的“感觉系统”决定了控制算法能拿到什么质量的反馈。青龙的传感器系统分为三块运动状态感知、关节状态感知、外部交互感知。运动状态感知的核心是IMU装在骨盆正中央也就是人体重心附近这样测得的加速度和角速度最能反映躯干姿态。IMU选型上我推荐带温度补偿的工业级六轴或九轴单元消费级航模IMU零偏稳定性太差走几步积分就漂得厉害。IMU安装时要用橡胶减震垫与结构隔离否则电机振动会直接污染加速度计信号。关节状态感知分为电机端和输出端两级。电机端用增量式编码器做FOC换相和速度闭环输出端用绝对值编码器测量关节真实角度。这样既保证了电流环的高速采样需求又避免了断电丢零和减速器回差带来的角度误差。每次上电后要做一次电机端和输出端编码器零位对齐这一步没做好后面整个运动学都是错的。外部交互感知主要靠脚底和手腕的六维力传感器。脚底六维力可以实时测量地面反作用力和作用点位置是步态控制里判断支撑状态的关键数据。手腕六维力则让机械臂在夹取物体时能实现柔顺控制。六维力传感器成本比较高如果预算有限可以先只在两脚底安装手腕的力传感器后面再补。3. 控制系统设计从关节伺服到全身协调3.1 控制系统总体架构控制系统是人形机器人真正难的环节。硬件平台再强控制跟不上机器人在原地晃两下就倒。青龙的控制系统采用典型的“感知-规划-控制”三层架构并在实时性上做了严格划分。最顶层是感知和任务规划跑在普通Linux工控机上负责视觉识别、环境建模、任务级行为决策。中间层是运动规划负责生成落脚点、质心轨迹和全身关节轨迹这一层通常跑在带实时补丁的Linux系统或者ROS环境里。最底层是关节控制和状态估计必须保证硬实时跑在EtherCAT主站加实时任务中周期通常做到1ms甚至更小。为什么要做严格的实时分层因为关节伺服和全身控制如果被非实时任务干扰调度抖动超过几毫秒机器人的动态平衡就会被打破。实际调试中我遇到过总线抖动导致膝关节输出扭矩波动结果整条腿高频抖动的情况。所以底层控制代码不建议和复杂的感知算法跑在同一个进程里最好用独立实时核或者独立控制器。青龙的整机控制流程可以概括为感知模块送出身姿和外部环境信息运动规划模块在几百赫兹频率下计算期望的质心和落脚点全身控制模块把期望轨迹映射到每一个关节的期望力矩最后关节伺服模块在千赫兹频率下跟踪这些力矩和位置。每一层都有独立的安全检查机制一旦发现异常就回落到安全姿态或触发急停。3.2 关节伺服控制回路关节伺服是整个控制闭环的最底层也是最依赖调试经验的环节。青龙每个关节都用FOC矢量控制的无刷电机驱动器控制回路分为三层电流环、速度环、位置环。电流环是响应最快的一层通常运行在10kHz到20kHz直接控制电机的q轴和d轴电流。电流环直连电机绕组带宽高但容易受到电流采样噪声和死区效应的影响。速度环在电流环外面运行在1kHz到5kHz输出为电流指令。位置环在最外层通常1kHz运行输出为速度指令。从内到外逐层闭合每一层调通了再调外层是基本的调试顺序。这里分享一个非常实用的调参经验先用开环测试确认电机方向和编码器方向否则你给正电流它却反转整个闭环直接发散。然后从电流环开始调给一个阶跃电流指令观察实际电流的上升时间和超调量。电流环带宽不用追求极致够用就好太高容易把电流采样噪声放大进去。位置环整定是关节抖动问题的高发区。如果位置环比例增益太大会出现高频啸叫调小又感觉关节很软。我通常先调阻尼也就是速度环的比例增益再调位置环刚度。调好之后用正弦扫频测一下关节的频率响应看看有没有明显的机械谐振峰。有谐振峰就得在速度环加陷波滤波器否则调试时一切正常跑起来一走一停就会激发共振。3.3 全身动力学控制人形机器人行走本质上是在不断制造失稳又恢复稳定的过程。青龙的全身控制采用的不是简单的关节PD跟踪而是基于模型预测控制MPC和全身动力学控制WBC的组合方案。步态规划层使用线性倒立摆模型LIPM简化质心动力学假设质心高度不变地面反作用力只沿水平方向作用于质心。这样可以把双足步态问题简化成一个线性模型预测控制问题预测未来0.5到1秒的质心轨迹和落脚点让机器人腿部提前布局。有了期望的质心轨迹和落脚点之后全身控制层需要在任务空间同时跟踪多个目标比如质心高度、躯干姿态、末端位置等。这些目标往往相互冲突所以WBC用加权或优先级的方式通过二次规划求一个最优的关节力矩分配方案。优先级高的任务优先满足比如保证不倒比保证抬手位置准确更重要。这种控制方案效果好但计算量大调试也更复杂。最开始做青龙的时候我只用简单的重心投影法和关节PD控制机器人在静态站立时还能稳住一旦迈步就乱套。后来逐步上了MPC加WBC才有了比较自然的行走效果。如果你的目标是快速验证硬件可以先从简化版的静态行走做起比如步态规划写死膝盖微屈重心缓慢移动先让机器人能走两步再考虑动态行走。状态估计也不可或缺。青龙使用扩展卡尔曼滤波器EKF融合IMU的角速度和加速度、关节编码器的角度、脚底力传感器推算的支撑情况实时估计躯干的姿态、位置和速度。没有准确的状态估计MPC和WBC都无从谈起因为控制器需要一个相对可靠的“我当前在哪里、往哪个方向运动”的反馈。3.4 通信总线选择人形机器人通信总线的选择直接关系到关节数量扩展的便利性和调试的便利性。青龙全身29个自由度每个关节模组都有电机编码器、输出端编码器、驱动器和温度传感器数据对总线带宽和实时同步的要求都比较高。我们一开始考虑过CAN总线因为CAN在工业领域很成熟简单可靠单条CAN2.0总线上1Mbps的带宽也够用但同步性相对弱一些要自己实现全局时间同步。后来测试中发现CAN总线在整机高速运动时高优先级的数据帧会挤占低优先级帧导致部分关节数据延迟不均匀调试方面也比较费劲。最终青龙选择了EtherCAT方案。EtherCAT的分布式时钟机制可以让所有从站在同一时刻采样主站周期可以做到1ms甚至更短同步精度达到微秒级。这对需要精确协调全身关节的MPC和WBC来说非常重要。EtherCAT主站用的标准工业主站加简单网卡从站就是关节驱动器自带的EtherCAT从站接口不需要额外开发省了很多事。总线选型对比总线类型同步精度带宽接线复杂度调试成本适用场景CAN/CANFD中1Mbps/5Mbps低低简单运动控制、早期验证EtherCAT高us级100Mbps中中高多关节、高实时同步实时以太网PROFINET等高100Mbps以上中高工业级多轴运动控制EtherCAT也不是没有缺点。它对线缆质量、连接器可靠性和接地处理要求更高工业协议栈调试起来比CAN要复杂。如果项目初期只有6到8个关节CAN其实足够用但要做到全身29个自由度并追求动态性能我更推荐EtherCAT。4. 实测过程从装配到整机联调的完整流程4.1 样机装配与线束管理青龙的装配顺序很有讲究不能从脚开始往上装也不能先装好整个躯干再装腿。我习惯的装配顺序是先把腿部和髋部做成独立模块单独供电先验证单腿各关节的运动范围和正反向。然后组装躯干和腰部再把另一条腿接上做双腿并联静态测试。最后才装手臂和头部。线束管理是很多人形机器人项目翻车的重灾区。关节线束如果直接暴露在表面不仅难看还会在运动过程中被拉扯和磨损。青龙的走线策略是执行器内部尽量用中空轴走线电机轴和减速器中心留出过线孔位让动力线和编码器线从关节内部穿过。少数实在走不了中空轴的关节也要设计专用的拖链或线槽避免线束打折和摩擦。接线时还有一个特别重要的点接地和屏蔽。EtherCAT和编码器信号线如果屏蔽层处理不当电机启停瞬间的电磁干扰会直接导致通信丢帧和编码器跳数。我的经验是屏蔽层要选择单端接地接地线尽可能粗短和驱动器电源地汇接在一点上。每个关节模组的外壳也要和整机地平面良好导通不然整台机器人就像一个天线干扰非常随机。4.2 关节参数调试顺序关节伺服参数调试是必须反复折腾的过程。青龙的整机联调前每个关节要先独立完成一轮完整的参数整定。我总结出一个固定流程照这个顺序走能省大量时间第一步开环检查。给电机一个很小的恒定电流指令确认电机转向是否符合预期电机端编码器和输出端编码器方向是否一致。很多编码器方向反了导致位置环直接正反馈发散问题就出在这一个小小的检查上。第二步电流环整定。先给q轴电流一个阶跃观察实际电流跟随情况。如果超调太大就适当降低电流环PI参数如果响应太慢就提高比例增益。电流环调好后电机应该能平稳输出力矩没有明显“滋滋”声。第三步速度环整定。给一个恒定速度指令看速度波动幅度。人形机器人关节速度波动会直接反映在运动平稳性上速度环比例太大会有高频啸叫积分太大会有低频摆动。第四步位置环整定。位置环增益决定关节刚度和跟随精度。先从小增益开始逐步增大直到出现振荡再退回一点点。差不多稳定的位置再通过手推关节感受一下有没有“发飘”的感觉。第五步正弦扫频和陷波器整定。对每个关节做0.5Hz到20Hz的正弦扫频记录幅值响应和相位响应。如果在某个频率出现明显的谐振峰就在速度环或电流环加陷波滤波器。这一步很关键很多整机抖动问题都要靠它解决。调试现象可能原因调整方向电流阶跃超调大电流环增益过高降低PI比例增益匀速运动速度波动速度环增益不够或摩擦补偿未调提高速度环增益、增加摩擦前馈关节高频啸叫速度环增益过高或谐振降低速度环增益、加陷波滤波器位置阶跃振荡位置环比例增益过大降低位置环比例增益调整阻尼停止后低频摆动速度环积分造成限幅饱和检查积分限幅降低积分增益这套流程看起来琐碎但每个关节都这么走一遍之后整机调试会顺畅得多。如果跳过单关节整定直接上整机一个问题多点爆发排查起来非常痛苦。4.3 从仿真到真机联调在把青龙真正放上赛道上之前我强烈建议先做充分的仿真验证。我们主要用MuJoCo做动力学仿真把URDF模型导入调好质量、惯量和摩擦参数先在仿真环境里跑通步态规划和控制算法。仿真能自动重置敢开大增益试错真机就不允许。但我必须提醒一句仿真里跑得好的算法直接放到真机上大概率会出问题。区别最大的是摩擦和传动柔性。仿真里关节是理想力矩源而真实谐波减速器有明显的摩擦和柔性滞后。所以第一轮真机联调时我会把控制增益降到仿真值的50%到70%让机器人先以一个“偏软”的状态动起来确认所有关节方向正确、通信正常再逐步提高增益。真机测试的安全措施不能省。第一次站立测试前必须在机器人上方加装吊架或安全绳很多团队觉得机器人不高就直接在地板上测一旦重心偏出支撑多边形摔下去可能就是几万元的损失。青龙的整机联调阶段还有一个“力限制模式”所有关节的期望力矩限制在正常值的30%以内即使控制信号异常关节也不会做出危险的大幅度动作。急停按钮必须安排在操作员手边并且和整机电源回路联动按下就能彻底断电。5. 常见问题与排查技巧实录5.1 关节抖动、异响与过流关节抖动是整机联调里出现频率最高的问题。青龙在一次试运行时膝关节在站立状态下出现肉眼可见的高频抖动伴随明显“嗡嗡”声。当时第一个怀疑是速度环增益太高调低之后抖动只减轻了一部分。用示波器看电机相电流发现电流波形叠加了明显的高频噪声进一步追查发现是出线端编码器屏蔽层松动导致换相信号受干扰。把屏蔽层重新处理好换相稳定了抖动基本消失。异响方面最常见的是机械同轴度偏差导致的周期性“咔咔”声。如果电机轴和减速器输入轴不同轴运转时波发生器会周期性受压产生明显的节拍声。这种问题只能停机检查装配重新调正轴系靠软件算法是消不掉的。运行一段时间后出现异响还要检查减速器润滑脂是否干涸或轴承是否有磨损。过流保护频繁触发除了选型偏小还可能是电机相线顺序错乱。FOC需要正确的电角度反馈如果相序接错或编码器零位错位控制器会误以为需要输出更大电流结果一会儿过流一会儿堵转。这时先退出闭环用开环方式确认相序和电角度再重新做零位对齐。5.2 EtherCAT通信丢帧与延迟排查EtherCAT通信问题在整机联调阶段也比较折磨人。青龙遇到过一种很隐蔽的现象单独测一个关节时通信一切正常六个关节一起动偶尔就会报一两个丢帧。这种问题不是协议本身的问题排查思路主要集中在物理层。第一步查看总线统计中的丢帧时间点如果丢帧总是出现在电机加速或大电流时刻基本可以判断是电磁干扰。检查信号线是否和动力线绑扎在一起走线如果混合走线必须分槽且信号线必须用屏蔽双绞线。第二步检查线缆两端屏蔽层的接地方式屏蔽层如果两端都接地容易形成地环路反过来引入噪声最好单端接地。第三步检查终端电阻EtherCAT总线首末两端必须有正确的终端电阻缺失会导致信号反射长距离传输时尤其明显。另外一个非常容易忽略的点是连接器接触电阻。人形机器人运动过程中关节线束跟随动作弯折连接器端子如果锁紧力不足会出现偶发断路。我用的是带锁扣的工业连接器并且走线时在连接器尾部加了固定卡扣防止反复弯折导致端子松动。整机跑过一段时间后定期重新按压检查一遍所有连接器成本很低但很有效。5.3 整机续航与发热管理续航和发热是硬件平台实际使用阶段最影响体验的问题。青龙设计指标是连续行走30分钟但第一轮实测只有不到18分钟原因是电池选型时只按电机额定功率估算了容量没把控制板、工控机、传感器和待机功耗算进去。重新统计整机平均功耗后我把电池容量从12Ah提升到了16Ah续航才勉强到35分钟左右。电池安全也必须认真对待。人形机器人是高功率设备电池输出电流经常在50A以上必须用支持大电流放电的动力电池连接器要选能承受持续大电流的航空插或安德森插头普通电源端子在大电流下会发热烧蚀。整机电源回路要加保险丝或断路器一旦电流异常能在毫秒级切断。发热管理上关节驱动器的热量积累比电机更严重。电机本身有金属外壳散热而驱动器装在小体积壳体内散热条件差。青龙在负载较大的髋和膝关节驱动器上加装了铝制散热片并在热管理策略里加入了电流降额曲线驱动器温度超过80℃时控制算法自动限制该关节的力矩输出。这个保护看起来很基础但能避免很多灾难性故障。控制系统的“负阻尼”这个问题也值得提一下。负阻尼通俗讲就是系统在某个频段不但不消耗能量反而给关节注入能量结果表现为振荡越来越大。青龙在初期整调位置环时就因为编码器滤波相位滞后太严重导致位置环看起来在误差大时反向发力实际等效成一个负阻尼系统整条腿越抖越厉害。后来我严格控制编码器滤波器的延迟并且用速度前馈补偿相位滞后才把这个问题压下去。调试过程中如果发现某个关节振荡幅度越来越大优先怀疑负阻尼要检查滤波器延迟和增益符号不要一味加大阻尼参数。续航和散热是硬件平台最容易“慢性病”化的两项指标前期设计不重视后面很难补。比如电池仓空间和散热风道必须在结构设计时预留否则电机一热就成了只能空调房里跑几步的实验品。我个人在实际操作中有个很深的体会人形机器人硬件平台设计的关键不是哪个部件最好而是所有子系统之间的匹配度。电机扭矩、减速器刚度、驱动器带宽、总线同步性、控制算法频率这些参数必须咬合在一起任何一个环节成为短板整机性能就被卡死。所以做这类项目先定清晰的需求再用工程迭代的思路把构型、硬件、控制层层打通比迷信某个高端部件要重要得多。最后再分享一个小技巧每一次整机联调不管成功失败都完整记录所有关节的电流、温度、位置轨迹和事件日志。这些数据不仅仅是事后分析的依据更是下次设计迭代最宝贵的输入。青龙后续的很多结构改进其实都来自这些实测数据的复盘而不是一开始的预想。硬件平台没有一步到位的方案只有不断基于数据打磨出来的成熟平台。