1. 任务定义与观测边界

1.1 先把任务名称对齐

ATEC2026 的公开仿真仓库把多个能力放在同一个挑战框架里。最容易出现的错误，是看到“机器狗、物体、相机”就把所有任务都叫成捡垃圾。实际工作时必须先确认任务 ID、机器人构型和评分器。

因此，“场景里没有垃圾”有两种可能：一是加载了 Task D，二是加载了 Task B 但当前视角或相机没有对准目标区域。不能只凭一个黑屏或空场景截图判断任务失败。

1.2 Task B 与 Task D 的控制结构不同

垃圾收集是长时序的 loco-manipulation：

textRGB-D 感知
  -> 目标类别、深度和世界坐标
  -> 选择最近目标
  -> 底盘接近与姿态调整
  -> 机械臂 / 夹爪抓取或推动
  -> 搬运到垃圾桶
  -> 释放、确认入桶、更新进度

推箱越障则更接近“带接触事件的 locomotion”：

text观察坑、箱体和平台
  -> 接近箱体
  -> 保持航向并建立稳定接触
  -> 推箱或侧推改变环境
  -> 通过坑和平台
  -> 到达终点并根据评分阶段切换策略

两者都可能使用 RGB-D 和 LiDAR，但评分事件、动作重点和失败恢复完全不同。Task A 的走路 policy 不能直接变成 Task B 的抓取控制器；Task D 的推箱状态机也不能直接解决目标识别和垃圾投放。

1.3 官方观测边界

官方公开仓库对 A/B/D 的观测组织主要包含：

• 机器人本体状态和关节状态；
• LiDAR height scan 或等价的地形高度观测；
• 头部 RGB-D 相机；
• 末端 RGB-D 相机；
• 任务需要的命令、历史动作或阶段信息。

在正式迁移代码前，应以当前官方环境注册、任务配置和提交接口为准，逐项核对：

textobservation keys
observation shape
camera name
image resolution
depth scale
action dimension
action meaning
current_score semantics

能不能使用全局相机

全局相机可以用于离线调试、录制俯视视频、生成标注和检查物体是否真实存在；它是否可以作为正式 policy 输入，要看比赛提交契约是否把该传感器放进允许的 observation 中。

如果官方提交接口只提供 proprio、height scan、头部 RGB-D 和末端 RGB-D，那么在 policy 中偷偷读取仿真世界坐标或额外全局相机，会产生两个问题：

1. 本地 rollout 可以成功，线上提交却拿不到同名字段；
2. 训练 observation 维度与部署 observation 维度不一致，导出的 policy 无法加载或行为失真。

推荐做法是把全局相机分成两个用途：

• 允许用途：viewer、录像、离线评估、调试目标生成和检查场景布置；
• 正式输入：只使用官方 observation contract 明确提供的传感器。

1.4 相机与场景排查顺序

打开仿真后什么都看不到时，按下面顺序排查：

1. 确认加载的是 Task A、Task B 还是 Task D，而不是只看文件夹名称。
2. 确认 viewer camera 是否跟随机器人，或者是否仍停留在世界原点。
3. 确认仿真是否 headless；headless 模式可能只有日志和视频输出，没有交互窗口。
4. 检查机器人初始位置和目标区域坐标，避免相机在目标区域之外。
5. 检查 RGB-D sensor 是否启用，以及 observation 中是否真的出现 image/depth key。
6. 用全局 viewer 或离线渲染确认物体确实生成，而不是把“没有看到”误判为“没有生成”。
7. 再检查物体材质、光照、相机 clipping range 和深度有效值。

1.5 动作维度必须以机器人构型为准

常见的动作契约如下：

Logic-TARS 的 Task D 实现采用 61D observation 和 16D locomotion action，再通过 adapter 得到官方 24D action。这种设计的核心是把底盘学习和官方提交接口解耦，而不是把维度硬凑出来。