现有的调酒机器人已经把「把酒做出来」解决得很好了。 我们做的是另一件事:让一杯酒的制作过程本身值得看。
先把话说清楚:现有系统不是做得差,是目标不同。 它们为吞吐量和一致性优化,并且达到了。
| 系统 | 形态 | 吞吐 | 价格 |
|---|---|---|---|
| Makr Shakr Toni | 双臂机器人(KUKA),158 瓶 | 80+ 杯/小时(官方页) | — |
| Makr Shakr Veloce | 双臂机器人,为速度设计 | 240 杯/小时 | — |
| Cecilia.ai | 屏幕形象 + 泵 · 语音对话 | 120 杯/小时 | $45,000 或 $2,000/月 |
| Yanu | 封闭机柜内机械臂 · 对话 + 支付 | 100 杯/小时 | — |
| MIXO | 8 / 20 蠕动泵 | — | — |
| TendedBar / Backbar One | 转盘 + 泵阀 | 为高吞吐设计 | — |
整套装置是围绕机器设计的:杯子放在固定夹具上、瓶子接在固定管路上、动作走固定轨迹。 在这个前提下,预编程既快又稳。那些流畅的演示视频恰恰证明了这一点——那是它们的强项,不是短板。
这是整份材料的支点,而且它有原文出处。
“The recipe database contains pre-programmed ratios, sequences, and pour volumes.”
“machine learning tracks popular combinations, personalizes suggestions, and adjusts pours based on historical data.”
AI 用在「推荐喝什么」,不在「怎么动」。手臂本身仍然是一条录好的轨迹。
固定杯位 → 固定轨迹 → 成功
杯子挪了 5 cm → 同一条轨迹 → 抓空
看画面 → 算动作 → 成功
杯子挪了 5 cm → 重新看画面 → 重新算
会聊天的调酒机器人有了,会做动作的机械臂也有了。 但没有一台把两者放在同一个身体上。
| 有没有会表演动作的身体 | 看不看客人 | |
|---|---|---|
| MIXO · TendedBar | 泵阀 / 转盘,无身体 | 无感知 |
| Makr Shakr Toni | 双臂 KUKA · 158 瓶 · 80+ 杯/时 | 官方页无相关描述 |
| Cecilia.ai · Yanu | 屏幕形象 / 机柜内,无表演动作 | 语音对话 · 会讲笑话 · 收款 |
| XLeRobot | 双臂 + 可动头 + 三路相机 | 人脸 · 表情 · 对话 |
还有一条横跨所有人的共性:无论会不会聊天,它们的手臂动作全部是预编程的。 AI 在推荐层、在对话层,就是不在动作层。
如果只要液体,摇一摇预调罐更便宜。 人愿意坐在吧台前,是因为那里有人、有表演、有交流。
250 杯/小时。适合场馆、邮轮、机场——排队的地方。
抬头看你、转动杯子让你看清颜色、把杯子推到你面前的那一刻。
在不排队的场景里——精品酒吧、展会、门店——这一段比速度值钱。
所以我们不去和 250 杯/小时竞争。我们做那台会抬头看你的。
注意视线这一行:它在时序里出现两次,一头一尾,中间制作时是锁死的。 这不是设计偏好,是被数据推出来的结论(第 9 页给证据)。
视线:转头找到客人
手臂:静止
语音点单,表情屏回应。手臂不动,所以这一段最先能演示。
视线:锁死
手臂:抓取 · 倾倒 · 摇晃 · 搅拌
策略驱动的连续动作。
视线:锁死
手臂:转动杯身
让客人看清颜色和层次——这是现有产品里不存在的动作。
视线:回到客人身上
手臂:朝客人实际所在的方向
而不是写死的取酒口坐标。
下面的画面抽自我们已经录好的示范数据, 来自机器人头部相机的原始输出。
xlerobot-team/xlerobot-cup-grasp-20260820-0230,50 集 / 19453 帧 / 30 fps。
用 ffmpeg 从原始视频抽帧,未做裁剪或调色。视觉-语言-动作模型(VLA)直接从人类示范里学。换一只杯子、挪一个位置, 靠泛化而不是重新示教。
人脸检测 + 表情识别 + OLED 表情屏 + 语音,子系统已经在跑。 它不是加在最后的装饰,而是决定视线该看哪的输入。
旋转展示、朝人递出。这类动作在现有产品里不存在, 因为它们的客人是走过去自己取酒的。
不给模型喂「杯子在 (x, y, z)」这样一个我们手算出来的坐标, 而是把画面按物体分好组,让它自己决定该注意谁。 场景里同时有瓶、杯、人的时候,这个差别是决定性的。
球形外壳 + 单只大眼,可动 pan/tilt,深度相机与表情屏都装在上面。 相机会动,正是下一页那个约束的来源。
双臂 + 可动头 + 三路相机 + 移动底盘,全部本地运行。 这块板子装不下 70 亿参数的模型——技术选择被算力真实地约束着。 这不是缺点:它逼我们去找更聪明而不是更大的做法。 下一页把这句话换成了数字。
「更聪明而不是更大」不是口号。这一页是它的账单——全部为本机实测。
| 买到什么 | 靠什么 | 内存 | 每周期耗时 |
|---|---|---|---|
| 换位置 杯子放哪都行 | 深度相机 + 几何 | +84 MB 零显存 | 3.56 ms |
| 换杯子 换一只不同外观的 | 物体分组模型 | +705 MB | 52.4 ms |
| 听懂点单 「我想要高脚杯」 | 开放词表检测 开局只跑一次 | 与上共享 | 0 |
三样全部载入,加上策略本身,实测占 3.2 GB,板子上仍剩 1.8 GB。 我们不靠换更大的模型来获得泛化——泛化来自冻住的预训练加上结构先验, 而这恰好是一块 7.4 GB 的板子上唯一走得通的路。
「什么时候看客人」这个产品决策,最后是被一行数字定下来的。
head_1 σ = 0.0000 范围 [-4.308, -4.308]
head_2 σ = 0.0000 范围 [49.846, 49.846]
所有示范里,头一次都没动过。模型从来没见过「视线在移动」的画面。
制作过程中让头跟着客人转,输入就跑出了模型见过的范围。 它不会「稍微差一点」,而是面对一类它完全没学过的情况。
深度相机装在会动的头上,它的标定是「头在某个姿态时」的标定。头一动,几何全废。
两个独立的约束指向同一个答案, 所以「迎宾和递出时看人、制作时锁死」不是我们挑的方案,是唯一能成立的那个。 好的产品决策常常长这样:不是选出来的,是被排除法剩下的。
全部是实机运行、可复现的能力,不是计划。
这一页通常不会出现在 pitch 里。我们放在这里,因为它是我们真正的差异。
实测跑过,有输出 未测没跑过
没测过的推断,不许当成测过的事实讲。
跑 4 次和跑 23 次在表里长得一样,但真实成功率的 95% 上界差了四倍。 我们一律用 Clopper-Pearson 精确区间。
我们写过检出率 97.6%、抖动 6.4 mm 的检测器,数字全漂亮—— 看图才发现它锁住的是机械臂自己。从此每个感知结论都要人眼过一遍。
某篇工作报真机 59% vs 41%。我们用同一套方法算它给的原始计数: 29/49 vs 20/49,区间重叠,Fisher p = 0.106,不显著。 所以我们引用它的方法,不引用它的成功率。
时间有限,所以先分清什么是演示的底线,什么是加分项。
固定位置稳定抓起,接上已经在跑的人脸、语音、表情。 数据、模型、安全层、试跑流程全部就位,不需要新数据、不需要新代码、不需要任何标定。
成本:一次现场跑测。
两条路各买一半,互不依赖,可以只做一条:
· 换位置——深度相机定位 + 几何解算(+84 MB / 3.56 ms)
· 换杯子——物体分组进模型(0.94 MB 新参数,不用重录数据)
成本:见上一页的账单。
迎宾段已经可以演示:手臂静止,所以它不和任何东西冲突—— 机器人抬头看着你、跟你说话、表情跟着变。那已经是现有产品里没有的东西了。 2026-09-05 完成的相机标定让它的视线角度从「猜一个视场角」变成实测值, 1.5 米外的注视误差减小约 10 厘米。
现有的调酒机器人把客人当成取酒的人。
我们想做的这台,把客人当成看的人。
这个区别决定了每一个技术选择: 为什么要学习式的动作而不是录好的轨迹,为什么视线控制要按阶段切换, 为什么第一版做「推出」而不是「递到手上」。