Playing Table Tennis with a Humanoid Robot Upper Body: A Baseline Placing the Unitree G1 in a Simulator with Human Speed Limits

Status: Draft (2026-10-18), measured. All numbers in the screens and text are values from inside the simulator, and camera frame rate, latency, and noise are assumed values. The robot in this post moves using a classical, non-learned planner. Evaluation used the same 500 evaluation balls (seed 0) and the same three conditions as in Part 7 (true state, 120 Hz with 30 ms latency, and 120 Hz with 100 ms latency). Values in parentheses are half-widths of the 95% confidence intervals. The robot model is from MuJoCo Menagerie unitree_g1(Unitree official g1_29dof_rev_1_0, BSD-3-Clause), and the original files were not modified. Since joint speed limits were not present in the model, official Unitree URDF values were used. The video was rendered on 2026-10-18 as a temporary pod on a single mini PC node in a home lab Kubernetes cluster (CPU only, peak memory 1.55 GiB). The environment used MuJoCo 3.16.0, Python 3.12.15, numpy 2.5.4, Mesa 25.0.7 (OSMesa), and encoding was done with ffmpeg 9.0.2 (libx264).

Table of Contents

• 1. Why a Humanoid Shape?
• 2. Video Preview
  • 2.1 A Single Ball from the Side-Rear
  • 2.2 The Same Ball from Above
  • 2.3 Four Different Balls
• 3. Robot and Planner
  • 3.1 Human Limits
• 4. Results: 500 Evaluation Balls
  • 4.1 Failure Breakdown by Cause
• 5. How Fast Must the Left-Right Axis Be?
• 6. How Fast Can the Racket Be Swung?
• 7. Fast Execution on GPU
• 8. Next: Learning and Robot-to-Robot Matches
• Unmeasured and Limitations

1. Why a Humanoid Shape?

The robots in Parts 5 through 9 featured a 2-DOF gantry and a 2-DOF wrist attached to the edge of the table. This is the easiest shape for receiving balls. However, the next goal of this lab is to create stronger robots by making them play matches against each other, and for those matches to resemble human table tennis, the robots must also look human.

Therefore, we chose the upper body of the widely used humanoid robot Unitree G1. Instead of legs, we attached a single left-right sliding axis. This axis simulates a table tennis player's sidestepping movement toward the ball.

We added one more condition: the robot must not move faster than a human. Robot joints can be several times faster than human joints, but a robot that wins using such speeds is not a "robot playing like a human." We applied literature-based human upper limits to joint angular velocities, left-right travel speed, acceleration, and racket speed, using the smaller of the robot limit and the human limit.

2. Video Preview

2.1 A Single Ball from the Side-Rear

Flying from the opponent's baseline, the ball was intercepted at 0.789 s after the robot shifted 0.37 m via the left-right axis. The racket speed at the moment of impact was 1.27 m/s. The orange dots show the trajectory of the ball. The torso turns following the ball, and the elbow and wrist position the racket face.

2.2 The Same Ball from Above

From the top view, it is easy to see that the robot moves in advance to the position where the ball will arrive. This "moving in advance" is the behavior that makes the biggest difference in this post (Section 4).

2.3 Four Different Balls

We chained together a ball where the left-right axis moved significantly to the right (+), a ball that moved 0.82 m to the left (−), a center ball, and a short bouncing ball. All four balls were successfully returned. The balls were chosen from the first 80 successful ones in descending order of left-right axis movement, and the selection rules and results are saved to files by the rendering script.

3. Robot and Planner

The planner uses the same ball prediction and hit determination as the gantry, replacing only the final step with inverse kinematics for the 11 joints of the G1 (including the left-right axis). Re-planning was configured to start from the previous posture, which raised the true state success rate from 88.5% to 94.0% on training balls.

3.1 Human Limits

• The left-right travel speed upper limit is 2.2 m/s, and the acceleration upper limit is 10 m/s². We could not find measured sidestep values for able-bodied table tennis players. Therefore, the speed was estimated as half of the center-of-mass left-right speed range of paralympic table tennis athletes (4.35 m/s bi-directional), and the acceleration was borrowed from tennis measurements.
• The racket speed upper limit is 19.6 m/s. It was never triggered throughout the evaluation. The joint upper limits alone keep the racket below maximum human speeds.
• Upper limit values and sources were gathered into a single configuration file. The ratio of truncation due to limits is counted separately in the training logs.

4. Results: 500 Evaluation Balls

Three things are apparent.

1. The left-right axis makes the biggest difference. Removing the left-right axis increases "unreachable balls" from 4.6% to 23.8% in the true state and drops the success rate from 91.4% to 66.4%. No matter how long the arms are, they cannot cover the 1.525 m table width from a stationary position. This is the same reason humans sidestep.
2. The cost of human limits is smaller than expected. When comparing the same balls paired before and after limits, 2.0–8.2% of balls were missed in the default configuration. Locking the waist increases this to 7.6–14.4%, because the arms alone must swing fast.
3. High latency makes it weaker than the gantry. At 100 ms latency, the default configuration drops to 27.4%, half that of the same-structured gantry (53.6%). Among the 500 balls, 45.4% failed due to "timing and prediction" (63% of failures). The heavy torso and left-right axis fail to keep up with delayed plan updates. This is the first area to be addressed through learning.

4.1 Failure Breakdown by Cause

Default configuration, human limits applied, ratio out of 500 balls. Only one cause is counted per ball.

38% of failures at 30 ms camera latency were caused by "hitting human joint limits." These are cases where the robot must move faster than a human to catch up to a ball discovered late. Human players miss these balls as well.

5. How Fast Must the Left-Right Axis Be?

Faster was not necessarily better. When acceleration reached 40 m/s² (approx. 4 g), the torso shifted significantly, and arm joint torques could not withstand the reaction force (torque saturation occurred in 35% of control cycles). The human range (speed ≤ 2.2 m/s, acceleration ≤ 10 m/s²) of 1.5–2.0 m/s and 10 m/s² fell into the optimal range.

The mass moved by the axis is 38.5 kg, combining the entire G1, racket, and carriage (assumed 5 kg). Pushing at 10 m/s² theoretically requires 385 N, and measured values in the simulator were 468 N at the 95th percentile with a maximum of 520 N. Removing the legs and mounting only the upper body reduces the mass to 24.1 kg, lowering the required force to about 2/3.

6. How Fast Can the Racket Be Swung?

Maximum racket speed (planned hitting posture, face normal direction) calculated using joint speed limits alone. This upper limit does not account for the time required for torque to accelerate up to that speed.

The 1.5–4 m/s required to return the ball is achieved in almost all postures with the default configuration. The 5–7 m/s required for a smash is achieved in most postures only with the 7-DOF arm and waist-used configuration under human limits. However, the current planner's racket speed at the moment of impact is a central 1.06 m/s, which is essentially blocking and returning the ball. Hitting hard is left for learning.

7. Fast Execution on GPU

Training requires running numerous balls simultaneously, so we also ran the same scenario in MuJoCo Warp (GPU). Comparing against CPU MuJoCo for 0.5 s, even during large robot movements, the ball position difference was a median of 5 µm and the joint difference was a maximum of 1.1×10⁻⁵ rad.

This is about 1/4 of the gantry (6.57M), due to increased contact calculations from the many joints and heavy torso. Since this was measured only once, variance has not been verified.

8. Next: Learning and Robot-to-Robot Matches

• Learning. We prepared a hybrid reinforcement learning environment tailored for G1, similar to the one in Part 7. It consists of 68 observations and 8 actions (6 for the gantry, plus the target positions and arrival times for the left and right axes). Training will be run as a Kubernetes training job (Kubeflow TrainJob), and smoke tests are waiting for GPUs.
• Robot-to-robot matches. We added a side parameter to the environment to place robots on both sides of the table. For the match scores and rules, we plan to use the referee engine used by TT Lab's scoreboard. We will also measure whether robots that have grown stronger through self-play are robust against fixed evaluation balls to filter out overfitting where they are 'only strong in matches'.

Unmeasured Factors and Limitations

• There are no results yet for the trained policy. All success rates in this post are from the planner without training.
• The torque-speed curve of the motor was not included. The racket speed in Section 6 is an upper bound.
• We could not find data for human joint angular acceleration, side-stepping speed of non-disabled table tennis players, or table tennis reaction times, so we either omitted them or borrowed values from other sports.
• The pelvis was fixed in space. The problem of balancing while standing was not addressed.
• The penalty weights of the planner were determined by looking at the first 100 evaluation balls, so there may be a slight selection bias.