A movement.
A shot.
A measured result.
How do you teach a humanoid to play soccer? We start with a smaller question: how can it learn to shoot at a goal?
The task takes place in a physics simulation. The robot has to coordinate its body, make contact with a ball and influence where the ball goes. A goal is an outcome to measure; the movements that produce it are what the policy must learn.
Shooting is the first stage of a broader research direction. Ball control, passing and decisions in game situations are future goals, not capabilities already established by this experiment.
This page describes the intended process for the new pipeline. The dashboard currently shows an earlier recorded experiment. A GPU training run, convergence and the new dashboard connection are not yet confirmed.
What actually learns?
A policy is the model that maps information available from the simulation to control actions for the body. Physics determines what happens when those actions are applied.
During training, simulated experience is used to update the policy’s weights. Those updates can change the behaviour produced by the same model architecture. A checkpoint is a saved version that can be tested or replayed later.
Playing a recording does not change those weights. Testing a saved model does not change them either. This distinction is why training, evaluation and replay are labelled separately.
A conceptual interaction cycle. The exact observations, actions, reward terms and update settings are defined by the trainer, not by this illustration.
Start with coordinated movement.
The first step is learning from reference movements. The aim is to establish coordinated control of the body before continuing with the ball-interaction task.
A shot depends on more than moving a foot. The rest of the body affects how contact happens. Reference movements give the learning process an initial movement structure to work from.
- What this step is for
- Learning to reproduce reference motion and coordinate control across the body.
- What it does not establish
- A convincing movement by itself does not demonstrate accurate shooting, reliable balance or the ability to play a soccer match.
The policy produced by this step is the starting point for subsequent shot training. Specific reference clips and trainer settings should be documented when the corresponding run is available.
Learn through ball interaction.
Training continues in the shooting task using the policy after motion learning. The robot acts in the simulated environment, the ball responds to contact, and the trainer collects experience for further policy updates.
The reward is the task’s training signal. Its exact definition belongs to the experiment configuration. It can reflect several aspects of behaviour, so a higher reward is not automatically a higher goal rate.
An episode is one simulation attempt. It can include a successful shot, a miss, missed contact or early termination. If no measurable shot occurred, that must not be silently converted into a goal or miss.
- Many attempts, one visible example
- A trainer can collect experience from multiple simulations. The episode shown to a visitor is only one observable attempt; the number of videos shown is not the total training volume.
- An update is not an attempt
- A training update changes the model. A checkpoint saves a version. An episode is a rollout of behaviour. These should not share one counter.
- No guaranteed improvement
- An updated policy may perform better, plateau or regress. That is why saved versions need separate evaluation.
Freeze a version. Test it fairly.
Evaluation runs a saved policy under defined conditions without updating its weights. It answers a narrower question: how did this version perform on this particular set of tests?
Select a checkpoint
Identify the saved version being tested. The newest candidate is not necessarily the active or best-performing version.
Define the test conditions
Keep goal width, starting conditions and the evaluation set explicit. Versions should be compared on matching conditions.
Repeat and measure
Report goals and total attempts alongside the goal rate. Include other measurements only when they were actually recorded.
Compare with a stated baseline
Explain which version is used for comparison. Keep training-validation checks separate from the held-out benchmark.
Success criteria matter. For example, counting a crossing inside the goal width is different from also checking ball height and the robot’s balance. The metric description must reflect the actual checking code.
For definitions specific to the earlier archive, read The recorded experiment. Those definitions should not be assumed to apply to a future run without verification.
A good shot is not a learning curve.
A highlight shows what happened once. Progress is a change in results across repeated, comparable evaluations.
On the archived fixed benchmark, checkpoint 000 records 10 goals from 32 attempts (31.25%). Checkpoint 010 records 5 from 32 (15.625%). This is one recorded comparison, not a prediction about future training.
The checkpoint 010 candidate was rejected by the archive’s promotion process. That decision uses separate training-validation data; it should not be attributed to the held-out benchmark.
Inspect the baseline measurements and checkpoint 010 manifest. A finite sample does not prove a general improvement or decline under all conditions.
- A newer checkpoint is not automatically better.
- A higher reward is not automatically better accuracy.
- Results at different goal widths are not one comparable accuracy measure.
- A scored goal does not automatically mean the robot stayed balanced.
- Simulation performance does not establish physical-hardware performance.
Know what you are watching.
| Mode | Meaning | Available now? |
|---|---|---|
| Replay | A recorded attempt from a saved checkpoint. No learning occurs during playback. | Yes, in the archive. |
| Saved training frame | The last recorded frame and its measurements from the archived run. | Yes, a static snapshot. |
| Live Training | A running session in which the trainer updates the policy. | Not connected. |
| Live Evaluation | A running test of a saved policy with fixed weights. | Not connected. |
The detailed body, position and recent-attempt panels currently belong to the saved training frame, not the playing checkpoint video. The archive has a replay for evaluation seed 1000; other attempts expose measurements without promising a video.
Use the dashboard to move between checkpoints, inspect individual measured attempts and compare recorded results. Read Understanding metrics for the meaning and limits of each measurement.
Open the recorded experiment ↗From the setup to observable training.
The training package is assembled. The next work is to validate the new training run and connect actual frames, events and measurements to the dashboard. Running successfully and converging are separate things to verify.
Until then, the status remains Training setup in progress. The earlier archive stays available, with its provenance and limitations visible.
Ball Control and Passing are planned research directions; Game Situations is a longer-term goal. We do not assign invented readiness percentages or launch dates.