ATEC2026 Track 2 L0 Desktop Organization Task E Post-race Review

This article outlines the complete competition process for Track 2 L0 «Desktop Organization» Task E of the ATEC2026 online competition. The task requires the Piper robotic arm to identify three randomly placed objects, grasp them, and place them in the designated basket area. Our final online score was 15.00, which is not a perfect score; the value of this open-source directory lies in reviewing the real engineering path, preserving the submitable code skeleton and failure evidence, so that future participants can avoid repeating the same mistakes.

Task Objectives

The core process of Task E is:

text视觉感知 -> 目标识别/定位 -> 运动规划或策略输出 -> 抓取 -> 运输 -> 篮筐释放

Online submission is done by uploading the source code as a file. The submission package we ultimately protect comes from the ACT seed1 best_loss branch:

textcode/act_seed1_best_submission/
  solution.py
  act/detr/*.py
  requirements.txt
  run.sh
  server.py
  UPLOAD_README.md

Note: policy_act.pt has not been uploaded to GitHub. It needs to be downloaded from a local package or Hugging Face model repository and placed in the same directory.

HF Reproduction Resource Entry

The local ATEC simulation copy has been cleaned up, and the large files required for reproduction are uniformly obtained from Hugging Face:

• Final model weight: Datawhale/atec2026-task-e-act-seed1-best
• Complete Task E reproduction repository: Datawhale/atec2026-task-e-reproducibility

The reproduction repository contains source/, scripts/, demo/, atec_robot_model/, third_party/GraspGen/, and code/task_e_collection/. The filtered HDF5 is located in the data/ shard directory, and can be restored using RESTORE_FILTERED_DATASET.sh in the repository root directory.

Final Score and Submission Package

Final protection package source: task_e_act_seed1_best_20260608_upload.zip in the Hugging Face model repository.

Key SHA256:

textpolicy_act.pt  282614de9673dc01e229557448e380b6a02c196b5c3953cec77b2aebd2305a8e
solution.py    a08790e7512c914e5b78132303e1c6098c8aba3b01a373933e6ddc617fa3a485

Routes We Have Tried

1. Official / scripted oracle data generation

The official Task E scripted oracle is more likely to succeed for object_3, but there are issues with grasping contact, Piper TCP, USD root/geometric center, and transport primitives for object_1 and object_2. Ultimately, we generated three object demonstration data using per-object primitive and closed loop servo:

textdatasets/atec_task_e_obj321_servo_100demos

This set of data supports ACT training, but it is not a set of rules that can be directly converted into a perfect planning controller.

2. ACT / XSA-ACT

ACT is the most usable submission route in the end. Key corrections include:

• Correct the semantics of Task E action: The action is (joint_target - default_joint_pos) / 0.5, not speed or a simple delta.
• solution_act.py supports automatic loading of model_args from the checkpoint.
• The XSA attention modification can be used as a ACT variant, but the online results are unstable.
• The correlation between training loss and task success rate is weak; it must be measured using a specific seed.

Online trial rankings show:

Therefore, the directory protects ACT seed1 best, rather than the single seed that once achieved a full score in seed2 checkpoint.

3. GraspNet / AnyGrasp / SAM3 / GraspGen-style PCA

We have grasped and verified various planning grasping routes:

• TunTunClaw / GraspNet;
• AnyGrasp SDK;
• SAM3 image segmentation;
• GraspGen-style PCA/AABB geometric grasping;
• basket-center release;
• pre-grasp approach / guarded insertion;
• object_1 block “inclusion and closure” action;
• object_3 banana low cradle/servo handling.

These routes demonstrate that “perceptual and candidate grasping poses” are not completely infeasible, and object_1 / object_3 can be夹 between several seeds. However, the submit-style demo/solution_pca.py still exhibits instability in IK, finger-center tracking, contact retention, and transport release, and cannot replace ACT for final submission.

Important lesson:

textAnyGrasp / GraspNet 不是一键满分控制器；
它只能给 grasp pose prior，后面仍需要 Piper IK、TCP 标定、夹爪接触保持和篮筐释放 primitive。

4. pi0.5 / OpenPI

Our system has tried pi0.5/OpenPI:

• fixed-base 16D padding old branch;
• native8 state/action branch;
• 20-demo / 100-demo;
• LoRA;
• pi05_base;
• raw unfiltered + absolute target action;
• action expert / action head branch;
• zero noise / chunk execution steps tuning.

None of the results exceeded ACT. Multiple branches with seed 11/12/13 were 0/0/0 or got extremely low scores. Post-competition analysis shows that pi0.5 is not due to “weakness in the model itself”, but rather the current data representation and phase modeling are not suitable for this Task E trajectory:

• Filtering data removes a large number of hold/stable frames, disrupting the temporal semantics of action chunks;
• The binding between single-camera/task prompts and actual grasping phases is weak;
• The feed-forward policy lacks continuous phases near the home/high-observation regions, resulting in jittering of actions between the home and mid-trajectory;
• Even if the raw absolute target 1-demo overfits, the Isaac rollout still fails to achieve effective pick/place.

Therefore, pi0.5 is not currently a candidate for submission.

Contents of this directory

textL0-桌面整理TaskE/
  README.md
  code/act_seed1_best_submission/
    UPLOAD_README.md
    solution.py
    requirements.txt
    run.sh
    server.py
    act/detr/*.py
  docs/
    ATEC2026_TaskE_规则物理配置与提交说明_20260604.md
    WORKSPACE_MEMORY_TaskE_完整调试记录.md
  hf_model_package/
    README.md
    policy_act.sha256
    task_e_act_seed1_best_20260608_upload.zip.sha256

docs/WORKSPACE_MEMORY_TaskE_完整调试记录.md is a complete working memory, containing numerous intermediate failure paths, video paths, checkpoint paths, and troubleshooting conclusions. It is long, but it is very important for post-mortem analysis.

How to reproduce the submission package

Place policy_act.pt in:

textL0-桌面整理TaskE/code/act_seed1_best_submission/policy_act.pt

Then, maintain the following structure when uploading the source code:

textsolution.py
policy_act.pt
act/detr/backbone.py
act/detr/detr_vae.py
act/detr/position_encoding.py
act/detr/transformer.py
act/detr/utils.py
requirements.txt

If the platform uploads according to the service directory, you can also include:

textserver.py
run.sh

Why not just put policy_act.pt into GitHub

policy_act.pt is approximately 64 MB. Although it is below the hard limit for a single file on GitHub, the binary size is not suitable to be included in the tutorial repository history. Recommended approach:

1. Store code, README, SHA256, and commit descriptions on GitHub;
2. Store weights and a complete commit compression package on Hugging Face;
3. Maintain the HF link and verification value in the README.

Hugging Face Link

The weights and the complete submission zip file have been uploaded to Datawhale Hugging Face:

texthttps://huggingface.co/Datawhale/atec2026-task-e-act-seed1-best

Corresponding upload commit:

texthttps://huggingface.co/Datawhale/atec2026-task-e-act-seed1-best/commit/4583bda9e3118e75987a0f91de62c155a70a2bed

Upload commands, file lists, and SHA256 values can be found in hf_model_package/README.md.

Use a separate dataset and logs in a Hugging Face Dataset repository for reproduction:

texthttps://huggingface.co/datasets/Datawhale/atec2026-task-e-reproducibility

Upload status: 2026-07-19. Remote verification is completed. 337 out of 337 fragments are complete; README.md, recovery scripts, SHA256 list, and log archives are all in the repository.

Among them, trajectory_filtered.hdf5 is approximately 33 GiB, which represents the training data after filtering by ACT for 100 three-object 3,2,1 calibrated-servo demonstrations. To improve the stability of web and CLI transmission, the file is divided into 337 100 MiB fragments:

textdata/final_100demos_filtered_split_100m/trajectory_filtered.hdf5.part-0000
...
data/final_100demos_filtered_split_100m/trajectory_filtered.hdf5.part-0336

Recovery method:

bashbash RESTORE_FILTERED_DATASET.sh
sha256sum -c SHA256_FILTERED_ORIGINAL.txt

Original complete filtered HDF5 SHA256:

text4b85980e72b8e76261ad037bfba97b4795210e3f77cdb5b71479846b9230ac02

Can local content be safely deleted?

It can be deleted, but it is recommended to do so in order:

1. Verify that this directory has been pushed to GitHub;
2. Verify that Hugging Face has uploaded policy_act.pt, submitted the zip file, and reproduced the dataset slices and logs;
3. Verify that the model SHA256, slice SHA256, and filtered HDF5 SHA256 after restoration match correctly;
4. Keep this directory and docs/WORKSPACE_MEMORY_TaskE_完整调试记录.md;
5. Then delete the large training outputs, datasets, runs, logs/videos, and openpi checkpoints under $PROJECT_ROOT.

Do not delete the unique local policy_act.pt before confirming that the HF weight can be downloaded.