INTP:
You ask about feasibility and yes a robot can be built to do many things. But you are constantly giving the impression that you severely underestimate the time and learning involved, and expect free constant hand holding along the way.
Maybe not what you want to hear or are capable of truly hearing, but this project is way too much for a self-proclaimed beginner. It's more than buying parts and sticking them together. That's likely the easiest part.
What he said; this being said, I still encourage you to give it a go. Just try doing it as cheap as possible. Spending time on it isn't a waste, since you'll learn a lot. Spending a lot of money would be.
I would consider myself an intermediate Java programmer and I do have some field experience with robotics. I do have a pretty extensive experience with a (simple) PCB design. I don't really know much about mechanical engineering...
But the thing is, if I were to attempt this project, I would estimate the time needed to no less than 3 months. However, my estimates regarding time required tend to be severly on the low side.
You don't, and can't see the problems that will arise as you try to complete the project. Allow me to elaborate:
First you'll need to code the pingpong ball detection. So you will fire up Processing, and you'll try to code something that scans the screen pixel by pixel and notes if the value differs from the previous one. You will be programatically moving random drawn shapes in the background and use this as your "video data". Soon you will find out the "fps" is around 0.1; so you will scratch your head and increase the distance between the pixels you're scanning. This will increase the speed a lot, but you will be thinking that this is a silly solution. Indeed, wouldn't it be better to make the movement detection in such a way, that it scans for the object in the area it's last seen it in and then move on from there? That would give you a big resolution for small movements, but you'll still be able to catch bigger ones, too! So you will implement that. Yes, but it'd be best to also take the direction the object has been moving in into account! So you add it, too. Whoops, but you've only been tracking one dot so far!! So you decide to add a second one. Your program breaks. You decide to fix it. Congratulations, now you can track multiple shapes on the screen! You decide to test this on real data. You run around with your camera phone, taking a video of the balls rolling on the ground. Then you spend 2 hours explaining that suspicious behavior to a cleaning lady who happened to be watching you the whole time.
Equipped with the test data, you decide to run your program on them. It all goes haywire. Turns out you didn't account for the camera image noise.
You use boxcar averaging to surpress the noise and... It works! woooohoo! You managed to track pingpong balls. Now... the tracked position seems jittery, so you decide to make a follower object, which tries to follow the estimated position of the ball on screen. But what's that? Whenever the balls accelerate, your tracker has a hard time keeping up. Puzzled, you go study a control theory to find out you need an integral regulator to track a ramp (or in general a regulator that can generate the input signal).
Once everything works, you go port it to Android. It takes you ages to figure out how to even read a pixel value from a camera; once you figure it out, you manage to port the whole stuff. However, it's not fast enough. Soooo you dig deep and try to solve everything on gpu chip of the phone and... go down the rabbithole.
But it all goes well! :3 Your phone can track the balls now. Now you need to send the data to your micro. After a while, you manage to get that to work. You fix the issue where when 2 balls go past each other, you are no longer sure which one is which;
Now you have to decide which one of the balls to go for! Well... the closest one? That one will be lowest on the screen. But... once the balls move, the closest one will be a different one. If you don't want the bot movement to be erratic, you'll need to fix this. Of course, you also want to target larger groups of pingpong balls! But... larger group is rather relative. But let's not go there.
Then you will be building the robot itself. You'll encounter many problems-such as your micro resetting once you start rollin,' as it's not getting enough current any more.
You will have issues with the motor stalling if you try to apply low duty cycle to it. This will sometimes happen and sometimes not. You will use a light based rotary encoder and a PID control loop to control the motor itself; you'll get to understand gray code.
And then there is still the mechanical engineering.
By the way, do you have a mechanical engineering background?