P3T – Personal TT Trainer

Device never made before, raise efficiency of table tennis training up to 100%.

If you are table tennis player, you know that you get better only if you are playing with player better than you are. The biggest problem for trainers is to distribute players evenly, so some time you play with better one, and some time you are that better training some rookie. Simple math shows that such context offers only 50% of the efficient training. Beside that, every player has something specific that needs to be improved: forehand/backhand strokes, blocks, spins, pushes, chops… and even you have player who is better than you, he/she might not be good enough to sparing you for a specific shot… which in further decreases the efficiency.

Goal

We set first goal to make device that can return some basic shots without spin. First milestone is set to three months, and up to then, we should get our minimal viable product.

Project start

We started the project on January, 12. For start, we bought the assembled robot arm from our favorite Aliexpress. There were some doubts about controlling technology (and still are) but we agreed to start with linux, PC and Arduino for driving the motors, and after we develop tracking, inverse kinematic and predicting  algorithms, we should downgrade to an embedded system.

Modules

Device is separated in several functional hardware/software entities, aka modules.

In short, system should recognize ball position in the space. Therefore we need two cameras sources, processed by openCV algorithms, or we need two Pixy devices. For easy start, we bought two Pixies. Those two xy positions streams, need to be processed to extract xyz position of ball. Then, using at least three points, Predictor algorithm should calculate position of hitting ball to table, and arriving point to the z0 surface of robot hand.

Architecture

At first look architecture of this project is straight forward. But when we were calculating a speed of the ball and how much recognitions of a ball we have to have to correctly predict the trajectory of the ball, there was one problem – a speed of our hardware. Which small embedded hardware will have this kind of speed? A solution of this problem currently we can’t predict so we had to create architecture that could one day end up on FPGA.
At this stage, we have task manager written in c++ and tasks. Every task can communicate with every task and plan is to port some tasks to PRU units or FPGU designs.

Prototype

And here is first “working” prototype. To be honest, we jump all modules except half of first (one xy stream) and last, the Arduino driver, and make this encouraging clip.

And of course, after successful ending of phase I (three month) we had celebration party in “?” restaurant.