I see the point about moving to precisely the desired location but that is one of the strengths of such robotic arms - the machinery is very accurate.
Even 'cheap' 6-axis robots have repeatability measured in fractions of a millimetre. Granted, that precision is not independent of speed and acceleration so of course the faster the arm moves, the harder it is to achieve the desired precision but one might argue that an error margin of a centimetre or so would be within the acceptable range for such a purpose as table tennis. Given the base KR AGILUS model has a repeatability of 0.03mm, that 1cm is around 3000x more lax. Presumably this would allow the speed and acceleration to be increased by sacrificing some of the unnecessary precision.
The second part of your point, which is getting the manipulator (holding a paddle) to the calculated point exactly at the desired moment I see as slightly more of an issue. That said, the 'wrist' articulation should have enough torque and acceleration to effect a suitable shot from quite close range. That means that there is no need for all the joints to work in tandem for the hit and so the arm can be positioned ahead of time and simply the manipulator moved at the correct moment.
So, again, we come back to the sensors and software. From the above, the sensors and software will then need to ascertain the ball location, vector, speed and rotation and then calculate the end position, accounting for ball spin, drop and bounce.
Again, no small feat but one would argue that they must have this sussed because it's a non-starter otherwise. A robot is only as good as its software so if the goal is to play table tennis, calculating ball trajectory is a roll-a-six-to-start.
The next step is the part that interests me - how it determines the return shot. The programming could calculate all return trajectories possible from the end position, select the best one and then calculate the position the manipulator needs to be in to hit that shot. Alternately, it could calculate the quickest position to get into that will intercept the ball and then work out the range of available shots from there, which would be a subset of the full range above, given the arm/paddle position has already been chosen.
How it decides which of all those possible shots is the 'best' is another question! I will be interested to see if there are sensors to track the player's position (and, ideally, direction they are moving in) and if the software uses that to select the best shot, playing to the left if the opposing player is moving to the right, etc...
The way I see it, the engineering challenge is speed and acceleration, not precision and the software challenge is shot selection. It will be interesting from both points of view!
Biting the hand that feeds IT
