2. List of Competition Issues and Solutions

This list organizes the typical issues we encounter during understanding, debugging, and deployment into reusable troubleshooting paths.

2.1 Mistaking Task B for “just picking up trash”

** Phenomenon**: Initially, the task is understood as finding the coordinates of an object, and then navigation is performed to the target point.

Root cause: The navigation sub-problem was treated as a task closed loop, without distinguishing between “discovering target,” “approaching target,” “grasping success,” and “placement success.”

Solution: Use an explicit phase state machine: SEARCH -> LOCALIZE -> APPROACH -> REACH -> CLOSE -> LIFT_VERIFY -> CARRY -> PLACE_VERIFY. Each phase records input, actions, exit conditions, and failure reasons.

2.2 Assuming that there are globally accessible coordinates in the simulation that can be directly read

** Phenomenon**: Use the pose, list, or true value coordinates of objects in the environment to guide navigation.

Root cause: These states may indeed exist within the simulation program, but they are not equivalent to the observations available for use in a formal policy.

Solution: Split the truth value information into two pipelines:

• debug_only: Allows output of true value distance, object height, and gripper status, which is used for fault identification.
• policy_input: Only allows images, depth, LiDAR, and proprioception from official observations.

Any field that enters the policy is registered in [[configs/observation_contract.yaml](…/…/…/…/…/15-Challenge competition/ATEC2026/TaskB-B2Piper/configs/observation_contract.yaml). During formal testing, the true value reading is disabled, and the masked observation is used for interface checks.

2.3 After adding the environment camera, the results become clearer

** Phenomenon**: From a third-party perspective, the entire scene can be seen, which helps determine whether the robot is off track.

Root cause: The environment camera is a visualization tool, not an official robot sensor. Adding it to observation will change the task boundaries.

Solution: Keep the environmental camera as the third track for local debugging videos. Do not register it in the policy observation, do not write its images into training data, and do not use it to generate runtime target coordinates. For detailed boundaries, see Environmental Camera and Debugging View .

2.4 The score is very high after approaching the target, but the object is not removed

** phenomenon**: The local distance, contact, or proximity to the agent metrics improve, and the robot in the video also touches the target; however, after restarting or moving to a trash can, the object does not move with the gripper.

Root cause: The contact agent score is not equal to grasping success. It may be due to the body, legs, gripper base, or ground contacting the object.

Solution: Add three independent confirmations:

1. After the gripper closes, the relative distance between the object and the end remains stable over a period of time.
2. When the lift end or base is raised, the object’s height increases synchronously, rather than staying on the ground.
3. After the robot exits the target area, the object continues to follow the gripper until the trash can is released.

The evaluation log retains the status of contact, clamping, lifting, and placement. It is prohibited to report only a distance score.

2.5 The robotic arm can perform movements, but its posture is unstable

Phenomenon: The leg movement is normal, but the robotic arm shows shaking, end offset, gripper sweeping over the target, or misalignment in motion dimensions.

Root cause: The joint order, action scaling, zero position, coordinate system, and end definition between different projects cannot be directly reused.

Solution: First, conduct an action interface audit, and then perform single-joint and end-point calibration:

• Read the order and range of the action space from the official environment.
• Apply small movements to each joint individually to verify the joint responses in the logs.
• Test the change in end position when the base remains stationary.
• Fix the legs, calibrate only the robotic arm and gripper, and then integrate full-body movements.
• Transform the target depth from camera coordinates to the robotic arm base coordinates, and record the external parameter version.

2.6 Misjudgment Policy After GPU or PhysX Errors

现象：When multiple simulation processes run concurrently, logs related to PhysX kernel, CUDA context, or early-state are generated; subsequently, this result is treated as a policy failure.

Root cause: Resource contention, residual processes, insufficient VRAM, and policy behaviors may occur simultaneously. The last few lines of logs alone cannot determine the cause.

Solution: Record the GPU, process, environment version, seed, runner, and output directory for each experiment. First perform a single-process smoke test, then increase the parallelism. When an error occurs, only handle the processes used in this experiment, without performing uniform cleanup. Count “environment startup failure” and “policy execution failure” separately.

2.7 Can External Projects Be Migrated Directly

Conclusion: Migrate the algorithm structure, not the implicit assumptions.

Can be referenced: visual search, 360-degree scanning, hierarchical navigation, end-effector lock, full-body IK, grasping state machine, result log.

Cannot be copied directly: robot URDF/USD, joint order, camera internal and external parameters, action dimensions, target categories, map coordinates, reward thresholds, and evaluator fields.

For each migration, a mapping table of “original project interface to Task B interface” must be created and verified through sensor boundary checks.