Can a Table Tennis Robot Be Made as Open Hardware: Rails, Swing Axis, Camera, and Licenses

Status: Draft (2026-10-18), calculations and research. Hardware has neither been purchased nor built yet. The figures in this post fall into three categories. Calculationsare values directly generated by our script (flight_window.py, axis_budget.py), taking the initial ball states from DeepMind's public dataset as input. The physics model uses a simplified model (drag, Magnus effect, impact bounds) rather than MuJoCo, and was run with two sets of coefficients (A: with Magnus, B: without) to express ranges. Researchvalues were confirmed by checking official vendors, papers, and repositories on 2026-10-18, and prices reflect what was listed on official vendors on that day. Estimatesare values that have a basis but could not be verified, and are labeled as such. Raw data can be found in the working directories tt-robot/hardware.md and tt-robot/hw/ .

Table of Contents

• 1. Intuition: The Waiting Axis and the Hitting Axis Have Different Jobs
• 2. Time Provided by the Ball: Events within 1 Second After the Opponent's Shot
• 3. The Positional Axis Can Be Slower Than Expected
• 4. The Hitting Axis: Why Low-Cost Open-Source Arms Are Slow
• 5. Structure: Belt Rails + Swing Axis
• 6. Why We Unified on moteus
• 7. The Eyes: Camera fps and Latency
• 8. Cost (Including Estimates)
• 9. Phase 1 Prototype Specifications
• 10. Licensing: Why We Do Not Attach an NC Clause
• 11. Limitations
• 12. Moving on to the Next Part
• References

1. Intuition: The Waiting Axis and the Hitting Axis Have Different Jobs

If we divide a table tennis player's body into two parts, it looks like this: the feet go early and waitat the spot where the ball will arrive, while the arm swings short and fast when the ball arrives. Even if the feet are slightly slow, leaving early ensures they aren't late. The arm needs high instantaneous speed, but the moving distance is short.

The same applies to robots. The positional axis, which covers the width of the table, needs to start early, while the swing axis, which generates racket speed, requires instantaneous acceleration. If a single arm tries to do both jobs, it becomes expensive and heavy. This post calculates in numbers how much cheaper and simpler it becomes when the two jobs are separated.

2. Time Provided by the Ball: Events within 1 Second After the Opponent's Shot

Out of the initial ball states in the DeepMind dataset (13,088 rallies and 2,704 serves), 14,703 balls heading toward the robot side were simulated using simplified physics. Balls bouncing once on the robot's side of the table numbered 11,723 for coefficient A and 10,431 for coefficient B (serves mostly move fast because their first bounce is on the opponent's side).

Balls arrive slower than expected because bounces and air resistance reduce their speed. On the other hand, since there are many short balls, moving the hitting surface further back reduces the number of balls that can be hit before the second bounce.

3. The Positional Axis Can Be Slower Than Expected

For each ball, it was assumed that the robot starts from the home position (x = 0, height 0.25 m), moves only after the "decision time," and follows a trapezoidal velocity profile per axis. It was assumed that a hit is successful even if it misses slightly by the 7.5 cm radius of the racket. The decision time is the combined value of camera latency and prediction stabilization time.

(Ranges represent values for coefficients B and A. Based on 9,025 balls for A and 8,930 balls for B reaching the hitting surface at y = −1.6 m, counting a success only when both horizontal and height axes reach on time.)

Every time the decision is delayed by 0.1 s, the axis specifications required to maintain the same success rate increase significantly. At a 0.2 s decision time, half of the balls require the horizontal axis to produce only 3.7 m/s², whereas covering 95% required 14.4 m/s², with a corresponding maximum speed of 2.92 m/s (Coefficient A). Spending money to reduce camera latency is cheaper than upgrading the motors.

The figure below illustrates the same calculation run with 5 balls. Clicking the figure shows the carriages of both specifications departing at 0.2 s to reach the hitting point while the balls are in flight.

The 5 balls in the figure were selected from 600 sampled with seed 0 and simulated using the same simplified physics to ensure an even distribution of horizontal positions. For the two edge balls (horizontal positions −0.74 m and +0.90 m), the 1.5 m/s · 10 m/s² carriage arrived at 0.79 s and 0.90 s, lagging behind the balls (0.74 s and 0.81 s), whereas the 3 m/s · 40 m/s² carriage arrived at 0.50 s and 0.55 s. For visualization purposes, the calculation was ported to a standard library, and the arrival rates for the 600 samples (82.7%, 95.2%, and 99.2% at 0.2 s decision time) matched the original calculation within 1 percentage point. The figure plots the horizontal axis only.

4. The Hitting Axis: Why Low-Cost Open-Source Arms Are Slow

Viewed as a 1D collision along the racket normal direction, the exit velocity of the ball is v_out = e·v_in + (1+e)·v_r . Assuming an incoming ball median speed of 2.8 m/s and a racket restitution coefficient e of 0.6–0.85 (estimated), the required racket speed is as follows:

We targeted 1.5–4 m/s for returns and 5–7 m/s for smashes. Translating this into arm tip speeds reveals that low-cost arms fall short.

• SO-101: The no-load speed of the STS3215 servo is 45 rpm for the 12V version and 52 rpm for the 7.4V version. Converting this while factoring in the reach and racket, the upper limit for the racket tip is 2.6–3.0 m/s, dropping to about 1.7 m/s under load (estimated).
• PAROL6, AR4 (stepper-based arms): Less than 1 m/s (estimated). AR4 also features a restrictive license prohibiting resale.
• OpenArm 2.0: Sufficient according to specifications (approx. 7.9 m/s at rated speed, estimated), but costs $6,500 for dual arms, and a separate rail is still needed to cover the table width.

Conversely, if a single swing axis is built with a 0.30 m long arm, a racket speed of 1.5–7 m/s corresponds to an angular velocity of 5–23 rad/s (48–220 rpm). This is easily achievable by direct-driving a brushless motor or using a 1:4 reduction gear.

5. Structure: Belt Rails + Swing Axis

Since the phase-one swing arm traces an arc, timing alone allows it to simultaneously cover height (0.03–0.53 m above the table) and depth, while this axis also generates the racket speed. This is essentially leaving only "a single shoulder" from the DeepMind robot (6-axis industrial arm + 2-axis rail). The reason depth is prioritized with a secondary axis is due to the table in Section 2. Even just moving the hitting surface back by 23 cm reduced hittable balls by 7–13 percentage points.

Axis dimensions were also calculated (rotor inertia is estimated).

• Horizontal Axis: With a moving mass of 2 kg, 40 m/s² acceleration, and 20 N friction, the required force is 100 N, or about 110 N including rotor inertia. Using a 20T pulley (radius 15.9 mm) and a D6374 requires a torque of 1.75 Nm and about 32 A of current, which is 35% of the 4.96 Nm peak. For the same task, the mj5208 (1.7 Nm peak) falls short.
• Swing Axis: Assuming a racket and arm inertia of about 0.02 kg·m² (estimated), 4 Nm is required to reach 20 rad/s within 0.1 s. Adding a 1:4 reduction to the mj5208 yields a peak of 6.8 Nm.

6. Why We Unified on moteus

• Both hardware and firmware are fully open and continue to receive updates. At the time of research, the last push to the moteus repository was on 2026-09-27. ODrive closed its designs starting from v3.6, and Tinymovr from v3.1. If a similar situation happens, others would be unable to reproduce our design.
• All axes are tied together using a single CAN-FD bus. Safety settings such as position limits, current limits, and watchdogs are configured as a single system.
• SimpleFOC is great for low-current wrists and educational purposes, but it does not suit transverse-axis currents (30–50 A).

7. Eyes: Camera FPS and Latency

The camera currently used for the table tennis scoreboard feature runs at 30 fps. This is not enough for a robot's eyes.

• A 3 m/s ball moves 10 cm in a single frame, and an 8 m/s ball moves 27 cm.
• If a USB3 camera holds 3–4 frames in its buffer, it adds 100–133 ms of latency at 30 fps (according to the camera manufacturer's FAQ). This alone exceeds half of the 0.2 s decision budget. If those same 3–4 frames were at 200 fps, it would be 15–20 ms (calculated).
• To view the 3D position and rotation of the hit point, two or more synchronized cameras (stereo) are required. DeepMind used two 125 Hz cameras.

After phase 1, we recommend using two Basler dart cameras at 200–250 fps. We have not yet verified whether the two cameras can be synchronized via hardware trigger (unverified). The target total latency (from image capture to motor command) is set to 50 ms or less, with a hit time error of about ±10 ms (ball 3 m/s × 10 ms = 3 cm, smaller than the racket radius, estimated).

8. Cost (Including Estimates)

Switching to two low-cost USB2 cameras reduces costs by $350–450, and having a human throw by hand instead of using a launcher saves $500–900. For comparison, just the OpenArm dual arms cost $6,500.

9. Phase 1 Prototype Specifications

• Horizontal Rail 1-Axis: Stroke 1.7–1.8 m, 3 m/s, 30–40 m/s², moving mass under 2 kg
• Swing 1-Axis: Arm 0.25–0.30 m, racket tip max 5 m/s, rotation axis approx. 0.25–0.30 m above the table and above the edge line
• Eyes: Global shutter 200 fps or higher stereo, decision time 0.2 s or less
• Ball: Open-design launcher (AIMY) with speeds of 3–8 m/s, starting with light spin
• Pass Criteria: 80% or more contact and 50% or more successful returns to the opponent's side out of 100 shots per launcher setting. There is currently no basis for these target values. The results are listed alongside the return rate of research pneumatic arms (75–77%).
• Safety: When a 2 kg carriage moves at 3 m/s, its kinetic energy is 9 J. Since none of the investigated controllers advertise certified STO (Safe Torque Off), emergency stops are handled by an external circuit (mushroom button → DC contactor), while applying overlapping controller position, current, and speed limits along with a watchdog. Operators remain behind a protective mesh.

10. Licensing: Why We Do Not Use NC

Although TT Lab is a non-profit project, we do not attach non-commercial (NC) conditions to our published outputs. The Open Source Hardware Association (OSHWA) Definition 1.0 prohibits discrimination against fields of endeavor (Clause 8), stating that commercial use must not be blocked. Attaching NC disqualifies a project from being recognized as open hardware. The fact that "we are non-profit" simply means we are allowed to use other people's NC materials; it does not mean we should lock our own outputs behind NC.

We also comply with the obligations of materials we incorporate. The AIMY launcher's CAD and code are BSD-3 (retain copyright notices), AIMY rotational trajectory data is DL-DE-BY-2.0 (attribution), and DeepMind ball states are CC BY 4.0 (attribution). For public repositories without a license, we reference only the ideas without copying files.

Attribution of data used in this article. Calculations in Sections 2–3 used initial ball states (rallies.json, serves.json, © 2025 Google LLC) published in Google DeepMind's competitive_robot_table_tennis repository as inputs. This data is under CC BY 4.0, and the code in the same repository is under Apache-2.0. We filtered for balls coming toward the robot (vel_y < 0) and simulated them using simplified physics; the data itself is not redistributed, and only calculation results are included.

11. Limitations

• Sections 2–3 use simplified physics. Drag, Magnus force, table restitution, and friction are all assumptions, which is why coefficients were run in pairs and expressed as ranges. Part 2will be the time to re-verify these with MuJoCo measurements.
• The results focus mainly on rally balls excluding serves, and DeepMind data consists of shots hit by humans ranging from beginners to advanced players. Professional player smash distributions are not included.
• Racket restitution coefficients, motor rotor inertia, and rail/frame/power supply prices are estimates. Camera synchronization for two cameras, the actual cycle time of the CAN-FD multi-axis loop, and the actual latency from camera to motor have not been verified.

12. Moving to the Next Part

The next step is to build this configuration inside MuJoCo first. By attaching the rail and swing axis to the ball model, arm length, rotation axis height, and secondary axes (depth vs. height) will be determined via simulation. Basics such as robot arm coordinate systems and inverse kinematics are covered together in the "Table Tennis Robot Arm Basics" series (table of contents). The next article in the series, Part 4, temporarily leaves table tennis behind to discuss experiments flying a PX4 drone from a pod using the same approach.

TT Nibble: If your feet start early, they don't need to be fast, and if your arm swings shortly and quickly, that works too. If you divide the work among the robot parts like that, you can build it cheaper than a single expensive arm. But your eyes have to be fast!

References

All links were verified as accessible on 2026-10-18. One vendor page blocked automated access and could not be re-opened this time, so its price is the value from the research document of that same date.

• DeepMind Public Data: https://github.com/google-deepmind/competitive_robot_table_tennis(initial ball states CC BY 4.0, code Apache-2.0), Paper: https://arxiv.org/abs/2408.03906, https://arxiv.org/abs/2309.03315
• Pneumatic Muscle Arm (return rate and smash speed): https://arxiv.org/abs/2006.05935, PAMY2 Design: https://github.com/intelligent-soft-robots/pamy2
• Lightweight 5-DOF Arm: https://arxiv.org/abs/2505.01617
• AIMY Ball Launcher: https://arxiv.org/abs/2210.06048, CAD: https://github.com/intelligent-soft-robots/ball_launcher_hardware
• moteus: https://github.com/mjbots/moteus, https://mjbots.com/products/moteus-r4-11, https://mjbots.com/products/mj5208
• SO-101: https://github.com/TheRobotStudio/SO-ARM100, OpenArm 2.0 Motors: https://docs.openarm.dev/hardware/openarm-2.0/motor
• Camera: Basler daA720-520uc https://www.baslerweb.com/en-us/shop/daa720-520uc-cs-mount/(automated access blocked during re-verification), Camera Latency FAQ https://support.stereolabs.com/hc/en-us/articles/206918319-What-is-the-latency-of-the-ZED-camera
• Licenses: OSHWA Open Source Hardware Definition 1.0 https://www.oshwa.org/definition/, CERN-OHL v2 https://cern-ohl.web.cern.ch/, CC BY 4.0 https://creativecommons.org/licenses/by/4.0/