How Humanoid Robots Learn to Fight: Simulation to Combat Data

“Learning to fight” is not one machine-learning problem

A fighting humanoid must perform several different tasks:

• estimate its own body state;
• walk and change direction;
• locate and track an opponent;
• select a fighting action;
• execute strikes without losing balance;
• respond to contact and damage;
• recover after a fall;
• coordinate with another robot in a multi-machine format.

These tasks may use different methods. A punch can be based on a captured reference movement, a balance controller can be learned in simulation, and a higher-level policy can choose when to use the skill. Safety monitoring and low-level actuator control may remain separate.

It is therefore misleading to imagine one network watching fights and emerging as a complete boxer. A practical system is more likely to combine modular skills, state estimation, control and event-specific supervision.

For the real-time stabilization underneath these skills, see how humanoid robots balance. For the mechanical components involved, start with how humanoid robots fight.

Stage 1: Turn human movement into a usable reference

Motion capture provides precise examples of posture and movement. In a fighting context, it can record a guard, punch, kick, evasive step or recovery pattern performed by a person.

That reference has two potential roles:

1. Motion prior: it gives the robot a stylistic and kinematic target rather than asking an algorithm to discover a recognizable martial-arts movement from nothing.
2. Ground truth: accurately tracked motion can be used to measure what a physical robot actually did and compare it with the intended trajectory or simulated result.

A human demonstration is not directly executable on a humanoid. The robot has different segment masses, joint ranges, torque limits, contact geometry and balance constraints. Retargeting must adapt the movement to that body, and dynamics control must make it physically feasible.

In URKL, motion-capture company Dison describes itself as the event’s official designated motion-capture partner. At Shanghai, it reported collecting low-latency six-degree-of-freedom motion-truth data for post-event review, movement analysis and algorithm iteration. That is evidence of measurement and evaluation infrastructure—not proof that every T800 fight skill was learned directly from human capture.

Stage 2: Build skills in physics simulation

Simulation allows a robot policy to experience far more trials than would be practical on expensive hardware. A simulated humanoid can be pushed, tripped, rotated and reset thousands of times without requiring a repair team after each fall.

A typical training loop is:

1. initialize the robot and environment;
2. provide observations and a task;
3. let the controller choose an action;
4. step the physics simulation forward;
5. calculate a reward or compare the result with a reference;
6. update the policy or optimize the motion;
7. repeat across many environments.

Possible rewards might encourage maintaining a desired body state, following a reference movement, reaching a foot-placement target, recovering from a disturbance or minimizing damaging contact. Poorly designed rewards can produce strange behavior, so “the AI learned it” is not a quality guarantee.

Reinforcement learning and imitation are not the same

Reinforcement learning improves actions using rewards from interaction with an environment.

Imitation learning uses examples, such as recorded motion or a teacher controller, to guide the policy toward demonstrated behavior.

They can be combined. A human reference may make a kick look plausible, while reinforcement learning helps the robot preserve balance across variations of that kick. Model-based trajectory optimization can also be used without framing the entire process as machine learning.

Stage 3: Randomize the simulated world

A policy trained in one perfect simulation may fail as soon as the real floor, sensors or robot differs slightly from the model. Domain randomization addresses this by varying conditions during training.

Examples include:

• body mass and center-of-mass offsets;
• joint damping or actuator behavior;
• floor friction and restitution;
• sensor noise;
• control and observation delays;
• external pushes;
• initial body poses and velocities;
• terrain and contact geometry.

The goal is not to predict every real-world condition exactly. It is to prevent the policy from depending on one unrealistically precise model.

A 2024 Science Robotics study demonstrated this general approach for the Digit humanoid. Radosavovic and colleagues trained a locomotion controller with large-scale reinforcement learning in randomized simulated environments and deployed it zero-shot on real hardware. The robot handled varied indoor and outdoor conditions and external disturbances.

That result supports the feasibility of sim-to-real humanoid locomotion. It does not demonstrate URKL combat, and it should not be presented as EngineAI’s method.

Stage 4: Cross the sim-to-real gap

The sim-to-real gap is the difference between simulated and physical behavior. Contact is one of the largest problems: rigid-body simulators approximate friction, deformation, impacts and actuator response, while real hardware adds compliance, backlash, temperature effects and sensor imperfections.

A fighting robot amplifies those differences because its task deliberately includes collisions.

A careful transfer process can include:

• validating the policy in a second, higher-fidelity simulator;
• checking joint, torque, velocity and self-collision limits;
• testing at reduced speed or energy;
• using a safety gantry where appropriate;
• beginning with isolated movements before combined sequences;
• comparing real motion with reference tracking;
• gradually increasing variability and contact intensity.

Zero-shot transfer means deploying a policy to hardware without additional policy training on that hardware. It does not mean skipping safety validation or assuming every simulation skill will work.

Stage 5: Train and test on the real machine

Real-world testing answers questions simulation cannot fully settle:

• Does the actual foot slip at contact?
• Does the actuator deliver the expected response when hot?
• Does the shell flex or obstruct a joint?
• Does a sensor produce biased readings after impact?
• Does the battery voltage change during a burst?
• Can the robot repeat the action after visible wear?

Full-contact testing is expensive because every failure can damage hardware. Teams therefore have an incentive to use simulation for broad exploration and reserve real fights for validating the most promising behaviors.

Research on safe falling illustrates why failure itself needs to be engineered. The SafeFall research framework trained a fall predictor and protective policy, then tested them on a Unitree G1 to reduce impact damage. This was independent academic research on a different robot—not an EngineAI technology announcement. It shows how learned failure responses can become part of a broader training and safety pipeline.

Stage 6: Turn combat data into the next iteration

A live event produces examples that laboratory designers may not have anticipated: unusual opponent contact, damaged sensors, unexpected body orientations and failed transitions between skills.

Useful data can include:

| Data source | What it can reveal | |---|---| | IMU and joint logs | Body state, joint motion and control response before a failure | | External motion capture | Reference trajectories and multi-robot positions independent of onboard estimates | | Event video | Context for contacts, tactics, resets and visible damage | | Actuator telemetry | Saturation, temperature and load around difficult actions | | Battery data | Peak demand and energy cost of strikes and recoveries | | Inspection and repair records | Components that repeatedly fail under contact | | Policy or skill identifiers | Which behavior was active when an outcome occurred |

EngineAI cofounder Yao Qiyuan told Jiefang Daily that combat data helps identify weak points in joints and guide reinforcement and reliability work. Dison’s Shanghai account says its motion-truth data supports review, action analysis and algorithm iteration.

These statements document a feedback loop from the event back into development. They do not mean the robots autonomously updated their own policies in the ring. Post-event analysis, retraining, validation and controlled redeployment are separate steps.

What changed between Shenzhen and Shanghai?

The July Shenzhen opening and September Shanghai city tour show an expansion in public capabilities. Shanghai added a kip-up, curved footwork, a flying knee and a multi-robot finale. Yao also described a move from July’s semi-autonomous operation to September’s autonomous mode in comments reported by Jiefang Daily.

For the session results and a spectator-focused account of the event, see URKL News’ Shanghai report.

The visible sequence is consistent with iterative development:

1. establish baseline fighting and recovery;
2. collect real contact and failure data;
3. revise hardware and control;
4. validate new movement and coordination skills;
5. demonstrate them at the next event.

What remains unknown is the contribution of each training method to each new move. Public sources do not establish, for example, that the flying knee was learned by reinforcement learning, that the kip-up came directly from human motion capture, or that multi-robot coordination emerged from self-play. Those would be inventions without further documentation.

Multi-robot training adds another layer

Shanghai’s two-against-one finale requires more than giving three robots individual fight skills.

A coordinated system may need to:

• maintain separate identities for all machines;
• estimate relative positions;
• fuse or compare observations;
• avoid teammate collisions;
• allocate tactical roles;
• update those roles as positions change;
• handle occlusion and damaged sensors.

EngineAI’s Shanghai highlights describe distributed multi-robot perception, role allocation and real-time relative-position calculations. These are organizer claims about the deployed system. They do not disclose whether training used centralized simulation, decentralized policies, hand-designed coordination rules or a hybrid approach.

Simulating multiple humanoids also increases computational and contact complexity. Successful transfer to a live three-machine event is therefore an engineering result, but not one that reveals its own training recipe.

Self-play can teach tactics, but it is not enough

Self-play lets simulated agents train against versions of themselves or other policies. It can generate varied opponent behavior without recording every possible human matchup.

For humanoid combat, however, a tactically successful policy still has to obey physics and hardware constraints. A simulated agent might exploit unrealistic contact, unsafe joint motion or sensing that is unavailable on the real robot.

A useful self-play setup would need realistic observations, action limits, contact models and rewards that penalize damaging or non-transferable behavior. Real-world validation would remain necessary.

No public source reviewed here confirms that self-play produced URKL’s current tactics.

What a transparent training report would disclose

A rigorous account of a new fight skill would identify:

• the reference data used, if any;
• whether the method was model-based, learned or hybrid;
• the reward or optimization objective;
• the randomization and disturbance conditions;
• simulation success rates and evaluation protocols;
• hardware safety constraints;
• the number of physical trials and failures;
• performance across different starting states;
• human supervision during deployment;
• changes made after event data was reviewed.

Publishing these details would make it possible to distinguish a choreographed trajectory, a robust feedback-controlled skill and an autonomous tactical policy. All three can look similar in a short highlight clip.

The training loop is the real competitive asset

The central advantage is not access to one spectacular algorithm. It is a repeatable loop connecting examples, simulation, hardware validation, accurate event measurement and engineering revision.

Human motion can make action recognizable. Simulation can make exploration scalable. Randomization can improve robustness. Real combat can expose weak components and missing behaviors. External motion capture can provide a reference for analyzing what actually happened.

The T800’s published hardware specifications describe the body used in that process. Its balance-control loop explains why each new strike also requires a stability solution. The remaining training details should be treated as open questions until EngineAI publishes them.