ManiSkill：GPU 并行的大规模操作基准

可以。下面按你指定的四个维度介绍 ManiSkill。说明基于仓库 main 分支对应的任务、文档和基准代码；仓库中没有发现名为 harness 的专门模块，因此这里将其理解为“用于接入训练算法、评估算法和性能测试的实验框架/基准执行器”。

1. 任务集

ManiSkill 是一个面向机器人操作学习的 GPU 并行仿真任务集，覆盖刚体操作、移动操作、 locomotion、灵巧手和数字孪生评测等场景。任务总入口位于 docs/source/tasks/index.md。

主要任务类别

其中，桌面任务的完整列表位于 table_top_gripper/index.md，经典控制任务位于 control/index.md。

标准 RL Benchmark

RL 文档定义了两组标准基准：

• Small Set：面向计算资源有限的研究者；
• Large Set：覆盖更多机器人和任务，目前仍在持续开发和测试。

当前文档中明确列出的代表性任务包括：

• PushCube-v1
• PickCube-v1
• PegInsertionSide-v1
• PushT-v1
• HumanoidPlaceAppleInBowl-v1
• AnymalC-Reach-v1
• OpenCabinetDrawer-v1

需要注意：文档文字称 Small Set 是 8 个任务，但当前有效列出的环境 ID 数量与文档注释存在不完全一致，使用时应以具体版本的配置和运行脚本为准。相关说明见 reinforcement_learning/baselines.md。

---

2. 引擎与机器人本体

2.1 仿真引擎

ManiSkill 的核心技术栈是：

• SAPIEN 3：场景、刚体、关节、机器人和渲染接口；
• PhysX：物理仿真，支持 CPU 和 CUDA GPU 后端；
• Vulkan / SAPIEN Renderer：用于 GPU 渲染、RGB、Depth、Segmentation 和 Ray Tracing；
• PyTorch：GPU 张量、批量状态、观测、动作和随机化；
• Gymnasium：统一环境 API；
• NumPy / SciPy：CPU 侧数据处理和数学计算。

依赖和版本信息见 setup.py。核心环境基类是 BaseEnv，场景管理由 ManiSkillScene 完成。

2.2 GPU 并行机制

ManiSkill 的主要优化不是简单地启动多个独立进程，而是：

1. 将多个任务实例组织成同一个 PhysX GPU 系统中的多个 sub-scenes；
2. 每个 sub-scene 拥有自己的机器人、物体和工作空间；
3. 物理状态、关节状态、速度和控制目标以 GPU buffer 的形式批量处理；
4. 通过 gpu_apply_* 和 gpu_fetch_* 在仿真和 PyTorch 张量之间同步；
5. 通过 GPU rendering group 批量生成相机观测。

GPU 仿真原理和 reset/step 生命周期见 gpu_simulation.md。

核心差异是：

• num_envs=1 时默认使用 PhysX CPU；
• num_envs>1 时默认使用 PhysX CUDA；
• 多个环境可以在一个 GPU 进程中并行运行；
• 每个环境可以拥有不同的场景、物体和随机化结果；
• 图像观测也可以批量渲染，而不仅仅是状态仿真。

2.3 支持的机器人本体

项目支持多种机器人类型，包括：

• 单臂机械臂：Franka Panda 等；
• 双机械臂：用于协作抓取和堆叠；
• 移动操作机器人：Fetch、Stretch、RoboCasa 类移动平台；
• 四足机器人：ANYmal C、Unitree Go2；
• 人形机器人：Unitree G1、Unitree H1、MuJoCo Humanoid；
• 灵巧手：D’Claw、Allegro Hand、TriFingerPro；
• 小型真实机械臂：SO100、WidowXAI 等。

机器人通过 robot_uid 注册和加载，任务可以通过 SUPPORTED_ROBOTS 限定兼容的机器人本体。BaseEnv 会负责加载 agent、控制器、传感器和动作空间，任务本身主要实现场景、随机化、成功条件和奖励函数。

---

3. 评估指标、分数和基线

3.1 任务级评估指标

ManiSkill 的标准评估代码位于 reinforcement_learning/setup.md。

标准评估会关闭部分 reset 行为，并通过 record_metrics=True 记录完整 episode 的指标，主要包括：

• success_once：整个 episode 中是否曾经成功；
• success_at_end：episode 最后一步是否成功；
• fail_once：episode 中是否曾经失败；
• fail_at_end：episode 最后一步是否失败；
• return：整个 episode 的累计奖励；
• episode_length 或步数相关指标；
• 任务自身提供的额外评估字段。

这种设计区别于简单地统计每一步的 success rate，因为 GPU 并行环境经常会自动 reset。如果不关闭 partial reset，可能会把不同 episode 的结果混在一起。

官方推荐的评估设置是：

• reconfiguration_freq=1；
• 每次 reset 重新随机化可变物体或场景；
• ignore_terminations=True；
• 等待完整 episode 结束后再统计指标；
• 使用固定 seed；
• 同时报告 success_once、success_at_end 和 return。

3.2 奖励模式

环境通常支持以下奖励模式：

• normalized_dense：归一化稠密奖励；
• dense：稠密奖励；
• sparse：稀疏奖励；
• none：不返回奖励。

基础环境中的 sparse reward 通常由 success/fail 条件转换得到：

• 成功：+1
• 失败：-1
• 尚未成功或失败：0

任务具体的成功条件可能是：

• 物体位置与目标距离小于阈值；
• 物体被稳定放置；
• 机器人保持静止；
• 插销插入到指定深度；
• 关节或铰接物体达到目标角度；
• 机器人没有跌倒；
• 物体没有继续被夹爪抓住。

3.3 当前提供的学习基线

仓库中的 baseline 主要包括：

PPO 的默认实现使用：

• 大量并行环境；
• GPU 上的 rollout；
• GAE；
• advantage normalization；
• PPO clipping；
• 可选的 WandB/TensorBoard；
• 训练和评估环境分离；
• 评估视频和轨迹保存。

PPO 示例见 examples/baselines/ppo/ppo.py。

3.4 分数基线

仓库提供了若干公开的实验结果入口，例如：

• PPO 状态观测结果：WandB；
• PPO RGB 视觉结果：WandB；
• baseline 目录说明：examples/baselines/README.md。

不过，仓库文档并没有为每个任务统一维护一个静态的“成功率排行榜”或固定分数表。分数通常需要结合以下条件理解：

• 任务 ID；
• state 还是 RGB 观测；
• CPU 还是 GPU 仿真；
• 控制模式；
• 随机化范围；
• 使用的 demo 数量；
• episode horizon；
• 是否开启 reconfiguration；
• seed 和评估 episode 数量。

因此，不能直接把不同配置下的 success rate 进行横向比较。更合理的报告方式是：

复制Task + Observation + Algorithm + Seed + Num Envs
+ Reward Mode + Reconfiguration Setting
+ Success Once / Success at End / Return

---

4. 面向 Harness 的支持和优化

仓库没有名为 harness 的独立目录或明确 API；从代码结构看，它主要通过标准环境接口、向量化封装、统一评估协议和性能 profiling来支持外部训练 harness 或 benchmark harness。

4.1 Gymnasium 兼容

ManiSkill 默认环境是批量环境：

复制obs.shape       = (num_envs, ...)
action.shape    = (num_envs, ...)
reward.shape    = (num_envs,)
terminated.shape= (num_envs,)

外部训练框架可以通过以下 wrapper 适配：

• CPUGymWrapper：把单环境转换成普通 Gymnasium API；
• ManiSkillVectorEnv：转换为 Gymnasium VectorEnv/AsyncVectorEnv 风格；
• FlattenActionSpaceWrapper：将字典动作空间转换为连续扁平动作空间；
• RecordEpisode：保存视频和轨迹；
• FlattenRGBDObservations：整理 RGB-D 观测格式。

这使得 PPO、SAC、RLPD、BC 以及其他第三方训练框架可以复用同一套环境接口。

4.2 GPU-first 的批量训练优化

对 harness 最重要的优化包括：

• 环境并行数由 num_envs 控制；
• 观测和奖励直接保留为 GPU Tensor；
• action 可以直接从训练模型所在 GPU 传入；
• 避免每一步 CPU/GPU 往返；
• 支持批量 reset；
• 支持只 reset 部分环境；
• 支持多个环境共享一个 PhysX GPU 系统；
• 状态、动作、控制目标和传感器结果批量处理。

这类设计特别适合 rollout-heavy 的 PPO、SAC 和 model-based RL。

4.3 统一的评估 Harness 逻辑

ManiSkill 将评估流程标准化为：

1. 创建固定数量的并行评估环境；
2. 设置 reconfiguration_freq=1；
3. 禁用 partial reset；
4. 运行固定数量的 episode steps；
5. 从 final_info["episode"] 中提取完整 episode 指标；
6. 计算均值并输出。

因此，算法 harness 不需要为每个任务单独实现 success/fail 统计逻辑。

4.4 性能 Benchmark Harness

仓库还提供了独立的性能测试框架：

• mani_skill/examples/benchmarking/gpu_sim.py
• profiling.py
• plot_results.py
• scripts/maniskill.sh

它可以测量：

• env.step FPS；
• 每秒并行 step 数；
• env.step + env.reset 性能；
• 并行环境数量对吞吐的影响；
• GPU 显存；
• CPU 显存；
• 相机数量；
• 相机分辨率；
• RGB、Depth、RGB-D 等观测模式；
• CPU 仿真与 GPU 仿真差异；
• ManiSkill 与 Isaac Lab 的性能对比。

结果会保存为 CSV，并可用脚本绘制 FPS 与并行环境数之间的曲线。

4.5 对真实策略评估的优化

ManiSkill 还针对 real-to-sim 和机器人策略评估做了以下设计：

• 支持 RGB、Depth、Segmentation、Point Cloud 等视觉输入；
• 支持 ray tracing 和快速 ray tracing；
• 支持从环境状态重放轨迹；
• 支持保存 .h5 轨迹；
• 支持对不同相机数量和分辨率进行批量评测；
• 使用 GPU 并行加速真实策略的仿真评估；
• 通过统一 wrapper 记录成功率、失败率和回报。

---

总结

从这四个维度看，ManiSkill 的定位可以概括为：

1. 任务集：覆盖桌面操作、移动操作、双臂协作、四足、人形、灵巧手、绘图、数字孪生和家庭长时程任务；
2. 引擎与本体：以 SAPIEN + PhysX + PyTorch 为核心，支持 CPU/GPU 仿真、GPU 渲染和多种机器人本体；
3. 评估与基线：提供统一的 success/fail/return 指标、标准 RL 任务集、PPO/BC/ACT 等算法基线，但没有维护一个统一的静态分数排行榜；
4. Harness 支持：通过 Gymnasium、VectorEnv、GPU Tensor、统一评估 wrapper、轨迹记录和性能 profiler，降低训练框架接入成本并提高批量实验吞吐。

另外，关于代码搜索结果：仓库中没有找到明确的 harness 命名模块，因此上面对 harness 的描述是根据其向量化环境、评估封装和 benchmark 工具归纳出的功能。代码搜索结果本身可能不完整，可以继续在 GitHub 中查看：ManiSkill 代码搜索。

---