logo Mr.Robota 具身智能学习手册 中文
Chapter 15: ATEC2026 Lightweight Code

3. Public Scheme and Logic-TARS Interpretation

As of July 31, 2026, there are official repositories, public forks, and player repositories on GitHub. However, no complete source code for the online competition champion/runner-up announced by ATEC has been found. The evaluations below are categorized based on whether the code exists, how closely it matches the task interface, and whether there is a complete closed loop for control. Self-reported results are not considered official results.

Repository Task Public Content Migration Decision
Logic-TARS/ATEC2026 Task D B2W + Piper; curriculum training; 61D/16D policy; 16D→24D adapter; state machine, LiDAR, heading correction, stuck recovery Preferred reference for Task D
ZSN2024/ATEC2026_Simulation_Challenge Task B B2wPiper Stage1 PPO, command scheduler, obs/action adapter, training/export/smoke commands Training framework for Task B
yma867/ATEC2026_Simulation_Challenge_RIL Task B YOLO, ByteTrack, RGB-D depth back projection, world coordinate output Perception reference for Task B
Lhy6900/ATEC2026_Simulation_Challenge G1 / GR00T whole-body adapter, blind locomotion, teleop Robot interfaces differ; cannot directly replace B2/B2W policies
StevenLiudw/Clear_ATEC2026_Simulation_Challenge Auxiliary for Task B locomotion smoke test, ACT/RL demo Suitable for baseline comparison

3.2 Why Logic-TARS is the Most Worth Watching

The README for Logic-TARS reports a ranking of 32/100. This number should only be used as an official description by the repository author, not as an official performance proof; what is truly valuable for migration is that it separates the training interface, deployment interface, and high-level control logic.

Training and Deployment Interfaces

Its core contract can be abstracted as:

textpolicy observation: 61D
policy action:      16D = 12D leg + 4D wheel
official action:    24D = 12D leg + 4D wheel + 8D Piper arm

This indicates that the arm movements are not arbitrarily ignored by the policy, but are explicitly fixed or set to zero in the deployment adapter. This approach allows the locomotion policy to inherit the existing chassis capabilities while meeting the official submission interface requirements.

Course Training

The public script shows a progressive route:

textflat locomotion
  -> rough straight walking
  -> rough omni B2W
  -> Task D fine-tuning
  -> export
  -> official submission adapter

This path can serve as a reference for training organization, but the checkpoint cannot be directly copied. Isaac Sim, robot assets, joint default values, and random seeds on different machines will affect the policy behavior.

Task D High-Level State Machine

The submission entry includes the following stages:

textapproach box
  -> push box
  -> navigate platform
  -> climb finish

During phase switching, it also takes into account the current score, box LiDAR detection, distance, bearing, and robot progress. Compared to a single speed command, the state machine can more easily identify which segment each “walking failure”, “contact failure”, and “platform failure” occurs in.

Task information for 61D observation

The public code adds task information after basic locomotion observations, including:

  • Normalize the current score;
  • Score phase is one-hot;
  • Whether the box is seen by LiDAR;
  • Box bearing;
  • Normalized value of the box distance.

The key to this design is to send both “which section of the task has been completed” and “where the box is now” into the policy, rather than only providing the status of the robot itself.

3.3 Parts That Can Be Moved

High Priority

  1. Action adaptation contract from 16D to 24D;
  2. Score-aware phase switching;
  3. Minimum detection interface for LiDAR box bearing/distance;
  4. Heading lock and speed correction;
  5. Stuck recovery when the score does not increase over a long period;
  6. Training sequence from flat to rough, then to fine-tuning for Task D.

Need to be confirmed again

  1. Which version of B2Piper or B2wPiper is used in our current branch?
  2. The exact order of each dimension of 61D with the local observation.
  3. The scale, symbols, and order of the four wheels for wheel action.
  4. Whether zeroing out is still allowed for Piper 8D fixed actions in the current official version.
  5. Whether the score threshold matches the current official scorer.
  6. The number of LiDAR rays, angle range, and height filtering parameters.
  7. Whether external checkpoints are available, as well as their licenses and official asset dependencies.

3.4 Parts That Cannot Be Directly Moved

  • Do not directly copy submission/solution.py into B2Piper;
  • Do not treat the box state machine of Task D as the garbage grasping controller of Task B;
  • Do not assume that global cameras or simulation world coordinates are available in the official submission;
  • Do not present the self-report 32/100 as the official ranking of Datawhale;
  • Do not package the source code repository lacking checkpoint as a ready-to-use high-score solution.

3.5 Fixed Version for External Repositories

The external list of solutions for this tutorial is fixed in the following public commit, so it can be reviewed after future code changes:

Repository Commit License
Logic-TARS/ATEC2026 b78c4afd1b84302fe8f88bcfd287eac64c33692c MIT
ZSN2024/ATEC2026_Simulation_Challenge ee4e0eb97928754d9404a3acd5d644020ac7794c MIT
yma867/ATEC2026_Simulation_Challenge_RIL e56a2a9e39c5231a91c0a8b1cce8ab1bc0e72403 MIT

Get the fixed version:

bashbash code/external_repo_audit/clone_references.sh

The script only clones the public source code; it does not download model weights or simulation caches. The external code still belongs to its original author, and its license and upstream links should be retained when used.