【VLA】AimBot-Pi0云端复现试验记录

type

status

date

slug

summary

1. 项目背景与挑战

本次实验的主要目的有：

工程复现：在纯命令行 Linux 环境下完整复现 AimBot-Pi0 baseline的推理流程。

算法改进：针对原模型“基于准星长度的几何深度提示”特征不明显的缺陷，提出并实现一种基于“语义色彩”的视觉增强方案。

小样本验证：设计基于小样本过拟合（Overfitting）的验证策略，低成本评估改进方案的有效性。

2. 关键工程复现与环境重构

2.1 异构渲染环境构建（EGL Backend）

问题描述：Libero 仿真环境默认依赖 X11/OpenGL 进行画面渲染，在无显示器的云服务器上直接运行时会因无法创建 OpenGL Context 而崩溃。

解决方案：重构渲染底层，强制指定 MuJoCo 使用 EGL（Embedded-System Graphics Library）作为离屏渲染后端。

关键配置代码（环境注入）：

2.2 深度依赖冲突修复

问题描述：PyTorch 2.6+ 引入了更严格的 weights_only=True 默认策略，导致加载旧版 Numpy 格式的初始状态文件 (init_states.pt) 时被拦截。同时 Robosuite v1.5+ API 变更导致环境重置失败。

解决方案：通过源码级热修复解除加载限制，并锁定 Robosuite 版本。

修复代码片段：

3. 算法改进：离散语义色彩提示 (Semantic Color Prompt)

3.1 改进动机

原 AimBot 策略通过准星（Reticle）的几何大小变化（近大远小）来提示深度。实验观察发现，在单一视角的 2D 图像中，细微的大小变化难以被 VLA 模型（PaliGemma-3B）精准捕捉，导致机器人在接近物体时往往犹豫或过早闭合夹爪。

3.2 算法实现

本实验重构了 reticle_builder.py，设计了一个基于末端距离 () 的有限状态机（FSM）。将连续的深度值映射为离散的 RGB 颜色信号，模拟“红绿灯”逻辑。

核心实现代码 (src/openpi/training/reticle_builder.py)：

4. 数据策略与训练配置

4.1 Proof of Concept (PoC) 小样本策略

鉴于全量 Libero 数据下载耗时过长，且实验目标为验证“颜色特征有效性”，采用小样本过拟合策略。

数据集：筛选 physical-intelligence/libero 前 50 个 Episode。

工程技巧：修改 LeRobot 库源码，绕过全量数据的时间戳一致性检查 (check_timestamps_sync)，实现“部分数据加载”。

定制下载脚本 (download_lite.py)：

4.2 微调超参数配置

基于 RTX 4090 (24GB VRAM) 的硬件限制，采用 LoRA 进行参数高效微调。

参数项	配置值	说明
Base Model	`pi0_fast_libero`	基于 PaliGemma-3B
Fine-tuning Method	LoRA	Rank=16, Alpha=32
Batch Size	1（2张就会会爆显存，无语qwq）	显存优化配置
Learning Rate	1e-4	Peak LR (Cosine Decay)
Max Steps	2000	针对 100 个样本的过拟合设置
Precision	bfloat16	混合精度训练

5. 实验结果与分析

5.1 第一阶段：Baseline 复现结果

在未修改模型结构的情况下，直接加载官方权重进行评估，以验证复现环境的准确性。

评估任务：libero_10 (随机抽取 10 个任务场景)

任务 ID	结果	备注
Task 0	❌ Fail	模型碰撞导致物体脱手
Task 1	✅ Success	ㅤ
Task 2	✅ Success	ㅤ
...	...	...
总计	90% 成功率	复现达标

分析：Baseline 的高成功率证明了 EGL 渲染环境和推理服务端的构建是完全正确的。

language token：put_both_the_alphabet_soup_and_the_tomato_sauce_in_the_basket

5.2 第二阶段：改进模型训练过程（进行中）

目前正在进行引入“语义色彩准星”后的微调训练。具体实验结果由于性能有限暂时搁置，留待后续补充……

6. 结论与心得

本次实验在较为受限的云端工程环境下，成功打通了从数据工程、仿真渲染到模型微调的全链路。

工程价值：证明了在无头 Linux 服务器上运行复杂的机器人视觉仿真（基于 EGL）是完全可行的，为后续的大规模并行训练提供了低成本方案。

方法论：提出的“语义色彩提示”将连续的深度回归问题转化为显著的分类感知问题。虽然目前仅在小样本上进行验证，但训练 Loss 的快速下降表明 PaliGemma 模型对这种强视觉特征具有极高的敏感度。

后续计划：在验证小样本过拟合成功后，将扩展数据下载范围至全量数据集，进行完整的一轮微调，以评估该方法在未知场景下的泛化能力。

技术tips备忘录

tumx解决ssh断连问题

Tmux 是一个终端复用器，允许在单个窗口中同时访问多个会话，解决SSH断开导致进程终止的问题。它可以新建、分离、接入和杀死会话，以及管理窗口和窗格。

可以利用tumx创建虚拟终端执行一些下载和训练任务，防止长时间挂机导致的ssh自动断连杀死终端对应进程

图像渲染的CCTV模式

所谓的 "CCTV 模式" (CCTV Mode) 实际上是指 第三人称上帝视角 (Third-Person Perspective / Spectator View) 的影像记录机制。它不同于机器人用来做决策的“眼睛”（如 Eye-in-Hand 也就是手腕相机），CCTV 模式主要是为了让人类观察员能够看清机器人的整体动作，用于评估、调试和生成演示视频。

在云端无头（Headless）环境中，其工作原理可以拆解为以下四个核心技术环节：

1. 虚拟相机的空间定义 (The Virtual Camera)

在物理仿真引擎（MuJoCo）的 XML 模型定义文件（MJCF）中，除了物理刚体，还定义了多个虚拟相机（Virtual Cameras）。

原理：这些相机本质上是仿真空间中的坐标点和朝向向量（Pose）。

CCTV 的位置：通常对应代码中的 agentview（正前方俯视）或 frontview（正前方平视）相机。这个视角是固定的，不会随机器人移动，像监控摄像头一样覆盖整个工作台，因此被称为 CCTV 模式。

2. 离屏渲染流水线 (Off-Screen Rendering Pipeline)

这是你在云端服务器上能生成视频的关键。因为服务器没有显示器，无法进行常规的 On-Screen 渲染。

原理：

EGL 上下文：利用你安装的 EGL 库，Python 代码请求 GPU 创建一个帧缓冲区对象 (Framebuffer Object, FBO)。这是一个存在于显存中的虚拟屏幕。

光栅化：MuJoCo 调用 OpenGL 指令，将 3D 场景（机器人、桌子、物体）根据 CCTV 相机的视角，“画”到这个显存里的 FBO 上，而不是画到真实的 HDMI 接口上。

像素回读 (Read Pixels)：渲染完成后，CPU 通过 glReadPixels 指令将显存中的图像数据（RGB 矩阵）读取到内存中，转为 Numpy 数组。

3. 同步采集循环 (The Capture Loop)

影像记录不是独立发生的，而是与物理仿真步长（Simulation Step）严格同步的。

原理：在 eval_libero_aimbot.py 的主循环中，逻辑如下：Python

4. 视频编码与封装 (Encoding)

原理：当一个 Episode（一次完整的任务尝试）结束后，内存中存有一个包含几百帧图像的列表（List of Numpy Arrays）。

实现：项目利用 imageio 库调用底层的 ffmpeg 编码器，将这些静态图片序列压缩编码为 H.264 格式的 MP4 视频文件。

简单来说，CCTV 模式就是利用 GPU 在后台显存中“偷偷”画出每一帧上帝视角的图，然后把这些图拼成视频。

这区别于机器人的第一人称视角（Eye-in-Hand）——后者是机器人的“眼睛”，数据会被喂给神经网络（Pi0）去计算动作；而 CCTV 视角通常只存下来给人看，不参与推理（或者作为辅助的全局输入）。

pi0使用的版本管理工具uv

uv 是由 Astral（Ruff 的开发团队）用 Rust 语言编写的 Python 包管理器和解析器。它被设计用来替代 pip、pip-tools 甚至 virtualenv。

在AimBot-Pi0复现任务中，它发挥了两个关键作用：

Python 解释器管理：它不需要预先安装 Anaconda，就可以自动下载并管理不同版本的 Python（如 Python 3.11），且不污染系统环境。

极速依赖解析：AimBot 依赖树非常深（MuJoCo -> JAX -> Flax -> Orbax ...），传统的 pip 是单线程解析，而 uv 利用 Rust 的并发优势和全局缓存，实现了毫秒级的解析。

维度	Conda (Anaconda/Miniconda)	uv (Astral)	实验场景结论
核心语言	Python (早期) / C++ (libmamba)	Rust	uv 完胜。在无头服务器上，Rust 二进制文件无需依赖，运行速度极快。
解析速度	慢。求解 SAT 问题效率低，复杂依赖可能卡住 10 分钟以上 ("Solving environment...")。	极快。通常比 pip 快 10-100 倍，比 Conda 快更多。	AimBot 依赖复杂，Conda 极易在解析 JAX 版本时死锁，uv 瞬间完成。
环境隔离	创建独立的 Conda 环境，体积大，包含大量非 Python 的二进制库。	基于标准的 Python `venv` (虚拟环境)，轻量级，遵循 PEP 标准。	uv 创建的环境更纯净，不容易出现系统库链接冲突 (GLIBC 错误)。
Python 版本	能够管理 Python 版本，但安装慢。	`uv python install` 秒级下载并链接，支持非侵入式多版本并存。	实验需要 Python 3.11，uv 一行命令即可配置完毕。
非 Python 库	强项。能安装 CUDA、FFmpeg、GCC 等系统级库。	弱项。专注于 Python 包管理。系统库需通过 `apt` 或 `wheels` 安装。	由于我们已有 root 权限 (`apt install`) 且 PyTorch 自带 CUDA 库，Conda 的优势不明显。
磁盘占用	巨大 (GB 级)，不仅存包，还存元数据缓存。	极小，利用全局内容寻址缓存 (Content-addressable cache)。	对于 4090 服务器这种昂贵的存储资源，uv 更友好。