作为一个长期在机器人系统里做感知和决策的老兵我最近在梳理整个人形机器人感知系统时感触挺深的。以前我们聊机器人感知基本就是传感器算法可视化能建图、能识别、能避障这事就算齐了。但放到人形机器人这个载体上感知的定位变了很多——它不再是一个独立的眼睛模块而是深度嵌进感知-控制-规划链条里的关键环节。我们今天就把这套系统的总体架构、模块分工以及正在发生的一体化趋势掰开揉碎了聊一遍。1. 为什么人形机器人的感知系统不是拿来看的很多人对人形机器人感知的第一反应是装一堆相机和雷达让机器人看见世界。这个说法没错但只讲对了一半。轮式机器人或者工业机械臂上的感知核心目标是看清楚——看障碍物、看目标物体、看边界然后把这些信息喂给移动底盘或机械臂。但人形机器人不一样它是一个全身运动的复杂系统感知的最终目的不是看懂世界而是为全身协调运动提供结构化的、可靠的输入。我举个例子你就明白了。一台移动机器人要过一条窄通道感知系统只需要输出这条通道多宽、后方有没有障碍底盘控制器自己就能规划路径。但一个人形机器人要走同样的窄通道它需要知道的可不止这些——路面有没有坑洼、地面支撑力够不够、侧向空间能不能容纳摆臂和摆动中的躯干、落脚点在哪块区域才不至于踩滑。这已经超出了物体检测测距的范畴更像是在给运动系统做场地勘察。这正是人形机器人感知系统区别于其他机器人的本质它必须同时服务环境理解和自身运动两条主线。换句话说感知输出的每一类信息最终要么变成步态规划里的可行域约束要么变成全身控制里的力学参考要么变成任务规划里的语义标签。如果感知结果只是显示在屏幕上很漂亮但对控制系统毫无帮助那这套感知架构本质上是不合格的。从另一个角度看感知-控制-规划这三者原本是三块相对独立的研究领域有各自的论文体系、评测基准和工具链。但人形机器人的落地需求把三者强行拉到了一起。因为人形机器人不像机械臂那样基座固定、界限明确也不像轮式机器人那样可以忽略姿态变化的影响。它的学步、越障、上下楼梯、搬东西每一步都涉及全身几十个自由度的协调感知的一点误差会被运动学和动力学放大控制器的一点延迟又会反过来让感知规划失真。所以我们必须从一开始就用一体化的视角去设计感知系统而不是把它当作一个孤立的视觉任务。这种视角转换对做传统视觉算法出身的人来说需要适应一段时间。我见过太多团队在感知模块上堆了很好的算法结果整机联调时发现规划器根本用不上它的输出格式控制器也不需要那么高精度的语义分割最后只能推倒重来做接口对齐。所以这篇文章的第一目标就是帮你把这个人形机器人感知系统的总体架构梳理清楚并且讲明白它和传统机器人感知到底差在哪儿。2. 环境感知在整个人形系统中的位置它到底服务谁人形机器人的软件架构通常可以粗略分成三层决策规划层、运动控制层、感知层。感知层在最底下好像只是提供数据的角色但如果你仔细拆解整个任务链路会发现感知层实际上同时向上层所有模块提供信息服务。先看任务规划层。这个层面负责回答机器人要做什么——是走过去拿杯子还是爬上台阶还是给别人递工具。它需要感知给出的是语义几何的混合信息杯子在哪里、是什么颜色、周围有没有别的东西挡路这属于物体识别和场景理解的范畴。没有这一层感知的信息任务规划只能瞎猜目标位置完全无法启动。然后看运动规划层。这个层面负责回答怎么走——具体到生成一条全身轨迹让双腿在哪个时刻落在哪个位置躯干在哪个时刻倾斜多少度。它需要感知给出的是可通行性地形几何信息这条路能不能走、哪块地面能踩、什么时候会遇到动态障碍。这部分工作是感知系统最繁重、也最容易出错的地方因为地形可能不平整障碍物可能移动机器人自身的运动又会影响传感器的观测视角。最后是运动控制层。这个层面负责把规划出来的轨迹真正执行下去每一步落脚是否踩稳、躯干是否有侧倾趋势、踝关节力矩是否超标。它需要感知给出的更多是本体状态接触信息——当前姿态、脚底是否完全触地、地面反作用力有多大。不要小看这些信息对双足机器人来说没有足底力和本体姿态的精确感知再好的步态规划也根本走不稳。所以你看感知系统在人形机器人内部其实是一个多接口的数据服务层。它既要给大脑任务规划提供语义又要给小脑运动规划提供几何约束还要给脊髓反射力控制提供本体反馈。这三者服务的对象不同、数据带宽不同、实时性要求也不同如果把它们强行合并成一条感知流水线一定会互相拖累。我一直觉得理解这种感知服务多个决策环节的关系是理解人形机器人感知架构的关键。很多初学者以为感知就是把相机数据变成地图其实在人形机器人的语境里地图只是其中一个很粗粒度的输出。真正核心的是你要为每一个下游模块找到合适的感知表征并且保证数据能在正确的时间、以正确的格式、带着正确的不确定性到达它该去的地方。3. 顶层设计从环境输入到决策输出的完整闭环如果让我用一张图来展示人形机器人感知系统的总体架构我不会把它画成一个简单的流水线而是会画成一个带有多个反馈回路的闭环结构。这里我只用文字来描述因为我觉得图片反而容易让人误以为系统是单向流动的。整个系统可以粗略分成五个环节。第一个环节是传感器层包括相机、激光雷达、惯性测量单元、关节编码器和足底力传感器。这一层做的事情是把物理世界的信号转成数字信号。每个传感器都有自己的坐标系、采样频率和噪声特性所以很关键的第一步就是对这些信号做时间同步和空间标定把它们转换到统一的机器人坐标系里面。第二个环节是数据处理层也可以称为感知前端。在这一层我们要做视觉里程计、激光点云配准、IMU惯性积分、多传感器融合最终输出的是机器人自身的位姿估计和历史轨迹。这一环相当于给机器人建立了我在哪里的自知感。没有这一环后续所有环境感知信息都无法在空间中有意义地拼接起来。第三个环节是环境建图层。这里开始对环境本身建模比如构建栅格地图、八叉树地图或高程图对场景里的物体做分割识别对动态障碍物做检测和跟踪。这一环输出的是世界长什么样的表示通常有几个不同尺度的版本——全局地图用于长期导航局部高程图用于实时避障语义地图用于任务规划。第四个环节是决策规划层。它拿到的已经是处理好的环境表示结合任务需求输出高层任务序列和低层运动轨迹。严格来说决策规划不算感知的一部分但它和感知之间有一个非常重要的反馈通道——规划结果会影响机器人的运动而运动又会改变传感器的观测视角所以感知系统必须持续根据规划意图调整观测重点。第五个环节是控制执行层。控制器负责跟踪规划轨迹实时调整关节力矩。它和感知之间也有直接的反馈连接比如落脚瞬间需要用足底力信息做触地检测姿态控制需要IMU的高速反馈。我特别想强调的是在这套架构里没有一条信息是单向流到下一个环节就完事的。感知层的质量直接影响决策规划决策规划产生的运动又会反过来让感知层面临新的挑战——比如运动过快会导致图像运动模糊弯腰过低会导致激光雷达视野受限。这种前后耦合关系才是人形机器人感知系统真正难设计的地方。4. 多源传感器感知系统的硬件基座和融合逻辑聊完总体架构回到最底层的传感器配置。人形机器人领域常说的多源传感器融合在硬件层面其实是有强烈约束的不是传感器越多越好而是要在性能、重量、功耗、成本和可靠性之间做平衡。以目前常见的人形机器人原型平台来看主流配置大致如下。双目或RGB-D相机几乎是标配一般安装在头部或躯干上提供彩色图像和深度图像用于目标识别、地形分析、动态物体检测这类偏语义的任务。激光雷达也很常见通常安装在躯干或头部用于远距离环境感知和全局地图构建它的测距精度远高于相机对建图质量至关重要。IMU是必须的它提供本体姿态和加速度信息是所有状态估计的基础。关节编码器内置在每个电机里提供关节角度和角速度是运动学和动力学计算的基础。足底六维力/力矩传感器则用在双足机器人的踝关节处测量地面反作用力是行走稳定性的直接信息来源。这里有一个非常容易踩坑的细节——传感器的空间同步和时间同步。空间同步又叫外参标定要解决的是每个传感器看到的物理位置在机器人坐标系里的精确坐标是什么。时间同步要解决的是不同传感器在同一个毫秒级时间片内采集的数据能否对齐。这两个问题在轮式机器人上就有但人形机器人上更致命因为人形机器人在行走过程中头部、躯干、腿部都在剧烈运动只要外参标定偏差几毫米时间同步偏差几十毫秒融合出来的环境表示就会出现明显的错位和漂移落点规划直接说你站在不该站的地方。所以我的经验是在搭建人形机器人感知系统的第一天就要把多传感器时间同步机制和外参标定工具链准备好不能等到中途联调再补。标定不是一次性工作机器人运行一段时间后外壳形变、螺丝松动、安装偏差都可能导致外参漂移所以最好能做在线标定或定期自动标定。从融合逻辑上说传感器不是简单的取平均或者谁准就听谁的。不同传感器有各自的优势时间和空间频段IMU在极短时间内非常准长时间就漂移相机在纹理丰富的地方表现好在黑暗或白墙场景就失灵激光雷达不受光照影响但对反射材质敏感。一个可用的融合系统必须能够根据当前场景和运动状态动态调整各个传感器的权重这既需要理论上的滤波框架也需要工程师的经验调参。5. 从环境感知到状态估计感知系统的双主线很多人把人形机器人的感知系统和环境感知系统完全等同这其实是个不小的误解。严格来说人形机器人的感知系统有两条主线一条是外部环境感知一条是本体状态估计。这两条主线在架构上是并列的、相互依赖的但处理的数据源和输出的目标完全不同。本体状态估计这条线处理的是IMU数据、关节编码器数据、足底力数据和视觉里程计数据最终输出的是机器人的躯干位姿、关节角度、速度、加速度以及支撑状态是双脚支撑还是单脚支撑支撑腿是哪几条。这些信息对控制来说是最高优先级的——双足机器人稳定性控制使用的主要变量都来自这条线。比如机器人要主动调整躯干姿态来对抗外界扰动就必须知道当前躯干的倾斜角度和角速度这只能靠IMU加状态估计来获得。又比如步态相位切换机器人需要在摆动腿落地瞬间感知到触地事件此时足底力传感器的跳变信息就至关重要这比纯视觉判断可靠得多。外部环境感知这条线处理的是相机图像、激光点云数据最终输出的是地图、障碍物列表、地形属性、目标物体位姿等信息。它的服务对象更多是规划系统我要往哪走、路上有什么、落脚点在哪里。和本体状态估计不同的是环境感知往往允许相对较慢的更新频率因为地形和大型障碍物在短时间内的变化不剧烈不像姿态那样每毫秒都在变。这两条主线不是独立运作的。举个简单的例子机器人要跨过一块石头。外部环境感知先告诉我们前方有一块高度约0.2米的障碍物可跨越这个信息属于环境感知。但是规划器要生成一条越障轨迹它必须结合机器人的本體状态——当前重心在哪里、两条腿的支撑宽度是多少、下一步要落到哪里。一旦机器人开始越障本体状态估计就以高频反馈配合控制等重心越过障碍完成落地支撑感知系统再更新地形状态。整个过程里外部感知指导往哪走本体感知支撑怎么站稳。从工程实现的角度这两条主线通常会采用不同的处理频率和算法框架。本体状态估计需要极高的实时性通常在几百赫兹到上千赫兹的循环里运行依赖的是数值优化和滤波类算法。外部环境感知则更灵活可以跑在几赫兹到三十赫兹的循环里使用深度学习或点云配准等计算更重的算法。感知架构设计者必须一开始就明白这两条主线的需求不同不能简单套用同一个感知框架否则不是拖垮实时性是牺牲精度。6. 感知-控制-规划的经典关系不是串联而是循环在很多人最初的理解里感知-控制-规划是典型的串联流水线感知模块出结果规划模块做决策控制模块执行。这个理解在很简单的任务里是成立的但在复杂的人形机器人系统里必须升级为循环嵌套的视角。第一层循环是高速的本体感知-控制循环。这个循环运行频率非常高通常在1kHz量级任务是把当前状态和期望状态的误差换算成关节力矩指令。在这个循环里感知的作用是提供状态反馈——姿态、角速度、足底力、关节角度。控制器本身不一定需要高智能但它对反馈的实时性和准确性要求极其苛刻。感知延迟哪怕多了一毫秒都会直接影响稳定性裕度。第二层循环是环境感知-运动规划的慢速循环运行频率通常在1到30Hz。任务是根据环境信息和任务目标生成运动轨迹或者整定步态参数。在这个循环里感知输出的环境地图、障碍物列表和地形分类会被规划器当作优化问题的约束条件。这时候感知的精度和不确定性表达就非常关键——如果感知给出的可行域太乐观规划器可能会生成一个踩到障碍物的轨迹如果太保守机器人又会像蜗牛一样不敢走。第三层循环是最外层的任务感知-高层规划循环运行频率可以低到0.1到1Hz甚至按需触发。任务是在长时间尺度上决定机器人接下来该执行哪个子任务。它需要感知给出的是场景语义和目标物体状态比如门是开的还是关的目标物体是否已经被抓住。这三层循环不是互相独立的它们之间存在嵌套关系。高层循环的决策会影响中层循环的目标中层循环的输出又给底层循环提供参考轨迹。反过来底层的控制和状态估计结果也会反馈给中高层比如机器人当前的稳定性余量已经很低是否需要中止当前越障计划。真正的系统架构就是这样一套环环相扣的循环结构绝不是一条单向流水线能表达的。理解了这个关系你就理解为什么人形机器人的感知系统需要特别设计多速率架构。你不能用一个统一的帧率去处理所有感知信息——如果所有感知都以高速率跑计算资源不够如果都以低速率跑控制根本用不上。好的架构一定会把感知数据按使用对象和时效性拆成不同的速率通道最高速的留给状态估计和控制中速的留给环境感知和规划低速的留给任务理解。这就是所谓感知-控制-规划一体化在工程架构上最基本的体现。7. 一体化趋势从模块拼接到特征共享的三层演进最近几年人形机器人领域最明显的趋势之一就是感知-控制-规划一体化。但这个词在不同人嘴里含义不太一样我倾向于把它拆成三个层面的演进来理解。第一层演进是接口层面的协议化。也就是感知、规划、控制三个模块仍然干各自的活但它们的输入输出格式被设计成互相咬合的一套体系比如感知输出的占用栅格直接就是规划器的代价地图规划生成的步态序列直接就是控制器的参考轨迹。这一层的一体化不需要改变任何算法本质纯粹是工程上的统一设计。我见过很多团队做得不错一套定义清晰的接口协议能省掉联调阶段的大半麻烦。第二层演进是表征层面的共享化。核心思路是感知模块不再输出人工设计的中间表示给控制/规划而是直接输出一个嵌入空间——一个特征向量。规划器或控制器在高维特征空间里做决策感知网络在特征空间里提供约束和目标。这其实已经在自动驾驶和机器人操控领域有不少实际应用比如一些视觉-运动策略输入就是图像输出就是关节动作完全跨越了感知、规划、控制这一步一步的人工切分。在人形机器人领域很多团队正在尝试用端到端的深度强化学习把原始视觉信息直接映射到双足步态控制不再显式建图效果在仿真里看起来已经相当出色。第三层演进是系统层面的联合优化化。也就是感知、规划、控制不再是分开训练、分开调参的三个模型而是一个大的学习系统感知网络为规划和控制服务规划的结果反向指导感知网络把注意力放在哪里。这一层目前还偏研究性质但对实际工程的影响已经开始显现——至少它改变了我们设定感知指标的方式不再只看检测精度而是要看到底对任务成功率有多大贡献。作为工程师我现在的态度是拥抱一体化趋势但保持理性。三个层面的一体化可以逐步推进接口协议化是马上能做的表征共享化可以挑一到两个具体任务先试系统联合优化则要在仿真平台里大量打磨再考虑真实机器人迁移。如果一上来就想做第三层大多数团队在数据规模、算力和调试能力上都会被压垮。8. 架构落地的关键考虑延迟、不确定性、计算资源与协同时序前面讲了这么多架构层面的道理最终落到工程实现必须面对几个绕不开的硬问题延迟、不确定性、计算资源和协同时序。延迟是第一个绕不开的坎。人形机器人的步态周期通常在0.8到1.2秒左右支撑腿切换的时间窗口更短往往只有几十毫秒到几百毫秒。感知系统从传感器采集到输出可用的环境信息延迟只要超过百毫秒级规划器就已经在对着过期的世界做决策。更麻烦的是感知延迟还不是恒定值它会随着环境复杂度、GPU负载和算法分支变化而抖动这种抖动比固定延迟更难对付。所以在架构里必须设计延迟监控和自适应的策略比如感知延迟增大时规划器自动扩大安全裕度把步幅收小、速度降低。不确定性是第二个必须直面的问题。任何传感器和算法都有误差但规划器需要的不是一个点估计而是一个分布。比如感知告诉你前方障碍距离1米但真实值可能是0.95米或者1.05米如果你的规划器只按1米来做避障它的成功率不会高。更合理的方式是让感知输出障碍物位置的不确定性范围规划器在做轨迹优化时把这个不确定性量化到安全约束里在危险区域自动减速。很多先进的规划框架已经支持这种不确定性感知的运动规划但对感知端提出了额外的要求——你不仅要测准还要知道自己有多准。计算资源是第三个瓶颈。人形机器人受限于电池和散热不可能背一个大型服务器。感知、规划、控制的总算力预算往往是几百瓦以内但环境感知的深度学习模型和建图优化算法都是计算大户。所以必须做算力调度和分配核心原则是关键的、高频的、安全相关的计算优先比如状态估计和控制必须独占一部分高速算力非关键的、低频的、任务相关的计算可以挤在剩余资源里慢慢跑。GPU上任务编排这块很多团队会采用流水线和数据复用技术尽量提高吞吐量。协同时序是最容易被低估的一点。所谓协同时序指的是多个传感器和处理节点的时间对齐问题。图像到达时IMU数据已经算到了哪个时间点规划器生成轨迹时使用的是哪一版地图控制器执行指令时这个轨迹是多久以前生成的现代机器人系统往往采用延迟补偿和时间戳管理来保证全链路时序一致性。具体实现上所有传感器数据进入系统后的第一件事就是打时间戳通信框架要保证各节点使用统一的时基规划器和控制器的状态输入必须对齐到同一时刻的估计值而不是各用各的缓存。这四个问题任何一个人形机器人感知架构都要正面回答。有的靠算法设计解决比如引入滤波和不确定性建模有的靠工程手段解决比如调度和同步有的是系统性难题需要整个机器人团队一起定规矩、做机制保障。没有哪个问题可以完全绕过去也没有哪个问题靠某一个天才模型就能搞定。9. 实际落地时的排错顺序与成体系建议结合我自己调试人形机器人原型系统的经验最后提供一个实用的排错思路和落地建议希望可以帮到正在搭系统的团队。如果你在真实机器人上碰到感知看起来正常、控制却不稳定的情况请严格按照这个顺序排查先看时钟同步再查状态估计频率然后检查感知输出的空间坐标系最后才是算法精度。第一步时钟同步错乱是所有诡异问题的原罪传感器之间和节点之间出现几十毫秒的对不齐感知和控制的融合就全乱了。第二步本体状态估计频率如果低于500Hz双足控制基本上很难稳因为从足底力变化到姿态调整的链路里频率不够意味着你根本来不及反应。第三步坐标系对不上很常见——激光雷达建的地图是雷达坐标系相机识别出的目标在相机坐标系如果外参标定没做好规划器拿到的目标位置可能直接偏出去好几厘米这足以让机器人一脚踩空。最后才是看检测精度、分割精度这些大家最关注的指标其实这些指标通常不是系统不稳定的首要原因。落地建议方面我给三条成体系的方向。第一把感知-控制-规划三块功能先做成强接口、弱耦合的框架再逐步加深耦合不要一开始就追求全端到端。第二所有模块的输入输出都要携带不确定性估计和时戳信息这会给下游的信任和调度带来巨大优势。第三在物理世界跑之前先在仿真平台里把全链路延迟配平评估不确定性传播的影响并从仿真环境中沉淀出验证用例再迁移到真实机器人上做真机验证。没有人能一步到位但按这三条走至少不会在中途推倒重来。我个人的体会是人形机器人感知系统本质上不是如何更好地看世界的问题而是如何在复杂运动和严格约束下让感知为控制与规划所用的问题。一个感知系统设计得好不好最终要看机器人整体在真实环境里的任务成功率而不是单看感知算法的漂亮指标。理解了这一点你设计出来的感知架构大概率会比只看算法的同行高一个层次。 
长河君 · 2026/10/20 22:18:24 · 阅读 1.2k 人形机器人感知系统架构解析：从环境感知到控制规划一体化
作为一个长期在机器人系统里做感知和决策的老兵我最近在梳理整个人形机器人感知系统时感触挺深的。以前我们聊机器人感知基本就是传感器算法可视化能建图、能识别、能避障这事就算齐了。但放到人形机器人这个载体上感知的定位变了很多——它不再是一个独立的眼睛模块而是深度嵌进感知-控制-规划链条里的关键环节。我们今天就把这套系统的总体架构、模块分工以及正在发生的一体化趋势掰开揉碎了聊一遍。1. 为什么人形机器人的感知系统不是拿来看的很多人对人形机器人感知的第一反应是装一堆相机和雷达让机器人看见世界。这个说法没错但只讲对了一半。轮式机器人或者工业机械臂上的感知核心目标是看清楚——看障碍物、看目标物体、看边界然后把这些信息喂给移动底盘或机械臂。但人形机器人不一样它是一个全身运动的复杂系统感知的最终目的不是看懂世界而是为全身协调运动提供结构化的、可靠的输入。我举个例子你就明白了。一台移动机器人要过一条窄通道感知系统只需要输出这条通道多宽、后方有没有障碍底盘控制器自己就能规划路径。但一个人形机器人要走同样的窄通道它需要知道的可不止这些——路面有没有坑洼、地面支撑力够不够、侧向空间能不能容纳摆臂和摆动中的躯干、落脚点在哪块区域才不至于踩滑。这已经超出了物体检测测距的范畴更像是在给运动系统做场地勘察。这正是人形机器人感知系统区别于其他机器人的本质它必须同时服务环境理解和自身运动两条主线。换句话说感知输出的每一类信息最终要么变成步态规划里的可行域约束要么变成全身控制里的力学参考要么变成任务规划里的语义标签。如果感知结果只是显示在屏幕上很漂亮但对控制系统毫无帮助那这套感知架构本质上是不合格的。从另一个角度看感知-控制-规划这三者原本是三块相对独立的研究领域有各自的论文体系、评测基准和工具链。但人形机器人的落地需求把三者强行拉到了一起。因为人形机器人不像机械臂那样基座固定、界限明确也不像轮式机器人那样可以忽略姿态变化的影响。它的学步、越障、上下楼梯、搬东西每一步都涉及全身几十个自由度的协调感知的一点误差会被运动学和动力学放大控制器的一点延迟又会反过来让感知规划失真。所以我们必须从一开始就用一体化的视角去设计感知系统而不是把它当作一个孤立的视觉任务。这种视角转换对做传统视觉算法出身的人来说需要适应一段时间。我见过太多团队在感知模块上堆了很好的算法结果整机联调时发现规划器根本用不上它的输出格式控制器也不需要那么高精度的语义分割最后只能推倒重来做接口对齐。所以这篇文章的第一目标就是帮你把这个人形机器人感知系统的总体架构梳理清楚并且讲明白它和传统机器人感知到底差在哪儿。2. 环境感知在整个人形系统中的位置它到底服务谁人形机器人的软件架构通常可以粗略分成三层决策规划层、运动控制层、感知层。感知层在最底下好像只是提供数据的角色但如果你仔细拆解整个任务链路会发现感知层实际上同时向上层所有模块提供信息服务。先看任务规划层。这个层面负责回答机器人要做什么——是走过去拿杯子还是爬上台阶还是给别人递工具。它需要感知给出的是语义几何的混合信息杯子在哪里、是什么颜色、周围有没有别的东西挡路这属于物体识别和场景理解的范畴。没有这一层感知的信息任务规划只能瞎猜目标位置完全无法启动。然后看运动规划层。这个层面负责回答怎么走——具体到生成一条全身轨迹让双腿在哪个时刻落在哪个位置躯干在哪个时刻倾斜多少度。它需要感知给出的是可通行性地形几何信息这条路能不能走、哪块地面能踩、什么时候会遇到动态障碍。这部分工作是感知系统最繁重、也最容易出错的地方因为地形可能不平整障碍物可能移动机器人自身的运动又会影响传感器的观测视角。最后是运动控制层。这个层面负责把规划出来的轨迹真正执行下去每一步落脚是否踩稳、躯干是否有侧倾趋势、踝关节力矩是否超标。它需要感知给出的更多是本体状态接触信息——当前姿态、脚底是否完全触地、地面反作用力有多大。不要小看这些信息对双足机器人来说没有足底力和本体姿态的精确感知再好的步态规划也根本走不稳。所以你看感知系统在人形机器人内部其实是一个多接口的数据服务层。它既要给大脑任务规划提供语义又要给小脑运动规划提供几何约束还要给脊髓反射力控制提供本体反馈。这三者服务的对象不同、数据带宽不同、实时性要求也不同如果把它们强行合并成一条感知流水线一定会互相拖累。我一直觉得理解这种感知服务多个决策环节的关系是理解人形机器人感知架构的关键。很多初学者以为感知就是把相机数据变成地图其实在人形机器人的语境里地图只是其中一个很粗粒度的输出。真正核心的是你要为每一个下游模块找到合适的感知表征并且保证数据能在正确的时间、以正确的格式、带着正确的不确定性到达它该去的地方。3. 顶层设计从环境输入到决策输出的完整闭环如果让我用一张图来展示人形机器人感知系统的总体架构我不会把它画成一个简单的流水线而是会画成一个带有多个反馈回路的闭环结构。这里我只用文字来描述因为我觉得图片反而容易让人误以为系统是单向流动的。整个系统可以粗略分成五个环节。第一个环节是传感器层包括相机、激光雷达、惯性测量单元、关节编码器和足底力传感器。这一层做的事情是把物理世界的信号转成数字信号。每个传感器都有自己的坐标系、采样频率和噪声特性所以很关键的第一步就是对这些信号做时间同步和空间标定把它们转换到统一的机器人坐标系里面。第二个环节是数据处理层也可以称为感知前端。在这一层我们要做视觉里程计、激光点云配准、IMU惯性积分、多传感器融合最终输出的是机器人自身的位姿估计和历史轨迹。这一环相当于给机器人建立了我在哪里的自知感。没有这一环后续所有环境感知信息都无法在空间中有意义地拼接起来。第三个环节是环境建图层。这里开始对环境本身建模比如构建栅格地图、八叉树地图或高程图对场景里的物体做分割识别对动态障碍物做检测和跟踪。这一环输出的是世界长什么样的表示通常有几个不同尺度的版本——全局地图用于长期导航局部高程图用于实时避障语义地图用于任务规划。第四个环节是决策规划层。它拿到的已经是处理好的环境表示结合任务需求输出高层任务序列和低层运动轨迹。严格来说决策规划不算感知的一部分但它和感知之间有一个非常重要的反馈通道——规划结果会影响机器人的运动而运动又会改变传感器的观测视角所以感知系统必须持续根据规划意图调整观测重点。第五个环节是控制执行层。控制器负责跟踪规划轨迹实时调整关节力矩。它和感知之间也有直接的反馈连接比如落脚瞬间需要用足底力信息做触地检测姿态控制需要IMU的高速反馈。我特别想强调的是在这套架构里没有一条信息是单向流到下一个环节就完事的。感知层的质量直接影响决策规划决策规划产生的运动又会反过来让感知层面临新的挑战——比如运动过快会导致图像运动模糊弯腰过低会导致激光雷达视野受限。这种前后耦合关系才是人形机器人感知系统真正难设计的地方。4. 多源传感器感知系统的硬件基座和融合逻辑聊完总体架构回到最底层的传感器配置。人形机器人领域常说的多源传感器融合在硬件层面其实是有强烈约束的不是传感器越多越好而是要在性能、重量、功耗、成本和可靠性之间做平衡。以目前常见的人形机器人原型平台来看主流配置大致如下。双目或RGB-D相机几乎是标配一般安装在头部或躯干上提供彩色图像和深度图像用于目标识别、地形分析、动态物体检测这类偏语义的任务。激光雷达也很常见通常安装在躯干或头部用于远距离环境感知和全局地图构建它的测距精度远高于相机对建图质量至关重要。IMU是必须的它提供本体姿态和加速度信息是所有状态估计的基础。关节编码器内置在每个电机里提供关节角度和角速度是运动学和动力学计算的基础。足底六维力/力矩传感器则用在双足机器人的踝关节处测量地面反作用力是行走稳定性的直接信息来源。这里有一个非常容易踩坑的细节——传感器的空间同步和时间同步。空间同步又叫外参标定要解决的是每个传感器看到的物理位置在机器人坐标系里的精确坐标是什么。时间同步要解决的是不同传感器在同一个毫秒级时间片内采集的数据能否对齐。这两个问题在轮式机器人上就有但人形机器人上更致命因为人形机器人在行走过程中头部、躯干、腿部都在剧烈运动只要外参标定偏差几毫米时间同步偏差几十毫秒融合出来的环境表示就会出现明显的错位和漂移落点规划直接说你站在不该站的地方。所以我的经验是在搭建人形机器人感知系统的第一天就要把多传感器时间同步机制和外参标定工具链准备好不能等到中途联调再补。标定不是一次性工作机器人运行一段时间后外壳形变、螺丝松动、安装偏差都可能导致外参漂移所以最好能做在线标定或定期自动标定。从融合逻辑上说传感器不是简单的取平均或者谁准就听谁的。不同传感器有各自的优势时间和空间频段IMU在极短时间内非常准长时间就漂移相机在纹理丰富的地方表现好在黑暗或白墙场景就失灵激光雷达不受光照影响但对反射材质敏感。一个可用的融合系统必须能够根据当前场景和运动状态动态调整各个传感器的权重这既需要理论上的滤波框架也需要工程师的经验调参。5. 从环境感知到状态估计感知系统的双主线很多人把人形机器人的感知系统和环境感知系统完全等同这其实是个不小的误解。严格来说人形机器人的感知系统有两条主线一条是外部环境感知一条是本体状态估计。这两条主线在架构上是并列的、相互依赖的但处理的数据源和输出的目标完全不同。本体状态估计这条线处理的是IMU数据、关节编码器数据、足底力数据和视觉里程计数据最终输出的是机器人的躯干位姿、关节角度、速度、加速度以及支撑状态是双脚支撑还是单脚支撑支撑腿是哪几条。这些信息对控制来说是最高优先级的——双足机器人稳定性控制使用的主要变量都来自这条线。比如机器人要主动调整躯干姿态来对抗外界扰动就必须知道当前躯干的倾斜角度和角速度这只能靠IMU加状态估计来获得。又比如步态相位切换机器人需要在摆动腿落地瞬间感知到触地事件此时足底力传感器的跳变信息就至关重要这比纯视觉判断可靠得多。外部环境感知这条线处理的是相机图像、激光点云数据最终输出的是地图、障碍物列表、地形属性、目标物体位姿等信息。它的服务对象更多是规划系统我要往哪走、路上有什么、落脚点在哪里。和本体状态估计不同的是环境感知往往允许相对较慢的更新频率因为地形和大型障碍物在短时间内的变化不剧烈不像姿态那样每毫秒都在变。这两条主线不是独立运作的。举个简单的例子机器人要跨过一块石头。外部环境感知先告诉我们前方有一块高度约0.2米的障碍物可跨越这个信息属于环境感知。但是规划器要生成一条越障轨迹它必须结合机器人的本體状态——当前重心在哪里、两条腿的支撑宽度是多少、下一步要落到哪里。一旦机器人开始越障本体状态估计就以高频反馈配合控制等重心越过障碍完成落地支撑感知系统再更新地形状态。整个过程里外部感知指导往哪走本体感知支撑怎么站稳。从工程实现的角度这两条主线通常会采用不同的处理频率和算法框架。本体状态估计需要极高的实时性通常在几百赫兹到上千赫兹的循环里运行依赖的是数值优化和滤波类算法。外部环境感知则更灵活可以跑在几赫兹到三十赫兹的循环里使用深度学习或点云配准等计算更重的算法。感知架构设计者必须一开始就明白这两条主线的需求不同不能简单套用同一个感知框架否则不是拖垮实时性是牺牲精度。6. 感知-控制-规划的经典关系不是串联而是循环在很多人最初的理解里感知-控制-规划是典型的串联流水线感知模块出结果规划模块做决策控制模块执行。这个理解在很简单的任务里是成立的但在复杂的人形机器人系统里必须升级为循环嵌套的视角。第一层循环是高速的本体感知-控制循环。这个循环运行频率非常高通常在1kHz量级任务是把当前状态和期望状态的误差换算成关节力矩指令。在这个循环里感知的作用是提供状态反馈——姿态、角速度、足底力、关节角度。控制器本身不一定需要高智能但它对反馈的实时性和准确性要求极其苛刻。感知延迟哪怕多了一毫秒都会直接影响稳定性裕度。第二层循环是环境感知-运动规划的慢速循环运行频率通常在1到30Hz。任务是根据环境信息和任务目标生成运动轨迹或者整定步态参数。在这个循环里感知输出的环境地图、障碍物列表和地形分类会被规划器当作优化问题的约束条件。这时候感知的精度和不确定性表达就非常关键——如果感知给出的可行域太乐观规划器可能会生成一个踩到障碍物的轨迹如果太保守机器人又会像蜗牛一样不敢走。第三层循环是最外层的任务感知-高层规划循环运行频率可以低到0.1到1Hz甚至按需触发。任务是在长时间尺度上决定机器人接下来该执行哪个子任务。它需要感知给出的是场景语义和目标物体状态比如门是开的还是关的目标物体是否已经被抓住。这三层循环不是互相独立的它们之间存在嵌套关系。高层循环的决策会影响中层循环的目标中层循环的输出又给底层循环提供参考轨迹。反过来底层的控制和状态估计结果也会反馈给中高层比如机器人当前的稳定性余量已经很低是否需要中止当前越障计划。真正的系统架构就是这样一套环环相扣的循环结构绝不是一条单向流水线能表达的。理解了这个关系你就理解为什么人形机器人的感知系统需要特别设计多速率架构。你不能用一个统一的帧率去处理所有感知信息——如果所有感知都以高速率跑计算资源不够如果都以低速率跑控制根本用不上。好的架构一定会把感知数据按使用对象和时效性拆成不同的速率通道最高速的留给状态估计和控制中速的留给环境感知和规划低速的留给任务理解。这就是所谓感知-控制-规划一体化在工程架构上最基本的体现。7. 一体化趋势从模块拼接到特征共享的三层演进最近几年人形机器人领域最明显的趋势之一就是感知-控制-规划一体化。但这个词在不同人嘴里含义不太一样我倾向于把它拆成三个层面的演进来理解。第一层演进是接口层面的协议化。也就是感知、规划、控制三个模块仍然干各自的活但它们的输入输出格式被设计成互相咬合的一套体系比如感知输出的占用栅格直接就是规划器的代价地图规划生成的步态序列直接就是控制器的参考轨迹。这一层的一体化不需要改变任何算法本质纯粹是工程上的统一设计。我见过很多团队做得不错一套定义清晰的接口协议能省掉联调阶段的大半麻烦。第二层演进是表征层面的共享化。核心思路是感知模块不再输出人工设计的中间表示给控制/规划而是直接输出一个嵌入空间——一个特征向量。规划器或控制器在高维特征空间里做决策感知网络在特征空间里提供约束和目标。这其实已经在自动驾驶和机器人操控领域有不少实际应用比如一些视觉-运动策略输入就是图像输出就是关节动作完全跨越了感知、规划、控制这一步一步的人工切分。在人形机器人领域很多团队正在尝试用端到端的深度强化学习把原始视觉信息直接映射到双足步态控制不再显式建图效果在仿真里看起来已经相当出色。第三层演进是系统层面的联合优化化。也就是感知、规划、控制不再是分开训练、分开调参的三个模型而是一个大的学习系统感知网络为规划和控制服务规划的结果反向指导感知网络把注意力放在哪里。这一层目前还偏研究性质但对实际工程的影响已经开始显现——至少它改变了我们设定感知指标的方式不再只看检测精度而是要看到底对任务成功率有多大贡献。作为工程师我现在的态度是拥抱一体化趋势但保持理性。三个层面的一体化可以逐步推进接口协议化是马上能做的表征共享化可以挑一到两个具体任务先试系统联合优化则要在仿真平台里大量打磨再考虑真实机器人迁移。如果一上来就想做第三层大多数团队在数据规模、算力和调试能力上都会被压垮。8. 架构落地的关键考虑延迟、不确定性、计算资源与协同时序前面讲了这么多架构层面的道理最终落到工程实现必须面对几个绕不开的硬问题延迟、不确定性、计算资源和协同时序。延迟是第一个绕不开的坎。人形机器人的步态周期通常在0.8到1.2秒左右支撑腿切换的时间窗口更短往往只有几十毫秒到几百毫秒。感知系统从传感器采集到输出可用的环境信息延迟只要超过百毫秒级规划器就已经在对着过期的世界做决策。更麻烦的是感知延迟还不是恒定值它会随着环境复杂度、GPU负载和算法分支变化而抖动这种抖动比固定延迟更难对付。所以在架构里必须设计延迟监控和自适应的策略比如感知延迟增大时规划器自动扩大安全裕度把步幅收小、速度降低。不确定性是第二个必须直面的问题。任何传感器和算法都有误差但规划器需要的不是一个点估计而是一个分布。比如感知告诉你前方障碍距离1米但真实值可能是0.95米或者1.05米如果你的规划器只按1米来做避障它的成功率不会高。更合理的方式是让感知输出障碍物位置的不确定性范围规划器在做轨迹优化时把这个不确定性量化到安全约束里在危险区域自动减速。很多先进的规划框架已经支持这种不确定性感知的运动规划但对感知端提出了额外的要求——你不仅要测准还要知道自己有多准。计算资源是第三个瓶颈。人形机器人受限于电池和散热不可能背一个大型服务器。感知、规划、控制的总算力预算往往是几百瓦以内但环境感知的深度学习模型和建图优化算法都是计算大户。所以必须做算力调度和分配核心原则是关键的、高频的、安全相关的计算优先比如状态估计和控制必须独占一部分高速算力非关键的、低频的、任务相关的计算可以挤在剩余资源里慢慢跑。GPU上任务编排这块很多团队会采用流水线和数据复用技术尽量提高吞吐量。协同时序是最容易被低估的一点。所谓协同时序指的是多个传感器和处理节点的时间对齐问题。图像到达时IMU数据已经算到了哪个时间点规划器生成轨迹时使用的是哪一版地图控制器执行指令时这个轨迹是多久以前生成的现代机器人系统往往采用延迟补偿和时间戳管理来保证全链路时序一致性。具体实现上所有传感器数据进入系统后的第一件事就是打时间戳通信框架要保证各节点使用统一的时基规划器和控制器的状态输入必须对齐到同一时刻的估计值而不是各用各的缓存。这四个问题任何一个人形机器人感知架构都要正面回答。有的靠算法设计解决比如引入滤波和不确定性建模有的靠工程手段解决比如调度和同步有的是系统性难题需要整个机器人团队一起定规矩、做机制保障。没有哪个问题可以完全绕过去也没有哪个问题靠某一个天才模型就能搞定。9. 实际落地时的排错顺序与成体系建议结合我自己调试人形机器人原型系统的经验最后提供一个实用的排错思路和落地建议希望可以帮到正在搭系统的团队。如果你在真实机器人上碰到感知看起来正常、控制却不稳定的情况请严格按照这个顺序排查先看时钟同步再查状态估计频率然后检查感知输出的空间坐标系最后才是算法精度。第一步时钟同步错乱是所有诡异问题的原罪传感器之间和节点之间出现几十毫秒的对不齐感知和控制的融合就全乱了。第二步本体状态估计频率如果低于500Hz双足控制基本上很难稳因为从足底力变化到姿态调整的链路里频率不够意味着你根本来不及反应。第三步坐标系对不上很常见——激光雷达建的地图是雷达坐标系相机识别出的目标在相机坐标系如果外参标定没做好规划器拿到的目标位置可能直接偏出去好几厘米这足以让机器人一脚踩空。最后才是看检测精度、分割精度这些大家最关注的指标其实这些指标通常不是系统不稳定的首要原因。落地建议方面我给三条成体系的方向。第一把感知-控制-规划三块功能先做成强接口、弱耦合的框架再逐步加深耦合不要一开始就追求全端到端。第二所有模块的输入输出都要携带不确定性估计和时戳信息这会给下游的信任和调度带来巨大优势。第三在物理世界跑之前先在仿真平台里把全链路延迟配平评估不确定性传播的影响并从仿真环境中沉淀出验证用例再迁移到真实机器人上做真机验证。没有人能一步到位但按这三条走至少不会在中途推倒重来。我个人的体会是人形机器人感知系统本质上不是如何更好地看世界的问题而是如何在复杂运动和严格约束下让感知为控制与规划所用的问题。一个感知系统设计得好不好最终要看机器人整体在真实环境里的任务成功率而不是单看感知算法的漂亮指标。理解了这一点你设计出来的感知架构大概率会比只看算法的同行高一个层次。