多模态模型驱动的机械臂动态操控：从沙包抛接到具身智能实践

把一道“玩具级”的任务，做成一个让整套机器人系统吃尽苦头的项目，是什么体验？如果你问我对“动态操控”这四个字什么时候有了真正的体感，那就是在 Gemini 4 Argon 项目里——用 Gemini 4 多模态模型做视觉语言大脑，用实验室代号称 Argon 的六轴机械臂做执行器，目标是让机械臂学会自己抓起沙包、抛到空中、再伸手稳稳接住。

很多人觉得，玩沙包嘛，找个会抓取的机器人分分钟搞定。可真做起来才会发现，抓取一个静止的沙包和接住一个飞行的沙包，难度完全不是一个量级。后者需要视觉、运动规划、控制、时间同步四个模块在零点几秒内协同工作，任何一个环节慢半拍，沙包就直接砸地。这篇东西没有水分，全是实操记录：架构怎么搭、标定怎么做、提示词怎么写、轨迹怎么算、踩坑怎么排，最后附一批实测数据。适合正在做具身智能、机械臂抓取或视觉伺服的人，也适合想入门多模态模型控制机器人的朋友。

1. 为什么拿“玩沙包”当第一道考题

1.1 静态抓放与动态操控，差的是整个控制哲学

常规的机械臂实验，十个有八个是码垛或分拣。这类任务里的目标物要么不动，要么在传送带上匀速跑，机器人有充裕的时间完成识别、规划、执行三步走。控制器只要保证“起点到终点不碰障碍”，本质上是个几何问题。

动态操控完全不是一回事。沙包一旦离手，它的位置和速度每毫秒都在变，机械臂没有“停下来想想”的余地。更麻烦的是，抛接沙包要求系统把视觉、预测、运动规划、控制放到同一条时间轴上，任何一个模块的延迟都会累积成最终的接空。我常打一个比方：静态抓放是学生做卷子，可以慢慢审题；动态操控是接飞盘，审完题盘已经飞过去了。

1.2 选沙包不选别的，三个理由

第一个理由是安全。沙包质量小、外壳软、没有尖角，就算接空或者误抛，砸在机械臂或地面上都不会造成损伤。实验桌上最怕的不是算法不收敛，而是调试到一半把设备撞了，选一个容错率高的“靶子”能省掉很多麻烦。

第二个理由是感知难度恰到好处。沙包形状规则、颜色单一，识别下界不高；但它在空中飞的时候会有运动模糊、有遮挡、有光照变化，这些足够暴露视觉链路的真实短板，又不会难到让人彻底放弃。拿来当系统的“体检项目”再合适不过。

第三个理由是任务可扩展性。抛、接、传、投四个动作几乎涵盖了动态操控的主要形态。沙包跑通了，换成网球、海绵块、软体工具，改的是感知提示词和几个物理参数；但如果一开始就用易碎的物件测试，调试成本会成倍上涨。

2. 双脑分工：Gemini 4 管“看懂”，Argon 管“动作”

2.1 大模型不应该直接接管电机

项目立项时，小队里有人提议，干脆把 Gemini 4 的输出直接映射成关节速度，搞一个“端到端控制”。我投了反对票，事后证明这个反对价值连城。Gemini 4 这种多模态模型的单次推理延迟通常在 200 到 500 毫秒，而 Argon 的伺服控制周期是 1 毫秒。让一个反应需要 300 毫秒的大脑去直接控制一个需要毫秒级响应的系统，等于让门将看完慢镜头回放再去扑点球，球早进网了。

所以最终架构是清晰的三层：Gemini 4 在最高层，负责把图像理解成结构化的场景描述和操作意图；中间层是一个调度程序，负责把意图翻译成机械臂的笛卡尔目标位姿，并管理任务状态机；最底层是 Argon 自带的实时控制环，以 1kHz 周期执行轨迹跟踪。每一层都在自己擅长的尺度上干活，互不拖累。

2.2 Argon 的硬件底细与控制接口

Argon 是实验室里一台六自由度串联机械臂的代号，额定负载约 5kg，工作半径约 800mm，重复定位精度 ±0.02mm，关节带力矩限制。对抛沙包这种任务来说，负载绰绰有余，真正要关心的是最大速度和加速度——追上飞行中的沙包，需要末端执行器在零点几秒内完成一个比较大的位移。

上位机通过自定义 TCP 协议与 Argon 通信，分成位置模式、速度模式和轨迹模式三种。位置模式适合“走到某处”的宏观运动，速度模式适合追赶阶段的实时修正，轨迹模式是一组带时间戳的位姿点序列，由底层插值成连续运动。下面是我们发送目标位姿的最小示例：

def send_target_pose(host, pose, duration_s): payload = { "mode": "move_ptp", "target": { "x_mm": pose[0], "y_mm": pose[1], "z_mm": pose[2], "roll_deg": pose[3], "pitch_deg": pose[4], "yaw_deg": pose[5] }, "duration_s": duration_s, "speed_limit_percent": 80 } send_json(host, payload)

注意这里额外加了一个speed_limit_percent字段。Argon 的默认速度参数是按工业场景调的，全速去追赶飞行目标，遇到接取完成的急停时会很容易触发力矩保护，甚至把物体拍飞。所以所有动态阶段的运动指令都显式限制在额定速度的 80% 以内。

2.3 任务状态机：拿捏、上抛、等待、接住

整套行为的顶层用状态机管理，一共四个状态：

• GRASP：机械臂移动到料盘上方，识别沙包位置，夹爪闭合拿起沙包。
• THROW：按预设抛掷轨迹运动，在释放点打开夹爪。
• WAIT：沙包离手后，机械臂回到待机位，视觉系统持续跟踪沙包。
• CATCH：根据预测落点，机械臂运动到拦截点，用戽斗式掌面接住沙包。

状态转换全部由中间层调度程序控制。最容易出问题的是 WAIT 到 CATCH 的切换：如果等沙包进入相机视野再规划运动，时间一定不够。所以系统在 THROW 结束那一刻就开始用弹道模型预测落点，CATCH 的目标位姿一开始就大致定了，视觉跟踪只用来做实时修正。这也是后面所有调优的基础。

3. 视觉感知链路：从视频帧到机械臂坐标系里的沙包

3.1 相机架设与手眼标定：一步错，步步错

视觉端用了一台 RGB-D 相机，架在作业区域正上方约 1.5 米处固定不动，属于典型的“眼在外”配置。选顶装而不是臂装，是因为抛接过程中机械臂大幅运动，臂装相机的视野会剧烈晃动，对连续跟踪极不友好。

固定相机之后，第一件事是标定相机到机械臂基座的位姿变换。这一步如果做错，后面所有“模型看到的像素”和“机械臂走到的坐标”之间都会有一个系统性偏差。我们用了一块 ArUco 标定板，放在机械臂工作空间内的多个位置，配合机械臂示教位姿求解外参。标定的要点是采集点要覆盖工作空间边缘和中间，只在中心区域取点会导致外推位置偏差越来越大。

实测下来，标定残差能控制在 5mm 以内。但深度相机在 1.5 米距离上的深度噪声能达到 ±10mm，这成了整个抓接精度的最大底噪。后来在深度图上做了多帧中值滤波，噪声降到 ±4mm 左右，才勉强满足接取要求。

3.2 提示词设计：让 Gemini 4 说结构化的“人话”

Gemini 4 在这里不负责控制，只负责“看”。每次推理输入一张下采样后的 RGB 帧，要求它输出一段严格符合约定格式的 JSON。提示词经过几轮迭代，最后定型成这样的风格：

你是机械臂场景的视觉感知助手。 我会给你一张来自俯视相机的 RGB 图像，画面中可能有一个沙包。 请检测画面中的沙包，并输出： 1. 沙包中心的像素坐标 center_uv [u, v]，图像左上角为原点； 2. 沙包当前状态 state，取值 flying 或 static； 3. 检测置信度 confidence，0 到 1 之间； 4. 如果画面中没有沙包，输出空列表。 只输出 JSON，不要输出任何解释。

这里有一个关键设计：让模型输出像素坐标，而不是世界坐标，也不让它猜深度。原因很简单，多模态模型对语义理解很强，但对度量级深度估计并不靠谱，让它猜 [x, y, z] 等于在误差之上叠误差。正确做法是让模型在 RGB 里把沙包找出来，给出像素位置，然后取出相同时间戳的深度图，在那个像素位置读取深度，再通过标定矩阵换算到机械臂基座坐标系。深度和坐标这些物理量永远从传感器拿，不让语言模型参与编造。

提示：多模态模型擅长语义层面的识别，对度量级的深度和速度判断不可靠。凡是能直接从传感器读取的物理量，都不要交给语言模型去猜。

正则化输出还用了一个小技巧：请求里附带两个 few-shot 示例，一个是有沙包的，一个是空场景的。加了示例之后，模型输出格式的稳定率从大约 70% 提升到接近 100%。温度参数调到 0，最大 token 数限制在 200 以内，防止它在 JSON 后面附赠一大段说明。

{ "objects": [ { "name": "sandbag", "confidence": 0.94, "center_uv": [742, 118], "state": "flying" } ] }

3.3 延迟补偿：大脑只有 5Hz，就给它配一个预判器

Gemini 4 的推理速度决定了视觉更新频率大概只有 4 到 5 帧每秒，这对抛接任务来说远远不够。沙包从抛出到飞过整个工作空间可能只有 600 毫秒，按 5Hz 的更新率，整个飞行过程只能被采样 3 次，中间全靠猜。

解决方案是在 Gemini 4 后面接一个轻量级跟踪器。在两次大模型推理之间，用一个基于颜色直方图的跟踪器以 30 到 60Hz 的频率刷新沙包位置。Gemini 4 的慢速语义识别负责“重新确认目标并把漂移的跟踪窗口拉回来”，快速跟踪器负责“让每次控制循环都有新鲜坐标”。两者互相纠错，系统才算真正能用。

更关键的是预判。接沙包时，机械臂需要到达的不是沙包的当前位置，而是它未来某一时刻的位置。我们把跟踪到的连续几帧 3D 坐标丢进一个常加速度模型，配合沙包离手时刻的速度初值，预测它到达接取高度平面的位置和时间。这一步直接决定了状态机什么时候从 WAIT 切到 CATCH。

4. 投掷与接取：动态操控的轨迹规划细节

4.1 投掷其实是个逆问题：从落点反推释放速度

很多人以为抛沙包的难点在“怎么用力甩胳膊”，实际上对我们来说，难点在于一个逆问题：已知想要的水平距离和接取点高度，反推机械臂在释放瞬间需要给沙包的初速度。高中物理就能解决，但工程实现上有几个坑。

释放点高度、接取点高度和水平距离一旦确定，给定一个释放仰角，就能算出需要的释放速度大小：

import math G = 9.81 # m/s^2 def release_speed(d, h, theta_deg): """ d: 水平距离，单位 m h: 接取点相对释放点的高度差，单位 m，向上为正 theta_deg: 释放仰角，单位 deg 返回释放速度 (m/s)，若该角度物理不可达返回 None """ theta = math.radians(theta_deg) # 由 d = v*cos(theta)*t 和 h = v*sin(theta)*t - 0.5*g*t^2 # 消去 t 得到 v^2 = g*d^2 / (2*cos(theta)^2*(d*tan(theta)-h)) denom = 2.0 * (math.cos(theta) ** 2) * (d * math.tan(theta) - h) if denom <= 0: return None return math.sqrt(G * d * d / denom) speed = release_speed(d=0.5, h=0.15, theta_deg=60) print(speed) # 约为 2.6 m/s

算出来的速度是理论值，实际还要做一次“手感标定”。因为夹爪打开瞬间会有摩擦和挤压，实际初速和理论值总有一定偏差。我们的做法是先按理论值设置抛掷轨迹，试抛十次，测量实际落点，拟合一个速度修正系数，再写进参数表。过程看着土，但比任何理论模型都可靠。

抛掷轨迹本身也有讲究。直接用插值让夹爪从低位走到高位再急停，沙包会在急停瞬间被甩出去，但释放点很难控制。我们改用一段带恒速末段的轨迹：前半段加速，后半段保持恒定速度，在恒速段的某个确定时刻打开夹爪。这样释放点对时间误差的敏感度最低。

4.2 接取的关键不是“抓得准”，而是“兜得稳”

第一版接取方案用的是两指平行夹爪，目标是沙包飞到掌心高度时准确捏住。结果惨不忍睹：成功率不到三成，而且大部分失败不是没接住，而是捏住的一瞬间沙包从指缝弹飞。原因也好理解，两指夹爪接触面小，沙包带着动量撞上来，接触瞬间能量没被吸收，只能变成反弹。

后来换了思路，把末端执行器换成 3D 打印的戽斗式掌面：一个浅碗形状的罩子，内壁贴了一层 5mm 软质泡棉。接取动作不再是“捏”，而是“兜”——机械臂把碗口对准沙包下落方向，让沙包落入碗内被泡棉吸收动能。这个改动让成功率直接翻倍。

另一个关键细节是拦截点选择：不要在沙包刚飞出来的位置接，也不要在落地前最后一刻接，最好在抛物线顶端附近接。那里垂直速度最小，对时间和位置的误差容忍度最大。碗式掌面其实不需要真正的“闭合”，只要在沙包进碗前把碗面摆正就行，真正的约束在姿态而不是夹爪开合。

4.3 关节限位与速度切换：别让机械臂“打到自己”

动态追赶最容易翻车的不是路径，而是机械臂自己撞自己。Argon 是六轴串联结构，追赶沙包时如果末端目标点落在工作空间边缘，中间关节很容易逼近奇异位形，关节瞬时加速度会爆表。

对策是给所有动态目标位姿加“可达性检查”：目标点必须落在基座前方一个预先圈定的长方体工作区里，末端姿态的俯仰角保持在一个安全区间内。如果预测拦截点落在工作区外，程序会主动放弃这次接取，把机械臂拉回待机位。看起来有点怂，但比撞坏设备划算得多。

速度切换上也有一个实用技巧：追赶阶段用 80% 额定速度，距目标点 150mm 范围内降速到 20%，再做小步长位置修正逼近。高速和低速之间用梯形速度规划过渡，避免加速度阶跃把整个基座带得发抖。

5. 实测与排障：从频频脱线到稳定接住的完整过程

5.1 误检风波：模型把桌子腿当成了沙包

第一次联调，场景里的沙包是橙色，桌腿是深棕色，我本以为识别不会有任何问题。结果 Gemini 4 时不时把一个深棕色块当沙包报出来，置信度在 0.5 到 0.7 之间摇摆。查日志发现，它被桌腿在俯视视角下产生的阴影骗了，颜色特征和沙包在某个光照条件下高度相似。

处理办法有三步。第一，提示词里明确加了一句“仅在画面中央 60% 区域内寻找沙包，忽略画面边缘”，把可能干扰的区域直接排除。第二，置信度设 0.8 阈值，低于阈值一律不采信。第三，也是最有用的：让轻量级跟踪器当仲裁者，大模型检测结果如果和跟踪器当前窗口距离超过 50 像素，就认为这次检测不可靠，保留跟踪器结果。这一套下来，误检率从肉眼可感知降到测试中几乎不存在。

5.2 接住又弹飞：夹爪方案的两次翻车

前面提到第一版两指夹爪成功率不到三成。我们还试过第二版：两指夹爪加硅胶软垫。结果比裸金属指面好一些，但遇到抛偏的情况，沙包撞到单侧指面还是会弹走。真正解决问题的还是戽斗式掌面加泡棉，同一套系统突然就能接住了。

注意：调试动态操控里最隐蔽的“偶发故障”，大概率不是随机噪声，而是一条你还没找到的数据流不同步。先检查时间戳，再怀疑硬件。

这个过程给我最大的教训是：动态接取的接触模型和静态抓取完全是两套逻辑。静态抓取追求接触面积大、位姿精确；动态接取追求冲击能量被缓冲、允许滑移。设计末端执行器之前，先想清楚目标物撞上来那一刻会发生什么，比调无数版控制参数都重要。

5.3 标定漂移：所有位置都偏了 3 厘米

项目进行到一半，有一阵子所有动作都表现得“很稳但就是接不到”。我们把每轮抛接的落点记录摊开，发现机械臂的接取点全部朝一个方向偏移了约 30mm，姿态没变。最初怀疑模型预测不准，后来在固定位置放了一个已知坐标的标记物，让系统检测标记物坐标和真值对比，才发现是手眼标定矩阵漂了。

原因是一次抛接失败时沙包飞出去砸到了相机支架，把相机角度碰歪了几度。俯视相机角度变化 2 度，1.5 米处的位置误差就会放大到几十毫米。从那以后，每次实验前都会跑一个快速校验：检测工作区角落固定 ArUco 码，如果位置偏差超过 5mm，就自动触发重新标定。这个 5mm 阈值成了整个系统稳定性的第一道防线。

5.4 最终数据与复盘

三轮完整测试的数据是这样：

注意“进入接取范围”和“成功接住”是两回事。进入范围说明预测对了，成功接住说明从预测到接触的整套动作都对上了。第三批 27 次进入范围中有 22 次接住，其余 5 次里，2 次是泡棉上滑出碗沿，3 次是闭合时机差了一点。如果把“兜住”换成真正的“夹稳并保持锁定”，还需要在掌面设计和抓握时序上再花一轮功夫。

6. 这套系统的迁移空间与给后来者的建议

6.1 换任务：从沙包到工具递送

很多朋友听到“教机器人玩沙包”第一反应是玩具项目，但我可以负责任地说，这套架构换一层皮就是一套很实用的协作机器人应用。

比如“人机工具递送”：机器人从桌上拿起一把螺丝刀，递给对面工位上的人。感知目标从“飞行中的沙包”变成“等待的手”，状态机从“抛—接”变成“移动—悬停—释放”，底层几乎不用动。再比如“空中交接”：两台机械臂之间传递易碎品或软体物件，核心就是截断时刻的时间对齐，和沙包接取是同一套数学。

6.2 换模型与换机器人的工程可移植性

架构上我们刻意做了一个抽象：把多模态模型封装成“感知服务”，输入是图像，输出是约定格式的 JSON；把机械臂封装成“运动服务”，输入是目标位姿和速度限制，输出是执行结果。两个服务接口都和数据格式绑定，不绑定具体品牌。

这意味着换掉 Gemini 4 换别的多模态模型，只需要改提示词和输出解析函数；换掉 Argon 换别的机械臂，只需要重写运动服务内部的协议转换。项目里我们实际验证过，把视觉服务从 Gemini 4 切到另一个开源多模态模型，从改代码到跑通只花了一个下午。模型能力差异会体现在误检率和格式稳定性上，但只要外围架构干净，替换成本就很低。

6.3 给后来者的几条实操建议

最后把几条压箱底的经验列出来，每一条都是用翻车换来的：

• 先做静态再做动态。第一周只让机械臂识别并拾取桌面上的沙包，确认坐标换算和抓取没问题，再上抛接。直接上动态任务会让排障失去锚点。
• 全链路打时间戳。图像帧、Gemini 响应、运动指令、夹爪开合信号，全部落到统一时钟上。排障时没有时间戳就像没有案发现场监控。
• 物理量不要让模型猜。深度、速度、加速度一律从传感器或运动学计算拿，语言模型只做语义层的识别和理解。
• 每个动态运动都设速度上限。80% 额定速度是调试期的黄金值，追求极限速度是在给后面的调试埋雷。
• 把每轮实验的原始日志存下来。图像、提示词、响应、位姿、结果，一整套打包归档。你一定会回头翻它们的。

项目做到最后，我自己反复回想的一个画面是：夜里十一点，我把第三批失败的日志平铺在屏幕上，发现每一次“接住又滑出”的记录里，夹爪闭合指令都比沙包进碗时间早了约 120 毫秒。找到这个时间差之前，我们试过调泡棉厚度、改碗口倾角、甚至调整夹爪速度，全都收效甚微。问题根本不在硬件，而在两条数据流的时钟没有对齐。后来把视觉时间戳和运动时间戳统一到同一个基准，这个“偶发故障”就再也没出现过。

如果你也在做类似的视觉—运动闭环项目，建议从第一天就把这句话贴在工作台上：先对齐时间，再谈精度。时间对了，剩下的事情都会变得顺理成章。