最近两周，小红书上开始密集出现一类笔记：在 Franka 机械臂上把 VLA 模型跑通。有作者直接写道，前前后后一个多礼拜，踩了好多坑，终于弄通了！小红书能把 Franka 加 VLA 这套组合在真机上跑通的人，肉眼可见地变多了。
先把话说清楚，这篇内容写给谁：你已经知道 VLA 是什么，实验室里有一台 Franka FR3（或者正打算入手），看过 π0 的演示视频，琢磨着怎么在自己机器上复现。如果你还在了解具身智能是什么，这篇会偏深；但如果你正卡在标定、采数据、调动作空间的某一步，下面的内容大概率能帮你省下不止一周。
先看清：为什么大家都在往 Franka 上挤
如果你觉得最近突然所有人都在拿 Franka 跑模型，那不是错觉。
一边是 OpenAI。有媒体梳理发现，OpenAI 在旧金山搭了实验室，百人轮班全天候采数据，专啃家庭日常琐碎任务的硬骨头。核心靠 Franka 机械臂 + 低成本控制器远程操作。微博头部 AI 公司采机器人数据，选的也是 Franka。
另一边是开源生态。谷歌发布 Gemini Robotics On-Device 时表示，其只针对ALOHA机器人训练了模型，但能够将其进一步适配到双臂FrankaFR3机器人和Apptronik的Apollo人形机器人。微博今年 7 月，蚂蚁灵波开源的 LingBot-VLA 2.0，官方列出的支持名单里同样包含 17 个品牌下的 20 种机器人配置：星尘智能、乐聚、宇树、Franka、傅利叶、睿而曼等。微博
也就是说，Franka 正在事实上成为 VLA 时代的标准试验台：模型拿它训练，开源模型优先适配它。对拿着 Franka 的人来说，这意味着能抄的作业、能用的数据格式和预训练权重都是最多的；但同时，别人踩过的坑也集中在这里。
第一步，标定：这可能是最不像你想的那一步
很多人拿到机器后的第一反应，是先做手眼标定。但这一步，很可能根本不需要做。
知乎上一篇讲 VLA 真机标定的文章里，有个很反直觉的结论：关节角预测因为动作空间是机器人内部空间，规避了大部分几何标定需求。GELLO 标定 + 相机位置固定是最核心的两件事。知乎
道理不复杂：如果你的 VLA（比如 π0）输出的是关节角，模型学的是图像到机器人自身关节的映射，中间根本不存在像素坐标到基座坐标的变换，手眼标定矩阵求出来也没地方可用。手眼标定服务的是预测末端笛卡尔位姿的路线。先搞清楚自己用的动作空间是哪一种，再决定标不标定，这个顺序不能反。
不需要手眼标定，时间花在哪？花在两处。
第一处是相机位置。同一篇标定文章里说得很直白：不需要求手眼变换矩阵，但需要用支架固定相机并在部署时精确复现。知乎模型学的是特定视角下的图像分布，相机一挪，出的是训练数据问题，不是几何标定问题，重做手眼标定救不了，只能回去补数据。所以实验台搭起来第一件事，是把相机支架钉死，别随手挪。
第二处是 GELLO。如果你用 GELLO 主臂（一种与 Franka 同构的低成本遥操作装置）采数据，它的关节编码器读数必须精确映射到 Franka 关节角，否则采出来的全是脏数据。验证方法很简单：GELLO 摆到某个姿态，Franka 跟随后两者关节角读数误差应 < 0.5°。知乎超了就先修映射，修到达标再谈采数。
还有一个对校准本身的好消息：机械臂出厂时已完成基础校准，但高强度使用或碰撞后可能漂移，从 Desk v5.8.0 开始，用户可直接在DESK（FrankaRobotics控制监测界面）进行自动校准。哔哩哔哩跟着官方演示走一遍，五分钟左右就能完成，不用像早年那样手动对标记。
第二步，采数据：真正的时间黑洞
跑通之后的第二个共识是：模型不难，采数据难。
有小红书作者记录过遥操作采集的体验：franka遥操带力反馈，说起来工作效率也是蛮低的，调了一个月了。小红书光调遥操作的力反馈就花了一个月，这是真在一线干活的人给出的时间颗粒度。
那一个能用的模型到底要多少数据？可以看一个已经跑通的样本：另一位作者用 π0.5 做叠杯子任务，公开的参数是采集数据179调，lora微调40kstep，loss：0.08，本地request_hz:2。小红书179 条轨迹（作者原文写作调，应是条的手误），对应一个叠杯子任务；你的目标任务越复杂，预算就要往上翻多少，可以自己掂量。
采集时有一条建议，知乎那篇 π0 全流程文章里说得非常直接：建议记录绝对关节角（即每时刻发出的目标 joint position 指令），openpi 在 config 中可以自动转为 delta。知乎反过来，如果一开始就记增量，后面发现格式不合，重采数据的时间成本远高于改一行配置。
顺带一个只属于 Franka 单臂用户的参数坑：openpi 里的 adapt_to_pi，这是针对 ALOHA 双臂机器人的坐标系适配选项（ALOHA 的关节顺序与 PI 内部格式不同）。对于 Franka 单臂，通常设为 False。知乎照抄双臂教程的配置，是这一步最常见的翻车原因。
第三步，训练：动作空间的三个坑
这一阶段的误解密度最高。多数人的 VLA 启蒙来自 OpenVLA，而 π0 和 OpenVLA 在动作表示上几乎是反着来的。
第一个坑是输出空间。π₀ 默认输出的是关节角度（joint positions），而不是末端位姿。这与 OpenVLA 正好相反。知乎习惯了 OpenVLA 七维末端增量的人，如果按旧思路去配 π0 的数据管线，错误不会报错，只会表现为模型学不动。
第二个坑是增量的参考系。很多人默认 delta 是相对上一帧，π0 的定义却是每个 action 是相对于当前 action chunk 首帧状态的增量，而不是相对于上一帧的增量。知乎两种写法在滚动执行时会产生完全不同的轨迹，自己写数据转换脚本的话，这一条值得贴在显示器边上。
第三个坑是显存。微调门槛比想象的低：π₀_base 全量微调需要约 40GB+（A100）；开启 LoRA + train_expert_only=True（只训练 action expert，冻结 VLM）可以降到约 24GB，适合 RTX 3090/4090。知乎一张消费级显卡就能覆盖微调阶段，不必为这一步去排队租 A100。
第四步，部署：别被推理频率吓到
最后是问得最多的一个问题：我的显卡推理一秒只有两三帧，真机怎么跑得起来？
答案是这两件事根本不在同一条时间线上。π₀ 通过 action chunking 在执行层达到 50 Hz，但 VLA 推理层本身约 2~5 Hz（每次推理生成 50 步）。两者是解耦的。知乎模型在后台异步算下一段动作，机器人持续执行当前这段 50 步的 chunk，等执行完，下一次推理已经就位。Franka 的 FCI 控制接口本身以 1kHz 运行，执行层 50Hz 对 VLA 来说已经足够平滑。
所以看到推理频率低不用慌，真正要盯的是 chunk 执行轨迹是否平滑、每次执行完时下一次推理有没有跟上。跟不上，要么减执行步数，要么换更快的推理后端，方向比死磕模型精度重要。
现在值不值得入坑
分两种情况说。
如果实验室已经有 Franka：值得现在就开始。π0 加 GELLO 这条线已经有中文的完整流程可抄，LingBot 这类开源模型也在持续把 Franka 列入官方支持，作业只会越来越多。但请给第一轮迭代预留至少一个月：搭台子和标定一两天，采数据两周起，训练加调试一周左右，其中采数据是最大的变量，前面两条小红书笔记已经说明了它的真实速度。
如果是为了跑 VLA 专门买臂：先想清楚。FR3 是二十万人民币级别的投入，而且这笔钱不覆盖最贵的部分——采数据的人力。没有稳定的采集人手和明确的任务目标，更划算的路线是先在仿真里把管线跑通，或者等开源生态再熟一轮再下手。
值得持续盯的信号也很明确：一边是 OpenAI 那个百人采数实验室最终放出什么形态的模型和数据，一边是是否有更多支持 Franka 和 LeRobot 数据格式的开源模型出现。这两条线无论哪条兑现，在 Franka 上跑 VLA 的门槛都会再降一截。
