What passed: a finite, independent single-return simulation test. Still to test: return-to-home recovery and continuous rallies. Build and purchases remain on hold.
420-ATTEMPT TESTLoading…
2,000-ATTEMPT TESTLoading…
THE TESTED DESIGN4 cameras · 1.6 m arm850 mm shoulder · 6.70 × 5.18 m robot's court
Each attempt starts at home. Automatic playback moves between separate tests; it does not demonstrate a continuous rally. After 500 ms of recorded braking, the robot pose is held while the calculated outgoing shuttle finishes its flight.
The recorded datasets use feather shuttle physics. Nylon has not been tested.
02 / SEE THE WHOLE SAMPLE
Where the robot went
Each point shows the chassis position at contact or closest approach. Success is shown by a circle; a failed attempt by a cross. Select a point to inspect its recorded replay.
Legal return× Failed attempt◇ Home (−3.00, 0.00) m
Select a point to open the replay.
Coordinates in metres: net x = 0; back line x = −6.70; sidelines y = ±2.59. Racket paths are projected onto the floor; use the oblique replay to inspect height.
Every feeder setting, equal scrutiny
The overall score includes every setting, including the weakest ones.
03 / CONNECT THE DRAWING TO THE TEST
The tested camera layout
Native SOLIDWORKS views
Ready pose · four low pan/tilt heads above fixed wheel structuresM04 · revised clearance stroke at 0.645 sM09 · executed arm and camera pose at 0.325 s
Why four low cameras?
Alternative viewpoints allow another pair to track when a head is blocked. Mounting on the fixed wheel structures removes the tall camera posts that crossed the arm’s path. Camera pivots are 0.50 m high; the pan and tilt motors move each head independently.
During a stroke, front cameras turn into a restricted rearward sector to avoid the arm. Rear cameras do much of the tracking. Four heads do not guarantee four simultaneous views.
Why move before certainty?
New delayed observations arrive while the chassis and arm are already moving. Every 10 ms, the controller updates its estimate and commands against a frozen library of 21 feeder settings. Motor torque, grip and actuator response are represented in MuJoCo.
This is a finite feeder controller, rather than a general AI that has learned to play a human. Practice and broader trajectory prediction are later stages.
THE EXPERIMENT’S BOUNDARIES
What the numbers mean
21 nominal feeds: one fresh complete run returned all 21 legally. Nominal camera-to-arm CAD clearance was checked at 7,115 poses every 5 ms, including braking, with zero recorded overlaps.
420 and 2,000: balanced repeats of the same 21 synthetic feather-feeder settings with ±2% launch-velocity variation, new camera noise, pose bias and frame dropouts. Every input was checked for legal net crossing and landing before testing.
90% threshold: an observed-count criterion, with a 95% Wilson interval reported separately. A batch score is conditional on its model and sampling assumptions.
Assumed vision: 80 Hz synchronised exposures, approximately 83° horizontal field of view, 20 ms acquisition delay plus 5 ms image-processing delay. Real lenses, electronics, target-computer throughput and calibration must establish these values.
Still open: whole-assembly collision/mass reconciliation, cables and drawings, structural FEA, safety, actual grip and shuttle calibration, continuous recovery, nylon and Phase 2 human-shot coverage. These tests do not release purchases.
The animation is a schematic drawn from recorded coordinates. The design gallery shows the actual native CAD. Display interpolation is for viewing; it does not replace the 1 ms dynamics integration or the saved 5 ms traces.
Research inspiration: published robot study, arXiv 2504.17771. Our 21 synthetic feeder settings are our own test definition; they do not reproduce the authors’ exact machine settings.
04 / A BETTER DESIGN STARTS WITH QUESTIONS
Teacher feedback
Help Agasthya decide what to test next.
The notes stay in this browser. Export them as a file to share manually; nothing is sent to a teacher or an online service.
Which model assumptions deserve a hands-on experiment?
What would make the camera and moving-arm tests more convincing?
Which failed setting should the next controller revision address?
How should independent feeds become continuous rallies?