Classical Control Baseline for a Table Tennis Robot: See, Predict, Swing, and Count the Returns

Status: Draft (2026-10-18), empirical measurement. Camera frequency, noise, delay, and robot velocity/force limits are all assumed values. Measurements were taken on 2026-10-18 on the same temporary pod as Part 2 (mini PC node Intel Core Ultra 9 185H, upper limit 3 CPU cores, 3 GiB memory, no GPU, mujoco 3.16.0). Physics time step 0.5 ms, racket contact solref (−4e6, −34) (values determined in Section 7 of Part 2). For the balls, we used the first 100 of the 500 samples (seed 0) identical to Part 2 from DeepMind's publicly released initial states, and under the 100 ms delay and 30 Hz conditions, only the first 50 were run due to time constraints. Each value was run once per condition. The first three conditions took 1,573 s for 300 runs (3 processes). Raw data is in the working directory tt-robot/out/(three F1 tables and raw JSON per run) and tt-robot/logs/ .

Table of Contents

• 1. Intuition: The Floor Reinforcement Learning Must Clear
• 2. Robot: Gantry 2-Axis + Wrist 2-Axis
• 3. Pipeline: One Function per Step
• 4. Results
• 5. What Explains Failures
• 6. Limitations
• 7. Moving on to the Next Part
• References

1. Intuition: The Floor Reinforcement Learning Must Clear

When teaching a table tennis robot via reinforcement learning, we first need a definition of "good." The baseline in this post is a hand-coded classical controller. It sees the ball, predicts its flight path using physical equations, computes the hitting spot and racket angle, and sends the arm to that position. There is no learning involved. To know what reinforcement learning actually improves, we must first find out how many returns this baseline makes and where it fails.

2. Robot: Gantry 2-Axis + Wrist 2-Axis

This layout corresponds to the "rail 2-axis + wrist 2-axis" (stages 2 and 3) from the hardware plan in Part 3. Because the gantry lacks a depth (y) axis, the exact moment the reachable y of the racket meets the ball's y defines the hitting time.

3. Pipeline: One Function per Step

1. Ball state estimation. Assuming the camera only observes the ball's position (120 Hz, noise σ 3 mm, delay 30 ms), we fit position, velocity, and spin via least squares. Since spin is only visible through trajectory curvature, we include a term pulling it toward prior values.
2. Flight prediction. Gravity, drag, and Magnus forces are solved using RK4, and table bounces are handled via an impulse model. Coefficients are measured simulator values from Part 2.
3. Shot determination. The reflection velocity required to reach the target landing spot (center of opponent's court) is calculated via shooting methods, and the mirror law and impulse model determine the racket normal and swing velocity.
4. Inverse kinematics. The two wrist angles follow directly from the normal vector, and the gantry requires a single subtraction (code below).
5. Joint trajectory. Connects the current state to the hitting instant (position, velocity, zero acceleration) using a fifth-order polynomial. The pitch velocity at impact translates directly to the swing.
6. Joint control. Tracks trajectories using computed torque (PD + feedforward), clamped by force limits.
7. Replanning. Plans once 0.2 s before the bounce, and after the bounce, realigns trajectories every 50 ms using new observations.

def ik(c, n, rb):
    """원하는 라켓 면 중심 c 와 법선 n → 관절 [x, z, yaw, pitch]."""
    n = np.asarray(n, float) / np.linalg.norm(n)
    th = math.asin(max(-1.0, min(1.0, n[2])))      # pitch
    psi = math.atan2(-n[0], n[1])                   # yaw
    x = c[0] - rb.L * math.sin(th) * math.sin(psi)  # 갠트리는 손목 오프셋을 빼면 끝
    z = c[2] - rb.L * math.cos(th)
    y_res = c[1] - (rb.y_g - rb.L * math.sin(th) * math.cos(psi))   # 0 이어야 닿는다
    q = np.array([x, z, psi, th])
    ok = bool(np.all(q >= np.array(rb.lo)) and np.all(q <= np.array(rb.hi)))
    return q, y_res, ok

(Excerpted from TT Lab experiment code ttsim.py ; docstrings and comments have been shortened.)

Because the orthogonal gantry maps its two axes directly to the racket position, there are no singularities, multiple solutions, or numerical inverse kinematics. With a 6-axis arm, the same task would require numerical optimization and singularity avoidance. Rotating the pitch makes the velocity of the racket face center point precisely orthogonal to the face, cleanly separating "where to aim" (angle) from "how hard to hit" (pitch velocity).

4. Results

"Hit but failed" combines balls landing out-of-bounds and into the robot's own court. The 50 balls in the 100 ms delay condition are identical to the first 50 balls of the 100-ball set under the 30 ms condition, where the success rate for those 50 was also 60%.

5. What Explains Failures

• Control is not the bottleneck. Median racket tracking error was 0.05–0.08 cm, and hitting time error was around 2 ms. Torque limits were hit in only 2 runs each under the true state and 30 ms conditions, and trajectories exceeding velocity/acceleration limits in fifth-order polynomials numbered 0–6 out of 100, all occurring on the gantry axis.
• The largest failure factor is the workspace (20–30% planning failures). There were 12–19 cases of "outside joint limits" and 6–10 cases of "ball failing to reach a reachable y coordinate for the racket." A fixed plane 38 cm behind the endline cannot reach short or low balls. Limiting analysis to successfully planned balls yields return success rates of 77.5% for true state, 77.9% for the 30 ms condition, and 68.6% for literature coefficients. This aligns with Part 3's rationale for prioritizing a depth (y) axis in stage 2.
• Camera delay matters far more than noise. Increasing delay from 30 ms to 100 ms at 120 Hz dropped the success rate from 60% to 26%, and the median ball prediction error at impact grew from 3.8 cm to 9.7 cm. At 30 Hz with a 100 ms delay (assumed typical of scoreboard cameras), success plummeted to 2%. Because this experiment fixed the planning horizon at 0.2 s, waiting longer for observations tailored to 30 Hz might improve results slightly (estimated). This matches the conclusion in Part 3 that "spending money to reduce camera delay is more cost-effective than upgrading motors."
• Incorrect coefficients drop performance by 12 percentage points. When the simulator uses DeepMind parameters but the planner uses literature coefficients, the success rate drops from 60% to 48%, and balls landing in the robot's own court increase from 2 to 9. The Magnus force discrepancy observed in Part 2 (4.2x) directly caused these hitting failures. For real robots, tuning coefficients using our camera trajectories directly impacts success rates.
• Even with the true state, success is capped at 62%. Remaining failures stem from discrepancies between the planner's impulse model and MuJoCo contacts (resulting in a 1.9 cm prediction error even with the true state and 16 "hit but out-of-bounds" instances) and workspace limitations. We estimate that reinforcement learning can outperform this baseline precisely through this "model discrepancy" gap, as it learns directly from the simulator rather than analytical models.

6. Limitations

• Camera frequency, noise, delay, and robot velocity/force limits are assumed values. Our camera's actual delay distribution has not yet been measured (unverified).
• Ball sets ranged from 50 to 100 per condition, run once each. The sample size is too small to establish statistical confidence intervals for success rates.
• The racket is modeled as a frictional box, and effective friction measured under this setup at 45° incidence was 0.047. Since it has almost no spin generation capability, aiming and spin returns were not addressed.
• Because per-run trajectories (step-by-step positions of ball and racket) were not saved, side-by-side visualizations of successfully returned versus delay-missed balls could not be generated this time. Trajectories will be recorded in future measurements.

7. Moving on to the Next Part

Next, we will pit two reinforcement learning approaches (a hybrid learning only strike parameters, and a direct joint-target approach) against this baseline using the same ball samples, camera assumptions, and robot limits (Part 7). Before that, in Part 6, we will review the DeepMind robot's limitations from their original paper and analyze spin mechanics via simulation. We will also include failure-reason breakdowns to clearly show which failure modes reinforcement learning eliminates.

TT's Note. The arm moved precisely with a 0.7 mm error, yet missed four out of ten balls. The problem wasn't the arm—it was the position (workspace) and the eyes (delay). Please fix the vision system first!

References

All links were verified active as of 2026-10-18.

• DeepMind, Achieving Human Level Competitive Robot Table Tennis(ICRA 2025): https://arxiv.org/abs/2408.03906
• 公開初期のボール状態 (Public initial ball states): https://github.com/google-deepmind/competitive_robot_table_tennis(© 2025 Google LLC, CC BY 4.0. Data is not redistributed; only simulation results are presented.)
• TT3D: Table Tennis 3D Reconstruction(2025, Planner literature coefficients): https://arxiv.org/abs/2504.10035
• Sony AI, Physics Models for Sim-to-Real Transfer in Professional-Level Robot Table Tennis(2026, Comparison of racket rebound formulas): https://arxiv.org/abs/2606.28805
• MuJoCo: https://github.com/google-deepmind/mujoco
• Citation codes refer to TT Lab experiment code.