1. Competition Definition and Observation Boundaries
1.1 What is the task
Task B is the Garbage Collection task of the ATEC2026 Simulation Challenge. The robotic arm used is the Unitree B2 plus Piper robotic arm. The goal is not just navigation, but enabling the robot to find target objects in the scene, perform proximity and manipulation, and deliver the objects into the designated trash can.
The official repository is the only source of task definitions:
The task parameters, action dimensions, joint order, camera names, and runner in the official repository may change with different versions. The text in the tutorial is used to establish a reasoning framework; actual operation must follow the detected official version.
1.2 Legal Observations
The public task description shows that the main input for Task B includes:
- The state of the robot body and proprioception.
- External geometric observations such as LiDAR.
- Head RGB-D image, used for search and long-distance target positioning.
- End-effector RGB-D image, used for close-range alignment and manipulation.
Here, “external” refers to the sensors on the robot body, not a上帝 perspective camera that can see everything. Even if third-party cameras are added to the environment for debugging, they cannot be automatically treated as policy observations.
1.3 Ban Dependencies
The following information can only be used for local diagnosis or offline annotation, and cannot be used in formal policy input:
| Information | Reason |
|---|---|
| Simulation object true pose | Equivalent to directly reading the answer, bypassing the perception issue |
| Object list corresponding to random seed | Damages cross-scene generalization and may violate evaluation boundaries |
| Robot true pose or object ID | Not a sensor observable |
| Global environment camera image | If not in the official observation space, it is not a valid policy input |
grasped_objects and other states within the evaluator |
Can be used to verify success, but cannot be used as policy decision inputs |
During local debugging, these values can be output to the log to answer “why no capture”. They must be removed from observation, policy, rewards, and termination conditions before submission.
1.4 Why “using coordinates for navigation” is insufficient
The planar coordinates of a target can only determine “where the robot base should move.” It does not solve:
- Whether the target is correctly identified.
- Whether the projection of the target in the head camera and end camera is consistent.
- Whether the transformation of the robotic arm base, end, and gripper is calibrated.
- Whether the target is within the working space accessible by the gripper.
- Whether the object is actually lifted after the gripper closes.
- Whether the robot can carry the object to the trash can and release it.
- Whether the evaluator confirms successful placement, rather than just confirming that the robot passed near the target.
Therefore, the implementation should treat “coordinate navigation” as an intermediate stage, rather than the end point of the task.