BEHAVIOR-1K：千种家务活动的符号化定义

What this is

BEHAVIOR-1K 是一个面向具身智能（Embodied AI）的综合性仿真基准与开发平台：它把日常家庭任务、符号化任务定义、真实感场景、机器人控制、物理仿真和统一评估组合在一起，用于训练和比较能够完成长时程、多步骤家庭操作的机器人策略。

需要区分两个范围：

• 完整 BEHAVIOR-1K 基准：约 1,000 个家庭活动，每个任务可通过 BDDL 定义目标状态。
• 2026 Challenge 子集：100 个 full-length household tasks、7 个场景、20,000 条人类遥操作示范，作为当前挑战和模型评测入口。

Stack

• 语言： Python 为主，也包含 Shell、HTML、PowerShell、JavaScript、Dockerfile
• 仿真引擎： NVIDIA Isaac Sim / Omniverse Kit 107.3.1
• 核心平台： OmniGibson
• 任务与本体： BDDL3（Behavior Domain Definition Language）
• 接口： Gymnasium 环境接口、Torch 后端、WebSocket policy serving
• 主要组件： PyTorch、Gymnasium、OmegaConf、NetworkX、DVC、MkDocs

---

How it's organized

复制OmniGibson/
  omnigibson/       Isaac Sim 仿真封装、场景、机器人、传感器、控制器、任务和评估
bddl3/
  bddl/             BDDL 解析、任务定义、谓词、条件评估和对象本体
datasets/            数据集和任务实例相关内容
docs/                项目文档、Challenge 规则、数据格式、基线和排行榜
joylo/               GELLO/JoyLo 遥操作和数据采集支持
eval-jobqueue/       批量评估任务基础设施
asset_pipeline/     3D 资产从 3ds Max 到 USD 的转换和校验
knowledgebase/      BDDL 对象、场景、synset 和能力属性的可视化知识库
docker/              Docker 和部署相关配置

整体运行链路：

1. BDDL 定义任务涉及的对象、初始状态和目标逻辑；
2. OmniGibson 将 BDDL 任务实例加载到 Isaac Sim 场景中；
3. Environment 根据配置加载 scene、robot、objects、task 和 sensors；
4. policy 接收 RGB/depth/proprioception 等观测并输出机器人动作；
5. evaluator 驱动仿真 rollout，并通过 BDDL goal predicates 和效率指标计算分数。

---

一、任务集：从 1,000 个活动到 Challenge 的 100 个任务

1. 完整任务集的核心形式

BEHAVIOR 的任务不是简单的“把 A 移到 B”，而是以 BDDL activity definition 表达：

复制(:objects ...)   # 任务中的对象及其类别
(:init ...)      # 初始空间关系和状态
(:goal ...)      # 目标逻辑条件

例如，任务可以要求：

• 物体放入容器；
• 清除污渍；
• 把物体放在指定表面；
• 打开门、抽屉或盖子；
• 加热、冷冻、切割、喷洒、倾倒；
• 多个目标条件同时满足。

BDDL 的重要特点是：它描述的是最终必须满足的状态逻辑，而不是规定机器人必须采用哪一条动作序列。因此 IL、RL、TAMP、LLM-planning 等不同方法都可以用同一个任务定义进行评测。

相关实现主要位于：

• bddl3/bddl/activity_definitions/
• bddl3/bddl/activity.py
• bddl3/bddl/condition_evaluation.py
• OmniGibson/omnigibson/tasks/

BDDL 文档明确说明，一个 activity definition 包含 domain、objects、initial condition 和 goal condition；仿真器需要实现对应谓词的 backend 和 object states，参见 BDDL README 和 BDDL activity definition 文档。

2. 任务难点：长时程、状态转换和多技能组合

2026 Challenge 数据页统计为：

• 100 个任务
• 20,000 条人类遥操作轨迹
• 270,600 个技能片段
• 31 种不同技能
• 平均每条轨迹约 27.06 个技能
• 平均轨迹时长约 351.54 秒

技能包括：

• attach
• chop
• open door
• open drawer
• pick up from
• place in
• place on
• pour
• press
• spray
• sweep surface
• turn on switch
• wipe hard

因此，BEHAVIOR 更接近“完成一项完整家务”，而不是单一 manipulation primitive。任务可能同时要求导航、双臂操作、抓取、开关、容器关系、粒子/液体状态变化和长时程规划。

数据格式和统计见 docs/challenge/dataset.md。

3. 任务实例化和随机化

任务被拆成三层标识：

复制activity_name
activity_definition_id
activity_instance_id

例如：

复制turning_on_radio
0
3

分别表示任务类型、任务定义版本和一个具体场景实例。

项目支持：

• 预采样任务实例；
• 在线 object sampling；
• 通过 scene、synset、category whitelist/blacklist 生成新的 task instances；
• 对相关物体和初始状态做随机化；
• 在 Challenge 中使用 public test / hidden test instance split。

任务采样流程由：

• autogenerate_task_custom_list_template.py
• sample_b1k_tasks.py
• multiply_b1k_tasks.py

等脚本完成。文档建议在可复现实验中使用 online_object_sampling=False，直接加载已经采样好的任务实例，见 Task Sampling 和 Behavior Tasks。

---

二、引擎 & 本体：OmniGibson + Isaac Sim + BDDL Object Taxonomy

1. OmniGibson：仿真和 Gymnasium 环境层

OmniGibson 是建立在 NVIDIA Omniverse/Isaac Sim 上的物理仿真平台，负责：

• 真实感场景和对象加载；
• PhysX 物理模拟；
• 移动操作机器人；
• 双臂、底盘、躯干和夹爪控制；
• RGB/depth/segmentation 等传感器；
• object states；
• 液体、颗粒、灰尘等 particle/material systems；
• transition rules；
• Gymnasium-compatible 环境；
• 向量化环境和 RL 训练接口。

核心入口是 omnigibson/envs/env_base.py。

Environment 的初始化逻辑大致是：

复制config
  -> scene
  -> objects
  -> robots
  -> task
  -> external sensors
  -> observation/action spaces
  -> reset

环境通过 registry 创建 scene、task、robot 和 object，允许使用 YAML/JSON 配置动态组合。观测可以来自：

• robot proprioception；
• task observation；
• external sensors；
• RGB/depth vision sensors；
• scene graph。

动作既可以是按机器人拆分的 dictionary，也可以被 flatten 成单一向量。

2. Simulator：Isaac Sim 的统一生命周期封装

simulator.py 封装了 Isaac Sim 的启动和运行生命周期：

• Isaac Sim App 启动；
• headless / GUI / remote streaming；
• physics/rendering/simulation timestep 管理；
• scene import；
• physics handle 刷新；
• object state 更新；
• controller stepping；
• contact sensor 数据；
• transition rule 更新；
• simulation save/restore；
• callback 管理；
• profiling；
• USD-Fabric synchronization。

它还专门处理 Isaac Sim/Omniverse 的一些工程问题，例如：

• 只允许一个底层 Simulator 实例；
• 在 object 增删后刷新 PhysX simulation view；
• 对 GPU dynamics、Fabric、GPU contact capacity 做配置；
• 将 USD 修改统一放到 editing_usd() context 中；
• 通过 USD edit guard 检测未同步的 USD 修改；
• 在仿真步骤前后分别执行 controller 和 state 更新；
• 在 headless 模式下避免不必要的渲染。

这使得上层任务代码不必直接处理 Isaac Sim 的底层生命周期。

3. BDDL：符号任务逻辑和仿真状态之间的桥梁

BDDL 不是传统意义上的 planner，而是一个任务表达和目标评估层。一个新的 simulator 如果要支持 BEHAVIOR，需要：

1. 实现 BDDLBackend；
2. 将 BDDL predicate 映射到 simulator-specific predicate class；
3. 为 predicates 提供对应的 object states；
4. 让仿真状态能够被 BDDL evaluator 查询。

例如：

• cooked
• ontop
• inside
• open
• stained
• covered
• touching

BDDL 的 backend 设计使任务定义尽量与具体仿真器解耦。BDDL 文档强调，新 simulator 必须实现每个任务谓词对应的 simulated object state，见 BDDL README 的新模拟器支持部分。

4. Object Taxonomy：WordNet-style synset 本体

对象本体由 bddl3/bddl/object_taxonomy.py 管理。

每个 synset 节点包含：

• concrete object categories；
• substances；
• abilities；
• parent-child hierarchy；
• 资产和语义关系。

例如，一个抽象 synset 可以对应多个具体 3D object categories；同一个类别还可以带有：

• cookable
• openable
• sliceable
• fillable
• toggleable
• particleSource
• particleSink
• heatSource
• coldSource

代码使用 NetworkX 图结构维护层级关系，支持：

• category → synset 查询；
• substance → synset 查询；
• 获取 parent/children/ancestors/descendants；
• 查询某个 synset 的所有叶子类别；
• 查询 object abilities；
• 根据 abilities 推导所需 meta links。

这套本体连接了三层：

复制BDDL synset
  -> object taxonomy / abilities
  -> concrete asset category
  -> USD object in OmniGibson

因此，BEHAVIOR 的任务不是只对某个固定 mesh 编写，而是可以针对一类具有相同语义能力的物体进行定义。

---

三、评估指标和分数基线

1. 主指标：Q-score，而不是单纯成功率

当前 2026 Challenge 的主排名指标是 task success score / Q-score。

如果任务的目标包含多个 BDDL predicates，那么最终分数会计算任务结束时满足的目标条件比例。也就是说：

复制Q = 已满足的目标谓词数量 / 目标谓词总数

如果所有目标都满足，则：

复制Q = 1.0

TaskMetric 的实现还考虑了初始状态：如果某个 predicate 一开始已经为真，不会把它简单地当作 policy 完成的新增目标。

实现见 OmniGibson/omnigibson/metrics/task_metric.py。

这种设计的价值是：

• 允许 partial credit；
• 鼓励策略完成部分任务，而不是全成全败；
• 对长时程、多目标任务更平滑；
• 比 binary success rate 更适合比较不同策略的中间进展。

task_sr 仍然会计算，但它是“Q-score 等于 1 的 rollout 比例”，不是唯一主指标。

2. 次级指标：时间和运动效率

评估还会记录：

模拟时间

• simulator_steps
• simulator_time
• normalized_time

其中 normalized time 以人类示范统计作为参考。

底盘移动距离

• base_distance_score

用于衡量机器人是否在场景中进行了不必要的移动或绕路。

双手/末端执行器位移

• left_distance_score
• right_distance_score

用于衡量操作过程中的运动效率。

Challenge 文档说明，时间、base distance 和 end-effector displacement 等效率指标会用人类示范统计进行归一化；当 Q-score 相同时，这些指标用于 tie-break。

详见 Evaluation and Rules。

3. 分数聚合方式

score_utils.py 会进行多级聚合：

复制per rollout
  -> per task / instance average
  -> all tasks average
  -> overall q_score / task_sr / efficiency scores

它最终输出：

复制{
  "q_score": ...,
  "task_sr": ...,
  "time_score": ...,
  "base_distance_score": ...,
  "left_distance_score": ...,
  "right_distance_score": ...
}

相关实现见 OmniGibson/omnigibson/eval/utils/score_utils.py。

4. 当前提供的 baseline

2026 Challenge baseline

当前文档提供两个主要 baseline：

• π0.5
• 基于 challenge fork 的 OpenPI；
• 提供 fine-tuned checkpoint；
• 作为视觉-语言-动作模型路线的参考。
• GR00T N1.7
• 基于 challenge fork 的 Isaac-GR00T；
• 提供 fine-tuned checkpoint；
• 用于验证从数据加载、训练、serving 到评估提交的完整链路。

文档中目前提供的 checkpoint 示例任务是：

复制turning_on_radio

参见 docs/challenge/baselines.md。

2025 Challenge / 历史 baseline

历史挑战还提供过：

• ACT
• Diffusion Policy
• BC-RNN
• WB-VIMA
• OpenVLA
• π0

这些方法的意义主要是给出不同类型的 imitation learning 和 pretrained VLA 对照。

需要注意：仓库中的 baselines.md 主要给出了方法、训练/评估流程和 checkpoint，并没有形成一个稳定的“所有 baseline 的统一分数表”。因此，不能仅根据 baseline 名称推断一个固定数值分数。历史提交分数则以 docs/challenge_submissions/*.json 为准，并且会随 test set、tag、评估配置和修复版本变化。

5. 评估输入限制

2026 Challenge 当前要求 policy 在评估时只能使用 robot onboard observations：

• RGB
• depth
• proprioception

不能使用：

• ground-truth segmentation；
• object state；
• target object pose；
• full-scene point cloud；
• robot global pose；
• 其他 simulator-only privileged information。

但是这些 privileged information 可以在训练阶段使用，只要评估阶段不使用。

这使得 benchmark 更接近真实机器人部署，而不是单纯利用仿真器内部状态。

---

四、支持 harness 做了什么优化？

这里的 harness 可以理解为“统一的策略评测/运行 harness”：它负责把外部 policy server 与 OmniGibson 仿真、任务实例、机器人配置、观测 wrapper、视频录制和指标计算接起来。

当前实现主要集中在：

• OmniGibson/omnigibson/eval/eval.py
• OmniGibson/omnigibson/eval/evaluator.py
• OmniGibson/omnigibson/eval/wrappers/
• OmniGibson/omnigibson/eval/utils/
• OmniGibson/omnigibson/eval/policies.py

1. 把 simulator 和 policy 解耦：WebSocket policy serving

评估脚本并不要求把模型直接写进 OmniGibson，而是允许：

复制OmniGibson evaluator
        |
        | WebSocket
        v
policy server

WebsocketClientPolicy 负责：

• 等待 policy server 的 /healthz；
• 建立 WebSocket 连接；
• 发送 observation；
• 接收 action；
• 支持 API key；
• 支持 ws / wss；
• 配置 ping/pong 和超时；
• 处理连接失败和重试；
• 通过 msgpack 传输数据。

这带来几个工程收益：

• policy 可以在独立 Docker 容器中运行；
• evaluator 和模型依赖隔离；
• 可接 OpenPI、GR00T 或自定义服务；
• 可以在不同机器或 GPU 上分别部署 simulator 和 policy；
• 提交时不需要把 Isaac Sim 装进模型容器。

这也是 Challenge 推荐 Docker submission 的基础。

2. action chunk / action reuse 优化

WebsocketPolicy.forward() 支持检查 observation 中的：

复制need_new_action

当 need_new_action=False 且已经有 last_action 时，直接复用上一次 action，而不是再次请求模型。

这是一种简单的 action-chunk / action reuse 机制，主要用于：

• 减少 policy server 请求次数；
• 降低 WebSocket 往返开销；
• 支持模型一次输出动作块、环境分步消费；
• 减少高分辨率视觉输入下的推理压力。

对于长时程任务和大模型，这一点很重要，因为瓶颈往往不仅是 Isaac Sim，也包括每一步的视觉模型推理。

3. headless 和多种 policy backend

eval.py 同时支持：

复制--policy websocket
--policy local

其中：

• websocket：连接真实 policy server；
• local：主要用于 smoke test，默认输出 zero action。

同时默认：

复制--headless

这样可以：

• 避免依赖 DISPLAY；
• 减少 GUI 和窗口刷新开销；
• 方便 Docker、服务器和批量评测；
• 提高评估环境的一致性。

4. partial scene loading

评估配置中默认使用：

复制"partial_scene_load": True

这意味着评测不必每次都加载完整的大场景，而可以只加载与当前任务相关的场景部分。

优化效果包括：

• 减少场景启动时间；
• 减少 GPU/CPU 内存占用；
• 减少无关物体对物理仿真的影响；
• 便于批量运行多个 task instances；
• 更适合 challenge 的大量 rollout 评估。

这项优化对 BEHAVIOR 尤其关键，因为完整 household scene 资产规模大，场景加载本身可能需要数分钟。

5. 统一 robot config 和 camera role

评估脚本支持：

复制--robot-config omnigibson/eval/r1pro.yaml

机器人配置集中描述：

• robot model/name；
• controller；
• proprioception；
• sensors；
• camera；
• reset pose；
• evaluation camera roles；
• action normalization。

默认 R1Pro 配置显式定义：

复制left_wrist
right_wrist
head

这些 camera roles 被 wrapper 和 video writer 使用，从而避免 policy、evaluator 和视频录制之间出现传感器命名不一致。

这也让自定义机器人成为可能：只要机器人是 OmniGibson 支持的模型，并提供符合要求的 robot config，就可以参加评估。

6. 观测 wrapper 标准化

Challenge harness 通过 wrapper 将仿真器内部丰富的 observation 统一限制为 policy 可见的输入。

对于标准赛道，最终暴露给 policy 的主要是：

复制RGB + depth + proprioception

而 simulator 内部仍然可以有：

• object states；
• segmentation；
• scene graph；
• global poses；
• BDDL predicate states。

但这些信息不会直接传递给 policy。

这使得训练阶段可以使用更丰富的监督，而评估阶段保持严格的 observation contract。

7. 自动生成标准化评估输出

每个 rollout 会生成：

• 一个 metrics JSON；
• 一个可选 MP4 视频；
• task、instance、rollout ID；
• success；
• Q-score；
• simulator time；
• agent distance；
• normalized distance。

典型流程是：

复制python -m omnigibson.eval.eval \
  --task-name turning_on_radio \
  --host 127.0.0.1 \
  --port 8000 \
  --instance-indices 0 \
  --num-rollouts 1 \
  --output-dir outputs/b1k_eval \
  --write-video

eval.py 会自动：

1. 解析 task 和 instance；
2. 加载 robot config；
3. 创建 WebSocket 或 local policy；
4. 启动 evaluator；
5. reset 并加载 task instance；
6. 执行 rollout；
7. 计算 metrics；
8. 保存 JSON；
9. 可选保存 MP4；
10. 输出汇总 success/Q-score。

这相当于把“模型输出动作”到“最终可提交分数”的流程标准化了。

8. 评估稳定性和复现性修复

仓库的 Challenge updates 记录了不少针对 harness 的优化和 bug fix，包括：

• 修复 evaluator 中的机器人初始 pose 不一致；
• 修复 gripper joint range；
• 修复 partial credit assignment；
• 修复多 worker sharding；
• 修复 action chunk indexing；
• 增加 connection-loss handling；
• 增加 max_steps；
• 增加 partial_scene_load；
• 修复 RGBD wrapper 改分辨率后 simulator handle 没有刷新；
• 修复 challenge dataset 中的 velocity observation；
• 固定 task scene instance 加载逻辑；
• 提供 score_utils 做提交前分数校验；
• 提供 HeavyRobotWrapper，将 robot base mass 调整到数据采集时的质量，减小 data collection 和 policy rollout 之间的 physics gap。

其中，HeavyRobotWrapper 和 score_utils 是特别值得注意的两个改进：

• HeavyRobotWrapper： 解决训练数据中的机器人动力学与评估仿真不一致问题；
• score_utils： 允许提交前检查输出 JSON、聚合 Q-score 和效率指标，避免因为格式或聚合错误导致提交失败。

---

总结

可以把 BEHAVIOR-1K 概括成下面这条链：

复制1,000 个 BDDL 家庭活动
        ↓
对象本体、能力属性和 3D 资产
        ↓
OmniGibson + Isaac Sim 物理仿真
        ↓
Gymnasium / RGBD / proprioception 环境
        ↓
WebSocket policy harness
        ↓
BDDL partial-credit Q-score + 时间/距离效率评估

它的核心价值不只是“提供一个仿真器”，而是提供了一个相对完整的 embodied AI research loop：

• 任务集负责定义长时程家庭行为；
• BDDL 和 object taxonomy负责定义语义、本体和目标状态；
• OmniGibson负责真实感物理世界和机器人交互；
• evaluation harness负责连接任意 policy、统一 rollout、记录视频和计算分数；
• baselines 与 demonstration dataset负责降低研究入口门槛。

补充说明：代码搜索结果有返回条数限制，因此关于 harness 的检索可能不是完整列表；可以在 GitHub 中继续查看全部匹配结果：BEHAVIOR-1K harness code search。

---