← 报告索引
XLeRobot · 2026-09-05

不是更快的出酒机,
是会看着你调酒的调酒师

现有的调酒机器人已经把「把酒做出来」解决得很好了。 我们做的是另一件事:让一杯酒的制作过程本身值得看。

240杯/小时
Makr Shakr Veloce 的吞吐
$45,000Cecilia.ai 售价
行业区间 $30k–$100k+
0把会表演的身体
和看着客人合在一起的系统
前两项有公开出处,见第 2 页。第三项的判断依据在第 4 页逐家拆开。
01 · 市场现状

他们做得很好的那部分

先把话说清楚:现有系统不是做得差,是目标不同。 它们为吞吐量和一致性优化,并且达到了。

系统形态吞吐价格
Makr Shakr Toni双臂机器人(KUKA),158 瓶80+ 杯/小时(官方页)—
Makr Shakr Veloce双臂机器人,为速度设计240 杯/小时—
Cecilia.ai屏幕形象 + 泵 · 语音对话120 杯/小时$45,000 或 $2,000/月
Yanu封闭机柜内机械臂 · 对话 + 支付100 杯/小时—
MIXO8 / 20 蠕动泵——
TendedBar / Backbar One转盘 + 泵阀为高吞吐设计—
为什么它们能这么快

整套装置是围绕机器设计的:杯子放在固定夹具上、瓶子接在固定管路上、动作走固定轨迹。 在这个前提下,预编程既快又稳。那些流畅的演示视频恰恰证明了这一点——那是它们的强项,不是短板。

来源:makrshakr.com/toni(官方)· cecilia.ai(官方)· yanu.ai(官方)· sedonatec.com · designboom。 Toni 的 80+ 是官方页数字;Veloce 的 240 来自媒体报道,另有二手来源写 250,此处以官方口径优先、媒体数字标明来源。
02 · 缺口

但他们的「AI」在哪一层?

这是整份材料的支点,而且它有原文出处。

动作层 · 预编程

“The recipe database contains pre-programmed ratios, sequences, and pour volumes.”

AI 层 · 推荐与个性化

“machine learning tracks popular combinations, personalizes suggestions, and adjusts pours based on historical data.”

AI 用在「推荐喝什么」,不在「怎么动」。手臂本身仍然是一条录好的轨迹。

预编程轨迹

固定杯位 → 固定轨迹 → 成功

杯子挪了 5 cm → 同一条轨迹 → 抓空

学习式策略(我们)

看画面 → 算动作 → 成功

杯子挪了 5 cm → 重新看画面 → 重新算

引文出处:sedonatec.com。这是我们唯一真正的技术押注,也是这份材料里唯一需要被验证的判断。
03 · 定位

真正的空位在哪

会聊天的调酒机器人有了,会做动作的机械臂也有了。 但没有一台把两者放在同一个身体上。

有没有会表演动作的身体看不看客人
MIXO · TendedBar泵阀 / 转盘,无身体无感知
Makr Shakr Toni双臂 KUKA · 158 瓶 · 80+ 杯/时官方页无相关描述
Cecilia.ai · Yanu屏幕形象 / 机柜内,无表演动作语音对话 · 会讲笑话 · 收款
XLeRobot双臂 + 可动头 + 三路相机人脸 · 表情 · 对话

还有一条横跨所有人的共性:无论会不会聊天,它们的手臂动作全部是预编程的。 AI 在推荐层、在对话层,就是不在动作层。

矩阵位置依据各家官方页面与公开报道,出处同上页。 「官方页无相关描述」指该页面全文,不代表该产品一定没有此能力,只代表官方没有把它作为卖点。
04 · 论点

酒吧卖的从来不只是酒

如果只要液体,摇一摇预调罐更便宜。 人愿意坐在吧台前,是因为那里有人、有表演、有交流。

现有系统优化的

出酒速度

250 杯/小时。适合场馆、邮轮、机场——排队的地方。

没人优化的

被看着的那 40 秒

抬头看你、转动杯子让你看清颜色、把杯子推到你面前的那一刻。

我们的判断

交互本身就是产品

在不排队的场景里——精品酒吧、展会、门店——这一段比速度值钱。

所以我们不去和 250 杯/小时竞争。我们做那台会抬头看你的。

05 · 产品形态

一次完整的服务,是四段

注意视线这一行:它在时序里出现两次,一头一尾,中间制作时是锁死的。 这不是设计偏好,是被数据推出来的结论(第 9 页给证据)。

01 · 迎宾 · 对话

视线:转头找到客人

手臂:静止

语音点单,表情屏回应。手臂不动,所以这一段最先能演示。

02 · 制作

视线:锁死

手臂:抓取 · 倾倒 · 摇晃 · 搅拌

策略驱动的连续动作。

03 · 旋转展示

视线:锁死

手臂:转动杯身

让客人看清颜色和层次——这是现有产品里不存在的动作。

04 · 递出

视线:回到客人身上

手臂:朝客人实际所在的方向

而不是写死的取酒口坐标。

「知道客人在哪」是首尾两段的共同前提。 现有系统不需要它,因为客人必须走到取酒口去拿——而这恰恰是我们要换掉的那一步。
06 · 机器人看到的

这不是渲染图,是它真实的视野

下面的画面抽自我们已经录好的示范数据, 来自机器人头部相机的原始输出。

头部相机四帧
头部相机 · 同一集里的四个时刻:杯子在桌上 → 手臂接近 → 夹爪到位 → 合拢。 这就是策略实际看到的分辨率,除放大外未做任何修饰。
腕部相机两帧
右腕相机 · 红色的是柔顺 fin-ray 夹爪,我们自己设计并打印。左:接近中。右:杯子进入视野。
三路相机——头部一路带深度,两只手腕各一路。 来源:数据集 xlerobot-team/xlerobot-cup-grasp-20260820-0230,50 集 / 19453 帧 / 30 fps。 用 ffmpeg 从原始视频抽帧,未做裁剪或调色。
07 · 技术路线

三件和别人不一样的事

01

学出来的动作,不是录好的轨迹

视觉-语言-动作模型(VLA)直接从人类示范里学。换一只杯子、挪一个位置, 靠泛化而不是重新示教。

02

情绪与对话是一等公民

人脸检测 + 表情识别 + OLED 表情屏 + 语音,子系统已经在跑。 它不是加在最后的装饰,而是决定视线该看哪的输入。

03

面向观众的动作

旋转展示、朝人递出。这类动作在现有产品里不存在, 因为它们的客人是走过去自己取酒的。

关键技术选择

把画面按物体分组,再交给模型

不给模型喂「杯子在 (x, y, z)」这样一个我们手算出来的坐标, 而是把画面按物体分好组,让它自己决定该注意谁。 场景里同时有瓶、杯、人的时候,这个差别是决定性的。

这条路线在真正的 VLA 上有先例(Oat-VLA)。 2026-09-05 已在本机把它跑起来实测:单帧 52.4 ms,输出 7 个物体, 逐帧人工看图核对过——接近阶段能把杯子单独分出来。第 8、9 页讲算力与代价。
08 · 硬件

跑在一块巴掌大的板子上

7.4 GBJetson Orin Nano
CPU 与 GPU 共用的全部内存
3.2 GB策略 + 感知全部载入后
本地推理,不联网,仍剩 1.8 GB
低一个量级相对 $30k–100k 的
现有商用系统价格区间
自研头部

球形外壳 + 单只大眼,可动 pan/tilt,深度相机与表情屏都装在上面。 相机会动,正是下一页那个约束的来源。

双臂 + 可动头 + 三路相机 + 移动底盘,全部本地运行。 这块板子装不下 70 亿参数的模型——技术选择被算力真实地约束着。 这不是缺点:它逼我们去找更聪明而不是更大的做法。 下一页把这句话换成了数字。

全部为实测数字,可在仓库中复现。2026-09-05 于本机逐项测得。
09 · 代价

泛化要花多少钱

「更聪明而不是更大」不是口号。这一页是它的账单——全部为本机实测。

77.8%模型参数是冻结的
350 M / 450 M,泛化就来自这里
22.2%每次训练真正会动的
只有动作专家那 100 M
0.94 MB再加一维泛化
需要新增的全部参数
三个方向的泛化,各自的边际成本
买到什么靠什么内存每周期耗时
换位置
杯子放哪都行
深度相机 + 几何+84 MB
零显存
3.56 ms
换杯子
换一只不同外观的
物体分组模型+705 MB52.4 ms
听懂点单
「我想要高脚杯」
开放词表检测
开局只跑一次
与上共享0

三样全部载入,加上策略本身,实测占 3.2 GB,板子上仍剩 1.8 GB。 我们不靠换更大的模型来获得泛化——泛化来自冻住的预训练加上结构先验, 而这恰好是一块 7.4 GB 的板子上唯一走得通的路。

2026-09-05 于本机实测:逐步加载测进程内存与显存;耗时取 50 次中位数。
10 · 一个具体例子

为什么制作时视线必须锁死

「什么时候看客人」这个产品决策,最后是被一行数字定下来的。

50 集示范 · 19453 帧 · 头部两个自由度

head_1   σ = 0.0000   范围 [-4.308, -4.308]
head_2   σ = 0.0000   范围 [49.846, 49.846]

所有示范里,头一次都没动过。模型从来没见过「视线在移动」的画面。

约束一 · 数据

制作过程中让头跟着客人转,输入就跑出了模型见过的范围。 它不会「稍微差一点」,而是面对一类它完全没学过的情况。

约束二 · 几何

深度相机装在会动的头上,它的标定是「头在某个姿态时」的标定。头一动,几何全废。

两个独立的约束指向同一个答案, 所以「迎宾和递出时看人、制作时锁死」不是我们挑的方案,是唯一能成立的那个。 好的产品决策常常长这样:不是选出来的,是被排除法剩下的。

11 · 进展

已经在机器上跑起来的

全部是实机运行、可复现的能力,不是计划。

数据与采集
  • 双臂遥操作 + 数据录制,VR 和主从臂两条独立通路
  • 50 集抓杯示范,30 fps,三路相机同步
  • 深度相机原生录制打通
交互子系统
  • 人脸检测与跟随
  • 表情识别 + OLED 表情屏
  • 语音对话
安全
  • 关节级安全层:拒帧率从 96.6% 调到 0.49%
  • 软件急停 + 双总线互斥保护
  • 笛卡尔包络与逐关节步长上限
模型与流程
  • VLA 策略在本机端到端跑通:看画面 → 出动作 → 驱动实机
  • 训练与部署流程贯通,含云端 GPU 训练链路
  • 试验记录规范:判据前置、失败模式、置信区间
每一项都有对应的运行记录和数据集,在仓库中可查。
12 · 方法

我们怎么保证数字是真的

这一页通常不会出现在 pitch 里。我们放在这里,因为它是我们真正的差异。

规矩一

每条结论标证据等级

实测跑过,有输出 未测没跑过

没测过的推断,不许当成测过的事实讲。

规矩二

报区间,不报点估计

跑 4 次和跑 23 次在表里长得一样,但真实成功率的 95% 上界差了四倍。 我们一律用 Clopper-Pearson 精确区间。

规矩三

感知方案必须过人工看图

我们写过检出率 97.6%、抖动 6.4 mm 的检测器,数字全漂亮—— 看图才发现它锁住的是机械臂自己。从此每个感知结论都要人眼过一遍。

规矩四

这条规矩也用在别人的论文上

某篇工作报真机 59% vs 41%。我们用同一套方法算它给的原始计数: 29/49 vs 20/49,区间重叠,Fisher p = 0.106,不显著。 所以我们引用它的方法,不引用它的成功率。

一个说自己已经成功的机器人项目,通常只是没有认真数过。我们数过。
13 · 路线

分两轮走:先成立,再泛化

时间有限,所以先分清什么是演示的底线,什么是加分项。

第一轮 · 让它成立

固定位置稳定抓起,接上已经在跑的人脸、语音、表情。 数据、模型、安全层、试跑流程全部就位,不需要新数据、不需要新代码、不需要任何标定。

成本:一次现场跑测。

第二轮 · 让它泛化

两条路各买一半,互不依赖,可以只做一条:
· 换位置——深度相机定位 + 几何解算(+84 MB / 3.56 ms)
· 换杯子——物体分组进模型(0.94 MB 新参数,不用重录数据)

成本:见上一页的账单。

最先能看到的东西

迎宾段已经可以演示:手臂静止,所以它不和任何东西冲突—— 机器人抬头看着你、跟你说话、表情跟着变。那已经是现有产品里没有的东西了。 2026-09-05 完成的相机标定让它的视线角度从「猜一个视场角」变成实测值, 1.5 米外的注视误差减小约 10 厘米。

排序依据是依赖关系,不是难度。第二轮的两条路都不是第一轮的前提。
14 · 结尾

一句话

现有的调酒机器人把客人当成取酒的人。
我们想做的这台,把客人当成看的人。

这个区别决定了每一个技术选择: 为什么要学习式的动作而不是录好的轨迹,为什么视线控制要按阶段切换, 为什么第一版做「推出」而不是「递到手上」。

XLeRobot · 2026-09-04 · 本页所有数字均可在仓库中复现。
代码与数据:github.com/ginagina19992023/Robotic_challenge