Learning to play soccer.
Starting with a shot.
impulselabs is a public research project working toward humanoid soccer in a physics simulation. Shooting at goal is our first stage.
We study how coordinated body movement and interaction with a ball can develop through simulated experience. The longer-term goal is to explore ball control, passing and decisions in game situations. These remain research directions, not established capabilities.
This documentation describes the planned training process and the recorded experiment currently available in the dashboard. It does not claim that the new training pipeline is running or converging.
Project status
The training package has been assembled. A GPU training run, convergence and connection of the new training process to the dashboard have not yet been confirmed.
The dashboard is an archive of an earlier custom experiment. Its completed run is separate from the new setup status. A finished archived run does not mean the new pipeline is live.
Recorded run details are available in the published feed.
How Stage 01 is structured
For a step-by-step introduction, read How it works.
Motion Learning
Learn to reproduce reference movements and coordinate control of the body.
Shot Training
Continue from the motion-trained policy with ball interaction. During training, simulated experience is used to update the policy.
Evaluation
Test saved versions under a defined set of conditions. Evaluation measures performance without changing the model weights.
These are steps within Shooting at Goal, not separate milestones in the soccer roadmap. Training can collect experience from multiple simulations; one displayed attempt does not represent the total amount of training.
The earlier custom experiment has its own update, validation and selection cycle, described below. Its results must not be presented as validation of the new process.
Using the dashboard
Open the dashboard, select a generation and inspect its replay and held-out evaluation results. A generation means a published checkpoint entry, not a new generation for every shot.
| View | What it means |
|---|---|
| Checkpoint replay | A saved simulation recording for the selected checkpoint. Playing it does not train a model. |
| Saved training frame | The final available frame and its measurements from the archived run. It is not a live stream. |
| Evaluation attempts | Measured outcomes from a fixed evaluation set. Select an attempt to inspect its seed and measurements. |
| Checkpoint history | Published versions, evaluation results, acceptance decisions and links to recorded manifests. |
In the supplied archive, the video corresponds to evaluation seed 1000. Other evaluation attempts have measurements but no promised video replay. The detailed body, position and recent-attempt panels describe the saved training frame; they are not synchronized telemetry for the replay video.
If connected in the future, Live Training would show a running training session and Live Evaluation would test a saved policy. Neither label should be used for this static archive.
How to read the numbers
- Goals / attempts and shot accuracy
- Accuracy is the number of goals divided by the number of evaluated attempts. Always read the numerator, denominator and test conditions together. A single successful shot does not demonstrate improvement.
- Mean reward
- The average task reward. It is a training signal, not another name for shooting accuracy. A reward improvement does not necessarily mean more goals.
- Goal-line error
- The archived evaluation reports distance from the goal centre at crossing and applies a penalty to a non-crossing. The reported mean therefore is not simply the average landing offset of successful shots.
- Ball speed
- The saved frame reports current simulated speed. An archived evaluation attempt reports peak speed as
max_ball_speed; these are different measurements. - Shot direction and centre offset
- Direction is relative to the goal line; 0° means perpendicular motion toward the goal. It does not alone imply a central hit. Offset describes the crossing position. Without a valid measurement, show missing data rather than an invented zero.
- Generation, iteration and attempt
- A published checkpoint, a policy update iteration and a simulation episode are separate entities. An accepted policy can remain older than the latest published candidate.
- Training counters
- Simulation steps, completed episodes and policy calls describe different work. The archive’s total episode counter includes training and both evaluation sets.
- Training diagnostics
- PPO loss, policy-change KL, weight-change L2 and optimizer steps describe the update process. They are not direct evidence of better shooting.
Compare versions on the same evaluation set and difficulty. Keep training-validation results, curriculum checks and held-out benchmark results separate. A goal and the robot’s balance are also separate outcomes.
The recorded experiment
The included archive is the completed run curriculum-live-001, containing checkpoint entries 000–010. It comes from an earlier custom trainer and is available for inspection, not as proof of the new pipeline.
According to the supplied experiment description, a goal is a crossing within the goal width; ball height and balance are not included in that criterion. Non-crossings receive a 3 m error penalty. The training code itself is not included in this website package, so these are documented archive definitions, not independently audited scoring guarantees.
- The independent held-out benchmark uses a fixed 0.4 m goal and 32 attempts per version.
- Training difficulty starts at a 2.0 m goal and narrows following stage checks. The rule requires at least 80% in two consecutive 32-shot checks.
- Candidate promotion uses a separate training-validation set. Acceptance does not guarantee improvement on held-out shots.
- The archive’s curriculum stage numbers are difficulty levels within that run. They are not the soccer roadmap stages.
Checkpoint 000 records 10 / 32 goals (31.25%) on the held-out benchmark. Checkpoint 010 records 5 / 32 (15.625%) and was rejected by the promotion process. The final feed still identifies checkpoint 000 as the active policy.
These figures describe one recorded experiment under its stated conditions. They do not establish a general trend or physical-robot performance. Inspect the baseline evaluation, checkpoint 010 evaluation and checkpoint 010 manifest.
Files and data
| File | Contents |
|---|---|
feed/latest.json | Run status, checkpoint history, counters, active policy and final heartbeat timestamp. |
manifest.json | Checkpoint metadata, evaluation summary, acceptance decision and source artifact hashes. |
evaluation.json | Held-out summary and per-attempt measurements. |
training.json | Recorded training results associated with the checkpoint. |
curriculum.json | Stage-check measurements at the recorded training goal width. |
replay.mp4 | The available recorded attempt. |
feed/live/state.json | A saved final training frame and its state. The path name does not make the snapshot live. |
Checkpoint files are under feed/runs/curriculum-live-001/gen-NNN/. Model weights are deliberately excluded from the shared archive. A hash for policy.onnx in a manifest refers to an artifact in the source experiment, not an available model download.
The impulselabs repository is the project link. This documentation does not assume installation commands or APIs that have not been supplied.
From an action to a game
Explore the full research roadmap for the focus and open questions of each direction.
- Stage 01 — Shooting at Goal Setup in progress
- Body coordination, ball contact, shot direction and measured outcomes.
- Ball Control Planned
- Receiving, carrying and maintaining control of the ball.
- Passing Planned
- Developing passes and interaction with a teammate.
- Game Situations Research direction
- Choosing actions in relation to the ball, teammates and opponents.
There are no promised release dates or invented completion percentages. The order and scope may change with research findings.
Frequently asked
Is this a real robot?
The experiment runs in physics simulation. The results do not establish performance on physical hardware.
Is the robot learning while I watch?
The current dashboard plays saved recordings or displays a saved frame. No trainer is connected. Evaluation and replay do not update a model.
Is impulselabs only about shooting?
Shooting is the first stage. The longer-term research goal is humanoid soccer, including ball control, passing and decisions in game situations.
Why can a newer checkpoint be worse?
Policy updates do not guarantee improvement. Repeated evaluation under consistent conditions is needed to compare versions.
Why are some attempts missing a replay?
The archive only includes a video for the recorded seed. Other attempts can be inspected through their measurements.
What happens when data is unavailable?
Before connection: Training setup in progress. No evaluation: Not evaluated yet. No recording: Replay unavailable. Future connection loss must retain the last event time without inventing new activity.
Sources and attribution
Project scope is based on the supplied project brief. Archive-specific descriptions come from the dashboard’s method notes, feed and checkpoint files.
The earlier experiment uses a pretrained TeleHuman / HumanoidSoccer policy, as identified in the supplied attribution. Its custom PPO trainer is not a reproduction of the original authors’ training method. The archived body is identified as a 29-joint Unitree G1 in MuJoCo. These names describe the source experiment and do not imply affiliation or endorsement.
The original CC BY-NC 4.0 license text and source attribution are retained. impulselabs integration changes include branding, navigation, presentation and explanatory documentation; archived measurements and recordings are preserved.