今年的人形機器人賽道正在從“能走幾步”的展示階段快速切換到“能跑、能跳、能比賽”的工程驗證階段。當北京人形機器人“天工 Ultra”以 38.15s 跑完 400 米并在人形機器人運動會上拿下首金時很多人看到的是新聞熱度但對做機器人、搞運動控制、關注具身智能的開發者來說這其實是一次非常典型的技術信號人形機器人的動態運動能力已經從“實驗室演示”走向了“競技場實測”。本文不打算只報喜訊而是把這場 400 米競速當成一扇技術觀察窗口拆解背后的人形機器人運動控制、軟件架構、關節執行器、算力平臺等關鍵環節。無論你是剛入門機器人學的學生還是正在做足式機器人項目的工程師都可以從這條新聞里提煉出值得借鑒的技術路線和工程方法論。1. 事件回顧38.15s 背后的技術信號1.1 一場屬于人形機器人的競速賽“天工 Ultra”出現在人形機器人運動會的 400 米競速項目中并以 38.15s 的成績完賽奪得該項目的首金。這則新聞之所以引起關注不只是因為“金牌”而是因為它把兩個原本很難放在一起衡量的事物放在了一起人類田徑規則和人形機器人的運動能力。很多人對人形機器人的認知還停留在“能穩穩走幾步”的階段。但“天工 Ultra”這次跑完 400 米說明它已經不是在做慢速靜態行走而是在進行高速動態跑步并且具備連續跑完一整圈的能力。這背后涉及的不只是電機功率更是步態規劃、實時平衡、狀態估計、整機結構強度等多個環節的協同。從公開報道來看這類人形機器人運動會正在成為檢驗具身智能技術成熟度的一種方式。相比單純展示“會翻跟頭”“會跳舞”競速項目更強調持續性、穩定性和重復性——這三個指標恰恰是工程落地最關心的。1.2 38.15s 的成績處于什么水平要理解 38.15s 這個數字先看人類田徑的參考男子 400 米世界紀錄大約在 43 秒級別女子紀錄約為 47 秒級別。也就是說如果只按時間對比38.15s 這個成績已經超過了人類頂尖運動員的水平。不過這里必須冷靜看待。機器人的 400 米成績不能直接和人類成績做簡單對比因為兩者在身體結構、關節自由度、能量來源、賽道規則上都不同。機器人可以做到極高的關節轉速和穩定的步頻但它缺乏人類那樣復雜而柔性的肌肉骨骼系統。真正值得關注的是一個雙足人形機器人能夠在高速奔跑狀態下保持不摔倒并連續完成 400 米這在工程上是很大的突破。對機器人開發者而言這個成績意味著動態步態算法已經從理論上走到了真實硬件中。換句話說“跑起來”已經不再是能不能的問題而是穩不穩、快不快、久不久的問題。1.3 為什么要關注競速類人形機器人有人會問人形機器人不是應該去做家務、搬運、巡檢嗎為什么要比賽跑步從技術角度看跑步是檢驗運動控制系統極限能力的高壓測試。一個能高速奔跑的機器人在低速行走、上下坡、越障、抗擾動等場景下的控制能力通常會更強。因為跑步過程中機器人會經歷“騰空相”和“觸地相”的快速切換對執行器的帶寬、傳感器的刷新率、控制算法的實時性都提出了極高要求。如果一套運動控制系統能在 400 米競速中穩定跑完全程那么把它遷移到工業巡檢、物流搬運、災害救援等場景時很多低速動平衡問題就會顯得相對簡單。這也是為什么頭部團隊愿意投入大量資源去優化奔跑能力——它不是炫技而是技術棧成熟度的試金石。2. 人形機器人跑步的核心技術棧2.1 系統整體架構一臺能跑的人形機器人本質上是一個高度集成的“感知-規劃-控制-執行”閉環系統。可以用下面這個簡易分層來理解感知層IMU、關節編碼器、足底力傳感器、相機 ↓ 狀態估計機身姿態、質心位置、接觸力 ↓ 運動規劃落腳點規劃、質心軌跡生成、步態切換 ↓ 實時控制全身動力學控制、力矩分配、平衡補償 ↓ 執行層關節電機、驅動器、減速器每一層都有各自的挑戰。感知層要在劇烈振動和快速運動下仍能準確估計姿態規劃層要在幾十毫秒內計算出下一步的落腳點和質心軌跡控制層要以 1kHz 甚至更高頻率輸出關節力矩執行層則要提供足夠大的瞬時功率并且能夠承受反復沖擊。2.2 感知與狀態估計跑步時機器人身體始終處于動態不平衡狀態傳統機器人常用的“靜態穩定”假設完全不成立。為了讓控制系統知道機器人當前處于什么狀態需要融合多類傳感器信息IMU慣性測量單元測量機身角速度和加速度是姿態估計的核心。關節編碼器提供每個關節的角度、角速度用于計算關節空間狀態。足底力傳感器測量地面對腳掌的接觸力幫助判斷支撐相和騰空相。狀態估計算法通常采用卡爾曼濾波或擴展卡爾曼濾波將 IMU 和編碼器數據融合起來估計出機身的橫滾角、俯仰角、質心位置和速度。在 400 米競速中每一步的著地沖擊都很大傳感器信號中會混入大量噪聲因此濾波參數的調校非常關鍵。2.3 規劃與控制運動規劃負責生成“機器人下一步應該怎么動”。在跑步場景中規劃器需要回答三個問題下一步落在哪里落腳點規劃。質心軌跡如何變化保持前進速度并維持平衡。支撐腿和擺動腿如何切換步態相位。控制層則負責把規劃結果轉化為具體的關節力矩。目前主流方案包括基于零力矩點ZMP的平衡控制、基于模型預測控制MPC的軌跡跟蹤、以及基于全身動力學Whole-Body ControlWBC的力矩分配。實際系統中往往是幾種方法組合使用MPC 負責前瞻性規劃WBC 負責全身協調和約束處理。2.4 執行與結構算法再強最終都要靠關節電機“出力”。人形機器人跑步時足端承受的地面反作用力會達到體重的數倍關節需要在極短時間內輸出很大的峰值扭矩同時還要控制好位置和速度。這對電機的高功率密度、減速器的傳動效率、驅動器的大電流響應能力都是硬性考驗。此外結構件的剛度也很重要。如果小腿或大腿結構在觸地瞬間發生明顯形變控制模型就會失效輕則步態紊亂重則摔倒損壞。這也是為什么高性能人形機器人普遍采用碳纖維、高強度鋁合金等輕質高強材料。3. 從“行走”到“奔跑”步態算法拆解3.1 行走與奔跑的動力學差異從生物力學角度看行走和奔跑最大的區別在于是否存在“騰空相”。行走時身體始終至少有一只腳與地面接觸可以理解為“交替支撐”。奔跑時則會出現雙腳同時離地的階段機器人需要依靠慣性完成騰空、擺動、再著地的循環。騰空相的出現讓控制問題從“連續接觸”變成了“非連續接觸”對控制算法的魯棒性和切換時機的準確性要求更高。另一個重要差異是速度控制方式。行走時主要通過改變步長和步頻來調節速度而奔跑時還需要考慮騰空高度、著地角度、地面反作用力方向等因素。3.2 線性倒立擺模型與質心軌跡為了簡化分析雙足跑步常常被抽象為“倒立擺模型”。其中最簡單的是線性倒立擺模型LIPM它假設機器人的質心高度保持不變質量全部集中在質心腿部質量忽略不計。在 LIPM 中質心的水平加速度與質心相對 ZMP零力矩點的偏移成正比ddot_x (g / h) * (x - p_zmp)其中x是質心水平位置。p_zmp是 ZMP 位置。h是質心高度。g是重力加速度。這個公式的含義是當質心位于 ZMP 前方時質心會向前加速當質心位于 ZMP 后方時質心會向后減速。因此通過合理規劃 ZMP 位置就可以控制質心的運動軌跡從而控制機器人的前進速度和穩定性。3.3 平衡控制從 ZMP 到全身力矩控制ZMP 理論是雙足步行控制的基礎之一。簡單來說ZMP 是地面上反作用力合力作用點如果 ZMP 始終落在支撐多邊形內機器人就不會發生翻滾。但跑步狀態下機器人處于動態不穩定狀態單純依靠 ZMP 約束很難實現高速運動。因此現代系統會加入全身動力學控制在滿足關節位置、速度、力矩限制的前提下同時對質心位置、機身姿態、足端力進行優化。這樣可以把“誰出力、出多少力”分配到全身各個關節避免單關節過載。在工程實現上控制頻率越高系統能抑制的擾動頻率就越高。常見的人形機器人控制頻率在 1kHz 左右也就是說每毫秒就要完成一次狀態更新和力矩計算這對計算平臺和通信總線都提出了很高要求。3.4 示例用 Python 觀察 LIPM 軌跡為了幫助理解 LIPM 中質心軌跡的生成過程下面給出一個簡化示例。這段代碼不是真實機器人控制代碼而是用來直觀展示 LIPM 的基本動態關系適合初學者在仿真環境里觀察。import numpy as np import matplotlib.pyplot as plt # 模擬參數 g 9.81 # 重力加速度 h 1.0 # 質心高度單位 m dt 0.001 # 控制周期 duration 0.3 # 模擬時長單位 s # 初始狀態 x 0.0 # 質心水平位置 vx 0.0 # 質心水平速度 # ZMP 目標位置假設在質心前方 0.1m會推動質心向前加速 p_zmp 0.1 time_list [] x_list [] vx_list [] for step in range(int(duration / dt)): # LIPM 動力學公式 ax (g / h) * (x - p_zmp) vx ax * dt x vx * dt time_list.append(step * dt) x_list.append(x) vx_list.append(vx) plt.figure(figsize(8, 4)) plt.plot(time_list, x_list, labelCoM position) plt.plot(time_list, vx_list, labelCoM velocity) plt.xlabel(time (s)) plt.ylabel(state) plt.title(LIPM CoM trajectory example) plt.legend() plt.grid() plt.show()運行這段代碼后可以看到質心位置和速度隨時間變化的曲線。當 ZMP 位于質心前方時質心會逐漸加速這反映出 ZMP 對質心運動的“牽引”作用。真實系統中ZMP 不可能一直放在一個固定位置規劃器需要根據落腳點實時調整 ZMP 序列。4. 人形機器人軟件架構競速背后的“大腦”4.1 分層軟件架構人形機器人軟件架構通常可以分成四層驅動層負責電機控制、編碼器采集、IO 通信一般運行在 MCU 或實時內核上。實時控制層負責狀態估計、步態控制、力矩分配運行周期通常在 1kHz。規劃層負責路徑規劃、步態切換、任務調度運行周期通常在 100Hz~500Hz。應用層負責感知融合、決策、人機交互運行頻率較低但邏輯較復雜。分層的好處是職責清晰、便于調試。跑步這類高性能任務主要考驗實時控制層而任務導航和人機協作則更依賴應用層。4.2 實時性與通信人形機器人在高速奔跑時任何超過 2~3ms 的控制延遲都可能導致不可恢復的摔倒。因此系統必須保證控制鏈路的實時性。實際操作中通常采用兩種方案方案一所有控制算法都在一臺高實時性工控機上運行通過 EtherCAT 等實時總線與伺服驅動器通信。方案二關節控制放到嵌入式 MCU 上主控只負責規劃計算好的關節軌跡下發到 MCU 執行。通信總線方面EtherCAT 因為高實時、高帶寬、支持多從站同步成為足式機器人的常見選擇。每個關節驅動器作為 EtherCAT 從站可以在幾百微秒內完成數據交換。4.3 仿真訓練與 sim-to-real現代人形機器人開發已經離不開仿真。以 MuJoCo、Isaac Gym 為代表的物理仿真器可以快速驗證步態算法并通過強化學習訓練策略。但在仿真里跑通的策略不意味著能在真實機器人上直接使用這就是 sim-to-real從仿真到現實問題。仿真與現實的差距主要來自動力學參數不完全一致關節摩擦、阻尼、結構柔性難以精確建模。傳感器噪聲不同真實 IMU 和編碼器噪聲更復雜。執行器延遲真實電機存在響應延遲和力矩爬升過程。解決 sim-to-real 的常見手段包括領域隨機化Domain Randomization即在仿真中隨機改變質量、摩擦力、延遲等參數讓策略在多種環境下都能適應從而提升在真實硬件上的魯棒性。4.4 示例ROS 2 控制節點框架ROS 2 是機器人領域常見的基礎軟件平臺。下面用一個簡化節點示例展示控制節點如何訂閱關節狀態并發布關節命令。這個示例只是框架演示接口需要根據你的機器人硬件調整。import rclpy from rclpy.node import Node from sensor_msgs.msg import JointState from std_msgs.msg import Float64MultiArray class LocomotionController(Node): def __init__(self): super().__init__(locomotion_controller) self.joint_state_sub self.create_subscription( JointState, /joint_states, self.state_callback, 10 ) self.command_pub self.create_publisher( Float64MultiArray, /joint_effort_commands, 10 ) self.get_logger().info(Locomotion controller started) def state_callback(self, msg: JointState): # 實際項目中這里需要調用步態規劃和力矩控制算法 # 這里僅發布一條示例命令 cmd Float64MultiArray() # 以 12 個關節為例實際數量按機器人配置 cmd.data [0.0] * 12 self.command_pub.publish(cmd) def main(argsNone): rclpy.init(argsargs) node LocomotionController() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()這個節點的邏輯非常簡單收到關節狀態后經過控制算法計算輸出關節力矩指令。真實項目里狀態回調函數中會加入狀態估計、落腳點生成、全身動力學求解等模塊計算量和復雜度會高很多。5. 硬件挑戰關節、驅動與能源5.1 高功率密度關節執行器跑步時人形機器人的髖、膝、踝關節需要同時承受體重數倍的沖擊力。以 70kg 級別的全尺寸人形機器人為例奔跑瞬間膝關節峰值力矩可能超過 200Nm而且需要在幾十毫秒內完成加速和減速。這就要求關節電機具備很高的功率密度。目前主流方案是“無框力矩電機 諧波減速器”或“無框力矩電機 行星減速器”。無框電機節省了外殼和軸承有利于減重諧波減速器體積小、減速比大適合機器人關節安裝但需要注意長期奔跑帶來的磨損和發熱問題。5.2 驅動與總線電機性能再強也需要驅動器把電流精準地輸送到繞組中。現在常用的關節驅動器大多基于 FOC磁場定向控制算法通過高速采集電機相電流和編碼器角度實現高動態響應的力矩閉環。驅動器需要支持大峰值電流同時還要盡量減小體積和重量以適配關節結構。在奔跑過程中多個關節驅動器需要嚴格同步。以一個周期 1kHz 的控制循環為例如果某個關節的指令晚到了 1ms整個步態可能就會失去協調。因此EtherCAT 這類支持分布式時鐘同步的總線協議非常關鍵它可以讓所有從站驅動器在幾乎同一時刻執行指令。5.3 能源、散熱與結構強度高速奔跑的能量消耗遠高于行走。機器人需要在幾十秒內持續輸出較大功率這就對電池的放電倍率和能量密度提出了要求。實際系統中還需要考慮電壓跌落、剩余電量對電機輸出力矩上限的影響盡量避免因電量不足導致步態失控。散熱也是不可忽視的問題。電機、驅動器、減速器在持續高負載下會產生大量熱量。如果溫升過高電機永磁體可能退磁驅動器可能觸發過溫保護最終導致關節力矩下降。常見的散熱手段包括被動散熱片、強制風冷、甚至液冷系統。天工 Ultra 能連續跑完 400 米說明它在能耗管理和散熱策略上做了大量工程優化。6. 人形機器人芯片與計算平臺趨勢6.1 端側算力需求人形機器人的“大腦”分為兩個層面一個是負責運動控制的實時計算通常不需要特別高的 AI 算力但對實時性和確定性要求極高另一個是負責環境感知、多模態大模型推理的 AI 計算對 GPU/NPU 算力要求很高。隨著人形機器人從實驗室走向開放場景“端側 AI 算力”成為越來越重要的指標。機器人需要在本地完成目標檢測、語義理解、路徑規劃等任務不能完全依賴云端因為網絡延遲和斷網風險在工業現場是不可接受的。6.2 芯片廠商的布局這一波人形機器人熱潮也帶動了機器人芯片產業鏈。除了大家熟悉的高性能 GPU 平臺國內芯片廠商也在積極布局機器人方向。例如“全志科技”等廠商推出了面向智能機器人應用的芯片方案主打低功耗、高集成度和軟硬件生態適配。從行業趨勢看未來人形機器人可能會采用“異構計算”架構一顆高實時性的 MCU/FPGA 負責關節控制和狀態估計一顆帶 NPU 的 SoC 負責感知與決策再搭配通信芯片和電源管理芯片形成完整的端側計算生態。對開發者來說選型時要優先關注算力、功耗、實時性以及開發工具鏈的成熟度。6.3 如何選擇計算平臺選擇人形機器人計算平臺時可以按下面幾個維度評估維度說明實時性能否保證控制任務在規定周期內完成是否存在調度抖動算力密度每瓦每秒能完成多少 AI 計算是否支持模型推理加速接口豐富度是否有足夠的 PCIe、EtherCAT、CAN、USB、GPIO 接口開發工具鏈是否支持 ROS 2、是否有長期維護的 BSP 和驅動功耗與散熱整機功耗預算是否允許是否需要額外散熱設計供應鏈穩定性是否容易采購是否有國產替代方案在原型驗證階段很多團隊會選擇通用工控機或高性能嵌入式平臺先把算法跑通。在量產階段則會根據成本和功耗做定制化芯片方案。這一輪人形機器人芯片熱詞背后的邏輯本質上是行業從“算法驗證”走向“產品落地”的信號。7. 常見誤區與討論7.1 “機器人比人類跑得快”怎么理解很多人看到 38.15s 的成績后會直接得出“機器人已經超越人類跑步能力”的結論。這個說法并不完全準確。人形機器人目前的“跑”與人類田徑意義上的“跑”存在多個差異賽道條件機器人測試是在專用場地角度、地面材質固定與奧運會標準賽道不同。機器人尺寸不同機器人腿長、重量不同步幅差異很大。能耗方式機器人靠電池驅動人類靠有氧和無氧代謝供能。穩定性人類在彎道、變道、風阻等復雜條件下依然能保持高水平控制而機器人目前更多還是在受控環境中發揮極致性能。正確的理解是38.15s 證明了人形機器人在“高速持續運動控制”上取得了重要突破但它并不意味著機器人在所有跑步場景中都超過人類。7.2 輪式機器人不是更簡單嗎在平地上輪式機器人確實在速度和能效上更有優勢。一個四輪底盤加激光雷達就能完成很多移動任務成本還遠低于雙足機器人。那為什么還要做雙足關鍵在于“通過性”和“適應性”。輪式機器人只能在地面較平整的環境中使用遇到臺階、樓梯、溝壑、亂石堆就會受限。雙足人形機器人可以適應人類生活和工作環境比如走進有樓梯的車間、爬上巡檢平臺的臺階、擠過狹窄的通道。人形的價值不在“比輪子跑得快”而在“能和人類共用空間”。所以輪式和腿式不是替代關系而是針對不同場景的互補方案。如果只在固定園區平地巡邏輪式機器人性價比更高如果任務環境充滿非結構地形腿式機器人更有價值。7.3 人形形態真的有必要嗎“人形”是否是最優形態在機器人領域一直有爭議。四足機器人如機器狗在穩定性、負載能力方面已經有成熟產品雙臂機器人配合軌道或輪式底盤也能完成部分操作任務。人形形態的優勢主要體現在三點一是與人類環境高度兼容工具、門把手、座椅、樓梯都是按人類身體尺度設計的二是操作能力人形機器人可以同時使用雙臂完成復雜任務而固定機械臂靈活性有限三是社會接受度人形機器人更容易被非技術人員理解和接受。當然代價也很大雙足平衡難以控制、整機成本高、維護復雜、能效低。是否選擇人形取決于任務需要而不是跟風。7.4 競速成績能代表產業成熟度嗎競速成績只是運動控制能力的指標之一不能完全代表產業成熟度。真正的產業落地還要看可靠性機器人能否連續運轉數千小時而不出現故障。可維護性關節模塊是否易于更換軟件是否能遠程升級。經濟性購買和運維成本是否能被客戶接受。安全性遇到突發情況時機器人能否安全降速停機不傷害人員和設備。因此看待天工 Ultra 的成績時一方面要肯定它背后的技術突破另一方面也要理性認識從“跑得快”到“用得起、用得穩、用得住”中間還有很長一段工程化道路。8. 給開發者的學習路線與工程建議8.1 學習路線如果你想進入人形機器人運動控制領域可以按下面路徑循序漸進打好基礎學習機器人學、線性代數、剛體動力學、自動控制原理。掌握仿真工具從 MuJoCo、PyBullet 或 Isaac Gym 入手先在仿真里跑通一個簡單的倒立擺或雙足模型。復現經典算法手寫 LIPM 步態規劃實現 ZMP 平衡控制再嘗試 MPC 和 WBC。學習 ROS 2理解話題、服務、動作通信模型搭建完整的感知-規劃-控制軟件棧。接觸真實硬件從單關節測試開始逐步完成整機聯調積累標定和調參經驗。關注強化學習學習 PPO、SAC 等算法嘗試用強化學習在仿真中訓練步態策略并研究 sim-to-real 遷移。8.2 工程實踐建議真實機器人項目開發和純算法研究有很大區別這里分享幾條工程經驗先保證穩定再追求速度。測試時可以先從慢速行走開始把狀態估計和控制頻率調穩再逐步提高速度。建立完善的日志系統。機器人在跑步時崩潰如果沒有完整的日志回放排查問題會非常困難。做好軟硬件接口抽象。控制算法不要和具體的電機型號、通信總線強耦合方便以后更換硬件。使用硬件在環仿真。在真實機器人上跑新算法前先在仿真和半實物環境中驗證減少炸機概率。重視踝關節的作用。高速奔跑時踝關節對姿態調整和地面反作用力控制非常關鍵不要只關注髖和膝。8.3 安全優先原則人形機器人高速運動時具有較強的沖擊力測試時務必注意安全首次測試必須安裝機械限位和安全繩避免摔倒后造成硬件損壞。調試過程中設置關節力矩上限和速度上限防止意外輸出過大導致電機損壞或傷人。在開放場地測試時劃定隔離區域禁止無關人員進入。每一次高負載奔跑測試前都要檢查電池電壓、關節溫度、緊固件狀態。安全不是測試的最后一步而是貫穿整個開發流程的設計原則。尤其是當機器人進入工廠、社區等實際場景后必須有完善的急停邏輯、碰撞檢測和降級保護策略。9. 結語下一站不是“更快”而是“更實用”天工 Ultra 用 38.15s 跑完 400 米確實是一個值得記錄的節點。它告訴我們人形機器人已經能夠以接近甚至超過人類的速度持續奔跑并且在真實場地里保持穩定完成比賽。這對運動控制、執行器設計、能源管理、實時計算平臺等整個鏈條都是一次高強度驗證。但跑步從來不是人形機器人的終點。下一站行業更關注的是機器人能不能帶著這套運動能力走進工廠、走進倉儲、走進家庭在真實任務中持續工作幾千小時而不出問題。到那個時候“更快”就不再是唯一的追求“更穩、更聰明、更便宜、更安全”會成為比速度更重要的話題。如果你對人形機器人運動控制感興趣建議從開源仿真項目入手先把 LIPM、ZMP、MPC 這些基礎概念跑通再逐步過渡到真實硬件。技術文檔看一百遍不如在仿真里親手調一次參數。機器人運動員在賽場上每一秒的成績提升背后都是無數個小時的算法迭代和工程打磨。希望這篇文章能幫你更清楚地看懂天工 Ultra 這次首金背后的技術含量也為你自己動手做機器人提供一條值得嘗試的路徑。