type
Post
status
Published
date
Apr 24, 2026 13:30
slug
summary
tags
具身智能
category
学习路径
icon
password
之前看 VLA,顾名思义嘛,Vision Language Action Models,很多时候会自然地把注意力放在视觉上:模型有没有看清目标?ROI 有没有框准?高分辨率局部图像有没有被有效利用?视觉 token 到 action expert 里之后还剩多少空间信息?这些问题当然都很重要,尤其是在一些高精度操作场景里,视觉 grounding 不稳定往往会直接导致动作失败。
但 OmniVTA 给我的感觉是,它在提醒我们:高精度操作不只是“看得准”的问题,很多时候更是“碰上之后能不能稳住”的问题。
比如插入、擦拭、切割、剥皮、抓取这些任务,视觉能帮助机器人找到目标,规划一个大致动作,但真正困难的部分往往发生在接触之后。插头是否插歪,擦拭时压力是否合适,刀有没有真正切入材料,夹爪是不是正在打滑,这些信息很难只靠视觉稳定判断。正是从这个角度出发,论文里引入了大规模视触觉数据集 OmniViTac,以及一个基于视触觉世界模型和高速触觉反馈的操作框架 OmniVTA。论文中提到,OmniViTac 包含 21,879 条轨迹,覆盖 86 个任务和 100+ 物体,并按照 wiping、peeling、cutting、grasping、assembly、adjustment 六类接触模式组织数据。
这也是我觉得这篇文章比较有意思的地方:它没有把触觉简单当成“多一个输入模态”,而是把触觉放到了世界模型预测和闭环控制的核心位置。
不是所有操作问题都能靠视觉解决
读这篇文章时,我最先想到的是自己之前对高精操作的理解可能有些偏视觉化。
做视觉 VLA 时,我们很容易把失败归因于“看得不够准”。比如按钮太小、把手边界不清、ROI 框偏了、局部细节没有进入 action expert。于是改进思路也会自然变成:换更强的视觉 encoder、加局部高清 patch、做 ROI token fusion、让模型重建局部区域。
但 OmniVTA 讨论的任务让我意识到,很多 contact-rich 操作即使视觉定位大致正确,也未必能成功。因为最后的成败取决于接触状态,而不是单纯的目标位置。
以插入任务为例,机器人可能已经把插头移动到了接口附近,视觉上看起来也对齐了,但真实接触中只要有一点姿态误差,就可能卡住。这个时候如果机器人没有感知到异常接触,只是继续执行原来的 action chunk,就很容易失败。
擦拭任务也是类似。视觉可以看到桌面和擦拭轨迹,但它不直接告诉你“压力够不够”“有没有贴住表面”“摩擦是否稳定”。这些信息更像是触觉或者力反馈才能提供的。
所以这篇文章最基础的启发是:视觉负责把机器人带到目标附近,但接触反馈决定机器人能不能完成最后的物理交互。
这和纯视觉 VLA 的研究视角确实不一样。视觉 VLA 更像是在解决“我要操作什么、在哪里操作”的问题,而 OmniVTA 更关注“我接触得对不对、接触状态会怎么变化、偏了之后怎么修”。
OmniViTac 的任务组织方式很值得学
OmniViTac 数据集里,我觉得最值得借鉴的不是轨迹数量本身,而是它的任务组织方式。
很多机器人数据集会按照任务名称分类,比如 pick、place、open、close、wipe。但 OmniViTac 更强调物理接触模式,把任务分成 wiping、peeling、cutting、grasping、assembly、adjustment 六类。这个分类方式让我感觉更接近机器人操作的本质。
因为同样是“完成一个任务”,背后的接触机制可能完全不同。
擦拭需要持续面接触和稳定压力;切割需要感知材料阻力变化;装配需要小范围几何对齐和卡滞检测;抓取需要判断夹持是否稳定、有没有滑移;手内调整则更依赖剪切力、扭转和连续微调。
这让我想到,如果以后自己设计高精操作 benchmark,不能只说“我做按钮、插孔、抓取这些任务”,还应该进一步说明它们分别对应什么接触模式。否则所谓“高精度操作”会显得很泛,别人也不容易判断方法到底解决了什么问题。
从这个角度看,OmniVTA 其实提供了一种更好的叙事方式:不是从任务名称出发,而是从交互机制出发。

TactileVAE:触觉不是一张普通图像

论文里的第一个模块是 TactileVAE。它的作用是把触觉传感器产生的高频形变信号压缩成一个低维 latent,供后面的世界模型和策略使用。
一开始我对 tactile sensor 的理解也比较浅,大概觉得它就是机器人手指上的“触觉摄像头”。但文章里其实没有直接把高分辨率触觉图像喂给模型,而是使用 marker 的 3D displacement field。也就是说,传感器表面的柔性材料在接触物体后会发生形变,每个 marker 在 x、y、z 方向上的位移就构成了触觉输入。
这个处理方式很合理。因为对操作来说,真正重要的不是触觉图像长得像不像,而是哪里被压了、哪里发生剪切、接触区域怎么变化。这些信息比 RGB 纹理更接近物理交互本身。
我觉得这点对视觉增强也有启发。我们做 ROI 或局部视觉特征时,不能只问这个局部图像能不能被重建得更清楚,而要问它是不是包含了对动作有用的信息。比如夹爪和目标之间的局部相对关系、边缘位置、接触点附近的几何误差,这些可能比“图像看起来更清晰”更重要。
换句话说,高精操作里的表征学习不应该只追求视觉质量,而应该追求交互相关性。
这篇文章最核心的点:预测未来触觉
OmniVTA 最启发我的地方,是它没有只把触觉作为当前输入,而是让世界模型去预测未来触觉。
传统 policy 大概是:
当前图像 + 当前状态 + 当前触觉 → 动作
但 OmniVTA 更像是:
历史视觉、触觉、动作 → 预测未来触觉
当前观测 + 未来触觉预测 → 生成动作
真实触觉反馈 → 高频修正动作
这里的变化很关键。触觉不再只是“我现在感受到了什么”,而变成了“我接下来应该感受到什么”。
我觉得这和人类操作有点像。比如我们擦桌子时,并不是只看着抹布在移动,而是会隐约预期手上应该有一种稳定的阻力;如果突然变轻,可能说明没贴住桌面;如果突然变重,可能说明卡住或者压力过大。也就是说,我们在操作中其实一直有一个对接触状态的预期。
OmniVTA 把这个想法工程化了:先用 world model 预测未来 tactile latent,再让 policy 根据这个未来接触信息生成动作。
这对我之前做视觉 VLA 的思考影响比较大。之前如果想增强视觉,我可能会优先考虑让模型看得更清楚。但现在我会多问一句:这个视觉增强最终有没有帮助模型预测未来交互状态?如果只是重建图像更好,但对接触、对齐、修正没有帮助,那它未必真的能提升操作能力。
LTD Encoder:有用的不是状态本身,而是差值
论文里还有一个我觉得挺巧妙的设计,叫 Latent Tactile Differential Encoder。
它做的事情很直接:把当前触觉特征、预测未来触觉特征,以及两者的差值拼起来。
这个差值其实很有意思。因为控制问题里最重要的往往不是“当前状态是什么”,而是“当前状态和目标状态差多少”。
比如插入任务中,当前接触和预期接触的差异可能意味着插头偏了;擦拭任务中,这个差异可能意味着压力不够;抓取任务中,它可能意味着物体正在滑。这样一看,LTD Encoder 实际上是在构造一种接触误差信号。
这让我想到,视觉 VLA 里也许可以有类似设计。我们不一定只能把当前视觉 token 喂给 action expert,也可以显式建模“当前局部状态”和“预期交互状态”之间的差别。比如夹爪和目标局部边缘的对齐误差,按钮按下前后的局部变化,物体运动是否符合预期等。
当然,如果没有真实触觉,这些只能算 pseudo-contact 或 interaction proxy,不能和 tactile feedback 等价。但这种“差分表征”的思路本身很有价值。
多模态融合不能一直平均用力
OmniVTA 还有一个设计叫 Adaptive Visuo-Tactile Fusion。它不是简单把视觉和触觉 concat,而是根据接触概率动态调整两种模态的权重。
这个设计看起来很自然,但其实很重要。
因为在操作的不同阶段,视觉和触觉的重要性是不一样的。接触前,触觉基本没什么有效信息,机器人主要依赖视觉去接近目标。接触后,视觉可能被遮挡,或者看不出细微的力变化,这时候触觉反而更可靠。
所以多模态融合不应该是静态的。不是“视觉 50%,触觉 50%”,也不是“所有 token 都扔进 transformer 让模型自己学”,而是应该随着任务阶段变化。
这点和我之前想的 gating 很有关。我之前更多从不确定性角度想 gating,比如 action expert 对某些阶段更不确定,所以需要额外视觉补充。读完这篇文章后,我觉得 gating 也可以有更物理的解释:它表示当前是不是进入了接触关键阶段,模型是否应该从视觉主导切换到触觉/反馈主导。
如果没有触觉传感器,也可以用一些替代信号,比如 gripper width、proprioception residual、视觉运动残差、ROI confidence、action uncertainty 等,去估计当前是否进入接触阶段。只是这时候表述要谨慎,不能说自己真的建模了力,只能说是 contact-aware 或 interaction-aware。
Slow-fast 结构很适合高精操作
OmniVTA 的整体结构是 slow-fast policy。慢速部分负责预测未来触觉和生成 action chunk,快速部分 RLTC 以 60Hz 使用触觉反馈修正动作。
这个结构我觉得特别适合解释 VLA 在高精操作中的问题。
大模型很强,但它不适合每秒几十次地重新推理。VLA backbone 擅长理解任务、融合视觉语言信息、生成较长时域的动作计划。但接触状态变化太快了,滑移、卡滞、压力突变这些东西不可能完全靠低频 action chunk 解决。
所以 OmniVTA 没有试图让一个大模型包办一切,而是把系统拆开:
这对 pi0/pi0.5 这类模型也有启发。action expert 可以作为 slow planner,但在高精接触阶段,可能需要一个轻量的 correction module。这个 module 不一定有很强语义能力,但要足够快,能够根据局部状态、反馈误差或不确定性输出 delta action。
我现在越来越觉得,高精操作系统可能不应该执着于“一个端到端大模型解决所有问题”。更现实的结构可能是:VLA 负责语义和粗动作,局部交互模块负责最后几毫米的修正。
实验里最有说服力的地方
这篇文章的实验很多,我最关注的是消融。
从结果看,单纯使用当前触觉并不够,加入未来触觉预测后,成功率明显提升;再加入 LTD Encoder 和 gating 后,效果继续变好。完整模型相比去掉 RLTC 的版本也更强,说明高速闭环控制确实有作用。
这说明几个设计不是随便堆上去的,而是有比较清晰的递进关系:
先把触觉编码好,再预测未来触觉,再根据接触阶段调整视觉/触觉权重,最后用真实反馈做快速修正。
这里最值得我记住的是:未来视觉生成不一定是最有价值的,未来触觉预测反而更直接。
在视觉 VLA 研究里,我们很容易觉得“更完整的视觉世界模型”会更好。但对 contact-rich 操作来说,未来图像未必是最关键的控制变量。真正决定成败的可能是未来接触状态,比如压力、滑移、卡滞、接触面积变化。
这提醒我,以后设计辅助任务时,不能只看它是不是“视觉上合理”,还要看它离控制目标有多近。
对我自己方向的影响
读完这篇文章后,我觉得自己对高精 VLA 的理解可以稍微换一种说法。
以前我可能会说:
高精操作失败是因为视觉 grounding 不够好。
现在我会补充一句:
很多失败还来自模型缺少对接触阶段的预测和修正能力。
所以我现在更倾向于把 VLA 操作能力分成三层:
我之前主要关注前两层,尤其是视觉和几何。但 OmniVTA 让我意识到,真正的高精操作可能绕不开第三层。
当然,这不意味着我必须马上去做 tactile sensor。现实上,硬做 visuo-tactile 也不太实际。但可以吸收它的方法思想,做一个更适合当前条件的方向,比如 contact-aware visual VLA。
也就是说,不直接引入真实触觉,而是通过视觉、动作历史、gripper state、proprioception residual 等信号,让模型显式感知自己是否进入接触阶段,是否需要局部修正,是否应该提高对 ROI 或反馈信号的权重。
这可能比单纯做“更高清的视觉增强”更贴近高精操作本身。
最后的一点感受
我觉得 OmniVTA 对我最大的启发,不是“触觉传感器很重要”这么简单。更准确地说,它让我意识到:机器人操作里的世界模型,不应该只建模外观世界,还应该建模交互世界。
视觉告诉机器人环境长什么样,触觉告诉机器人自己和环境之间正在发生什么。对于真正需要接触的任务来说,后者可能才是最后决定成功与否的关键。
如果说很多视觉 VLA 工作是在解决“怎么让机器人看见目标”,那么 OmniVTA 更像是在问:
机器人碰到目标之后,怎么知道自己碰得对不对?
这个问题其实更接近真实机器人操作的核心。
对我自己的研究来说,这篇文章也让我不太想继续只围绕“视觉更强”打转。视觉当然重要,但高精操作最终不是视觉竞赛,而是物理交互问题。模型需要看见目标,也需要预测接触,更需要在接触偏离时及时修正。
一句话总结我的阅读感受:高精 VLA 不能只追求看得更清楚,还要学会碰得更稳定。
- 作者:CreamGreen.
- 链接:www.creamgreen.com/article/34f555f7-8779-808b-8fce-e6c88a929659
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章

.png?table=block&id=34f555f7-8779-808b-8fce-e6c88a929659&t=34f555f7-8779-808b-8fce-e6c88a929659)
.png?table=block&id=28e555f7-8779-80ec-b81a-d42f2e03ca40&t=28e555f7-8779-80ec-b81a-d42f2e03ca40)
.png?table=block&id=297555f7-8779-80ee-912a-f9920dd2cd23&t=297555f7-8779-80ee-912a-f9920dd2cd23)

.png?table=block&id=350555f7-8779-8035-9cc3-d4f1926e71e2&t=350555f7-8779-8035-9cc3-d4f1926e71e2)


