01五大 AI 核心问题

采摘机器人面对的世界比工厂机械臂复杂十倍。果实长在不规则的枝条上，会被叶子遮挡，颜色和背景相近，风一吹位置就变。下面五个问题是 2024 至今所有发表的采摘机器人论文都在回答的——每个问题对应一种独立的技术栈。

① 果实检测与成熟度判断

表面上是个目标检测问题，YOLO 类模型在 COCO 上做了多年。但农业场景有三个非标准条件：成熟度需要 4 分类（绿/粉/红/过熟，单一阈值不够），红色果实在带红反光的绿叶背景下对比度极低（枸杞最典型），同一簇果可能有 70% 被叶子遮挡。 直接用预训练 YOLO 准确率会从 95% 掉到 60% 以下。

我们的策略是分两段：YOLO11s fine-tune 做粗定位，然后 frozen DINOv2 特征 + 单层 MLP 做精确成熟度分类。DINOv2 的 backbone 不变，只换分类头——这样 200 张标注图就够。[1]

② 3D 空间定位

视觉知道果在哪里还不够，机械臂需要毫米级的 6D 位姿 (x, y, z, roll, pitch, yaw)。RGB-D 相机（如 RealSense D405）能给立体硬件深度，但在叶子翻动、阴影斑驳、果实表面反光的情况下会出现“幽灵深度”——某些像素的深度估错几厘米，导致机械臂去够空气或撞枝。

解法是融合两路深度：硬件立体（confident 但稀疏）+ Depth Anything V2 单目神经深度（dense 但相对）。两路一致的地方才信，不一致的地方调用 NanoSAM 重新分割再投票。最终位姿误差控制在 ±5 mm。

③ 可达性与路径规划

枝条柔软，会跟机械臂之间发生“双向影响”——你伸过去枝条被撞偏，果就跟着移动。这意味着规划阶段算出来的关节轨迹在执行 100 ms 后可能就过时了。传统做法是用 MoveIt2 + FCL 做静态规划，离接近目标 10 cm 时再切到伺服控制。

我们在 MoveIt2 上加了一层异步流式规划——大脑慢规划（5 Hz），小脑接管最后 10 cm（30-50 Hz）。这中间的协调由 Real-Time Chunking 处理，下面 §02 详讲。

④ 末端柔顺控制

蓝莓表皮压力 ≥ 0.5 N 就会出现可见瘀伤，冲击能量 ≥ 120 g 直接破皮。这意味着夹爪不仅要软，抓取动作本身的速度、扭转角度、力的渐变都要被精确控制。传统 PID 控制器无法处理这种多维约束。

解法是用 Diffusion Policy CNN U-Net 学习人类示教的抓取轨迹。50-200 个遥操作 demo（用 SO-101 leader-follower，单价 $250）就能让策略学会“接近 - 包裹 - 扭转 - 撤回”四个阶段的连续动作。[2]

⑤ 跨作物泛化

每种水果都要重新收 5000 demo，团队会被数据成本拖垮。我们的设计是共享骨干 + 每作物 LoRA 适配器——番茄做主基线（5000 demo 一次性投入），枸杞/冬枣/草莓各 100-200 demo + LoRA 微调即可。详见 §III。[3]

02我们的架构原则

每条原则都有公开论文或源代码支撑——不是产品宣传，是工程依据。

03双脑分层架构

整套系统由两台计算单元组成。MVP 阶段全跑在 Jetson AGX Orin 64GB 上；量产阶段把小脑移到 RK3588 SBC（省 50% BOM），通过千兆以太网 + ROS 2 Zenoh 共享内存通信。

为什么大脑要慢？因为 Qwen2.5-VL-3B-AWQ 在 AGX Orin 上单次推理 ~300 ms（论坛实测 30 tok/s，参考 NVIDIA forum thread 345073[7]），不可能 30 Hz 跑。但大脑负责的事——读懂"摘左侧第二串成熟枸杞"、判断遮挡是否能绕过、估计采摘是否安全——这些 1-2 Hz 就够了。

为什么小脑要快？50 Hz 控制频率是机械臂闭环响应风扰、湿度变化、果实位置抖动的最低门槛。低于这个频率，外环扰动来不及补偿，会出现"过冲—回拉"的振荡，破坏果皮。

RTC 怎么让两边对得上？下文 §05 详解，简单说就是：大脑发的动作 chunk（8 步 × 6D 位姿，覆盖未来 250 ms）小脑按 30 Hz 逐步执行；中途新观测到达时，大脑下一帧发新 chunk，小脑用 ΠGDM 把新旧 chunk 平滑拼接，不出现关节速度跳变。

04感知栈

感知层 30 Hz 跑在 Jetson AGX Orin 上，端到端延迟 28 ms 一帧。整个流水线分 6 个阶段，每个阶段在论文或工程实测中都验证过 Jetson 上的 FPS。

为什么 SAM2 原版不用？SAM2 在 AGX Orin 上只有 2 FPS，跑不动 30 Hz 主循环。NVIDIA 自己开发的 NanoSAM 把 image encoder 蒸馏到 mobile ViT 量级，AGX 上可达 30 FPS。[8]

为什么 SAM 只对 top-K 候选做？YOLO 每帧检测可能输出 50 个 bbox，但机械臂一次只能摘一个。优先级排序后取最高的 3-5 个候选送 SAM 做精细分割，剩下 45 个直接丢——节约 80% 算力。

Depth Anything V2 用 Small 不用 Base 或 Large？因为我们用立体硬件深度做 ground truth，DA 只负责"补洞"（叶子重叠、阴影区域）。Small 已经够用，Base 多 50% 延迟收益不到 2% 精度。

05Real-Time Chunking

这是整套系统最精巧的部分——把异步推理框成一个图像 inpainting 问题。

RTC 的论文是 Physical Intelligence 团队 2025 年 6 月发的 Real-Time Execution of Action Chunking Flow Policies[4]。它解决的问题是：diffusion / flow policy 一次推理出未来 H=50 步动作，但实际只执行前几步就要重新推理。如果新旧 chunk 拼接的位置不平滑，关节就会抖。

RTC 的核心 trick 是把新 chunk 的去噪过程额外加一项软约束，让前 d 步（已执行）冻结，中间 (H-s) 步软约束向旧 chunk 靠近，最后 s 步自由生成。这样新旧 chunk 在中间过渡段自然衔接。

数学上是 ΠGDM (pseudo-inverse guided diffusion model) 的移植——原本用在图像 inpainting 上，现在用在动作 chunk 的"时间维度 inpainting"上。整个修正函数的核心 15 行代码（JAX 版本）：

def pinv_corrected_velocity(self, x_t, obs, y, t, inference_delay):
    # Predict clean sample x_1 via flow ODE
    def denoiser(x_t):
        v_t = self(obs[None], x_t[None], t)[0]
        return x_t + v_t * (1 - t), v_t

    x_1, vjp_fun, v_t = jax.vjp(denoiser, x_t, has_aux=True)
    weights = get_prefix_weights(inference_delay, prefix_attention_horizon,
                                  self.action_chunk_size, schedule)
    error = (y - x_1) * weights[:, None]
    pinv_correction = vjp_fun(error)[0]
    inv_r2 = (t**2 + (1 - t)**2) / ((1 - t)**2)
    c = jnp.nan_to_num((1 - t) / t, posinf=max_guidance_weight)
    guidance_weight = jnp.minimum(c * inv_r2, max_guidance_weight)
    return v_t + guidance_weight * pinv_correction

诚实的真实区间：论文 Figure 1 给的 300 ms 延迟数字是经验上限，不是理论保证。实测做到 +200 ms 延迟（约 270 ms 总）保持稳定，更高的延迟没测。RTC 的有效工作区间是3-12 Hz 大脑 + 50 Hz 控制器，不是 1 Hz VLM 桥（这个常见误读我们之前犯过）。

06小脑选型矩阵

我们在 6 种主流 policy 之间做了选型，每种都读了论文 + 代码 + recent issues。Diffusion Policy CNN U-Net 是唯一同时满足三条硬指标的选择：(1) 有完整 real-robot 代码栈，(2) ONNX 可导出量化，(3) demo 规模与团队匹配。

07通信总线

大脑和小脑通过 ROS 2 Humble + rmw_zenoh shared memory 通信，端到端延迟 5 μs（同机进程间）或 1 ms（千兆以太网跨机）。消息格式选了"语言原语 + 6D 位姿"的 JSON 形式——可调试、可日志、可审计。

{
  "instruction_zh": "摘取左侧第二串成熟枸杞",
  "target_bbox_2d": [847, 412, 923, 488],
  "target_pose_6d": [0.42, -0.18, 0.95, 1.57, 0.0, 3.14],
  "primitive": "approach | grasp | twist_pluck | retract",
  "ripeness_class": "mature",
  "ripeness_confidence": 0.85,
  "max_force_n": 0.5,
  "shake_freq_hz": 25,
  "shake_amp_mm": 8,
  "stamp_ns": 1735689600000000000,
  "ttl_ms": 500
}

为什么不用 protobuf？JSON 慢、大、但人能读。在我们这个量级（1-2 Hz 消息），可调试性 ≫ 性能。等 Y2 商用扩到 100+ 机器人时再切 protobuf 不晚。

primitive 字段的妙处：把"摘"原子化成 4 个动作 (approach / grasp / twist_pluck / retract)，每个原子动作绑定一个小脑专用策略 (4 个 Diffusion Policy heads，共享 backbone)。跨水果换作物时，primitive 序列变化（番茄是 approach→grasp→twist→retract，枸杞是 approach→shake→catch→retract），但中层接口稳定。

08数据需求曲线

每个数字都可以 trace 到论文的具体 Table 或 Figure。

09LeRobot v0.5.1

HuggingFace LeRobot 是 2026 年 4 月发布的 v0.5.1，commit 1396b9fab7。我们对每个 policy 模块、PEFT 集成、RTC 集成都做了源码审计。下面是可以直接用 vs 需要 patch的清单。

典型的训练命令（从 SO-101 收数据 → 训 Diffusion Policy → 跨水果 LoRA 微调）：

# 1. 安装 v0.5.1
$ pip install lerobot[smolvla,pi0]==0.5.1

# 2. 用 SO-101 收 200 demo（番茄基线）
$ lerobot-record \
    --robot.type=so101_follower \
    --teleop.type=so101_leader \
    --dataset.repo_id=$USER/tomato_pick_v1 \
    --dataset.num_episodes=200 \
    --dataset.fps=30

# 3. 训 Diffusion Policy CNN U-Net
$ lerobot-train \
    --dataset.repo_id=$USER/tomato_pick_v1 \
    --policy.type=diffusion \
    --policy.horizon=16 --policy.n_action_steps=8 \
    --batch_size=64 --steps=200000

# 4. 跨作物 LoRA 微调（枸杞 200 demo + 番茄 50 replay）
$ lerobot-train \
    --policy.path=$USER/dp_tomato \
    --peft.method_type=LORA --peft.r=32 \
    --dataset.repo_id=[$USER/goji,$USER/tomato] \
    --dataset.weights=[0.8,0.2] \
    --steps=20000

# 5. 导出 ONNX 给生产用（自写脚本 · 因为官方没有）
$ python scripts/custom_export_onnx.py \
    --checkpoint=$USER/dp_tomato_goji_lora \
    --output=models/goji_v1.onnx --opset=17

10跨作物迁移

跨作物迁移的关键是分清哪些层共享，哪些层 per-crop。我们的设计：

为什么 LoRA r=32 而不是 r=8 或 r=64？r=8 的表达力不够拟合一个新作物的动作分布（实验上成功率掉 10-15%），r=64 的参数增多但收益边际递减。32 是 OpenVLA paper 和 LeRobot 默认推荐值——我们没改。

为什么主基线选番茄不选枸杞？(1) Helios 仿真有 cherry tomato 原生支持，可以预训练。(2) 温室番茄全年可采，遥操作数据收集周期不受季节限制。(3) 番茄遮挡结构跟枸杞类似，可作"接近"的迁移源。

11三作物方案 · 路径合并

80% 代码复用，20% 是末端硬件 + 小脑 LoRA + 数据集。每作物路径标"仿真原生 / 自写"状态。

12仿真：能干什么 · 不能干什么

Helios plugins/plantarchitecture/include/Assets.h 物种清单（commit 1.3.72，2026.05 验证）：

"Find the Fruit" (arXiv 2505.16547) 的真相：Isaac Lab 农业相关最高调的论文，测试用的是塑料假果实——not real plants. 96% sim → 87% real-on-fake.

13硬件 BOM

三档配置覆盖从实验室验证到 Y2 量产。Qwen-VL 改用 3B-AWQ（不是 7B）[7]，RK3588 只在量产档跑蒸馏 CNN，双脑省 BOM 但需要工程一季度。

14中国对手 · 经核实

15SOTA 三件套

跨 12 篇 2024-2026 论文综述后的真实瓶颈——不是夹爪软硬度，是遮挡感知和周期时间。

三个洞察：

• 软爪硬件不再是瓶颈——损伤率已 ≈ 人类。问题在视觉遮挡 + 周期
• WSU 草莓加风扇移遮挡 58 → 74%（+15.8 pp）—— "物理介入感知"是新思路
• Rong 番茄 cut-point 88.5% → 抓取成功率 57.7% — 30 pp 流失在抓取/规划，不在感知前端

166 个月技术里程碑

P50 预算 ¥456K · 2 工程师 · 6 个月。每个里程碑都有 VERIFY 验收点。