资讯动态

人形机器人是具身智能终点吗?实时音视频链路才是关键

发布时间:2026/10/28 6:00:51 来源:尧图企业网站定制
1. 从一句提问说起人形机器人到底是不是具身智能的终点“人形机器人是具身智能的终点吗”这个问题我第一次在团队内部听到时第一反应是——这问题问反了。真正值得琢磨的不是“是不是终点”而是“为什么大家默认把终点画成人形”。你看这两年具身智能、人形机器人、VLA、实时音视频这几个词几乎绑在一起出现xbotics 具身智能开源社区里讨论最热的也是开源人形机器人 hunter 这类项目具身智能学习路线被反复转发。热度背后其实藏着一个很朴素的工程事实智能要进入物理世界第一步不是长出腿和手而是先能稳定地“看见、听见、反应”。我自己是从实时音视频这条线切进机器人领域的早期做的是低延迟传输和媒体处理后来发现机器人身上那套感知-决策-执行链路本质上和实时音视频系统有大量重叠。所以这篇不打算给你灌“具身智能是什么”的科普而是想从一个做过实时音视频的从业者视角把“人形机器人是不是终点”这个问题拆开聊聊智能机器进入物理世界的底层逻辑到底是什么以及为什么实时音视频能力是绕不过去的一环。适合谁看如果你在做机器人、做具身智能、做 VLA 相关的东西或者你是个开发者想找一条具身智能学习路线又或者你只是好奇为什么所有做机器人的团队都在死磕延迟——这篇应该能给你一些不一样的角度。我会尽量说人话把参数、链路、坑都摊开讲。2. 具身智能的核心命题智能体如何“活”在物理世界里2.1 具身智能和传统 AI 的根本区别在哪先把概念理清楚。传统 AI不管是图像分类还是大语言模型它的输入输出都是符号或数据模型跑完给个结果就结束了它不承担“动作的后果”。具身智能不一样它必须把感知、决策、执行闭成一个环而且这个环是在真实物理时间里跑的。你模型再聪明如果决策出来的时候杯子已经掉地上了那这个智能就是无效的。这就是为什么具身智能这个词里“具身”两个字比“智能”更关键。它强调智能体有一个物理载体要通过传感器去感知世界通过执行器去改变世界并且要承受改变世界的后果。这个闭环里任何一个环节的延迟、抖动、丢帧都会直接变成物理世界里的失败动作。我常拿一个类比传统 AI 像在纸上做数学题做错了擦掉重来具身智能像在开车你方向盘打晚半秒车就撞了。这个“晚半秒”就是实时性问题也是后面所有技术选型的出发点。2.2 为什么“实时”是具身智能的生命线很多人聊具身智能喜欢聊模型架构、聊 VLA、聊端到端但真正决定一个机器人能不能用的往往是那些不性感的东西——延迟、抖动、同步。我做过一个粗略的测算一个典型的机器人感知-决策-执行闭环如果总延迟超过 100ms操作者或模型就会明显感觉到“滞后”超过 200ms精细操作基本没法做超过 500ms连抓取都会变得笨拙。这个数字不是拍脑袋来的。人类自身的感知-运动闭环延迟大概在 100-200ms 量级比如你看到球飞过来再伸手去接中间的反应时间就是这个范围。机器人要和人类协作、要在人类环境里工作它的闭环延迟至少不能比人类差太多否则协作就是灾难。而实时音视频技术解决的恰恰就是这个链路里最容易被忽视、又最致命的部分感知数据的实时采集、编码、传输、解码、同步。摄像头采集一帧图像编码压缩通过网络传到计算单元解码喂给模型模型输出动作指令再传回执行器——这一整条链路每一环都在吃延迟。实时音视频的功夫就是把这每一环都压到极致。2.3 人形只是形态不是目的回到标题那个问题。我的观点很明确人形机器人是具身智能的一种重要形态但绝不是终点甚至不是唯一的重点。为什么大家执着于人形因为人类环境是为人形设计的——门把手的高度、楼梯的台阶、工具的握持方式全都是按人的身体尺度来的。人形机器人最大的优势是“不用改造环境就能直接用”。但形态服务于任务。在工厂里机械臂可能比人形更高效在仓储里轮式底盘加机械臂可能比双足更稳在家庭里人形确实有优势因为家庭环境太非结构化。所以真正的问题不是“要不要做人形”而是“你的任务需要什么样的身体以及这个身体需要什么样的实时能力”。我见过太多团队一上来就死磕双足平衡结果连基本的视觉伺服都没做稳。具身智能学习路线上我建议的顺序是先搞定感知和实时链路再搞定决策最后才是复杂形态的运动控制。形态是最后一步不是第一步。3. 实时音视频为什么是智能机器进入物理世界的底层逻辑3.1 感知链路机器人“看见听见”背后的实时媒体处理机器人要感知世界最核心的两类传感器就是摄像头和麦克风。摄像头给视觉麦克风给听觉这两类数据本质上都是实时媒体流。很多人以为机器人视觉就是“调个 OpenCV 读帧”但真实系统里从 sensor 出图到模型拿到可用数据中间有一大堆实时媒体处理要做。首先是采集。工业相机、深度相机、RGB 相机出图格式五花八门YUV、RGB、RAW帧率从 30 到 120 不等。采集环节要保证不丢帧、时间戳准确否则后面所有同步都是错的。我踩过的坑早期用普通 USB 相机时间戳是驱动给的抖动能有几十毫秒做多传感器融合时直接崩。然后是编码。原始图像数据量巨大1080p 30fps 的 RGB 一秒钟就是 180MB 左右不压缩根本传不动。但编码会引入延迟H.264 的编码延迟通常在 10-30msH.265 更低一些但算力要求高。这里就要权衡是传原始数据走高速总线还是编码后走网络。我的经验是机内短距离用 MIPI 或 USB3 传原始跨设备或远程操作用硬件编码。解码和同步是另一个大头。多路摄像头加麦克风时间戳必须对齐否则视觉和听觉对不上模型学出来的东西就是错的。实时音视频里的时间戳对齐、抖动缓冲、音视频同步这些机制直接可以搬到机器人上。3.2 决策链路VLA 模型对实时数据流的依赖VLA也就是 Vision-Language-Action 模型是这两年具身智能最热的方向。它的思路是把视觉、语言、动作统一到一个模型里输入图像和指令直接输出动作。听起来很美但工程上它对数据流的要求极高。VLA 模型通常需要连续的视觉输入不是单帧而是一个时间窗口内的多帧才能理解动作的动态。这就要求视觉数据流必须稳定、低延迟、时间戳连续。如果中间丢了几帧或者延迟抖动大模型看到的就是“卡顿的世界”输出的动作就会跳变。我实测过一个 VLA 推理链路摄像头采集到模型输出如果中间用软件编码加网络传输端到端延迟能到 150ms 以上换成硬件编码加零拷贝传输能压到 50ms 以内。这 100ms 的差距在抓取任务里就是“抓得到”和“抓不到”的区别。所以 VLA 不是光有模型就行它背后需要一套实时媒体管道来喂数据。这套管道的能力直接决定了 VLA 能不能在真实机器人上跑起来。3.3 执行链路从指令到动作的延迟预算怎么算执行链路经常被忽略但它同样吃延迟。模型输出动作指令后要通过通信传到执行器执行器再驱动电机。这里涉及控制频率的问题一个稳定的力控或位置控控制频率通常在 100Hz 到 1kHz也就是每 1-10ms 要出一个指令。如果上层决策延迟大下层控制就得靠插值或预测来补补得不好就会抖。我习惯给一个机器人系统做延迟预算表把每一环的延迟列出来加总看是否满足任务要求。下面是一个典型例子环节典型延迟优化手段传感器采集5-15ms硬件触发、全局快门编码10-30ms硬件编码、低延迟配置传输5-50ms有线优先、QoS 保障解码5-20ms硬件解码、零拷贝模型推理20-100ms模型量化、算子优化指令传输1-10ms实时总线、优先级队列执行器响应5-20ms高带宽驱动、前馈补偿加总下来一个没优化过的系统轻松超过 200ms优化过的能压到 80ms 以内。这个表我建议每个做机器人的都自己填一遍填完就知道瓶颈在哪。3.4 SmartMediaKit 这类工具在机器人场景里的定位说到实时音视频工具SmartMediaKit 这类媒体处理套件在机器人场景里其实很有价值。它把采集、编码、传输、解码、渲染这一整套链路封装好了开发者不用从零造轮子。我早期自己写过采集和编码后来发现用成熟套件能省几个月时间而且稳定性更好。它在机器人里的定位我理解是感知数据的基础设施。机器人不需要关心 H.264 的 NAL 单元怎么打包不需要关心 RTP 的时间戳怎么算它只需要拿到“对齐好的、低延迟的、可用的媒体流”。SmartMediaKit 这类工具就是干这个的。当然机器人场景对它的要求比普通直播更高延迟要更低同步要更准还要能和 ROS 这类机器人中间件对接。4. 从实时音视频到具身智能一套可落地的技术链路拆解4.1 硬件选型摄像头、麦克风、算力平台怎么配硬件选型是第一步也是最容易踩坑的一步。我按经验给几个原则。摄像头优先选全局快门卷帘快门在运动场景下会有果冻效应机器人一动图像就歪。帧率至少 60fps做精细操作建议 120fps。接口优先 MIPI 或 GMSLUSB 在长距离和多路场景下不稳定。深度相机看任务结构光适合近距离ToF 适合中距离双目适合远距离但算力要求高。麦克风如果是做语音交互建议用麦克风阵列4 麦或 6 麦能做声源定位和波束成形。单麦在机器人本体噪声下基本没法用。算力平台这是最纠结的。GPU 平台推理快但功耗高边缘 NPU 功耗低但生态差。我的建议是分层感知和实时媒体处理用低功耗 SoC模型推理用独立加速卡两者用高速总线连。这样既能保证实时性又能保证算力。4.2 采集与编码低延迟配置的关键参数采集和编码的配置直接决定链路的基础延迟。我列几个关键参数。采集端关闭自动曝光和自动白平衡用固定参数否则帧间亮度跳变会让模型困惑。开启硬件时间戳精度到微秒。缓冲区设小宁可丢帧也不要积压积压意味着延迟累积。编码端用硬件编码器别用软件。H.264 的profile选 baseline 或 main别选 highhigh 的 B 帧会引入额外延迟。关闭 B 帧用 IPPP 结构。GOP设小比如 15-30 帧方便快速恢复。码率控制用 CBR别用 VBRVBR 的码率波动会导致延迟抖动。下面是一段典型的低延迟编码配置思路以常见编码器参数为例# 低延迟编码关键参数示意 profilemain # 不用 high避免 B 帧 bframes0 # 关闭 B 帧 gop15 # 小 GOP快速恢复 rc_modecbr # 恒定码率稳定延迟 bitrate8000 # 8Mbps按分辨率调整 slice_mode1 # 分片降低单帧延迟这些参数不是死的要根据你的分辨率和网络调。但原则是一切为了低延迟和稳定牺牲压缩率没关系。4.3 传输与同步多路数据流怎么对齐多路数据流对齐是机器人感知的核心难点。视觉、深度、IMU、麦克风每一路都有自己的时钟怎么对齐我的做法是统一时钟源。所有传感器都用同一个硬件触发信号或者都用 PTP 这类网络时钟同步。采集时打上统一时间戳传输时保留时间戳接收端按时间戳做对齐。传输上优先有线。以太网、GMSL、USB3 都比 WiFi 稳。如果必须无线用 5G 或专用频段别用拥挤的 2.4G。传输协议上RTP 有成熟的时间戳和序列号机制可以直接用。QoS 要配好给媒体流最高优先级。同步策略上我常用最近邻对齐加插值。比如视觉 30fpsIMU 200Hz就按 IMU 的时间戳去找最近的视觉帧中间用插值补。插值会引入误差但比不对齐好得多。4.4 与 ROS 等机器人中间件的对接方式机器人领域绕不开 ROS。实时音视频链路要和 ROS 对接核心是把媒体流封装成 ROS 消息。图像用sensor_msgs/Image音频用audio_common_msgs时间戳用 ROS 的Time。这里有个坑ROS 的消息传递有序列化和反序列化开销高帧率下很吃 CPU。我的做法是用零拷贝共享内存传图像ROS 消息里只放指针和元数据。ROS2 的intra-process通信和loan message机制就是干这个的。另一个坑是 ROS 的时间系统和传感器时间戳不一致。ROS 有use_sim_time和真实时间两套混用会乱。建议统一用传感器硬件时间戳ROS 只做转发。5. 实操复盘我踩过的坑和验证过的经验5.1 延迟优化的三个反直觉结论第一个反直觉不是延迟越低越好而是抖动越小越好。一个稳定 80ms 的链路比一个 20-150ms 跳动的链路好用得多。因为模型和控制算法可以补偿固定延迟但补偿不了抖动。所以优化时先压抖动再压均值。第二个反直觉编码不一定增加延迟。如果原始数据量大到传输成为瓶颈编码反而能降低端到端延迟。我实测过4K 原始数据走 USB 传 100ms编码成 8Mbps 走网络只要 30ms。所以别一听编码就觉得慢要看整体。第三个反直觉多传感器融合不一定提高精度。如果同步没做好融合反而引入误差。我早期做视觉加 IMU同步差 20ms融合后的位姿比单用视觉还差。后来把同步做到 2ms 以内融合才真正有用。5.2 常见问题速查表问题现象可能原因排查方向解决手段图像卡顿采集丢帧或传输拥塞看采集时间戳和网络丢包减小缓冲、提高 QoS音视频不同步时钟源不统一对比两路时间戳统一硬件时钟模型输出跳变输入帧不连续检查丢帧和延迟抖动稳定数据流、加预测控制抖动决策延迟大测端到端延迟优化链路、加插值编码延迟高用了 B 帧或 VBR看编码配置关 B 帧、改 CBR多路不同步触发信号不一致检查硬件触发统一触发源5.3 给不同阶段开发者的具身智能学习路线建议如果你是新手我建议的顺序是先学实时音视频基础搞懂采集、编码、传输、同步再学机器人基础搞懂 ROS、坐标变换、运动学然后学感知搞懂视觉和点云最后学 VLA 和决策。别一上来就啃 VLA 论文没有实时链路支撑模型再好也跑不起来。如果你有机器人基础建议补实时媒体处理这块。很多机器人工程师对延迟不敏感觉得“能跑就行”但具身智能对延迟的要求比传统机器人高一个量级。如果你有音视频基础建议补机器人运动和控制。音视频的实时性思维是优势但机器人的物理约束是新的挑战。5.4 开源社区和开源人形机器人项目的参与方式xbotics 这类具身智能开源社区以及开源人形机器人 hunter 这类项目是很好的学习入口。我的建议是先跑通再改。别一上来就提 PR先把项目跑起来理解它的架构找到它的瓶颈再动手。参与方式上可以从数据链路优化入手。很多开源机器人项目的实时媒体链路是短板你如果有音视频背景很容易找到优化点。这种贡献比改模型更容易被接受也更有价值。6. 回到那个问题终点不在形态在实时闭环的能力聊了这么多回到“人形机器人是具身智能的终点吗”。我的答案是终点不是某一种形态而是智能体在物理世界里稳定闭环的能力。人形是一种形态轮式是一种形态机械臂也是一种形态它们都需要实时感知、实时决策、实时执行。谁把这个闭环做得最稳、最快、最可靠谁就最接近终点。实时音视频在这个闭环里的角色是感知数据的基础设施。它不性感不常被讨论但它决定了智能体能不能“活”在物理世界里。我见过太多团队在模型上卷生卷死结果被一个 200ms 的延迟卡住。也见过团队把实时链路做扎实后用不那么先进的模型跑出了更好的效果。最后分享一个我自己的体会做具身智能别只盯着模型看。多花点时间在数据链路上多测延迟多压抖动多对齐时间戳。这些功夫不会白费它们会变成机器人在物理世界里每一次稳定动作的底气。形态会变模型会迭代但实时闭环的能力是永远的地基。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑