3. Public Scheme and Logic-TARS Interpretation
3.1 Conclusion of Public Solution Search
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
- Action adaptation contract from 16D to 24D;
- Score-aware phase switching;
- Minimum detection interface for LiDAR box bearing/distance;
- Heading lock and speed correction;
- Stuck recovery when the score does not increase over a long period;
- Training sequence from flat to rough, then to fine-tuning for Task D.
Need to be confirmed again
- Which version of B2Piper or B2wPiper is used in our current branch?
- The exact order of each dimension of 61D with the local observation.
- The scale, symbols, and order of the four wheels for wheel action.
- Whether zeroing out is still allowed for Piper 8D fixed actions in the current official version.
- Whether the score threshold matches the current official scorer.
- The number of LiDAR rays, angle range, and height filtering parameters.
- 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.pyinto 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/100as 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.