1. Task Definition and Observation Boundaries

1.1 Align the task name first

The public simulation repository for ATEC2026 combines multiple capabilities within a single challenge framework. The most common mistake is to assume all tasks are garbage collection tasks just because of the presence of “robot dogs, objects, and cameras”. In actual operation, it is necessary to confirm the task ID, robot configuration, and scorer first.

Therefore, there are two possible reasons for “no garbage in the scene”: either Task D was loaded, or Task B was loaded but the current view or camera is not aligned with the target area. You cannot judge that a task failed based on a screenshot of a black screen or an empty scene.

1.2 Task B and Task D have different control structures

Garbage collection is a long-time loco-manipulation:

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

Pushing boxes over obstacles is closer to “locomotion with contact events”:

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

Both may use RGB-D and LiDAR, but the scoring events, action focus, and failure recovery are completely different. The walking policy in Task A cannot be directly transformed into the grasping controller in Task B; the push box state machine in Task D also cannot directly solve target recognition and garbage disposal.

1.3 Official Observation Boundaries

The official public repository’s observation organization for A/B/D mainly includes:

• The status of the robot body and joint states;
• LiDAR height scan or equivalent terrain height observation;
• Head RGB-D camera;
• End RGB-D camera;
• Commands, historical actions, or stage information required for the task.

Before officially migrating the code, you should check each item according to the current official environment registration, task configuration, and submission interface:

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

Can the global camera be used?

The global camera can be used for offline debugging, recording overhead videos, generating annotations, and checking whether objects exist. Whether it can be used as an input for a formal policy depends on whether the competition submission contract includes this sensor in the allowed observations.

If the official submission interface only provides proprio, height scan, head RGB-D, and tail RGB-D, then secretly reading simulation world coordinates or additional global cameras in the policy will cause two issues:

1. The local rollout can be successful, but no such field is available when submitting online;
2. The training observation dimension does not match the deployment observation dimension, resulting in the exported policy being unable to be loaded or with distorted behavior.

It is recommended to use the global camera for two purposes:

• Allowed uses: viewer, recording, offline evaluation, debugging target generation, and checking scene setup;
• Official inputs: Only use the sensors explicitly provided in the official observation contract.

1.4 Order of Camera and Scene Troubleshooting

When nothing appears after opening the simulation, check it in the following order:

1. Confirm whether the simulation is loading Task A, Task B, or Task D, rather than just checking the folder name.
2. Verify if the viewer camera follows the robot, or if it remains at the world origin.
3. Ensure that the simulation is in headless mode; in headless mode, there may be only log and video outputs, without an interactive window.
4. Check the initial position of the robot and the coordinates of the target area to avoid the camera being outside the target area.
5. Check if the RGB-D sensor is enabled, and whether the image/depth key actually appears in the observation.
6. Use the global viewer or offline rendering to confirm that the object is generated, rather than misinterpreting “not seen” as “not generated”.
7. Further examine the object material, lighting, camera clipping range, and depth valid values.

1.5 The action dimension must be based on the robot configuration

Common action contracts are as follows:

The Task D implementation of Logic-TARS uses 61D observation and 16D locomotion actions, and then an adapter is used to obtain the official 24D action. The core of this design is to decouple the chassis learning from the official submission interface, rather than forcing the dimensions into place manually.