2. List of Competition Issues and Solutions

This list divides the issues into four columns: “phenomenon”, “real cause”, “solution method”, and “verification boundaries”. The purpose is to avoid treating a single successful case as a stable solution.

2.1 Task Understanding Issues

Phenomenon: Looking for trash all the time, but the scenarios involve pits, platforms, and boxes

Reason: The current task being executed is Task D. The core aspect of Task D’s scoring involves crossing obstacles and pushing boxes, not identifying, grasping, and placing trash.

Solution: First, record the task ID, robot ID, action dimension, and scoring event, then decide which set of code to use. Task B only proceeds to the garbage target, trash can, and deployment process.

Verify boundaries: Seeing only the boxes does not prove that the entire Task D is completed. It is also necessary to check the x position, overhanging, platform, endpoint, and score increment.

2.2 Perspective and “Nothing Visible” Issue

Phenomenon: The viewer is black, or there are no robots or targets on the screen

Reason: The common issue is not that the environment has no content, but rather headless mode, incorrect viewer camera position, disabled cameras, the robot being far from the camera, or starting a training entry that only outputs logs.

Solution:

text先用单环境播放
再打开 cameras / viewer
再保存一帧 RGB-D
再用全局 viewer 检查场景
最后才看 policy 行为

For formal submission, the global view for debugging and the cameras allowed by the policy should be separated. The global view is suitable for answering whether “the target is generated,” but it cannot automatically prove that it is allowed as a policy input.

2.3 Rating Issues

Phenomenon: The robot moved, but the score is only 2.0

Reason: Action execution and scoring events are not the same thing. The low score in Task D may only indicate that the robot has crossed the first x threshold, but it has not yet completed pushing boxes, moving platforms, or reaching the endpoint stage.

Solution: Save at each rollout:

current_score time series;
Robot root pose;
Box position and relative distance;
Phase status;
Video of the last 5 seconds when an error occurs.

It is not enough to just check “if the robot moved”, but also to see how the score increased after an event and why the next event did not trigger.

2.4 Issues with Observation Dimension and Action Dimension

Phenomenon: The policy can be trained, but there are shape errors or abnormal robot actions during submission.

Reason: The output dimension of the trained policy, the action dimension of the official submission interface, and the robot configuration are inconsistent. B2Piper and B2wPiper cannot be used interchangeably; 16D locomotion action cannot be directly used as 24D official action.

Solution: Add an explicit adapter at the deployment boundary, and perform a shape check before entering the simulation:

pythonassert action16.shape[-1] == 16
action24 = adapt_taskd_16d_to_official(action16)
assert action24.shape[-1] == 24

For a small reference implementation, see [[code/taskd_reference_adapter.py](…/…/…/…/…/…/15-Challenge competition/ATEC2026/code/taskd_reference_adapter.py). It only describes the interfaces and stage logic, and does not claim to replace the complete policy.

2.5 Box Push Contact Problem

Phenomenon: The robot approaches the box, but the box is tilted, lost, or stuck.

Reason: Providing only a forward speed command cannot handle yawing, surface changes, speed decay at the pit edge, and the box leaving the LiDAR view.

Solution: Break Task D into explicit states:

textapproach_box
push_box
nav_platform
climb_finish
recover

Each stage uses different maximum speed limits, heading locking, box distance thresholds, and exit conditions. LiDAR is used to estimate the box bearing/distance; scores are used to confirm whether the stage is truly completed; stuck recovery is used to retreat, turn, or move sideways when the score does not increase for a long time.

2.6 Training Issues

Phenomenon: Training reward increases, but official score does not rise

Reason: The training rewards may only be given for speed tracking, pose stability, or short-term contact, without covering official scoring events. The training curve cannot replace task success rate and video quality.

Solution: Establish a three-tier evaluation:

Unit level: Observe shape, action adapter, and model loading;
Rollout level: Single environment playback, stage switching, video, and score trace;
Benchmark level: Fixed seed, multiple runs, official scorer, or equivalent local scoring.

Only modify one variable at a time, and keep the best checkpoint and corresponding video. Do not automatically overwrite the known submitable version just because the training loss of the new checkpoint is lower.

2.7 Migration Issues for Public Solutions

Phenomenon: After copying `solution.py` from another repository, the program can start but behaves incorrectly.

Reason: Public repositories may use different robots, different environment names, different action scales, different camera parameters, and different scorers. The fact that the code can be imported only indicates that the syntax and dependencies are basically functional, but it does not ensure consistent control semantics.

Solution: Migrate in the following order:

text许可证和上游 commit
  -> 任务/机器人/动作维度
  -> observation key 和归一化
  -> action scale 和关节顺序
  -> 环境注册与 checkpoint
  -> 单元测试和 smoke rollout
  -> 多次评分比较

2.8 Task B: Disconnection between Perception and Manipulation

Phenomenon: YOLO can identify trash, but robots do not pick up or place it

Reason: The perception module only provides categories, bboxes, depths, and world coordinates; it does not automatically generate valid chassis trajectory, end pose, gripper state machine, or placement confirmation.

Solution: Fix the perception output into a clear interface, and then let the manipulation layer consume it:

textperception_output
  -> target / objects_remaining / obstacles / bin / robot
  -> approach controller
  -> grasp controller
  -> carry controller
  -> release verifier

The perception README for yma867 is an interface reference, but its solution.py is clearly a zero-action placeholder. Therefore, passing the visual test should not be mistaken for garbage collection completion.

2.9 Release Issues

Phenomenon: Want to directly submit all training directories and external repositories to GitHub

Reason: The training directory typically contains checkpoints, caches, videos, simulation assets, logs, private paths, and tokens. Direct submission can cause the repository to become cluttered, and it may also reveal credentials or violate third-party distribution boundaries.