Until Hitting the Ball: Seven Steps from Perception to Motor Current and the Time Budget

Status: Draft (2026-10-18), Measured. The numbers in this post were calculated directly on a single laptop (Apple M1 Max, macOS 26.5) using Python 3.9.6 and numpy 2.0.2. Times are the median of 7 runs, with the first run discarded as a warm-up. Raw data and code are in the working directory measure/robot-arm-basics/(m01_budget.py, m01b_fast.py, out/m01_budget.json). None of the values were measured on actual robot hardware (unmeasured on hardware). The initial ball states used DeepMind's public dataset (CC-BY 4.0), and table tennis specifications were verified against the original ITTF Statutes 2026. All reference materials were accessed on 2026-10-18. Writing convention: Measured data is the default, unmeasured items are marked as "[Unmeasured]", and unverified items as "[Unverified]".

Table of Contents

• 1. Intuition: Seven Things That Must Be Done Within 0.6 Seconds
• 2. Illustration: Seven Steps and Our Code's Calculation Time
• 3. Calculation: How Soon Does the Ball Arrive?
  • For Faster Balls
• 4. Breaking Down the Time Step by Step
• 5. Common Models and Constants of This Series
• 6. Limitations
• 7. Conclusion
• References

1. Intuition: Seven Things That Must Be Done Within 0.6 Seconds

A human already starts turning their body the moment the ball leaves the opponent's racket. They track the ball with their eyes, guess where it will bounce, pull their arm back, and swing. All of this happens in less than a second, mostly without conscious awareness.

A robot must solve this process calculation by calculation. This series divides that calculation into seven steps.

Part 10 compares what is solved via equations versus what is left to learning among these steps, along with table tennis robot papers.

This series is preparatory work to build an open-source hardware table tennis robot. Therefore, every single number is written to connect to "what parts should I buy." Examples include how many m/s the racket achieves given a certain joint speed limit (Part 5), how many cm the ball misses by if the racket angle is off by 1° (Part 7), and what breaks down if the control cycle is 200 Hz (Part 9).

2. Illustration: Seven Steps and Our Code's Calculation Time

• The numbers on the right are the calculation times measured in each part of this series. Since this is educational code written in pure Python and numpy, it can be significantly reduced on actual hardware, but how many times faster it becomes when ported to C++ was not measured (unmeasured).
• The two orange blocks (flight prediction, shot selection) are the heaviest. This is because both integrate the ball trajectory over thousands of steps. The remaining steps are in the microsecond range.
• The two numbers in the final step are not calculation times, but repetition frequencies. The 1000 Hz position loop is this series' simulation setting, and the 30 kHz current loop is the default switching frequency documented in the open-source motor controller moteus (moteus theory.md).

3. Calculation: How Soon Does the Ball Arrive?

The starting point of the time budget is the flight time of the ball. We prepared two things to measure it directly.

Initial state of the ball. Google DeepMind's public competitive_robot_table_tennis dataset contains 15,792 ball positions, velocities, and angular velocities immediatelyafter being hit by a human or robot (13,088 rallies, 2,704 serves). This data was used for training in the paper by D'Ambrosio et al. 2024 (arXiv:2408.03906) and is distributed under CC-BY 4.0. In the coordinate system, the center of the table top is the origin, x is width, y is length, and z is up. The entire series uses this same coordinate system. The robot stands on the y < 0 side.

Flight model. The equations of motion, covered in detail in Part 6, are integrated using RK4 at 1 ms intervals.

m · dv/dt = m·g  −  ½ ρ C_D A |v| v  +  ½ ρ A r C_M (ω × v)
            중력     항력(drag)          Magnus 힘
탁구대에 닿으면: 법선 속도에 반발 계수 e, 접선 방향은 쿨롱 마찰 μ

The code is short. It filters and launches only the balls coming toward the robot from the dataset, bounces them once on the robot's side of the table, and records the timestamps when they pass various "hitting planes".

incoming = [s for s in rallies + serves if s["vel_y"] < 0]      # 로봇(y<0) 쪽으로 오는 공 14,703개
for s in incoming:
    rec = fly(p, v, w, dt=1e-3, stop=lambda t, p, v, nb: p[1] < -2.2 or nb >= 2)
    # 첫 바운스가 로봇 쪽 탁구대 안이면 유효. 이후 y = -1.37, -1.6, -1.9 를 지나는 시각·높이·속력을 기록

The results are as follows: out of 14,703 balls, 11,590 landed properly on the robot's side of the table (the rest were nets or outs), and among those, 10,618 flew all the way to the end line (y = −1.37 m).

The calculation time took 130 seconds to run all 14,703 balls, which is about 9 ms per ball.

For Faster Balls

The balls in this dataset are not fast. The appendix of the same paper classifies balls over 7 m/s as "fast," while the 95th percentile in the table above is 7.6 m/s. As the skill level increases, balls become faster, so we calculated this separately. We simulated hitting a ball from 45 cm above the opponent's end line in the −y direction with speed v and top spin of 50 rad/s, and adjusted the vertical speeds using bisection so that it landed at y = −0.7 m on the robot's side (m01b_fast.py). All five cases clear the net.

Büchler et al. (2022) report that their pneumatic muscle robot hit balls at an average of about 12 m/s in smash tasks (arXiv:2006.05935 v1). To receive a ball of that speed, the budget is 0.32 seconds—half of the dataset median.

4. Breaking Down the Time Step by Step

Let's break down the 0.65 seconds by step. It is important to note that these do not happen sequentially, but overlap. While watching the ball, the arm is already moving into a ready position, and predictions are refined with every new incoming frame.

Two things are apparent from the table.

1. Calculation time is not the bottleneck. Even with educational Python, it is 25 ms. The bottlenecks are the fact that the prediction accuracy improves only when watching the ball long enough, and the latency accumulating in cameras, communication, and controllers. Google's system had an observation latency alone of 40 ms.
2. Viewing time and movement time trade off against each other. The longer you watch, the better the prediction, but the less time the arm has to move. Therefore, actual systems send the arm to a rough ready position even when predictions are crude, and adjust the target as predictions are refined (trajectory replanning in Part 8).

5. Common Models and Constants of This Series

All parts use the same constants. Values confirmed by opening the original texts and assumptions are distinguished and noted.

The coordinate system, mass, diameter, and table specifications match the MuJoCo table tennis simulator being developed in the same project. Since the simulator took the DeepMind dataset laptop's MJCF as its starting point, the ball states in this post can be directly plugged in to cross-verify results.

6. Limitations

• The flight model assumes spin does not decay during flight. Spin damping over a flight of around 0.5 seconds was not measured (unmeasured).
• The balls in the dataset are amateur-level rallies mixing humans and robots. Primary sources for professional-level ball speed distributions could not be accessed (unverified).
• The "time of crossing the end line" is merely a representative value of the time the robot can hit the ball. The actual hitting point depends on the robot's workspace and strategy. Koç et al. (2018) point out that a fixed virtual hitting plane unnecessarily restricts the trajectory, and they optimize the hitting time and hitting point together. This series simply sets the y = −1.6 m plane as the default hitting plane.
• The latency figures are taken from measurements of Google's system, and the latency of the hardware we will build is unmeasured.

7. Summary

• An opponent's shot arrives in front of the robot in 0.65 seconds based on the dataset median, or in 0.2 to 0.3 seconds for a fast shot.
• Calculations are fast. What eats up time are "watching long enough", "latency", and "moving the arm".
• Therefore, the first numbers to look at when choosing hardware are the camera frame rate, latency, and joint acceleration limits. Starting from the next part, we connect those numbers one by one into calculations.

Titi's Note. During the 0.6 seconds the ball is coming, the robot performs seven tasks. Calculations finish quickly, but the real dilemma is that the longer you watch the ball, the less time you have to move your arm!

References

All materials were accessed on October 18, 2026.

• ITTF, Statutes 2026, Chapter 2 The Laws of Table Tennis (2.1.1, 2.1.3, 2.2.3, 2.3.1, 2.3.2).
• Google DeepMind, competitive_robot_table_tennis initial ball state dataset, CC-BY 4.0.
• D'Ambrosio et al., Achieving Human Level Competitive Robot Table Tennis, arXiv:2408.03906(ICRA 2025).
• D'Ambrosio et al., Robotic Table Tennis: A Case Study into a High Speed Learning System, arXiv:2309.03315(RSS 2023), Table I.
• Büchler et al., Learning to Play Table Tennis From Scratch using Muscular Robots, arXiv:2006.05935 v1.
• Koç, Maeda, Peters, Online optimal trajectory generation for robot table tennis, Robotics and Autonomous Systems 105 (2018), Author's preprint.
• Nakashima et al., Modeling of Rebound Phenomenon of a Rigid Ball with Friction and Elastic Effects, ACC 2010, Institutional repository.
• Conti et al. (Sony AI), Physics Models for Sim-to-Real Transfer in Professional-Level Robot Table Tennis, arXiv:2606.28805, Table I.
• mjbots, moteus docs/reference/theory.md.